Hi all, im using the dialog module with db_cassandra backend.. I dont believe this issue is related to cassandra, but its worth mentioning anyways. so... I run kamailio, make calls, see dialogs in the DB.. and I Can use "kamctl mi dlg_list" and see that dialogs go away when I hangup a call.. When I query the DB Backend, I still see the queries, but they have a state of 5. I Initially thought this was a bug, but it seems dialogs in state 5 get cleaned up after a period. so I moved on. now , lets restart kamailio.. kamailio loads all dialogs on startup, after kamailio starts I call "kamctl mi dlg_list" again, and it shows all my dialogs from the DB. they DO show as "State 5" but for some reason, these dialogs appear to stick around for a long time, and the bigger issue it causes me is that my channel limiting ( using get_profile_size ) seems to consider these dialogs ( in state 5 ) as being active calls. Please someone point me in the right direction... :) what am I doing wrong ? ( or is this a bug somewhere ) Sincerely Jay

Hello, I pushed some patches to the master branch in order to remove the dialog

Then, the second patch is to not add dialogs in profiles when loading

Here are the links to the patches: -

-

Should be straightforward to cherry pick to 4.1 (even 4.0 I expect). If

I plan also to not add the dialogs in memory for state terminated, but

On the other hand, if the dialogs are not removed from db, might be an

Cheers, Daniel On 24/02/14 11:19, jay binks wrote: So poking round the code for the dialog module.... Im not sure what im missing here. get_profile_size dosnt care bout the state of a dialog... so you get ALL

