[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