Re: [OpenSIPS-Users] Opensips 1.8 ds_list behavior in dispatcher

2016-01-19 Thread Bogdan-Andrei Iancu

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 
> 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  | 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
> 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
 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 |


Re: [OpenSIPS-Users] Opensips 1.8 ds_list behavior in dispatcher

2016-01-18 Thread Gunjan Korlekar
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 
wrote:

> Hi Gunjan,
>
> have you checked the opensips logs for any potential errors ? maybe the
> reload fails.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://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 | 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 <
> bog...@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 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 

Re: [OpenSIPS-Users] Opensips 1.8 ds_list behavior in dispatcher

2016-01-15 Thread Bogdan-Andrei Iancu

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  | 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 
> 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
 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 

Re: [OpenSIPS-Users] Opensips 1.8 ds_list behavior in dispatcher

2016-01-14 Thread Bogdan-Andrei Iancu

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 
 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 list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Opensips 1.8 ds_list behavior in dispatcher

2016-01-14 Thread Gunjan Korlekar
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 
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
>   |
>
> 

[OpenSIPS-Users] Opensips 1.8 ds_list behavior in dispatcher

2016-01-13 Thread Gunjan Korlekar
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 list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users