[SR-Users] /usr/sbin/kamailio - unresolvable destination error

[Ginti Saurabh]

Hi,

Please help to sort the problem.

Getting "Unresolvable destination" error in /var/log/messages.
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Dropping non-provisional replies in onreply_route

[Daniel-Constantin Mierla]

Yes, transaction will be ended, onsend_route is executed after all
transaction processing was done. There might be some error messages in
the logs, but that can be eventually tuned with a small patch.

Cheers,
Daniel


On 21/10/16 14:30, Alex Balashov wrote:
> Thanks, that's a good idea! 
>
> If I use the onsend route, I can still expect the transaction life to come to 
> an end at this point, right? If not, I need some other way of manually 
> sunsetting transactions. 
>
> On October 21, 2016 8:23:01 AM EDT, Daniel-Constantin Mierla 
>  wrote:
>> One addition that was done rather recent is execution of onsend_route
>> for replies (it may require a core param to be set) and maybe you can
>> drop there based on an avp -- it may be a solution if you don't care
>> about transaction, but only not to send the sip response to the end
>> point.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 21/10/16 11:45, Alex Balashov wrote:
>>> Yeah, I'm trying to avoid something complex like keeping state in
>> htable. 
>>> I did try it - the docs are correct. drop() on a >= 2xx reply does
>> nothing in a named (TM) onreply_route[]. 
>>> I really don't care if the transaction is completed internally. I
>> just want to stop the reply going back to the UAC. 
>>> So, just wondering if there's some clever alternative idea. If not, I
>> guess I will have to use a global onreply_route and feed it information
>> about whether to use the drop using htable. 
>>>
>>> On October 21, 2016 5:39:04 AM EDT, Daniel-Constantin Mierla
>>  wrote:
 You can try it, not sure if docs are really in sync there.

 On the other hand, could be that the transaction was matching the
>> 2xx
 and then practically the state of transaction changed to completed,
>> so
 even doing a drop of not sending out, the transaction is still
>> ended.
 An alternative solution is using a hash table with expiration of the
 items matching the max timeout for transactions.

 Cheers,
 Daniel


 On 21/10/16 11:24, Alex Balashov wrote:
> The core documentation says that in a named onreply_route[], only
> provisional replies can be drop()'d. To drop any reply, it is
> necessary to use a global onreply_route.
>
> Is there any workaround for this, i.e. so I can drop a 2xx reply
>> from
> a specific TM transaction?
>
> The reason is, to know whether to drop it, I need access to either
> AVPs or, ideally, dialog variables. Since the global onreply_route
>> is
> executed by the core, I presume I won't have access to anything
>> that
> persists through TM there.
>
> Thanks!
>
> -- Alex
>
 -- 
 Daniel-Constantin Mierla
 http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
 Kamailio Advanced Training, Berlin, Oct 24-26, 2016 -
 http://www.asipto.com


 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>> list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>> -- Alex
>>>
>>> --
>>> Principal, Evariste Systems LLC (www.evaristesys.com)
>>>
>>> Sent from my Google Nexus.
>>>
>
> -- Alex
>
> --
> Principal, Evariste Systems LLC (www.evaristesys.com)
>
> Sent from my Google Nexus.
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Dropping non-provisional replies in onreply_route

[Alex Balashov]

Thanks, that's a good idea! 

If I use the onsend route, I can still expect the transaction life to come to 
an end at this point, right? If not, I need some other way of manually 
sunsetting transactions. 

On October 21, 2016 8:23:01 AM EDT, Daniel-Constantin Mierla 
 wrote:
>One addition that was done rather recent is execution of onsend_route
>for replies (it may require a core param to be set) and maybe you can
>drop there based on an avp -- it may be a solution if you don't care
>about transaction, but only not to send the sip response to the end
>point.
>
>Cheers,
>Daniel
>
>
>On 21/10/16 11:45, Alex Balashov wrote:
>> Yeah, I'm trying to avoid something complex like keeping state in
>htable. 
>>
>> I did try it - the docs are correct. drop() on a >= 2xx reply does
>nothing in a named (TM) onreply_route[]. 
>>
>> I really don't care if the transaction is completed internally. I
>just want to stop the reply going back to the UAC. 
>>
>> So, just wondering if there's some clever alternative idea. If not, I
>guess I will have to use a global onreply_route and feed it information
>about whether to use the drop using htable. 
>>
>>
>> On October 21, 2016 5:39:04 AM EDT, Daniel-Constantin Mierla
> wrote:
>>> You can try it, not sure if docs are really in sync there.
>>>
>>> On the other hand, could be that the transaction was matching the
>2xx
>>> and then practically the state of transaction changed to completed,
>so
>>> even doing a drop of not sending out, the transaction is still
>ended.
>>>
>>> An alternative solution is using a hash table with expiration of the
>>> items matching the max timeout for transactions.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 21/10/16 11:24, Alex Balashov wrote:
 The core documentation says that in a named onreply_route[], only
 provisional replies can be drop()'d. To drop any reply, it is
 necessary to use a global onreply_route.

 Is there any workaround for this, i.e. so I can drop a 2xx reply
