[OpenSIPS-Users] Dispatcher/dbtext load order incorrect

[Jock McKechnie]

Thank you kindly, Liviu;

Unfortunately reordering the gateways makes no difference - I believe it's
implicitly doing an ORDER BY of the destination field. I have submitted a
bug.

As a side note, curiously ds_reload does not actually work from dbtext
dispatcher tables. I wasn't sure if this was a "bug" or a "feature" so I
have never asked, I wasn't sure if it was related to how dbtext was
implemented that it was simply not an option. Should it work, do you think?

Also, while I'm asking - do you know when someone will update the Debian
repository for OpenSIPs? It's still listing 1.8.5 as the latest release,
and you're now up to 1.8.7 -- and presumably any 'fix' for me will be in a
later subversion too. Is there someone I can suck up to who will push the
latest packages when the time comes?

My thanks again for your suggestions;

 - Jock

On Thu, Apr 23, 2015 at 5:23 AM, Liviu Chircu <liviu at opensips.org> wrote:

>  Hello Jock,
>
> I can definitely confirm that the issue is specific to "db_text".
> Dispatcher is just storing the gateways exactly as they arrive from the
> generic db driver.
>
> Two solutions:
>     - quick-and-dirty: reverse the order of the gateways of each setid in
> dbtext's "dispatcher" file (you could even automate this!), then do
> "opensipsctl fifo ds_reload"
>     - slow-and-clean: submit a bug report on GitHub [1]. should be solved
> during the upcoming week
>
> [1]
> https://github.com/OpenSIPS/opensips/issues?q=is%3Aopen+is%3Aissue+label%3Abug
>
> Best regards,
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 22.04.2015 19:37, Jock McKechnie wrote:
>
>  My apologies if this one has been covered before, my google fu is
> failing me, but we're running a pretty large load out of OpenSIPS v1.8.5
> (LTS) and have struck an oddity that I don't appear to have noticed before.
>
>  We're using the dispatcher module with a dbtext database  source and the
> order that the entries are being loaded are not in row order. I do see the
> dbtext documentation is clear that ORDER BY is not possible, so perhaps
> this is a unfixable situation with this DB back-end, but I kind of assumed
> that the order would always match the order in the dbtext data file itself
> (based on the id auto column).
>
>  There are only two entries in the dispatcher table:
> id(int,auto) setid(int) destination(string) socket(string,null) flags(int)
> weight(int) attrs(string) description(string)
> 0:1:sip\:192.168.55.9\:5060::0:1:'':'handler01'
> 1:1:sip\:192.168.55.8\:5060::0:1:'':'handler02'
>
>  When I run a 'ds_list' (calls through the system prove it's using the
> order below, also):
> SET_NO:: 1
> SET:: 1
>          URI:: sip:192.168.55.8
>          URI:: sip:192.168.55.9
>
>  Clearly the dbtext module is sorting, or possibly unsorting in a hash,
> on the destination. If I was just doing a round-robin, which normally I am,
> it's completely moot - but today's problem is I'm trying to implement a
> "failover" (ds_select_domain("1", "8")) scenario which means I need the
> data to remain in order.
>
>  Suggestions? Hopefully other than "move to a real DB" as we're trying to
> keep this as lean as possible.
>
>  My thanks for your time!
>
>   - Jock
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150423/ec1c595c/attachment-0001.htm>