Hi,
There does not seem to be a way to update the limits of pipes dynamically.
If I don't use DB backing, there is no MI/RPC command to flush existing pipes and cause them to be recreated with reconstituted limits.
If I use DB backing and add pipes to the pl_pipes table, an SQL update to the limit column does not influence existing pipes that have been loaded from the DB on startup.
Am I missing something, or does the existing feature set of the module simply not allow this?
Thanks,
On 10/19/2014 03:25 AM, Alex Balashov wrote:
If I don't use DB backing, there is no MI/RPC command to flush existing pipes and cause them to be recreated with reconstituted limits.
I should clarify: there is the pl.set_pipe command, but it does not like the pipe name being an integer as given in the example, i.e.
kamcmd pl.set_pipe 2 RED 10
This gives me:
[root@centosity6 kamailio]# kamcmd pl.set_pipe 1 TAILDROP 50 error: 400 - error at parameter 0: expected string type but record doesn't match type
-- Alex
On 19/10/14 09:28, Alex Balashov wrote:
On 10/19/2014 03:25 AM, Alex Balashov wrote:
If I don't use DB backing, there is no MI/RPC command to flush existing pipes and cause them to be recreated with reconstituted limits.
I should clarify: there is the pl.set_pipe command, but it does not like the pipe name being an integer as given in the example, i.e.
kamcmd pl.set_pipe 2 RED 10
This gives me:
[root@centosity6 kamailio]# kamcmd pl.set_pipe 1 TAILDROP 50 error: 400 - error at parameter 0: expected string type but record doesn't match type
This is kamcmd auto-converting numbers to integer, use:
kamcmd pl.set_pipe s:2 RED 10
Cheers, Daniel
Hello,
On 19/10/14 09:25, Alex Balashov wrote:
Hi,
There does not seem to be a way to update the limits of pipes dynamically.
If I don't use DB backing, there is no MI/RPC command to flush existing pipes and cause them to be recreated with reconstituted limits.
If I use DB backing and add pipes to the pl_pipes table, an SQL update to the limit column does not influence existing pipes that have been loaded from the DB on startup.
Am I missing something, or does the existing feature set of the module simply not allow this?
I haven't really considered that, but, but on the other hand, that could be misinterpretation bug of what would be a dynamic pipe -- the code is there, just needs to refresh the value in memory. I will look over it as I get some time during traveling to Astricon (read -- it can take a bit to show up).
Cheers, Daniel
Hello,
I pushed a patch to master for handling this case. Can you give it a try and see if the limit gets updated as expected?
Cheers, Daniel
On 19/10/14 11:50, Daniel-Constantin Mierla wrote:
Hello,
On 19/10/14 09:25, Alex Balashov wrote:
Hi,
There does not seem to be a way to update the limits of pipes dynamically.
If I don't use DB backing, there is no MI/RPC command to flush existing pipes and cause them to be recreated with reconstituted limits.
If I use DB backing and add pipes to the pl_pipes table, an SQL update to the limit column does not influence existing pipes that have been loaded from the DB on startup.
Am I missing something, or does the existing feature set of the module simply not allow this?
I haven't really considered that, but, but on the other hand, that could be misinterpretation bug of what would be a dynamic pipe -- the code is there, just needs to refresh the value in memory. I will look over it as I get some time during traveling to Astricon (read -- it can take a bit to show up).
Cheers, Daniel
-
Alex Balashov -
Daniel-Constantin Mierla