Hiredis + limit_execute bridge ends up in hangup(-ERR)
Hello list, Recently I've changed limit_execute engine from hash to hiredis and it leaded to some weird floating bug. Sometimes I get hangup(-ERR) with no further explanation, it doesn't occur each time, sometimes similar bridge can be fine, sometimes it results in immediate hangup(-ERR) with no channel B created (invite is not even coming out). When I switch the limit_execute engine back to hash it works fine. That occurs both on Centos 7 and Debian 8 machines, on Centos I have latest code from git branch v.1.6, on Debian - latest packages from FS repo. Here's the log of the problematic place https://pastebin.com/AJG8S5Yx <https://pastebin.com/AJG8S5Yx> If you need the full log please let me know. Redis benchmark showed that redis is working fine, I have only two machines per one redis-server, so it's not a socket or memory limit (but anyway I didn't check that yet, will do later today) Thanks in advance ________________________________ Alexandru Covalschi VoIP Engineer and System Administrator tel: +373 673 98 493
Well, I think I know the issue 127.0.0.1:6379> get 2_392_12791 "-9" I suppose we need some mechanism to prevent values less than 0 being stored in redis... ________________________________ Alexandru Covalschi VoIP Engineer and System Administrator tel: +373 673 98 493
30 янв. 2018 г., в 15:20, Alexandru Covalschi <568691@gmail.com> написал(а):
Hello list,
Recently I've changed limit_execute engine from hash to hiredis and it leaded to some weird floating bug. Sometimes I get hangup(-ERR) with no further explanation, it doesn't occur each time, sometimes similar bridge can be fine, sometimes it results in immediate hangup(-ERR) with no channel B created (invite is not even coming out). When I switch the limit_execute engine back to hash it works fine. That occurs both on Centos 7 and Debian 8 machines, on Centos I have latest code from git branch v.1.6, on Debian - latest packages from FS repo.
Here's the log of the problematic place https://pastebin.com/AJG8S5Yx <https://pastebin.com/AJG8S5Yx> If you need the full log please let me know. Redis benchmark showed that redis is working fine, I have only two machines per one redis-server, so it's not a socket or memory limit (but anyway I didn't check that yet, will do later today)
Thanks in advance
________________________________ Alexandru Covalschi VoIP Engineer and System Administrator tel: +373 673 98 493
Ok so now I've stopped freeswitches, deleted redis database, restarted redis, restarted freeswitches - and still have negative values in the database. What am I doing wrong? ________________________________ Alexandru Covalschi VoIP Engineer and System Administrator tel: +373 673 98 493
30 янв. 2018 г., в 18:18, Alexandru Covalschi <568691@gmail.com> написал(а):
Well, I think I know the issue 127.0.0.1:6379> get 2_392_12791 "-9"
I suppose we need some mechanism to prevent values less than 0 being stored in redis... ________________________________ Alexandru Covalschi VoIP Engineer and System Administrator tel: +373 673 98 493
30 янв. 2018 г., в 15:20, Alexandru Covalschi <568691@gmail.com <mailto:568691@gmail.com>> написал(а):
Hello list,
Recently I've changed limit_execute engine from hash to hiredis and it leaded to some weird floating bug. Sometimes I get hangup(-ERR) with no further explanation, it doesn't occur each time, sometimes similar bridge can be fine, sometimes it results in immediate hangup(-ERR) with no channel B created (invite is not even coming out). When I switch the limit_execute engine back to hash it works fine. That occurs both on Centos 7 and Debian 8 machines, on Centos I have latest code from git branch v.1.6, on Debian - latest packages from FS repo.
Here's the log of the problematic place https://pastebin.com/AJG8S5Yx <https://pastebin.com/AJG8S5Yx> If you need the full log please let me know. Redis benchmark showed that redis is working fine, I have only two machines per one redis-server, so it's not a socket or memory limit (but anyway I didn't check that yet, will do later today)
Thanks in advance
________________________________ Alexandru Covalschi VoIP Engineer and System Administrator tel: +373 673 98 493
Sounds like a bug in the module. Chris
On Jan 30, 2018, at 11:47, Alexandru Covalschi <568691@gmail.com> wrote:
Ok so now I've stopped freeswitches, deleted redis database, restarted redis, restarted freeswitches - and still have negative values in the database. What am I doing wrong?
________________________________ Alexandru Covalschi VoIP Engineer and System Administrator tel: +373 673 98 493
30 янв. 2018 г., в 18:18, Alexandru Covalschi <568691@gmail.com> написал(а):
Well, I think I know the issue 127.0.0.1:6379> get 2_392_12791 "-9"
I suppose we need some mechanism to prevent values less than 0 being stored in redis... ________________________________ Alexandru Covalschi VoIP Engineer and System Administrator tel: +373 673 98 493
30 янв. 2018 г., в 15:20, Alexandru Covalschi <568691@gmail.com> написал(а):
Hello list,
Recently I've changed limit_execute engine from hash to hiredis and it leaded to some weird floating bug. Sometimes I get hangup(-ERR) with no further explanation, it doesn't occur each time, sometimes similar bridge can be fine, sometimes it results in immediate hangup(-ERR) with no channel B created (invite is not even coming out). When I switch the limit_execute engine back to hash it works fine. That occurs both on Centos 7 and Debian 8 machines, on Centos I have latest code from git branch v.1.6, on Debian - latest packages from FS repo.
Here's the log of the problematic place https://pastebin.com/AJG8S5Yx If you need the full log please let me know. Redis benchmark showed that redis is working fine, I have only two machines per one redis-server, so it's not a socket or memory limit (but anyway I didn't check that yet, will do later today)
Thanks in advance
________________________________ Alexandru Covalschi VoIP Engineer and System Administrator tel: +373 673 98 493
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
Official FreeSWITCH Sites http://www.freeswitch.org http://confluence.freeswitch.org http://www.cluecon.com
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
May be a bug... Now I switched to ODBC engine, that one works fine - but I don't get any transfer to limit_exceeded - still that hangup(-ERR). Anyone has any idea? ________________________________ Alexandru Covalschi VoIP Engineer and System Administrator tel: +373 673 98 493
30 янв. 2018 г., в 18:47, Alexandru Covalschi <568691@gmail.com> написал(а):
Ok so now I've stopped freeswitches, deleted redis database, restarted redis, restarted freeswitches - and still have negative values in the database. What am I doing wrong?
________________________________ Alexandru Covalschi VoIP Engineer and System Administrator tel: +373 673 98 493
30 янв. 2018 г., в 18:18, Alexandru Covalschi <568691@gmail.com <mailto:568691@gmail.com>> написал(а):
Well, I think I know the issue 127.0.0.1:6379> get 2_392_12791 "-9"
I suppose we need some mechanism to prevent values less than 0 being stored in redis... ________________________________ Alexandru Covalschi VoIP Engineer and System Administrator tel: +373 673 98 493
30 янв. 2018 г., в 15:20, Alexandru Covalschi <568691@gmail.com <mailto:568691@gmail.com>> написал(а):
Hello list,
Recently I've changed limit_execute engine from hash to hiredis and it leaded to some weird floating bug. Sometimes I get hangup(-ERR) with no further explanation, it doesn't occur each time, sometimes similar bridge can be fine, sometimes it results in immediate hangup(-ERR) with no channel B created (invite is not even coming out). When I switch the limit_execute engine back to hash it works fine. That occurs both on Centos 7 and Debian 8 machines, on Centos I have latest code from git branch v.1.6, on Debian - latest packages from FS repo.
Here's the log of the problematic place https://pastebin.com/AJG8S5Yx <https://pastebin.com/AJG8S5Yx> If you need the full log please let me know. Redis benchmark showed that redis is working fine, I have only two machines per one redis-server, so it's not a socket or memory limit (but anyway I didn't check that yet, will do later today)
Thanks in advance
________________________________ Alexandru Covalschi VoIP Engineer and System Administrator tel: +373 673 98 493
participants (2)
-
Alexandru Covalschi
-
cmrienzo＠gmail.com