Hi,
I'm requesting 'dlg.list' from JSONRPC-S via XHTTP on a rather busy server, i.e.
event_route[xhttp:request] { xlog("L_INFO", 'action=ER-XHTTP-REQUEST | ret=LOG_HTTP_REQ | data={"method": "$rm", "path": "$hu", "source": "$si:$sp"}');
# Digest challenge omitted.
if($hu =~ "^/rpc") { xlog("L_INFO", 'action=ER-XHTTP-REQUEST | ret=JSON_RPC_REQUEST | data={"path": "$hu"}');
jsonrpc_dispatch(); } else { xhttp_reply("404", "Not Found", "text/html", ""); } }
# curl --digest -v \ -X POST -H 'Content-Type: application/json' \ -H 'Call-ID: abc12' \ -d '{"jsonrpc": "2.0", "method": "dlg.list", "id": "0deadb33f"}' \ 'http://sipus_adm:raSheinmet4@10.0.62.74:5060/csrp_rpc/'
and finding that when there's more than a hundred or so dialogs in play, Kamailio abruptly closes the connection in the middle of returning the output:
----- "tag": "AF5DA9B4-6D5", "contact": "sip:14045551212@xxx.xxx.xxx.xxx:5060", "cseq": "0", "route_set": "", "socket": "udp:xxx.xxx.xxx.xxx:5060" }, * transfer closed with 151674 bytes remaining to read * Closing connection #0 curl: (18) transfer closed with 151674 bytes remaining to read "profiles": ["total",[root@proxy kamailio]# ------
I can't seem to figure out what parameters regulate this. I'm using the following TCP settings:
tcp_async=yes tcp_connect_timeout=5 tcp_crlf_ping=no tcp_keepalive=yes tcp_keepidle=30 tcp_linger2=10 tcp_max_connections=4096 tcp_send_timeout=3 tcp_accept_no_cl=yes tcp_wq_blk_size=65535 tcp_wq_max=20971520
But this doesn't seem to have had any effect.
Any help appreciated!
Thanks,
-- Alex
FWIW, the total response size according to Content-Length is close to 1 MB:
-- Header says content-length is: 737406 Chunked: 5660 Chunked: 14348 Chunked: 17244 ABORT! Runtime RPC client error: JSON parse error - SyntaxError: Unexpected end of input --
The "ABORT!" comes from an event fired when the server (Kamailio) aborts the connection and closes the socket.
-- Alex
On 08/09/2016 12:27 PM, Alex Balashov wrote:
Have you set the parameter:
https://www.kamailio.org/wiki/cookbooks/devel/core#tcp_conn_wq_max
Cheers, Daniel
On 09/08/16 18:46, Alex Balashov wrote:
I have indeed - it was in my original post:
tcp_wq_max=20971520
On August 10, 2016 3:00:22 AM EDT, Daniel-Constantin Mierla miconda@gmail.com wrote:
-- Alex
-- Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
On 10/08/16 09:01, Alex Balashov wrote:
I have indeed - it was in my original post:
tcp_wq_max=20971520
But this is not tcp_conn_wq_max
Cheers, Daniel
Huh. You're right, it's not! :-)
What value should I set it to for a 0.5 MB - 1 MB payload?
On August 10, 2016 3:03:32 AM EDT, Daniel-Constantin Mierla miconda@gmail.com wrote:
-- Alex
-- Principal, Evariste Systems LLC (www.evaristesys.com)
Sent from my Google Nexus.
On 10/08/16 09:04, Alex Balashov wrote:
Huh. You're right, it's not! :-)
What value should I set it to for a 0.5 MB - 1 MB payload?
Try larger than what you expect. You may need to adjust tcp_wq_max if you have many parallel large responses.
Cheers, Daniel
-
Alex Balashov -
Daniel-Constantin Mierla