<div dir="ltr"><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>My thanks to everyone who helped and my apologies for apparently goofing up my own testing before posting.</div><div><br></div><div> - Jock</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 23, 2015 at 3:55 PM, Ovidiu Sas <span dir="ltr"><<a href="mailto:osas@voipembedded.com" target="_blank">osas@voipembedded.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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.</p>
<p dir="ltr">Regards,<br>
Ovidiu Sas</p><div class="HOEnZb"><div class="h5">
<div style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>I have confirmed that turning off db_text caching allows me to reload - my thanks!</div><div><br></div><div> - Jock </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 23, 2015 at 1:25 PM, Ovidiu Sas <span dir="ltr"><<a href="mailto:osas@voipembedded.com" target="_blank">osas@voipembedded.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You should try on the latest stable (or the new 2.1 release candidate).<br>
AFAIR, this used to work and reload works for sure.<br>
You need to read the documentation on the db_text module and make sure<br>
that you are not using db_text in cached mode.<br>
<br>
Regards,<br>
Ovidiu Sas<br>
<div><div><br>
On Thu, Apr 23, 2015 at 2:16 PM, Jock McKechnie<br>
<<a href="mailto:jock.mckechnie@gmail.com" target="_blank">jock.mckechnie@gmail.com</a>> wrote:<br>
> Thank you kindly, Liviu;<br>
><br>
> Unfortunately reordering the gateways makes no difference - I believe it's<br>
> implicitly doing an ORDER BY of the destination field. I have submitted a<br>
> bug.<br>
><br>
> As a side note, curiously ds_reload does not actually work from dbtext<br>
> dispatcher tables. I wasn't sure if this was a "bug" or a "feature" so I<br>
> have never asked, I wasn't sure if it was related to how dbtext was<br>
> implemented that it was simply not an option. Should it work, do you think?<br>
><br>
> Also, while I'm asking - do you know when someone will update the Debian<br>
> repository for OpenSIPs? It's still listing 1.8.5 as the latest release, and<br>
> you're now up to 1.8.7 -- and presumably any 'fix' for me will be in a later<br>
> subversion too. Is there someone I can suck up to who will push the latest<br>
> packages when the time comes?<br>
><br>
> My thanks again for your suggestions;<br>
><br>
> - Jock<br>
><br>
> On Thu, Apr 23, 2015 at 5:23 AM, Liviu Chircu <<a href="mailto:liviu@opensips.org" target="_blank">liviu@opensips.org</a>> wrote:<br>
>><br>
>> Hello Jock,<br>
>><br>
>> I can definitely confirm that the issue is specific to "db_text".<br>
>> Dispatcher is just storing the gateways exactly as they arrive from the<br>
>> generic db driver.<br>
>><br>
>> Two solutions:<br>
>> - quick-and-dirty: reverse the order of the gateways of each setid in<br>
>> dbtext's "dispatcher" file (you could even automate this!), then do<br>
>> "opensipsctl fifo ds_reload"<br>
>> - slow-and-clean: submit a bug report on GitHub [1]. should be solved<br>
>> during the upcoming week<br>
>><br>
>> [1]<br>
>> <a href="https://github.com/OpenSIPS/opensips/issues?q=is%3Aopen+is%3Aissue+label%3Abug" target="_blank">https://github.com/OpenSIPS/opensips/issues?q=is%3Aopen+is%3Aissue+label%3Abug</a><br>
>><br>
>> Best regards,<br>
>><br>
>> Liviu Chircu<br>
>> OpenSIPS Developer<br>
>> <a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a><br>
>><br>
>> On <a href="tel:22.04.2015%2019" value="+12204201519" target="_blank">22.04.2015 19</a>:37, Jock McKechnie wrote:<br>
>><br>
>> My apologies if this one has been covered before, my google fu is failing<br>
>> me, but we're running a pretty large load out of OpenSIPS v1.8.5 (LTS) and<br>
>> have struck an oddity that I don't appear to have noticed before.<br>
>><br>
>> We're using the dispatcher module with a dbtext database source and the<br>
>> order that the entries are being loaded are not in row order. I do see the<br>
>> dbtext documentation is clear that ORDER BY is not possible, so perhaps this<br>
>> is a unfixable situation with this DB back-end, but I kind of assumed that<br>
>> the order would always match the order in the dbtext data file itself (based<br>
>> on the id auto column).<br>
>><br>
>> There are only two entries in the dispatcher table:<br>
>> id(int,auto) setid(int) destination(string) socket(string,null) flags(int)<br>
>> weight(int) attrs(string) description(string)<br>
>> 0:1:sip\:192.168.55.9\:5060::0:1:'':'handler01'<br>
>> 1:1:sip\:192.168.55.8\:5060::0:1:'':'handler02'<br>
>><br>
>> When I run a 'ds_list' (calls through the system prove it's using the<br>
>> order below, also):<br>
>> SET_NO:: 1<br>
>> SET:: 1<br>
>> URI:: sip:192.168.55.8<br>
>> URI:: sip:192.168.55.9<br>
>><br>
>> Clearly the dbtext module is sorting, or possibly unsorting in a hash, on<br>
>> the destination. If I was just doing a round-robin, which normally I am,<br>
>> it's completely moot - but today's problem is I'm trying to implement a<br>
>> "failover" (ds_select_domain("1", "8")) scenario which means I need the data<br>
>> to remain in order.<br>
>><br>
>> Suggestions? Hopefully other than "move to a real DB" as we're trying to<br>
>> keep this as lean as possible.<br>
>><br>
>> My thanks for your time!<br>
>><br>
>> - Jock<br>
>><br>
>><br>
>> _______________________________________________<br>
>> Users mailing list<br>
>> <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Users mailing list<br>
>> <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
>> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> Users mailing list<br>
> <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
><br>
<br>
<br>
<br>
</div></div><span><font color="#888888">--<br>
VoIP Embedded, Inc.<br>
<a href="http://www.voipembedded.com" target="_blank">http://www.voipembedded.com</a><br>
</font></span><div><div><br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div>
<br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></div>
</div></div><br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br></blockquote></div><br></div>