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: