Thank you, Rupa. I will try to change it to hash and see what happen. Just curiosity, is there any advantage/disadvantage using hash vs. db. I am currently not doing any cluster. I picked mod_db because it was mentioned first in the Wiki/Limit :) Dorn. On Tue, Oct 19, 2010 at 9:00 AM, Rupa Schomaker <rupa@rupa.com> wrote:
Thanks for the response. From re-reviewing the code, I can't see how this error can occur in actual usage. I don't see a code path where the callback handler would be called without a corresponding backend set.
Without knowing how this condition is occurring I can't say whether adding traffic would increase the rate at which you see the error nor how to go about preventing the error.
One question: you are using the db backend. I assume this is because you have a cluster of machines? If not, maybe try the hash backend and see if you get different behavior?
The code in question should not depend on the backend but maybe try "just in case".
On Tue, Oct 19, 2010 at 10:23 AM, DJB International <djbinter@gmail.com>wrote:
Rupa,
Thank you for your clear response.
This issue happened to be on my production server. I can reproduce since it happened almost every day, but only happened to 1-2 calls max out of many concurrent calls. Thus, I am not that concern right now until I started to see more of this error.
I use limit just to keep track of concurrent calls per each gateway similar to below:
For inbound: <action application="limit" data="db inbound 5.6.7.8 10000"/>
For outbound: <action application="limit_execute" data="db outbound 1.2.3.4 10000 bridge sofia/gateway/1.2.3.4/${destination_number}<http://1.2.3.4/$%7Bdestination_number%7D>" />
My next question would be whether it would generate more of this errors if I routed more calls to this server, and if there is any recommendation on how to prevent it.
Thank you, Dorn.
On Tue, Oct 19, 2010 at 5:56 AM, Rupa Schomaker <rupa@rupa.com> wrote:
This is a "shouldn't happen" sanity check you are tripping over -- I probably should have worded the error message better.
Immediate cause is that the list of backends (hash, sql, etc) that have registered interest in this call is empty. This shouldn't happen because we register the handler at the same time that we set the channel var of interested backends.
Can you find a way to reproduce this reliably?
The effect of this would be to (potentially) not decrement a counter when we should have.
On Mon, Oct 18, 2010 at 7:31 PM, DJB International <djbinter@gmail.com>wrote:
I have noticed once in a while in the log file with the following error:
[ERR] switch_limit.c:86 Unset limit backendlist!
What exactly would cause this error?
Thank you, Dorn B.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- -Rupa
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- -Rupa
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org