[OpenSIPS-Users] Opensips 1.8 ds_list behavior in dispatcher
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Jan 19 10:56:12 CET 2016
Hi,
This was fixed starting with 1.11, so you should upgrade your version as
1.8 is deprecated.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 18.01.2016 20:22, Gunjan Korlekar wrote:
> Hi Bogdan,
>
> Thanks for the tip! I checked the opensips logs and I saw the
> following message when we executed a 'dispatcher reload' command -
>
> WARNING:dispatcher:ds_load_db: no dispatching data in the db -- empty
> destination set
>
> Digging into the code for the ds_load_db function in dispatch.c I
> found the following -
>
> if(nr_rows == 0)
> {
> LM_WARN("no dispatching data in the db -- empty destination set\n");
> ds_dbf.free_result(ds_db_handle, res);
> return 0;
> }
>
> So, essentially when the dispatcher table is empty, the reload
> function does not sync the secondary memory with the primary and
> returns, which causes stale data to remain in the primary, which is
> why 'fifo ds_list' command never updated after the 'dispatcher rmgw'.
>
> Is there a patch or a fix you can provide for the above in the
> opensips 1.8 version of the source?
>
> Thanks,
> Gunjan
>
> On Fri, Jan 15, 2016 at 1:31 AM, Bogdan-Andrei Iancu
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>
> Hi Gunjan,
>
> have you checked the opensips logs for any potential errors ?
> maybe the reload fails.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.com
>
> On 14.01.2016 19:10, Gunjan Korlekar wrote:
>> Hi Bogdan,
>>
>> Thanks for the clarification regarding the memory and the ds_list
>> command.
>> From what I see in the opensipsctl source, the 'opensipsctl
>> dispatcher rmgw' command also runs a 'ds_reload' after running
>> the database query to remove the entry. Hence in my above
>> sequence of operations, the primary storage should have synced
>> with the secondary storage before I ran 'fifo ds_list' and should
>> not have expected data in the ds_list output -
>>
>> ./opensipsctl dispatcher show
>> dispatcher gateways
>> +----+-------+------------------+--------+-------+--------+-------+-------------+
>> | id | setid | destination | socket | flags | weight | attrs
>> | description |
>> +----+-------+------------------+--------+-------+--------+-------+-------------+
>> | 5 | 40 | sip:2.2.2.6:5060 <http://2.2.2.6:5060/> | NULL |
>> 0 | 1 | | test1 |
>> +----+-------+------------------+--------+-------+--------+-------+-------------+
>>
>> ./opensipsctl dispatcher rmgw 5 <<<<------ ds_reload here
>> ./opensipsctl fifo ds_list <<<----- should show synced output ?
>> SET_NO:: 1
>> SET:: 40
>> URI:: sip:2.2.2.6:5060 <http://2.2.2.6:5060/> flag=A
>> ./opensipsctl dispatcher show
>> dispatcher gateways
>>
>> I tried the above by running 'fifo ds_reload' explicitly after
>> 'dispatcher rmgw' as well. However I did not see a difference in
>> the result. Can you please help in understanding the issue?
>>
>> Thanks,
>> Gunjan
>>
>> On Thu, Jan 14, 2016 at 1:39 AM, Bogdan-Andrei Iancu
>> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>>
>> Hi Gunjan,
>>
>> In dispatcher there are 2 storages:
>> - primary storage which is in memory
>> - secondary storage (read only at startup or reload)
>> which is the DB
>>
>> First is about synchronizing the 2 storages (from secondary
>> to primary via a ds_reload command). AFter that is about
>> which storage you are querying for data. Like the
>> "opensipsctl fifo ds_list" (via MI command) gets data from
>> memory cache while the "opensipsctl dispatcher show" simply
>> dumps db content.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>> On 14.01.2016 03:44, Gunjan Korlekar wrote:
>>> Hello,
>>>
>>> I am observing some unusual behavior of the ds_list command
>>> when adding and removing gateways in the dispatcher table
>>> for opensips 1.8
>>>
>>> I am running the following sequence of commands -
>>>
>>> ./opensipsctl dispatcher addgw 40 sip:2.2.2.4:5060
>>> <http://2.2.2.4:5060/> 0 'test1'
>>> ./opensipsctl dispatcher addgw 40 sip:2.2.2.5:5060
>>> <http://2.2.2.5:5060/> 0 'test1'
>>> ./opensipsctl dispatcher addgw 40 sip:2.2.2.6:5060
>>> <http://2.2.2.6:5060/> 0 'test1'
>>>
>>> When I view the dispatcher list using ds_list I see-
>>> ./opensipsctl fifo ds_list
>>> SET_NO:: 1
>>> SET:: 40
>>> URI:: sip:2.2.2.4:5060 <http://2.2.2.4:5060/> flag=A
>>> URI:: sip:2.2.2.5:5060 <http://2.2.2.5:5060/> flag=A
>>> URI:: sip:2.2.2.6:5060 <http://2.2.2.6:5060/> flag=A
>>> and the ./opensipsctl dispatcher show output is as follows -
>>> dispatcher gateways
>>> +----+-------+------------------+--------+-------+--------+-------+-------------+
>>> | id | setid | destination | socket | flags | weight |
>>> attrs | description |
>>> +----+-------+------------------+--------+-------+--------+-------+-------------+
>>> | 3 | 40 | sip:2.2.2.4:5060 <http://2.2.2.4:5060/> |
>>> NULL | 0 | 1 | | test1 |
>>> | 4 | 40 | sip:2.2.2.5:5060 <http://2.2.2.5:5060/> |
>>> NULL | 0 | 1 | | test1 |
>>> | 5 | 40 | sip:2.2.2.6:5060 <http://2.2.2.6:5060/> |
>>> NULL | 0 | 1 | | test1 |
>>> +----+-------+------------------+--------+-------+--------+-------+-------------+
>>>
>>> However when I remove the 3 gateways one after another using
>>> the ./opensipsctl dispatcher rmgw command. I see that the
>>> gateway that was removed last can still be seen in the
>>> ds_list command even though 'dispatcher show' does not show
>>> any gateways present. Here is the sequence of commands I am
>>> executing-
>>>
>>> ./opensipsctl dispatcher rmgw 3
>>> ./opensipsctl fifo ds_list
>>> SET_NO:: 1
>>> SET:: 40
>>> URI:: sip:2.2.2.5:5060 <http://2.2.2.5:5060/> flag=A
>>> URI:: sip:2.2.2.6:5060 <http://2.2.2.6:5060/> flag=A
>>> ./opensipsctl dispatcher show
>>> dispatcher gateways
>>> +----+-------+------------------+--------+-------+--------+-------+-------------+
>>> | id | setid | destination | socket | flags | weight |
>>> attrs | description |
>>> +----+-------+------------------+--------+-------+--------+-------+-------------+
>>> | 4 | 40 | sip:2.2.2.5:5060 <http://2.2.2.5:5060/> |
>>> NULL | 0 | 1 | | test1 |
>>> | 5 | 40 | sip:2.2.2.6:5060 <http://2.2.2.6:5060/> |
>>> NULL | 0 | 1 | | test1 |
>>> +----+-------+------------------+--------+-------+--------+-------+-------------+
>>>
>>> ./opensipsctl dispatcher rmgw 4
>>> ./opensipsctl fifo ds_list
>>> SET_NO:: 1
>>> SET:: 40
>>> URI:: sip:2.2.2.6:5060 <http://2.2.2.6:5060/> flag=A
>>> ./opensipsctl dispatcher show
>>> dispatcher gateways
>>> +----+-------+------------------+--------+-------+--------+-------+-------------+
>>> | id | setid | destination | socket | flags | weight |
>>> attrs | description |
>>> +----+-------+------------------+--------+-------+--------+-------+-------------+
>>> | 5 | 40 | sip:2.2.2.6:5060 <http://2.2.2.6:5060/> |
>>> NULL | 0 | 1 | | test1 |
>>> +----+-------+------------------+--------+-------+--------+-------+-------------+
>>>
>>> ./opensipsctl dispatcher rmgw 5
>>> ./opensipsctl fifo ds_list
>>> SET_NO:: 1
>>> SET:: 40
>>> URI:: sip:2.2.2.6:5060 <http://2.2.2.6:5060/> flag=A
>>> ./opensipsctl dispatcher show
>>> dispatcher gateways
>>>
>>>
>>> Can you please help in understanding this behavior? Is this
>>> expected behavior? Is there something I am missing that
>>> needs to be done to correct this?
>>>
>>> --
>>> Thanks,
>>> Gunjan
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>> --
>> Thanks,
>> Gunjan
>
>
>
>
> --
> Thanks,
> Gunjan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20160119/2d7c9ef7/attachment-0001.htm>
More information about the Users
mailing list