( which is interesting if you want to use dialog module to enforce

So you go... OK... kamailio only expects to have "ACTIVE" dialogs in

lets assume that to be the case. but then in dlg_db_handler.c , load_dialog_info_from_db loads all

so all dialogs in the DB ( ones that didnt get deleted yet... but were

upon startup. what this means is... ( assume starting with empty DB ) I start kamailio, make some calls... they get synced to the DB. I end the calls, kamailio removes from dialogs module internal hash,

I kill kamailio ( or crash .. whatever ).... restart kamailio and it

and thinks they are still active calls. Im SURE Im missing something here, because it seems to be VERY common to

maybe not so much using cassandra db behind the scenes, but as of yet

if im wrong, please point me in the right direction. Jay On 24 February 2014 17:54, jay binks <jaybinks(a)gmail.com> wrote: > > Am I REALLY the only person who has ever run into this !? > > > On 19 February 2014 14:08, jay binks <jaybinks(a)gmail.com> wrote: >> >> Hi all, im using the dialog module with db_cassandra backend.. >> I dont believe this issue is related to cassandra, but its worth

>> >> so... I run kamailio, make calls, see dialogs in the DB.. >> and I Can use "kamctl mi dlg_list" and see that dialogs go away when I

>> >> When I query the DB Backend, I still see the queries, but they have a

>> I Initially thought this was a bug, but it seems dialogs in state 5

>> so I moved on. >> >> now , lets restart kamailio.. >> kamailio loads all dialogs on startup, after kamailio starts I call

>> but for some reason, these dialogs appear to stick around for a long

-- Sincerely Jay _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hi All, so Ive done what Carlos suggested and swapped out my dialog db to Mysql rather than cassandra. All worked 100% as you would expect. Right so the issue is db_cassandra . I started testing and going through the code. I found I had these lines, which was interesting & concerning. update_dialog_dbinfo_unsafe(): could not add another dialog to db I had been ignoring them, because the dialog was in the DB and I figured I would come back and figure that out later. but this seems to have been key to this whole thing. ends up that in dlg_db_handler.c dialog_dbf.insert was getting a 1 back from kamailio on the insert and a 0 back from mysql... WTF.. ok. so I trace into db_cassa_insert which calls db_cassa_modify .. around line 1210 I can see this .. CON_CASSA(_h)->con->batch_mutate(CFMap, oac::ConsistencyLevel::ONE); return 1; wrapped in a try / catch block.. seems db_cassandra wants to return 1 for success but kamailio ( or dialog module at least ) expects 0 for success . so I change that to be return 0, and re-test. everything works as expected, "could not add another dialog to db" stops coming up on my console, and dialogs are removed when calls hangup. seems this 1 thing is enough to screw dialogs in cassandra ( and who knows what else ). This is the reason for my email though, if we simply change that to 0, what else may break !?? however http://www.asipto.com/pub/kamailio-devel-guide/#c09f_insertclearly states that "0 if everything is OK" so this is clearly a bug that needs fixing. Can I get someone with more experience to test this for me and possibly apply the attached patch !? Jay On 25 February 2014 05:58, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: dialog from its associated profiles when it gets in terminated state. I encountered such issue (not that) recently, but I haven't gotten the time to get to it before. from database and the state is terminated (5). http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=edf61ac… http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9b88eb7… you test and all goes fine, I will backport -- here I had no time for real testing. destroy them at db load time. But this needs a bit of a review, to be sure that all necessary callbacks are executed. issue with the database driver (cassandra in this case, which is rather new module). Do you get any syslog errors from kamailio or database server? I expect that people would have reported such issue for other database engines so far. Still it might be an issue, just that was not noticed... ALL dialogs that are in the hash table. channel limits etc ) the hash table... kewl.. dialogs from the DB, regardless of state. in state 5 ) get re-created in kamailio but the sync to DB hasnt happened yet. re-loads all those dialogs to use dialogs for channel limiting.. ... Im still yet to find anything that makes me thing this is db_cassandra mis-behaving. mentioning anyways. I hangup a call.. state of 5. get cleaned up after a period. "kamctl mi dlg_list" again, and it shows all my dialogs from the DB. they DO show as "State 5" time, and the bigger issue it causes me is that my channel limiting ( using get_profile_size ) seems to consider these dialogs ( in state 5 ) as being active calls. -- Sincerely Jay

Just noticed the same thing in db_cassa_delete.. patch updated to fix both Jay On 5 March 2014 12:52, jay binks &lt;jaybinks(a)gmail.com <mailto:jaybinks@gmail.com>> wrote: Hi All, so Ive done what Carlos suggested and swapped out my dialog db to Mysql rather than cassandra. All worked 100% as you would expect. Right so the issue is db_cassandra . I started testing and going through the code. I found I had these lines, which was interesting & concerning. update_dialog_dbinfo_unsafe(): could not add another dialog to db I had been ignoring them, because the dialog was in the DB and I figured I would come back and figure that out later. but this seems to have been key to this whole thing. ends up that in dlg_db_handler.c dialog_dbf.insert was getting a 1 back from kamailio on the insert and a 0 back from mysql... WTF.. ok. so I trace into db_cassa_insert which calls db_cassa_modify .. around line 1210 I can see this .. CON_CASSA(_h)->con->batch_mutate(CFMap, oac::ConsistencyLevel::ONE); return 1; wrapped in a try / catch block.. seems db_cassandra wants to return 1 for success but kamailio ( or dialog module at least ) expects 0 for success . so I change that to be return 0, and re-test. everything works as expected, "could not add another dialog to db" stops coming up on my console, and dialogs are removed when calls hangup. seems this 1 thing is enough to screw dialogs in cassandra ( and who knows what else ). This is the reason for my email though, if we simply change that to 0, what else may break !?? however http://www.asipto.com/pub/kamailio-devel-guide/#c09f_insert clearly states that "0 if everything is OK" so this is clearly a bug that needs fixing. Can I get someone with more experience to test this for me and possibly apply the attached patch !? Jay On 25 February 2014 05:58, Daniel-Constantin Mierla &lt;miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote: remove the dialog from its associated profiles when it gets in terminated state. I encountered such issue (not that) recently, but I haven't gotten the time to get to it before. profiles when loading from database and the state is terminated (5). http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=edf61ac… http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9b88eb7… 4.0 I expect). If you test and all goes fine, I will backport -- here I had no time for real testing. terminated, but destroy them at db load time. But this needs a bit of a review, to be sure that all necessary callbacks are executed. db, might be an issue with the database driver (cassandra in this case, which is rather new module). Do you get any syslog errors from kamailio or database server? I expect that people would have reported such issue for other database engines so far. Still it might be an issue, just that was not noticed... dialog... so you get ALL dialogs that are in the hash table. to enforce channel limits etc ) "ACTIVE" dialogs in the hash table... kewl.. loads all dialogs from the DB, regardless of state. yet... but were in state 5 ) get re-created in kamailio the DB. internal hash, but the sync to DB hasnt happened yet. kamailio and it re-loads all those dialogs be VERY common to use dialogs for channel limiting.. but as of yet ... Im still yet to find anything that makes me thing this is db_cassandra mis-behaving. &lt;jaybinks(a)gmail.com <mailto:jaybinks@gmail.com>> wrote: &lt;jaybinks(a)gmail.com <mailto:jaybinks@gmail.com>> wrote: backend.. but its worth mentioning anyways. dialogs go away when I hangup a call.. but they have a state of 5. dialogs in state 5 get cleaned up after a period. starts I call "kamctl mi dlg_list" again, and it shows all my dialogs from the DB. they DO show as "State 5" around for a long time, and the bigger issue it causes me is that my channel limiting ( using get_profile_size ) seems to consider these dialogs ( in state 5 ) as being active calls. <mailto:sr-dev@lists.sip-router.org> <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda sr-users mailing list <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Sincerely Jay -- Sincerely Jay

Just noticed the same thing in db_cassa_delete.. patch updated to fix both Jay On 5 March 2014 12:52, jay binks &lt;jaybinks(a)gmail.com <mailto:jaybinks@gmail.com>> wrote: Hi All, so Ive done what Carlos suggested and swapped out my dialog db to Mysql rather than cassandra. All worked 100% as you would expect. Right so the issue is db_cassandra . I started testing and going through the code. I found I had these lines, which was interesting & concerning. update_dialog_dbinfo_unsafe(): could not add another dialog to db I had been ignoring them, because the dialog was in the DB and I figured I would come back and figure that out later. but this seems to have been key to this whole thing. ends up that in dlg_db_handler.c dialog_dbf.insert was getting a 1 back from kamailio on the insert and a 0 back from mysql... WTF.. ok. so I trace into db_cassa_insert which calls db_cassa_modify .. around line 1210 I can see this .. CON_CASSA(_h)->con->batch_mutate(CFMap, oac::ConsistencyLevel::ONE); return 1; wrapped in a try / catch block.. seems db_cassandra wants to return 1 for success but kamailio ( or dialog module at least ) expects 0 for success . so I change that to be return 0, and re-test. everything works as expected, "could not add another dialog to db" stops coming up on my console, and dialogs are removed when calls hangup. seems this 1 thing is enough to screw dialogs in cassandra ( and who knows what else ). This is the reason for my email though, if we simply change that to 0, what else may break !?? however http://www.asipto.com/pub/kamailio-devel-guide/#c09f_insert clearly states that "0 if everything is OK" so this is clearly a bug that needs fixing. Can I get someone with more experience to test this for me and possibly apply the attached patch !? Jay On 25 February 2014 05:58, Daniel-Constantin Mierla &lt;miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote: remove the dialog from its associated profiles when it gets in terminated state. I encountered such issue (not that) recently, but I haven't gotten the time to get to it before. when loading from database and the state is terminated (5). http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=edf61ac… http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9b88eb7… expect). If you test and all goes fine, I will backport -- here I had no time for real testing. terminated, but destroy them at db load time. But this needs a bit of a review, to be sure that all necessary callbacks are executed. might be an issue with the database driver (cassandra in this case, which is rather new module). Do you get any syslog errors from kamailio or database server? I expect that people would have reported such issue for other database engines so far. Still it might be an issue, just that was not noticed... so you get ALL dialogs that are in the hash table. enforce channel limits etc ) dialogs in the hash table... kewl.. loads all dialogs from the DB, regardless of state. yet... but were in state 5 ) get re-created in kamailio internal hash, but the sync to DB hasnt happened yet. kamailio and it re-loads all those dialogs VERY common to use dialogs for channel limiting.. as of yet ... Im still yet to find anything that makes me thing this is db_cassandra mis-behaving. <mailto:jaybinks@gmail.com>> wrote: <mailto:jaybinks@gmail.com>> wrote: backend.. its worth mentioning anyways. go away when I hangup a call.. they have a state of 5. in state 5 get cleaned up after a period. starts I call "kamctl mi dlg_list" again, and it shows all my dialogs from the DB. they DO show as "State 5" for a long time, and the bigger issue it causes me is that my channel limiting ( using get_profile_size ) seems to consider these dialogs ( in state 5 ) as being active calls. <mailto:sr-dev@lists.sip-router.org> <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda mailing list <mailto:sr-users@lists.sip-router.org> -- Sincerely Jay -- Sincerely Jay