Hello,
can you change to a stream socket? Otherwise there might be some OS
limits in place.
The MI was changed to use system memory, the same is with ctl module.
But the ctl uses a local buffer to built the output, that's why it needs
the max sizes via mod params. Also, irrc, Richard Fuchs removed some
iovec limitations in the module (they should be in 4.0.x).
kamcmd uses system malloc, afaik.
With all these, the limits are likely to be from OS.
Cheers,
Daniel
On 8/14/13 2:41 PM, Alex Balashov wrote:
By the way, I have not tried connecting to the binrpc
interface via
network socket and retrieving the output that way. I am only trying
to connect to it via the 'kamcmd' utility via the default UNIX domain
socket.
On 08/14/2013 08:37 AM, Alex Balashov wrote:
Hello,
I am having trouble getting a large list of dialogs (800+) out of
Kamailio using the dlg.list binrpc command.
I posted a while back that the list of dialog data was coming back
truncated, and was told to increase:
modparam("ctl", "binrpc_max_body_size", ...)
modparam("ctl", "binrpc_struct_max_body_size", ...)
I did that, increasing the buffers to 20 MB. Then, when I ran
sercmd -s unixs:/tmp/kamailio_ctl dlg.list
I got:
ERROR: reply too big
which clearly seemed to be on the client side now.
So, I looked in the sources for sercmd (now sercmd), in
sip-router/utils/sercmd/sercmd.c, and found this:
if ((ret=get_reply(s, reply_buf, MAX_REPLY_SIZE, cookie, &in_pkt,
&msg_body))<0){
switch(ret){
case -1:
goto error_read;
case -2:
goto error_parse;
case -3:
goto error_cookie;
case -4:
goto error_toobig;
So, I adjusted:
#define MAX_REPLY_SIZE
to several megabytes as well, and tried the same with MAX_BODY_SIZE too.
Now, when I run the dlg.list command, it just hangs and never returns
anything. It was stuck there for well over 20 minutes. An 'strace' on
sercmd reveals that it receives what appears to be the full listing, but
keeps wanting to read() more. I don't have the exact output handy at
the moment, but it looked like this:
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, path="/tmp/kamailio_ctl"}, 110) = 0
writev(3, [{"\241\3\v%s\230\4", 7}, {"\221\tdlg.list\0", 11}], 2)
= 18
read(3, "\241\27\16\257%s\230\4\221Hhash:551:9521 state:4 "...,
786432) = 340000
read(3,
[just hangs here]
Now, I would have assumed that perhaps there is more to read and the
output is not returning due to some endless locking of the dialog
profile table, which is constantly changing. However, that cannot be
the case because
kamctl fifo dlg_list
works fine for any amount of dialogs, and always returns all the data
near-instantly!
Any assistance is much appreciated!
-- Alex
[1] I don't have the output handy at the moment, but it was a read()
value: