[OpenSIPS-Users] Dispatcher/dbtext load order incorrect

Bogdan-Andrei Iancu bogdan at opensips.org
Fri May 8 11:52:17 CEST 2015


Hi all,

Just for the sake of completion, this problem was fixed in all OpenSIPS 
versions, after Jock's report:
     https://github.com/OpenSIPS/opensips/issues/479

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 24.04.2015 00:38, Jock McKechnie wrote:
> 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 
> <mailto: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
>     <mailto: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 <mailto: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 <mailto: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 <tel:22.04.2015%2019>: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 <mailto:Users at lists.opensips.org>
>         >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>         >>
>         >>
>         >>
>         >> _______________________________________________
>         >> Users mailing list
>         >> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>         >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>         >>
>         >
>         >
>         > _______________________________________________
>         > Users mailing list
>         > Users at lists.opensips.org <mailto: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 <mailto:Users at lists.opensips.org>
>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto: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/20150508/66f0d2bb/attachment-0001.htm>


More information about the Users mailing list