[sr-dev] kazoo module updates & documentation

Daniel-Constantin Mierla miconda at gmail.com
Sat Sep 13 10:17:29 CEST 2014


Hello,

this looks like a problem, indeed. Thanks for troubleshooting to get 
down to it.

However, the solution to store the result in local variable is still not 
the good choice. That is because we have so called result fetch support, 
where the result from the query is not retrieved all at once from 
database connection, but you can specify the number of rows (e.g., you 
want to get in db_res only 1000 rows at the moment). Therefore, the 
result of the initial query will not be processed entirely if the second 
query is done over the same connection after retrieving only the first 
fetch_rows.

I haven't looked deep at your patch to db_text, it might solve it for 
your module, but overall the problem remains with the other db modules 
(e.g., mysql, ...). We need to come up with a fix for everything affected.

One solution is to update the presence module to use two connection, one 
not-pooled (so it will do always a new connection, not selecting from 
existing pool if db_url matches). IIRC, there is a similar case in 
another module, developed at that time by Peter or Hugh -- cc-ed them, 
hopefully they can share some insights quickly. I will look as well over 
the issue to see if there are alternatives to fix it.

Cheers,
Daniel

On 13/09/14 03:59, Luis Azedo wrote:
> Hi Daniel,
>
> please take a look at msg_presentity_clean function in publish.c 
> module presence.
>
> if the initial query returns a result
> if pres_notifier_processes = 0 (immediate notify)
> it calls publ_notify function
> in publ_notify function in notify.c
> if(p->event->agg_nbody) // dialoginfo aggregates the results
> {
> notify_body = *get_p_notify_body*(pres_uri, p->event , offline_etag, 
> NULL);
>          .....
> *get_p_notify_body *queries the *presentity *table to get other 
> records to aggregate body
> which will override the result in the connection.
>
> so the process is the same but it calls the query 2 times in a row 
> without freeing the 1st result.
>
>
>
>
> ------------------------------------------------------------------------
> *From:* sr-dev-bounces at lists.sip-router.org 
> [sr-dev-bounces at lists.sip-router.org] on behalf of Daniel-Constantin 
> Mierla [miconda at gmail.com]
> *Sent:* Friday, September 12, 2014 12:15 PM
> *To:* Kamailio (SER) - Development Mailing List
> *Subject:* Re: [sr-dev] kazoo module updates & documentation
>
> Hello,
>
> changes to kazoo modules are ok, you can merge them.
>
> But the one for db_text I don't find it (yet) necessary, because it 
> may solve an issue in a wrong way.
>
> I asked you to push the other patch on db_text related to blob type 
> handling in freeing the value. That can be done. For the one storing 
> the result on db_res variable, I will comment separately.
>
> Daniel
>
> On 12/09/14 20:55, Luis Azedo wrote:
>> Hi,
>>
>> i would like to propose the small changes to the kazoo module in 
>> branch lazedo/kazoo to go into master.
>> it's mostly code cleanup & dependency removal.
>>
>> also added the documentation on that branch and would appreciate any 
>> feedback.
>>
>>
>> there is also a patch to the db_text module. the comment on that 
>> commit tells the reason for that patch.
>>
>> Thanks
>>
>>
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
> -- 
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda  -http://www.linkedin.com/in/miconda
> Next Kamailio Advanced Trainings 2014 -http://www.asipto.com
> Sep 22-25, Berlin, Germany

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140913/4b8c01f3/attachment.html>


More information about the sr-dev mailing list