[OpenSIPS-Users] Dispatcher/dbtext load order incorrect

Thu Apr 23 22:42:23 CEST 2015

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20150423/1e2c69ba/attachment.htm>