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 <[email protected]> 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 > [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
