Re: [sr-dev] [SR-Users] dialog module with DB Backend

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