>from
 a specific TM transaction?

 The reason is, to know whether to drop it, I need access to either
 AVPs or, ideally, dialog variables. Since the global onreply_route
>is
 executed by the core, I presume I won't have access to anything
>that
 persists through TM there.

 Thanks!

 -- Alex

>>> -- 
>>> Daniel-Constantin Mierla
>>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 -
>>> http://www.asipto.com
>>>
>>>
>>> ___
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
>list
>>> sr-users@lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>> -- Alex
>>
>> --
>> Principal, Evariste Systems LLC (www.evaristesys.com)
>>
>> Sent from my Google Nexus.
>>


-- Alex

--
Principal, Evariste Systems LLC (www.evaristesys.com)

Sent from my Google Nexus.


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Dropping non-provisional replies in onreply_route

[Daniel-Constantin Mierla]

One addition that was done rather recent is execution of onsend_route
for replies (it may require a core param to be set) and maybe you can
drop there based on an avp -- it may be a solution if you don't care
about transaction, but only not to send the sip response to the end point.

Cheers,
Daniel


On 21/10/16 11:45, Alex Balashov wrote:
> Yeah, I'm trying to avoid something complex like keeping state in htable. 
>
> I did try it - the docs are correct. drop() on a >= 2xx reply does nothing in 
> a named (TM) onreply_route[]. 
>
> I really don't care if the transaction is completed internally. I just want 
> to stop the reply going back to the UAC. 
>
> So, just wondering if there's some clever alternative idea. If not, I guess I 
> will have to use a global onreply_route and feed it information about whether 
> to use the drop using htable. 
>
>
> On October 21, 2016 5:39:04 AM EDT, Daniel-Constantin Mierla 
>  wrote:
>> You can try it, not sure if docs are really in sync there.
>>
>> On the other hand, could be that the transaction was matching the 2xx
>> and then practically the state of transaction changed to completed, so
>> even doing a drop of not sending out, the transaction is still ended.
>>
>> An alternative solution is using a hash table with expiration of the
>> items matching the max timeout for transactions.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 21/10/16 11:24, Alex Balashov wrote:
>>> The core documentation says that in a named onreply_route[], only
>>> provisional replies can be drop()'d. To drop any reply, it is
>>> necessary to use a global onreply_route.
>>>
>>> Is there any workaround for this, i.e. so I can drop a 2xx reply from
>>> a specific TM transaction?
>>>
>>> The reason is, to know whether to drop it, I need access to either
>>> AVPs or, ideally, dialog variables. Since the global onreply_route is
>>> executed by the core, I presume I won't have access to anything that
>>> persists through TM there.
>>>
>>> Thanks!
>>>
>>> -- Alex
>>>
>> -- 
>> Daniel-Constantin Mierla
>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 -
>> http://www.asipto.com
>>
>>
>> ___
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
> -- Alex
>
> --
> Principal, Evariste Systems LLC (www.evaristesys.com)
>
> Sent from my Google Nexus.
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Edge proxy / Registrar Script

[Infinicalls Infinicalls]

Hi,
 Thanks. I used dispatcher example for proxy file , populated the
dispatcher table and added

modparam("path", "use_received", 1) to config file.

And used the kamailio-basic.cfg for registrar with

modparam("registrar", "use_path", 1)
modparam("registrar", "path_mode", 1)
modparam("registrar", "path_use_received", 1)

rtp is on and listening in the registrar.

However it says, "No Registrar" this time. I really don't understand
the problem. Can you please point me to working example scripts?

regards
Ganesh Kumar

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Dropping non-provisional replies in onreply_route

[Alex Balashov]

Yeah, I'm trying to avoid something complex like keeping state in htable. 

I did try it - the docs are correct. drop() on a >= 2xx reply does nothing in a 
named (TM) onreply_route[]. 

I really don't care if the transaction is completed internally. I just want to 
stop the reply going back to the UAC. 

So, just wondering if there's some clever alternative idea. If not, I guess I 
will have to use a global onreply_route and feed it information about whether 
to use the drop using htable. 


On October 21, 2016 5:39:04 AM EDT, Daniel-Constantin Mierla 
 wrote:
