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:
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 "...,
- = 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:
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:
On 08/14/2013 10:01 AM, Daniel-Constantin Mierla wrote:
can you change to a stream socket? Otherwise there might be some OS limits in place.
I'll try that, thanks Daniel.
But, it's now no longer complaining about sizes: it just hangs. Is that still a symptom of running into limits?
-- Alex
On 8/14/13 4:02 PM, Alex Balashov wrote:
On 08/14/2013 10:01 AM, Daniel-Constantin Mierla wrote:
can you change to a stream socket? Otherwise there might be some OS limits in place.
I'll try that, thanks Daniel.
But, it's now no longer complaining about sizes: it just hangs. Is that still a symptom of running into limits?
Not sure, but if it hangs, attach with gdb to the pid and do a backtrace to see where it is stuck:
gdb /path/to/executable __PID__
Cheers, Daniel
On 08/14/2013 10:01 AM, Daniel-Constantin Mierla wrote:
can you change to a stream socket? Otherwise there might be some OS limits in place.
Hi Daniel,
I tried TCP and it didn't help.
-- Alex
Does it still hang? Can you attach with gdb and see where it is stuck?
Cheers, Daniel
On Wed, Sep 11, 2013 at 12:28 PM, Alex Balashov abalashov@evaristesys.comwrote:
On 08/14/2013 10:01 AM, Daniel-Constantin Mierla wrote:
can you change to a stream socket? Otherwise there might be some OS
limits in place.
Hi Daniel,
I tried TCP and it didn't help.
-- Alex
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
______________________________**_________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**usershttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
At some point we need a framed protocol for this kind of lists. Kamailio builds it in memory before sending. We do need something that sends out chunks.
/O
14 aug 2013 kl. 14:41 skrev Alex Balashov abalashov@evaristesys.com:
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:
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
On 09/02/2013 03:19 AM, Olle E. Johansson wrote:
At some point we need a framed protocol for this kind of lists. Kamailio builds it in memory before sending. We do need something that sends out chunks.
Perhaps.
In my case, there were about ~800 dialogs. Assuming 1 kB per dialog - even 2 kB, fine, or even 4 kB, given page sizes - that's only a few megabytes. I don't think that's a big deal to build in memory these days, although back when I had my 386 SX/40, I would've been pretty angry.
On 9/2/13 9:23 AM, Alex Balashov wrote:
On 09/02/2013 03:19 AM, Olle E. Johansson wrote:
At some point we need a framed protocol for this kind of lists. Kamailio builds it in memory before sending. We do need something that sends out chunks.
Perhaps.
In my case, there were about ~800 dialogs. Assuming 1 kB per dialog - even 2 kB, fine, or even 4 kB, given page sizes - that's only a few megabytes. I don't think that's a big deal to build in memory these days, although back when I had my 386 SX/40, I would've been pretty angry.
I think for ctl there was an enhancement by Richard Fuchs to deal better with full iovec structure. But with other modules might require some different approach, e.g., the xmlrpc typically has to build some xml structure in memory and then print it in a buffer.
Cheers, Daniel