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 | 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 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 <[email protected]>
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 Developerhttp://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 0 'test1'
> ./opensipsctl dispatcher addgw 40 sip:2.2.2.5:5060 0 'test1'
> ./opensipsctl dispatcher addgw 40 sip: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 flag=A
> URI:: sip:2.2.2.5:5060 flag=A
> URI:: sip: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 | NULL | 0 | 1 | | test1
> |
> | 4 | 40 | sip:2.2.2.5:5060 | NULL | 0 | 1 | | test1
> |
> | 5 | 40 | sip: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 flag=A
> URI:: sip: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 | NULL | 0 | 1 | | test1
> |
> | 5 | 40 | sip: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 flag=A
> ./opensipsctl dispatcher show
> dispatcher gateways
>
> +----+-------+------------------+--------+-------+--------+-------+-------------+
> | id | setid | destination | socket | flags | weight | attrs |
> description |
>
> +----+-------+------------------+--------+-------+--------+-------+-------------+
> | 5 | 40 | sip: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 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
> [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
--
Thanks,
Gunjan
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