>You can try it, not sure if docs are really in sync there.
>
>On the other hand, could be that the transaction was matching the 2xx
>and then practically the state of transaction changed to completed, so
>even doing a drop of not sending out, the transaction is still ended.
>
>An alternative solution is using a hash table with expiration of the
>items matching the max timeout for transactions.
>
>Cheers,
>Daniel
>
>
>On 21/10/16 11:24, Alex Balashov wrote:
>> The core documentation says that in a named onreply_route[], only
>> provisional replies can be drop()'d. To drop any reply, it is
>> necessary to use a global onreply_route.
>>
>> Is there any workaround for this, i.e. so I can drop a 2xx reply from
>> a specific TM transaction?
>>
>> The reason is, to know whether to drop it, I need access to either
>> AVPs or, ideally, dialog variables. Since the global onreply_route is
>> executed by the core, I presume I won't have access to anything that
>> persists through TM there.
>>
>> Thanks!
>>
>> -- Alex
>>
>
>-- 
>Daniel-Constantin Mierla
>http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>Kamailio Advanced Training, Berlin, Oct 24-26, 2016 -
>http://www.asipto.com
>
>
>___
>SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>sr-users@lists.sip-router.org
>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


-- Alex

--
Principal, Evariste Systems LLC (www.evaristesys.com)

Sent from my Google Nexus.


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Dropping non-provisional replies in onreply_route

[Daniel-Constantin Mierla]

You can try it, not sure if docs are really in sync there.

On the other hand, could be that the transaction was matching the 2xx
and then practically the state of transaction changed to completed, so
even doing a drop of not sending out, the transaction is still ended.

An alternative solution is using a hash table with expiration of the
items matching the max timeout for transactions.

Cheers,
Daniel


On 21/10/16 11:24, Alex Balashov wrote:
> The core documentation says that in a named onreply_route[], only
> provisional replies can be drop()'d. To drop any reply, it is
> necessary to use a global onreply_route.
>
> Is there any workaround for this, i.e. so I can drop a 2xx reply from
> a specific TM transaction?
>
> The reason is, to know whether to drop it, I need access to either
> AVPs or, ideally, dialog variables. Since the global onreply_route is
> executed by the core, I presume I won't have access to anything that
> persists through TM there.
>
> Thanks!
>
> -- Alex
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB

[Daniel-Constantin Mierla]

Hello,


On 21/10/16 11:22, Jurijs Ivolga wrote:
> Hi Daniel,
>
> After 8 days there is still small memory leak, 200MB of Ram wasn't
> freed during this 8 days, please check diagram below.
>
> 1) Is this something usual?
> 2) Memory leak seems very small, maybe I should never worry about
> this? What you think?
>
200MB in 8 days it's still relevant and a leak. Maybe you can run again
with valgrind...

Unless it is unclaimed memory by kernel:

  -
https://www.kamailio.org/wiki/tutorials/troubleshooting/memory#os_memory_reports

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB

[Jurijs Ivolga]

Hi Daniel,

After 8 days there is still small memory leak, 200MB of Ram wasn't freed
during this 8 days, please check diagram below.

1) Is this something usual?
2) Memory leak seems very small, maybe I should never worry about this?
What you think?

[image: Inline image 2]

Thank
you!

With kind regards,

Jurijs

On Wed, Oct 12, 2016 at 4:47 PM, Daniel-Constantin Mierla  wrote:

