JSONRPC-S module README has:
2. Limitations
This module does not implement asynchronous RPC commands. It is unlikely that asynchronous RPC commands will be executed from an JSON-RPC over HTTP client.
Does this mean that, for example, tm.t_uac_wait command cannot be executed using JSON-RPC over HTTP?
If so, why "it is unlikely that asynchronous RPC commands will be executed from an JSON-RPC over HTTP client", since those commands are currently commonly executed from XMLRPC client using xmlrpc module?
It would be nice if JSONRPC-S module could be used as replacement of xmlrpc module.
-- Juha
Hello,
On 17.08.18 09:48, Juha Heinanen wrote:
JSONRPC-S module README has:
- Limitations
This module does not implement asynchronous RPC commands. It is unlikely that asynchronous RPC commands will be executed from an JSON-RPC over HTTP client.Does this mean that, for example, tm.t_uac_wait command cannot be executed using JSON-RPC over HTTP?
If so, why "it is unlikely that asynchronous RPC commands will be executed from an JSON-RPC over HTTP client", since those commands are currently commonly executed from XMLRPC client using xmlrpc module?
It would be nice if JSONRPC-S module could be used as replacement of xmlrpc module.
the module has support for async commands sent over HTTP, but not over other transport layers, iirc.
That remark needs to be updated.
Cheers, Daniel
I cave tm.t_uac_wait over JSONRPC-S a try and got a crash:
(gdb) where #0 0x00007ff1ec5e6cf9 in jsonrpc_send (ctx=0x7ff1e27066c8) at jsonrpcs_mod.c:390 #1 0x00007ff1ec5ee5ac in jsonrpc_delayed_ctx_close (dctx=0x7ff1e2706660) at jsonrpcs_mod.c:1037 #2 0x00007ff1f1deb375 in rpc_uac_callback (t=0x7ff1e26d91e0, type=1024, ps=0x7ffceb219720) at rpc_uac.c:391 #3 0x00007ff1f1e15d65 in run_trans_callbacks_internal (cb_lst=0x7ff1e26d9250, type=1024, trans=0x7ff1e26d91e0, params=0x7ffceb219720) at t_hooks.c:260 #4 0x00007ff1f1e15e89 in run_trans_callbacks (type=1024, trans=0x7ff1e26d91e0, req=0x0, rpl=0x7ff1f4b06130, code=200) at t_hooks.c:287 #5 0x00007ff1f1dca327 in local_reply (t=0x7ff1e26d91e0, p_msg=0x7ff1f4b06130, branch=0, msg_status=200, cancel_data=0x7ffceb2198f0) at t_reply.c:2136 #6 0x00007ff1f1dccb40 in reply_received (p_msg=0x7ff1f4b06130) at t_reply.c:2538 #7 0x0000560eda5a8744 in do_forward_reply (msg=0x7ff1f4b06130, mode=0) at core/forward.c:744 #8 0x0000560eda5aa18e in forward_reply (msg=0x7ff1f4b06130) at core/forward.c:845 #9 0x0000560eda6232ab in receive_msg ( buf=0x560edbc749a0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/TCP 192.168.43.107;branch=z9hG4bK07df.191c5bf4", '0' <repeats 24 times>, ".0\r\nTo: sip:jh@test.tutpro.com;tag=skjao\r\nFrom: sip:click2dial@test.tutpro.com;tag=040757adc8d4bf"..., len=733, rcv_info=0x7ff1e26d3d58) at core/receive.c:424 #10 0x0000560eda6c0ecd in receive_tcp_msg ( tcpbuf=0x7ff1e26d4038 "SIP/2.0 200 OK\r\nVia: SIP/2.0/TCP 192.168.43.107;branch=z9hG4bK07df.191c5bf4", '0' <repeats 24 times>, ".0\r\nTo: sip:jh@test.tutpro.com;tag=skjao\r\nFrom: sip:click2dial@test.tutpro.com;tag=040757adc8d4bf"..., len=733, rcv_info=0x7ff1e26d3d58, con=0x7ff1e26d3d40) at core/tcp_read.c:1428 #11 0x0000560eda6c319f in tcp_read_req (con=0x7ff1e26d3d40, bytes_read=0x7ffceb21a004, read_flags=0x7ffceb21a00c) at core/tcp_read.c:1611 #12 0x0000560eda6c6dc6 in handle_io (fm=0x7ff1f40b8690, events=1, idx=-1) at core/tcp_read.c:1843 #13 0x0000560eda6b41b7 in io_wait_loop_epoll (h=0x560edab49f40 <io_w>, t=2, repeat=0) at core/io_wait.h:1065 #14 0x0000560eda6c819c in tcp_receive_loop (unix_sock=45) at core/tcp_read.c:1955 #15 0x0000560eda56c056 in tcp_init_children () at core/tcp_main.c:4853 #16 0x0000560eda494912 in main_loop () at main.c:1711 #17 0x0000560eda49b92a in main (argc=17, argv=0x7ffceb21a688) at main.c:2645
-- Juha
Get couple of more details from gdb:
frame 0
list
info locals
p *ctx
p *ctx->jreq
p *ctx->jrpl
Cheers, Daniel
On 17.08.18 14:14, Juha Heinanen wrote:
I cave tm.t_uac_wait over JSONRPC-S a try and got a crash:
(gdb) where #0 0x00007ff1ec5e6cf9 in jsonrpc_send (ctx=0x7ff1e27066c8) at jsonrpcs_mod.c:390 #1 0x00007ff1ec5ee5ac in jsonrpc_delayed_ctx_close (dctx=0x7ff1e2706660) at jsonrpcs_mod.c:1037 #2 0x00007ff1f1deb375 in rpc_uac_callback (t=0x7ff1e26d91e0, type=1024, ps=0x7ffceb219720) at rpc_uac.c:391 #3 0x00007ff1f1e15d65 in run_trans_callbacks_internal (cb_lst=0x7ff1e26d9250, type=1024, trans=0x7ff1e26d91e0, params=0x7ffceb219720) at t_hooks.c:260 #4 0x00007ff1f1e15e89 in run_trans_callbacks (type=1024, trans=0x7ff1e26d91e0, req=0x0, rpl=0x7ff1f4b06130, code=200) at t_hooks.c:287 #5 0x00007ff1f1dca327 in local_reply (t=0x7ff1e26d91e0, p_msg=0x7ff1f4b06130, branch=0, msg_status=200, cancel_data=0x7ffceb2198f0) at t_reply.c:2136 #6 0x00007ff1f1dccb40 in reply_received (p_msg=0x7ff1f4b06130) at t_reply.c:2538 #7 0x0000560eda5a8744 in do_forward_reply (msg=0x7ff1f4b06130, mode=0) at core/forward.c:744 #8 0x0000560eda5aa18e in forward_reply (msg=0x7ff1f4b06130) at core/forward.c:845 #9 0x0000560eda6232ab in receive_msg ( buf=0x560edbc749a0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/TCP 192.168.43.107;branch=z9hG4bK07df.191c5bf4", '0' <repeats 24 times>, ".0\r\nTo: sip:jh@test.tutpro.com;tag=skjao\r\nFrom: sip:click2dial@test.tutpro.com;tag=040757adc8d4bf"..., len=733, rcv_info=0x7ff1e26d3d58) at core/receive.c:424 #10 0x0000560eda6c0ecd in receive_tcp_msg ( tcpbuf=0x7ff1e26d4038 "SIP/2.0 200 OK\r\nVia: SIP/2.0/TCP 192.168.43.107;branch=z9hG4bK07df.191c5bf4", '0' <repeats 24 times>, ".0\r\nTo: sip:jh@test.tutpro.com;tag=skjao\r\nFrom: sip:click2dial@test.tutpro.com;tag=040757adc8d4bf"..., len=733, rcv_info=0x7ff1e26d3d58, con=0x7ff1e26d3d40) at core/tcp_read.c:1428 #11 0x0000560eda6c319f in tcp_read_req (con=0x7ff1e26d3d40, bytes_read=0x7ffceb21a004, read_flags=0x7ffceb21a00c) at core/tcp_read.c:1611 #12 0x0000560eda6c6dc6 in handle_io (fm=0x7ff1f40b8690, events=1, idx=-1) at core/tcp_read.c:1843 #13 0x0000560eda6b41b7 in io_wait_loop_epoll (h=0x560edab49f40 <io_w>, t=2, repeat=0) at core/io_wait.h:1065 #14 0x0000560eda6c819c in tcp_receive_loop (unix_sock=45) at core/tcp_read.c:1955 #15 0x0000560eda56c056 in tcp_init_children () at core/tcp_main.c:4853 #16 0x0000560eda494912 in main_loop () at main.c:1711 #17 0x0000560eda49b92a in main (argc=17, argv=0x7ffceb21a688) at main.c:2645
-- Juha
Daniel-Constantin Mierla writes:
Get couple of more details from gdb:
Below, Juha
(gdb) frame 0 #0 0x00007ff1ec5e6cf9 in jsonrpc_send (ctx=0x7ff1e27066c8) at jsonrpcs_mod.c:390 390 in jsonrpcs_mod.c (gdb) list 385 in jsonrpcs_mod.c (gdb) info locals nj = 0x0 i = -630111740 rbuf = {s = 0x3 <error: Cannot access memory at address 0x3>, len = -187033216} __func__ = "jsonrpc_send" (gdb) p *ctx $1 = {msg = 0x7ff1e270d170, msg_shm_block_size = 3024, method = 0x0, flags = 257, jreq = 0x0, req_node = 0x0, jrpl = 0x560edbc8ea20, rpl_node = 0x0, reply_sent = 1, error_code = 0, error_text = {s = 0x0, len = 0}, http_code = 200, http_text = {s = 0x7ff1ec607b1d "OK", len = 2}, transport = 1} (gdb) p *ctx->jreq Cannot access memory at address 0x0 (gdb) p *ctx->jrpl $2 = {root = 0x560edbc8f380, flags = 0, buf = {s = 0x0, len = 0}, malloc_fn = 0x7ff1f4ceef10 <__GI___libc_malloc>, free_fn = 0x7ff1f4cef510 <__GI___libc_free>}
I just pushed a commit in master branch, hopefully is fixing the issue -- let me know the results and if ok, it will be backported.
Cheers, Daniel
On 17.08.18 14:59, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Get couple of more details from gdb:
Below, Juha
(gdb) frame 0 #0 0x00007ff1ec5e6cf9 in jsonrpc_send (ctx=0x7ff1e27066c8) at jsonrpcs_mod.c:390 390 in jsonrpcs_mod.c (gdb) list 385 in jsonrpcs_mod.c (gdb) info locals nj = 0x0 i = -630111740 rbuf = {s = 0x3 <error: Cannot access memory at address 0x3>, len = -187033216} __func__ = "jsonrpc_send" (gdb) p *ctx $1 = {msg = 0x7ff1e270d170, msg_shm_block_size = 3024, method = 0x0, flags = 257, jreq = 0x0, req_node = 0x0, jrpl = 0x560edbc8ea20, rpl_node = 0x0, reply_sent = 1, error_code = 0, error_text = {s = 0x0, len = 0}, http_code = 200, http_text = {s = 0x7ff1ec607b1d "OK", len = 2}, transport = 1} (gdb) p *ctx->jreq Cannot access memory at address 0x0 (gdb) p *ctx->jrpl $2 = {root = 0x560edbc8f380, flags = 0, buf = {s = 0x0, len = 0}, malloc_fn = 0x7ff1f4ceef10 <__GI___libc_malloc>, free_fn = 0x7ff1f4cef510 <__GI___libc_free>}
On 18.08.18 19:16, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
I just pushed a commit in master branch, hopefully is fixing the issue -- let me know the results and if ok, it will be backported.
Daniel,
Thanks for the commit. My tm.t_uac_wait test (using master) now worked fine without issues.
Thanks for testing and reporting, I will backport.
Cheers, Daniel
-
Daniel-Constantin Mierla -
Juha Heinanen