[OpenSIPS-Users] Dispatcher Order SQL DB - version 1.11.5

Federico Edorna fedorna at anura.com.ar
Tue Aug 18 16:11:10 CEST 2015


In my table there is a priority column! ;) I don't know where did I get
that schema... sorry, my mistake.

Now, going back to the workarround (just in case someone has the same
issue), since I'm not using the attrs column value in the config file, I
will use that column to order the set. To accomplish that, I tried with the
following patch in modules/dispatcher/dispatch.c


--- /tmp/dispatch.c 2015-08-18 10:40:27.461325458 -0300
+++ ./dispatch.c 2015-08-18 10:39:45.941081837 -0300
@@ -699,7 +699,7 @@
  memset( d_data, 0, sizeof(ds_data_t));

  /*select the whole table and all the columns*/
- if(ds_dbf.query(ds_db_handle,0,0,0,query_cols,0,6,0,&res) < 0) {
+ if(ds_dbf.query(ds_db_handle,0,0,0,query_cols,0,6,&ds_dest_attrs_col,&res)
< 0) {
  LM_ERR("error while querying database\n");
  goto error;
  }


That is, ds_dbf.query sorts the table using &ds_dest_attrs_col. Now the
postgres log shows:

2015-08-18 10:46:51 ART [9503]: [2-1] LOG:  duration: 0.224 ms  statement:
select setid,destination,socket,state,weight,attrs from sbc.dispatcher * order
by attrs*

I will try with this (at my own risk...) until we upgrade to 2.x

Thanks!


On Tue, Aug 18, 2015 at 8:45 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Federico,
>
> There is no "priority" field in the dispatcher table in 1.11 :
>     http://www.opensips.org/Documentation/Install-DBSchema-1-11#AEN4123
>
> wrong table ?
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 17.08.2015 21:03, Federico Edorna wrote:
>
> Actually the table has the priority column in ver 1.11. Anyway, thanks for
> your response Bogdan, I will try to find a workarround for this version
> until we upgrade to 2.x.
>
> Thanks & Regards
>
> Federico
>
> On Mon, Aug 17, 2015 at 5:56 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>
> wrote:
>
>> Hi Federico,
>>
>> This is an known issue with the older versions of OpenSIPS (not being
>> able set an order for the records). In 2.1 this was solved by having a
>> priority column which dictates the oder of usage of records.
>>
>> For versions before 2.1, you have to rely on the oder provided by DB :(.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>>
>> On 14.08.2015 20:49, Federico Edorna wrote:
>>
>> Hello Guys,
>> I'm using dispatcher module with postgres database. The ds_select_dst
>> function in the script file is used like this:
>>
>> ds_select_dst("$(var(ds_set){s.int})","8");
>>
>> that is, using "8" algorithm (first entry in set is chosen) because I
>> need to use always the same destination in the set while it is up. If not,
>> then the backup destination (next in the set) is used.
>>
>> The problem I've found is that when the sets are read from database
>> (opensips restart or fifo ds_reload), the select hasn't a "order" directive
>>  in the sql statement, so the order is defined depending of the last tuple
>> update. The postgres log shows this when doing a fifo ds_reload:
>>
>> 2015-08-14 11:36:53 ART [23684]: [1-1] LOG:  duration: 0.582 ms
>>  statement: select setid,destination,socket,state,weight,attrs from
>> sbc.dispatcher
>>
>> And the syslog & debug=6 shows:
>>
>> DBG:db_postgres:db_postgres_submit_query: 0x7f4344987010
>> PQsendQuery(select setid,destination,socket,state,weight,attrs from
>> sbc.dispatcher )
>>
>> So, any sql update in any column will change the order in the set because
>> we don't have the "order by priority" for example.
>>
>> Is there any way to use the weight, priority or the id to have a fixed
>> order in the set(s) destination?
>>
>>
>> Many Thanks!
>> Federico
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150818/728c3304/attachment.htm>


More information about the Users mailing list