<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I applied the patch to master and backported to 4.1 branch,<br>
<br>
Cheers,<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 06/03/14 09:38, jay binks wrote:<br>
</div>
<blockquote
cite="mid:CAO47HpchGd-2p0ciaunpZDbvTghKjrEtA4xOCxGmuo02gWtuTg@mail.gmail.com"
type="cite">
<div dir="ltr">I have fixed the remaining return 1's , and also
added a little more logging for if a query reties to connect and
fails ( retry count ).
<div><br>
</div>
<div>find attached latest patch file... ( tested to patch
against master head )</div>
<div>hopefully this is good enough for you to commit.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 5 March 2014 21:42,
Daniel-Constantin Mierla <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:miconda@gmail.com"
target="_blank">miconda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hello,<br>
<br>
can you make the patch for master branch? I just
backported two patches that were in master branch but not
yet in 4.1.<br>
<br>
With this occasion, can you review if the other 'return 1'
expose the same issue? I noticed another one in
db_cassa_delete and in db_cassa_query.<br>
<br>
Thanks,<br>
Daniel
<div>
<div class="h5"><br>
<br>
<div>On 05/03/14 03:57, jay binks wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Just noticed the same thing
in db_cassa_delete..
<div>patch updated to fix both</div>
<div><br>
</div>
<div>Jay</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On 5 March 2014 12:52,
jay binks <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jaybinks@gmail.com"
target="_blank">jaybinks@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">Hi All,<br>
<br>
so Ive done what Carlos suggested and
swapped out my dialog db to Mysql rather
than cassandra.<br>
All worked 100% as you would expect.<br>
<br>
Right so the issue is db_cassandra .<br>
<br>
I started testing and going through the
code.<br>
<br>
I found I had these lines, which was
interesting & concerning.<br>
update_dialog_dbinfo_unsafe(): could not add
another dialog to db<br>
I had been ignoring them, because the dialog
was in the DB and I figured I would come
back and figure that out later.<br>
<br>
but this seems to have been key to this
whole thing.<br>
<br>
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.<br>
<br>
so I trace into db_cassa_insert which calls
db_cassa_modify ..<br>
around line 1210 I can see this ..<br>
<br>
CON_CASSA(_h)->con->batch_mutate(CFMap,
oac::ConsistencyLevel::ONE);<br>
return 1;<br>
<br>
wrapped in a try / catch block..<br>
seems db_cassandra wants to return 1 for
success but kamailio ( or dialog module at
least ) expects 0 for success .<br>
<br>
so I change that to be return 0, and
re-test.<br>
everything works as expected, "could not
add another dialog to db" stops coming up on
my console,<br>
and dialogs are removed when calls hangup.<br>
<br>
seems this 1 thing is enough to screw
dialogs in cassandra ( and who knows what
else ).<br>
This is the reason for my email though, if
we simply change that to 0, what else may
break !??<br>
<br>
however <a moz-do-not-send="true"
href="http://www.asipto.com/pub/kamailio-devel-guide/#c09f_insert"
target="_blank">http://www.asipto.com/pub/kamailio-devel-guide/#c09f_insert</a>
clearly states that "0 if everything is OK"<br>
so this is clearly a bug that needs fixing.<br>
<br>
Can I get someone with more experience to
test this for me and possibly apply the
attached patch !?
<div><br>
</div>
<div>Jay</div>
<div><br>
</div>
<div>
<div>
<div>
<div><br>
</div>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On 25 February 2014 05:58,
Daniel-Constantin Mierla <<a
moz-do-not-send="true"
href="mailto:miconda@gmail.com"
target="_blank">miconda@gmail.com</a>>
wrote:<br>
><br>
> Hello,<br>
><br>
> I pushed some patches to the
master branch in order to 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.<br>
><br>
> Then, the second patch is to not
add dialogs in profiles when loading
from database and the state is
terminated (5).<br>
><br>
> Here are the links to the
patches:<br>
><br>
> - <a moz-do-not-send="true"
href="http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=edf61acb57ed5e8ee0ca9ec1f796e43ce993be48"
target="_blank">http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=edf61acb57ed5e8ee0ca9ec1f796e43ce993be48</a><br>
> - <a moz-do-not-send="true"
href="http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9b88eb7ee2d243882383a44f601baa21fd679cd5"
target="_blank">http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=9b88eb7ee2d243882383a44f601baa21fd679cd5</a><br>
><br>
> Should be straightforward to
cherry pick to 4.1 (even 4.0 I
expect). If you test and all goes
fine, I will backport -- here I had no
time for real testing.<br>
><br>
> I plan also to not add the
dialogs in memory for state
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.<br>
><br>
> On the other hand, if the dialogs
are not removed from 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...<br>
><br>
> Cheers,<br>
> Daniel<br>
><br>
> On 24/02/14 11:19, jay binks
wrote:<br>
><br>
> So poking round the code for the
dialog module.... <br>
> Im not sure what im missing here.<br>
><br>
><br>
> get_profile_size dosnt care bout
the state of a dialog... so you get
ALL dialogs that are in the hash
table.<br>
> ( which is interesting if you
want to use dialog module to enforce
channel limits etc )<br>
><br>
> So you go... OK... kamailio only
expects to have "ACTIVE" dialogs in
the hash table... kewl..<br>
> lets assume that to be the case.<br>
><br>
> but then in dlg_db_handler.c ,
load_dialog_info_from_db loads all
dialogs from the DB, regardless of
state.<br>
> so all dialogs in the DB ( ones
that didnt get deleted yet... but were
in state 5 ) get re-created in
kamailio<br>
> upon startup.<br>
><br>
> what this means is...<br>
> ( assume starting with empty DB )<br>
><br>
> I start kamailio, make some
calls... they get synced to the DB.<br>
> I end the calls, kamailio
removes from dialogs module internal
hash, but the sync to DB hasnt
happened yet.<br>
><br>
> I kill kamailio ( or crash ..
whatever ).... restart kamailio and
it re-loads all those dialogs<br>
> and thinks they are still active
calls.<br>
><br>
> Im SURE Im missing something
here, because it seems to be VERY
common to use dialogs for channel
limiting..<br>
> maybe not so much using cassandra
db behind the scenes, but as of yet
... Im still yet to find anything that
makes me thing this is db_cassandra
mis-behaving.<br>
><br>
> if im wrong, please point me in
the right direction.<br>
><br>
> Jay<br>
><br>
><br>
><br>
><br>
> On 24 February 2014 17:54, jay
binks <<a moz-do-not-send="true"
href="mailto:jaybinks@gmail.com"
target="_blank">jaybinks@gmail.com</a>>
wrote:<br>
>><br>
>> Am I REALLY the only person
who has ever run into this !?<br>
>><br>
>><br>
>> On 19 February 2014 14:08,
jay binks <<a
moz-do-not-send="true"
href="mailto:jaybinks@gmail.com"
target="_blank">jaybinks@gmail.com</a>>
wrote:<br>
>>><br>
>>> Hi all, im using the
dialog module with db_cassandra
backend..<br>
>>> I dont believe this issue
is related to cassandra, but its worth
mentioning anyways.<br>
>>><br>
>>> so... I run kamailio,
make calls, see dialogs in the DB..<br>
>>> and I Can use "kamctl mi
dlg_list" and see that dialogs go away
when I hangup a call..<br>
>>><br>
>>> When I query the DB
Backend, I still see the queries, but
they have a state of 5.<br>
>>> I Initially thought this
was a bug, but it seems dialogs in
state 5 get cleaned up after a period.<br>
>>> so I moved on.<br>
>>><br>
>>> now , lets restart
kamailio..<br>
>>> 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"<br>
>>> 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. <br>
>>><br>
>>> Please someone point me
in the right direction... :)<br>
>>><br>
>>> what am I doing wrong ?<br>
>>> ( or is this a bug
somewhere )<br>
>>><br>
>>> Sincerely<br>
>>><br>
>>> Jay<br>
>><br>
>><br>
>><br>
>><br>
>> -- <br>
>> Sincerely<br>
>><br>
>> Jay<br>
><br>
><br>
><br>
><br>
> -- <br>
> Sincerely<br>
><br>
> Jay<br>
><br>
><br>
>
_______________________________________________<br>
> sr-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:sr-dev@lists.sip-router.org"
target="_blank">sr-dev@lists.sip-router.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev"
target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
><br>
><br>
> -- <br>
> Daniel-Constantin Mierla - <a
moz-do-not-send="true"
href="http://www.asipto.com"
target="_blank">http://www.asipto.com</a><br>
> <a moz-do-not-send="true"
href="http://twitter.com/#%21/miconda"
target="_blank">http://twitter.com/#!/miconda</a>
- <a moz-do-not-send="true"
href="http://www.linkedin.com/in/miconda"
target="_blank">http://www.linkedin.com/in/miconda</a><br>
><br>
><br>
</div>
</div>
>
_______________________________________________<br>
> SIP Express Router (SER) and Kamailio
(OpenSER) - sr-users mailing list<br>
> <a moz-do-not-send="true"
href="mailto:sr-users@lists.sip-router.org"
target="_blank">sr-users@lists.sip-router.org</a><br>
> <a moz-do-not-send="true"
href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users"
target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
><br>
<br>
<br>
<br>
--<br>
Sincerely<span><font color="#888888"><br>
<br>
Jay<br>
</font></span></div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Sincerely<br>
<br>
Jay </div>
</blockquote>
<br>
<pre cols="72">--
Daniel-Constantin Mierla - <a moz-do-not-send="true" href="http://www.asipto.com" target="_blank">http://www.asipto.com</a>
<a moz-do-not-send="true" href="http://twitter.com/#%21/miconda" target="_blank">http://twitter.com/#!/miconda</a> - <a moz-do-not-send="true" href="http://www.linkedin.com/in/miconda" target="_blank">http://www.linkedin.com/in/miconda</a></pre>
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Sincerely<br>
<br>
Jay
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a></pre>
</body>
</html>