[OpenSIPS-Users] REG::Opensips V1.11.5 & V1.11.10 Duplicate TCP Conections
Răzvan Crainea
razvan at opensips.org
Mon May 15 05:36:31 EDT 2017
Hi, Ravitez!
As I said, unfortunately there is no way to prevent OpenSIPS from doing
this.
The only thing I can think of is to somehow "delay" the connect by
randomly delay processing. I know this is not the best solution, but
unfortunately there's nothing to do with the current design.
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
On 05/12/2017 01:55 AM, Ravitez Ravi wrote:
> Hello Razvan,
> Good Day,
> Would like to bring up that if children(workes)
> try to create TCP connections without a locking mechanism we may hit
> TCP connection limit and not process or handle valid requests
>
> eg :
> tcp_max_connections=10;
> tcp_connection_lifetime=43200;
> tcp_children=32
> Considering the above configuration with the
> existing framework we can use up all 10 connections and then reject
> new connections.
> Please advise.Thank you :)
>
>
> Regard,
> Ravitez.D
>
>
> On Tue, May 9, 2017 at 10:20 AM, Ravitez Ravi
> <ravitez.dondeti at gmail.com <mailto:ravitez.dondeti at gmail.com>> wrote:
>
> Hello Razvan,
> God Day,
> Thank you for the update,it seems that though
> we create multiple TCP connections opensips uses only one tcp
> connection to send the data out.
> should a child be locking the tcp connection
> mechanism? while creating a new tcp connection as we will be
> overwriting the tcpconn_aliases_has to the
> latest/recent fd.
>
>> I believe here's the root cause :
>> - When a child tries to find a connection to the destination
>> it calls _tcpconn_find() (assuming we are using ip and not id)
>> system checks _/*tcpconn_aliases_hash */_for the connection info.
>> */this map is maintained by the parent process and each child
>> lock its while reaing tcpconn_get().in order to simulate the
>> scenario lets assume a->parent->state is BAD this method/*
>> */ will return null and so the child tries to create a new
>> connections,assuming there's a second child trying to find the
>> same connections and goes through the same process/*
>>
>> - */Now each child thinks there's no connection to the
>> destination and calls tcpconn_connect() this will create a socket
>> to the destination and passes over the fd to the /*
>> */ main process to update the has map./*
>>
>> - */Not sure if tcp_connect() should have locking mechanism as
>> in tcpconn_get()./*
> Thank you :)
>
> Regards,
> Ravitez.D
>
> On Mon, May 8, 2017 at 10:48 AM, Răzvan Crainea
> <razvan at opensips.org <mailto:razvan at opensips.org>> wrote:
>
> Hi, Ravitez!
>
> You are right - if opensips gets multiple messages in parallel
> that need to get to a single destination, each process will
> open a different connection to that destination. However, all
> sequential messages will use a single TCP connection.
> Synchronizing all the TCP actions to ensure you will have a
> single connection might be a bit overkill in terms of performance.
>
> May I ask if this is a problem for you? Can you detail a bit why?
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutions
> www.opensips-solutions.com <http://www.opensips-solutions.com>
>
> On 05/04/2017 04:11 PM, Ravitez Ravi wrote:
>> Hi All,
>> Good Day,
>> I have been seeing opensips creating
>> mutiple(duplicate) TCP connections to the same destination if
>> hit with heavy call load.
>>
>> *What do i mean?*
>> opensips ip : 10.10.10.1
>> Destination : 10.10.10.2
>> Tcp Children : 32
>> Ideally opensips will create only one tcp connections and
>> reuses it,if there's a heavy call load i see there are
>> several tcp connections which are created to the same
>> destination.
>> I believe here's the root cause :
>> - When a child tries to find a connection to the
>> destination it calls _tcpconn_find() (assuming we are using
>> ip and not id) system checks tcpconn_aliases_hash for the
>> connection info.
>> this map is maintained by the parent process and each
>> child lock its while reaing tcpconn_get().in order to
>> simulate the scenario lets assume a->parent->state is BAD
>> this method
>> will return null and so the child tries to create a new
>> connections,assuming there's a second child trying to find
>> the same connections and goes through the same process
>>
>> - Now each child thinks there's no connection to the
>> destination and calls tcpconn_connect() this will create a
>> socket to the destination and passes over the fd to the
>> main process to update the has map.
>>
>> - Not sure if tcp_connect() should have locking
>> mechanism as in tcpconn_get().
>>
>>
>>
>> Please correct me if my understanding is wrong,please share
>> your thoughts.
>> Thank you.
>>
>>
>>
>> Regards,
>> Ravitez.D
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170515/c5848015/attachment-0001.html>
More information about the Users
mailing list