> Hello,
>
> thanks -- coming in my mind now, xcap_client should use also the curl
> library.
> Cheers,
> Daniel
>
>
> On 12/10/16 15:35, Jurijs Ivolga wrote:
>
> Hi Daniel,
>
> I will test couple more days and later I will try to add some comments to
> utils, http_client & HTTP_ASYNC_CLIENT(not sure if there any other modules
> which use curl, but I will check) modules when I will be 200% sure that
> issue is gone.
>
> With kind regards,
>
> Jurijs
>
> On Wed, Oct 12, 2016 at 4:30 PM, Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Hello,
>>
>> ok, so that was...
>>
>> Maybe it would be good to add a note to the docs of the module about this
>> issue so people become aware of it. I guess the other http_* modules are
>> affected. Pull requests or other suggestions are welcome, of course!
>>
>> Cheers,
>> Daniel
>>
>> On 12/10/16 15:04, Jurijs Ivolga wrote:
>>
>> Hi Daniel,
>>
>> Thank you a lot, it looks that issue is solved, after updating libcurl.
>>
>> I was using following manual for updating libcurl, in case if somebody
>> will have same issue.
>>
>> https://www.digitalocean.com/community/questions/how-to-upgr
>> ade-curl-in-centos6
>>
>> With kind regards,
>>
>> Jurijs
>>
>> On Tue, Oct 11, 2016 at 2:43 PM, Jurijs Ivolga 
>> wrote:
>>
>>> Hi Daniel,
>>>
>>> You are correct we are using heavily http_query.
>>>
>>> I found following bug report:
>>>
>>> https://bugs.centos.org/view.php?id=9391
>>>
>>> I will try to update to libcurl 7.44 and check if this help.
>>>
>>> Thank you a lot Daniel!
>>>
>>> With kind regards,
>>>
>>> Jurijs
>>>
>>> On Tue, Oct 11, 2016 at 10:55 AM, Daniel-Constantin Mierla <
>>> mico...@gmail.com> wrote:
>>>
 Hello,

 from the logs, it seems to be related to curl library, I see many
 reports like:

 ==16459== 189,318 bytes in 167 blocks are possibly lost in loss record
 681 of 683
 ==16459==at 0x4C26FEF: calloc (vg_replace_malloc.c:711)
 ==16459==by 0x104BB699: ??? (in /usr/lib64/libnsspem.so)
 ==16459==by 0x104AA537: ??? (in /usr/lib64/libnsspem.so)
 ==16459==by 0x104AB81E: ??? (in /usr/lib64/libnsspem.so)
 ==16459==by 0x104B0B88: ??? (in /usr/lib64/libnsspem.so)
 ==16459==by 0x104B77E1: ??? (in /usr/lib64/libnsspem.so)
 ==16459==by 0xB71ABC9: ??? (in /usr/lib64/libnss3.so)
 ==16459==by 0xB71AE62: PK11_CreateGenericObject (in
 /usr/lib64/libnss3.so)
 ==16459==by 0xA0674DF: ??? (in /usr/lib64/libcurl.so.4.1.1)
 ==16459==by 0xA067666: ??? (in /usr/lib64/libcurl.so.4.1.1)
 ==16459==by 0xA069141: ??? (in /usr/lib64/libcurl.so.4.1.1)
 ==16459==by 0xA0601C4: Curl_ssl_connect (in
 /usr/lib64/libcurl.so.4.1.1)

 That's like almost 200KB lost in this report.

 From the list of the modules, I see you have utils and I guess you use
 http query function from there, is it?

 Cheers,
 Daniel

 On 10/10/16 12:06, Jurijs Ivolga wrote:

 Hi Daniel,

 I left valgrind running for little while, not sure if this will be
 enough.

 Please find attached log file.

 Thank you a lot for your help!

 With kind regards,

 Jurijs

 On Fri, Oct 7, 2016 at 7:15 PM, Daniel-Constantin Mierla <
 mico...@gmail.com> wrote:

> Hello,
>
> that's the way it was done for older versions of kamailio.
>
> In master and 4.4 the memory debugging is turned on and it is
> reflected by the presence of DBG_SR_MEMORY in the output of 'kamailio -v'.
>
> Anyhow, what you reported is not a leak inside kamailio memory
> manager, but a leak of using system memory, so it is not affected by
> DBG_SR_MEMORY and cannot be troubleshooted using the mechanisms for pkg 
> and
> shm managers.
>
> Cheers,
> Daniel
>
>
 --
 Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - 
 http://www.linkedin.com/in/miconda
 Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com

 --
>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - 
>> http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
>>
>> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - 
> http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
>
>
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list

Re: [SR-Users] Basic TM suspend question

[Daniel-Constantin Mierla]

