[OpenSIPS-Users] Dispatcher/dbtext load order incorrect

Thu Apr 23 23:38:37 CEST 2015

How extraordinarily odd. I was absolutely certain I had tested this. I
spent a lot of time monkeying around with the db_text file to try and
accidentally make it work before I submitted the question, but, it
certainly works. Hmz.

Well, er, in this case, I think my issue has been solved - including the
lack of reload. I think I'll update the bug to include this information and
let the devs decide whether they want to mess with it or not. If they do,
they'll break this existing behaviour which is... logically wrong, but
controllable. I'll let their wisdom decide for them.

My thanks to everyone who helped and my apologies for apparently goofing up
my own testing before posting.

 - Jock

On Thu, Apr 23, 2015 at 3:55 PM, Ovidiu Sas <osas at voipembedded.com> wrote:

> Even the destination should be respected. The cached list is the same as
> the one listed through the mi command. Switch the order on your db_text
> file, reload and you should see the list on the mi command reversed.
>
> Regards,
> Ovidiu Sas
> Unfortunately upgrading the OpenSIPS we have in deployment is not likely
> to happen - we have something like 250 OpenSIPS systems running and
> upgrading just one for this bug is... probably not going to get past the IT
> nuts. We picked 1.8 as we were moving up from 1.6 and this would provide
> the smallest jump - and is an LTS.
>
> We do run db_text in caching mode - the logic behind it was so that every
> call would not require a disk check. However, upon rethinking this (as
> prompted by your suggestion) I now realise that dispatcher does the
> caching, so we should turn it off on db_text.
>
> I have confirmed that turning off db_text caching allows me to reload - my
> thanks!
>
>  -  Jock
>
>
> On Thu, Apr 23, 2015 at 1:25 PM, Ovidiu Sas <osas at voipembedded.com> wrote:
>
>> You should try on the latest stable (or the new 2.1 release candidate).
>> AFAIR, this used to work and reload works for sure.
>> You need to read the documentation on the db_text module and make sure
>> that you are not using db_text in cached mode.
>>
>> Regards,
>> Ovidiu Sas
>>
>> On Thu, Apr 23, 2015 at 2:16 PM, Jock McKechnie
>> <jock.mckechnie at gmail.com> wrote:
>> > 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 Developer
>> >> http://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 list
>> >> Users at lists.opensips.org
>> >> http://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
>> >>
>> >
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.opensips.org
>> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> >
>>
>>
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://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
>
>
> _______________________________________________
> 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/ad1d345c/attachment.htm>