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

[Federico Edorna]

"weights" was my first choice, but I changed my mind because we were not
using "atrrs" column neither. Anyway, I will keep in mind your suggestion.

Many Thanks!

On Wed, Aug 19, 2015 at 10:59 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi Federico,
>
> Well, it is a good workaround. As a hint, if you do not want to sacrifice
> the "attrs" column for ordering (attributes are really useful to have in
> many usage scenarios), you can better use the "weights" column.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
> On 18.08.2015 17:11, Federico Edorna wrote:
>
> 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/20150819/afed7614/attachment.htm>