On 21/10/16 11:26, Alex Balashov wrote:
> On 10/21/2016 05:22 AM, Daniel-Constantin Mierla wrote:
>
>> Also the timeout runs for it and failure_route can be executed in
>> that case.
>
> Interesting. That brings up two more questions:
>
> 1. If fr_timer is set to 3000 but I suspend the transaction for 4
> seconds, does that mean that failure_route is going to be called at
> the 3000 mark anyway? If so, does that mean the transaction is
> implicitly woken up (t_continue()'d) at that moment?
if you resume, the transaction is back in processing -- from timeout
point of view, you can think of t_suspend() as a t_relay() without
sending out and the t_continue() as receiving a negative response and
willing to re-route the request.
>
> 2. Does the failure_route run in a normal SIP worker, or in an async
> worker, if using async_task_route() here?
>
Failure route for local triggered timeout is executed in the timer
process, the others by the sip worker that received the negative response.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Basic TM suspend question

[Alex Balashov]

On 10/21/2016 05:22 AM, Daniel-Constantin Mierla wrote:


Also the timeout runs for it and failure_route can be executed in
that case.


Interesting. That brings up two more questions:

1. If fr_timer is set to 3000 but I suspend the transaction for 4 
seconds, does that mean that failure_route is going to be called at the 
3000 mark anyway? If so, does that mean the transaction is implicitly 
woken up (t_continue()'d) at that moment?


2. Does the failure_route run in a normal SIP worker, or in an async 
worker, if using async_task_route() here?


--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Dropping non-provisional replies in onreply_route

[Alex Balashov]

The core documentation says that in a named onreply_route[], only 
provisional replies can be drop()'d. To drop any reply, it is necessary 
to use a global onreply_route.


Is there any workaround for this, i.e. so I can drop a 2xx reply from a 
specific TM transaction?


The reason is, to know whether to drop it, I need access to either AVPs 
or, ideally, dialog variables. Since the global onreply_route is 
executed by the core, I presume I won't have access to anything that 
persists through TM there.


Thanks!

-- Alex

--
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Basic TM suspend question

[Daniel-Constantin Mierla]

Hello,


On 20/10/16 21:51, Alex Balashov wrote:
> Hi,
>
> If a transaction is currently t_suspended() and has not been
> t_continued(), will t_check_trans() still find that transaction for
> retransmission-dampening purposes, e.g. if a retransmission of the
> same request as the original one is received?
>
yes, the transaction is detected. Also the timeout runs for it and
failure_route can be executed in that case.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Postgres: Exclusive Transaction Locks vs. Vacuumer

[Daniel-Constantin Mierla]

Hello,

I haven't added that part of code, nor using postgres to be able to
comment on specific points, but my blind guess is that there are many
queries done in between the table locks, like a check if a record exist,
followed by insert/update/delete/..., so just locking on a row might not
prevent races. Not sure if Peter is still around for more comments, iirc
he worked on that, ...

Cheers,
Daniel


On 21/10/16 11:00, Stefan Kohlhauser wrote:
> Hey everyone!
>
> We noticed that under high load of registrations and using the pua module we 
> can reach a state where the PUA table bloats our Postgres to several GB. 
> However, a SELECT on pua only shows a few hundred entries. The other half 
> million or so entries are obsoleted but not cleaned up.
> The reason for this seems to be that the autovacuumer of the Postgres can't 
> get to work because the PUA table is almost permanently locked.
> Our Postgres logs are full with errors about the autovacuumer being canceled 
> because it couldn't get to work.
>
> Looking at modules/db_postgres/km_dbase.c::db_postgres_start_transaction() I 
> noticed that there are two locking modes used:
> str lock_write_end_str = str_init(" IN EXCLUSIVE MODE");
> str lock_full_end_str = str_init(" IN ACCESS EXCLUSIVE MODE");
>
> According to
> https://www.postgresql.org/docs/9.2/static/explicit-locking.html
> these modes mean forbidding everything else except reads and forbidding 
> everything else.
> However, according to this documentation ROW EXCLUSIVE is the standard lock 
> for entry altering operations (INSERT, UPDATE, DELETE). And this would still 
> allow the autovacuumer to do its job.
>
> Is there a specific reason why these more restricting locking modes are used 
> instead of ROW EXCLUSIVE?
>
> Thanks.
>
> Best regards,
> Stefan
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Postgres: Exclusive Transaction Locks vs. Vacuumer

[Stefan Kohlhauser]

Hey everyone!

We noticed that under high load of registrations and using the pua module we 
can reach a state where the PUA table bloats our Postgres to several GB. 
However, a SELECT on pua only shows a few hundred entries. The other half 
million or so entries are obsoleted but not cleaned up.
The reason for this seems to be that the autovacuumer of the Postgres can't get 
to work because the PUA table is almost permanently locked.
Our Postgres logs are full with errors about the autovacuumer being canceled 
because it couldn't get to work.

Looking at modules/db_postgres/km_dbase.c::db_postgres_start_transaction() I 
noticed that there are two locking modes used:
str lock_write_end_str = str_init(" IN EXCLUSIVE MODE");
str lock_full_end_str = str_init(" IN ACCESS EXCLUSIVE MODE");

According to
https://www.postgresql.org/docs/9.2/static/explicit-locking.html
these modes mean forbidding everything else except reads and forbidding 
everything else.
However, according to this documentation ROW EXCLUSIVE is the standard lock for 
entry altering operations (INSERT, UPDATE, DELETE). And this would still allow 
the autovacuumer to do its job.

Is there a specific reason why these more restricting locking modes are used 
instead of ROW EXCLUSIVE?

Thanks.

Best regards,
Stefan

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users