[SR-Users] RPC command dlg.list (for large amounts of dialogs)

[Daniel-Constantin Mierla]

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:
>>
>
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda