[jira] [Created] (PROTON-2104) [c++ client] Error specifying url with IPv6 literal host address
Chuck Rolke created PROTON-2104: --- Summary: [c++ client] Error specifying url with IPv6 literal host address Key: PROTON-2104 URL: https://issues.apache.org/jira/browse/PROTON-2104 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: proton-c-0.29.0 Reporter: Chuck Rolke C++ examples simple_send and simple_recv accept IPv6 loopback address [::1] but have issues with other apparently legal addresses. These work on my system: {{ ping6 fe80::c662:ab36:1ef1:1596 ping6 fe80::c662:ab36:1ef1:1596%wlp4s0 ping6 fe80::::c662:ab36:1ef1:1596 }} Wrapping the host part in square brackets and sending that address to simple_send fails: {{ ./simple_send -a [fe80::c662:ab36:1ef1:1596]:5672/abc proton:io: Invalid argument - on connect fe80::c662:ab36:1ef1:1596:5672 }} All three variants of the address that work with ping6 fail with the same error on the simple_send command line. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-255) Policy miscounts quick socket open/close against total connection limit
[ https://issues.apache.org/jira/browse/DISPATCH-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke closed DISPATCH-255. Resolution: Fixed Fixed in 0.6 > Policy miscounts quick socket open/close against total connection limit > --- > > Key: DISPATCH-255 > URL: https://issues.apache.org/jira/browse/DISPATCH-255 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: Backlog > > > Self test system_tests_policy is failing. > In the test the tester.router is created with > {noformat} > cls.router = cls.tester.qdrouterd('conn-limit-router', config, wait=True) > {noformat} > For the Wait=true the test code repeated opens a socket to the configured > listener. > When the socket connects then the router is declared up and ready. > Internally though the policy code has counted the socket open as an incoming > listener connection. This failure comes when the socket closes and the > connection is not 'uncounted'. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1423) Multicast sender with no receiver has first 250 messages released
[ https://issues.apache.org/jira/browse/DISPATCH-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1423: -- Attachment: INTB-250-released-1.8.0.html > Multicast sender with no receiver has first 250 messages released > - > > Key: DISPATCH-1423 > URL: https://issues.apache.org/jira/browse/DISPATCH-1423 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Priority: Major > Attachments: INTB-250-released-1.8.0.html, INTB.conf > > > When a sender starts and there's no receiver already attached then the first > 250 messages the sender sends get released. After that the router waits for > the a receiver to attach before issuing more credit to the sender. The proton > c++ simple_send and simple receive clients expose this problem. > 1. Start router with attached config file > 2. Start sender > simple_send -a 127.0.0.1:5672/multicast/q1 -m 500 > 3. Start receiver >simple_recv -a 127.0.0.1:5672/multicast/q1 -m 500 > The sender competes with 'all messages confirmed'. > The receiver is waiting for the second 250 messages. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1417) Crash when connection_wake ctx points to freed memory
[ https://issues.apache.org/jira/browse/DISPATCH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1417: -- Attachment: (was: INTB.conf) > Crash when connection_wake ctx points to freed memory > - > > Key: DISPATCH-1417 > URL: https://issues.apache.org/jira/browse/DISPATCH-1417 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.9.0 > > > Test clients are streaming unsettled multicast messages to and from an edge > router. Another client repeats the cycle "connect, receive one message from > the stream, disconnect". Soon the edge router core dumps with: > {{(gdb) bt > #0 get_pconnection (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > #1 0x7fc8c0582a1c in pn_connection_wake (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:1439 > #2 0x7fc8c0668472 in connection_wake (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:505 > #3 0x7fc8c066b2af in qd_server_activate (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:1304 > #4 0x7fc8c064f3dd in qdr_activate_connections_CT (core=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:65 > #5 0x7fc8c064fa1d in router_core_thread (arg=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:171 > #6 0x7fc8c056258e in start_thread () from /usr/lib64/libpthread.so.0 > #7 0x7fc8c0201713 in clone () from /usr/lib64/libc.so.6 > (gdb) info threads > Id Target Id Frame > * 1 Thread 0x7fc8b1e44700 (LWP 21706) get_pconnection (c=0x) > at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > 2 Thread 0x7fc8bf8ff240 (LWP 21696) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 3 Thread 0x7fc8b0e42700 (LWP 21708) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 4 Thread 0x7fc8abfff700 (LWP 21709) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 5 Thread 0x7fc8b1643700 (LWP 21707) 0x7fc8c01f6481 in poll () from > /usr/lib64/libc.so.6 > 6 Thread 0x7fc8ab7fe700 (LWP 21710) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1423) Multicast sender with no receiver has first 250 messages released
[ https://issues.apache.org/jira/browse/DISPATCH-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1423: -- Attachment: INTB.conf > Multicast sender with no receiver has first 250 messages released > - > > Key: DISPATCH-1423 > URL: https://issues.apache.org/jira/browse/DISPATCH-1423 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Priority: Major > Attachments: INTB.conf > > > When a sender starts and there's no receiver already attached then the first > 250 messages the sender sends get released. After that the router waits for > the a receiver to attach before issuing more credit to the sender. The proton > c++ simple_send and simple receive clients expose this problem. > 1. Start router with attached config file > 2. Start sender > simple_send -a 127.0.0.1:5672/multicast/q1 -m 500 > 3. Start receiver >simple_recv -a 127.0.0.1:5672/multicast/q1 -m 500 > The sender competes with 'all messages confirmed'. > The receiver is waiting for the second 250 messages. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1417) Crash when connection_wake ctx points to freed memory
[ https://issues.apache.org/jira/browse/DISPATCH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1417: -- Attachment: INTB.conf > Crash when connection_wake ctx points to freed memory > - > > Key: DISPATCH-1417 > URL: https://issues.apache.org/jira/browse/DISPATCH-1417 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.9.0 > > Attachments: INTB.conf > > > Test clients are streaming unsettled multicast messages to and from an edge > router. Another client repeats the cycle "connect, receive one message from > the stream, disconnect". Soon the edge router core dumps with: > {{(gdb) bt > #0 get_pconnection (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > #1 0x7fc8c0582a1c in pn_connection_wake (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:1439 > #2 0x7fc8c0668472 in connection_wake (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:505 > #3 0x7fc8c066b2af in qd_server_activate (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:1304 > #4 0x7fc8c064f3dd in qdr_activate_connections_CT (core=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:65 > #5 0x7fc8c064fa1d in router_core_thread (arg=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:171 > #6 0x7fc8c056258e in start_thread () from /usr/lib64/libpthread.so.0 > #7 0x7fc8c0201713 in clone () from /usr/lib64/libc.so.6 > (gdb) info threads > Id Target Id Frame > * 1 Thread 0x7fc8b1e44700 (LWP 21706) get_pconnection (c=0x) > at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > 2 Thread 0x7fc8bf8ff240 (LWP 21696) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 3 Thread 0x7fc8b0e42700 (LWP 21708) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 4 Thread 0x7fc8abfff700 (LWP 21709) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 5 Thread 0x7fc8b1643700 (LWP 21707) 0x7fc8c01f6481 in poll () from > /usr/lib64/libc.so.6 > 6 Thread 0x7fc8ab7fe700 (LWP 21710) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1423) Multicast sender with no receiver has first 250 messages released
Chuck Rolke created DISPATCH-1423: - Summary: Multicast sender with no receiver has first 250 messages released Key: DISPATCH-1423 URL: https://issues.apache.org/jira/browse/DISPATCH-1423 Project: Qpid Dispatch Issue Type: Bug Components: Routing Engine Affects Versions: 1.8.0 Reporter: Chuck Rolke When a sender starts and there's no receiver already attached then the first 250 messages the sender sends get released. After that the router waits for the a receiver to attach before issuing more credit to the sender. The proton c++ simple_send and simple receive clients expose this problem. 1. Start router with attached config file 2. Start sender simple_send -a 127.0.0.1:5672/multicast/q1 -m 500 3. Start receiver simple_recv -a 127.0.0.1:5672/multicast/q1 -m 500 The sender competes with 'all messages confirmed'. The receiver is waiting for the second 250 messages. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1417) Crash when connection_wake ctx points to freed memory
[ https://issues.apache.org/jira/browse/DISPATCH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16928758#comment-16928758 ] Chuck Rolke commented on DISPATCH-1417: --- I withdraw the earlier statement about the regression since 1.8.0. Heavier testing got the same error with the 1.8.0 release code. > Crash when connection_wake ctx points to freed memory > - > > Key: DISPATCH-1417 > URL: https://issues.apache.org/jira/browse/DISPATCH-1417 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.9.0 > > > Test clients are streaming unsettled multicast messages to and from an edge > router. Another client repeats the cycle "connect, receive one message from > the stream, disconnect". Soon the edge router core dumps with: > {{(gdb) bt > #0 get_pconnection (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > #1 0x7fc8c0582a1c in pn_connection_wake (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:1439 > #2 0x7fc8c0668472 in connection_wake (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:505 > #3 0x7fc8c066b2af in qd_server_activate (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:1304 > #4 0x7fc8c064f3dd in qdr_activate_connections_CT (core=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:65 > #5 0x7fc8c064fa1d in router_core_thread (arg=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:171 > #6 0x7fc8c056258e in start_thread () from /usr/lib64/libpthread.so.0 > #7 0x7fc8c0201713 in clone () from /usr/lib64/libc.so.6 > (gdb) info threads > Id Target Id Frame > * 1 Thread 0x7fc8b1e44700 (LWP 21706) get_pconnection (c=0x) > at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > 2 Thread 0x7fc8bf8ff240 (LWP 21696) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 3 Thread 0x7fc8b0e42700 (LWP 21708) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 4 Thread 0x7fc8abfff700 (LWP 21709) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 5 Thread 0x7fc8b1643700 (LWP 21707) 0x7fc8c01f6481 in poll () from > /usr/lib64/libc.so.6 > 6 Thread 0x7fc8ab7fe700 (LWP 21710) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1417) Crash when connection_wake ctx points to freed memory
[ https://issues.apache.org/jira/browse/DISPATCH-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16928108#comment-16928108 ] Chuck Rolke commented on DISPATCH-1417: --- This appears to be a regression since 1.8.0. 1.8.0 has no crash. Running the same setup and sender/receiver pattern all the routers stay up for 3,000,000 messages. > Crash when connection_wake ctx points to freed memory > - > > Key: DISPATCH-1417 > URL: https://issues.apache.org/jira/browse/DISPATCH-1417 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Major > Fix For: 1.9.0 > > > Test clients are streaming unsettled multicast messages to and from an edge > router. Another client repeats the cycle "connect, receive one message from > the stream, disconnect". Soon the edge router core dumps with: > {{(gdb) bt > #0 get_pconnection (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > #1 0x7fc8c0582a1c in pn_connection_wake (c=0x) at > /home/chug/git/qpid-proton/c/src/proactor/epoll.c:1439 > #2 0x7fc8c0668472 in connection_wake (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:505 > #3 0x7fc8c066b2af in qd_server_activate (ctx=0x1a43658) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:1304 > #4 0x7fc8c064f3dd in qdr_activate_connections_CT (core=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:65 > #5 0x7fc8c064fa1d in router_core_thread (arg=0x19c8ce0) at > /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:171 > #6 0x7fc8c056258e in start_thread () from /usr/lib64/libpthread.so.0 > #7 0x7fc8c0201713 in clone () from /usr/lib64/libc.so.6 > (gdb) info threads > Id Target Id Frame > * 1 Thread 0x7fc8b1e44700 (LWP 21706) get_pconnection (c=0x) > at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 > 2 Thread 0x7fc8bf8ff240 (LWP 21696) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 3 Thread 0x7fc8b0e42700 (LWP 21708) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 4 Thread 0x7fc8abfff700 (LWP 21709) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6 > 5 Thread 0x7fc8b1643700 (LWP 21707) 0x7fc8c01f6481 in poll () from > /usr/lib64/libc.so.6 > 6 Thread 0x7fc8ab7fe700 (LWP 21710) 0x7fc8c0201a47 in epoll_wait () from > /usr/lib64/libc.so.6}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1417) Crash when connection_wake ctx points to freed memory
Chuck Rolke created DISPATCH-1417: - Summary: Crash when connection_wake ctx points to freed memory Key: DISPATCH-1417 URL: https://issues.apache.org/jira/browse/DISPATCH-1417 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Ganesh Murthy Fix For: 1.9.0 Test clients are streaming unsettled multicast messages to and from an edge router. Another client repeats the cycle "connect, receive one message from the stream, disconnect". Soon the edge router core dumps with: {{(gdb) bt #0 get_pconnection (c=0x) at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 #1 0x7fc8c0582a1c in pn_connection_wake (c=0x) at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:1439 #2 0x7fc8c0668472 in connection_wake (ctx=0x1a43658) at /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:505 #3 0x7fc8c066b2af in qd_server_activate (ctx=0x1a43658) at /home/chug/Downloads/qpid-dispatch-1.9.0/src/server.c:1304 #4 0x7fc8c064f3dd in qdr_activate_connections_CT (core=0x19c8ce0) at /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:65 #5 0x7fc8c064fa1d in router_core_thread (arg=0x19c8ce0) at /home/chug/Downloads/qpid-dispatch-1.9.0/src/router_core/router_core_thread.c:171 #6 0x7fc8c056258e in start_thread () from /usr/lib64/libpthread.so.0 #7 0x7fc8c0201713 in clone () from /usr/lib64/libc.so.6 (gdb) info threads Id Target Id Frame * 1 Thread 0x7fc8b1e44700 (LWP 21706) get_pconnection (c=0x) at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:578 2 Thread 0x7fc8bf8ff240 (LWP 21696) 0x7fc8c0201a47 in epoll_wait () from /usr/lib64/libc.so.6 3 Thread 0x7fc8b0e42700 (LWP 21708) 0x7fc8c0201a47 in epoll_wait () from /usr/lib64/libc.so.6 4 Thread 0x7fc8abfff700 (LWP 21709) 0x7fc8c0201a47 in epoll_wait () from /usr/lib64/libc.so.6 5 Thread 0x7fc8b1643700 (LWP 21707) 0x7fc8c01f6481 in poll () from /usr/lib64/libc.so.6 6 Thread 0x7fc8ab7fe700 (LWP 21710) 0x7fc8c0201a47 in epoll_wait () from /usr/lib64/libc.so.6}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1416) Policy log could include denial counts on connection close
Chuck Rolke created DISPATCH-1416: - Summary: Policy log could include denial counts on connection close Key: DISPATCH-1416 URL: https://issues.apache.org/jira/browse/DISPATCH-1416 Project: Qpid Dispatch Issue Type: Improvement Components: Policy Engine Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Currently the Policy module logs the number of active sessions, senders, receivers, and nConnections(see below) on a connection when it is closed. This list could be expanded to include the policy statistics block that counts sessions, senders, and receiver denials. nConnections is the current live number of total incoming connections managed by policy and is not directly related to the current connection. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1415) qdstat does not show process memory usage
Chuck Rolke created DISPATCH-1415: - Summary: qdstat does not show process memory usage Key: DISPATCH-1415 URL: https://issues.apache.org/jira/browse/DISPATCH-1415 Project: Qpid Dispatch Issue Type: Improvement Components: Management Agent Affects Versions: 1.8.0 Reporter: Chuck Rolke *qdstat -m* shows managed memory usage but it does not show qdrouterd process memory usage. An improvement would be to display process memory usage somewhere via qdstat. Often a memory leak (DISPATCH-1407) will be in objects not held in managed memory. In these cases memory usage may grow unbounded but not be visible by qdstat. A new line or three could be added to qdstat -g or a new switch could be added to qdstat. Good values to show are the standard columns from top: VIRT, RES, and SHR. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-1414) Include source/target address in the policy DENY info messages
[ https://issues.apache.org/jira/browse/DISPATCH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke closed DISPATCH-1414. - Assignee: Chuck Rolke Resolution: Not A Bug The requested information is already present. > Include source/target address in the policy DENY info messages > -- > > Key: DISPATCH-1414 > URL: https://issues.apache.org/jira/browse/DISPATCH-1414 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Assignee: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1414.txt > > > The policy DENY info message currently omits the source/target address. This > impedes the diagnosis of policy misconfigurations. Currently the message > looks like this: > {{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u', > rhost '10.128.6.1', vhost 'vv' based on link target name}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1414) Include source/target address in the policy DENY info messages
[ https://issues.apache.org/jira/browse/DISPATCH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1414: -- Attachment: DISPATCH-1414.txt > Include source/target address in the policy DENY info messages > -- > > Key: DISPATCH-1414 > URL: https://issues.apache.org/jira/browse/DISPATCH-1414 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > Attachments: DISPATCH-1414.txt > > > The policy DENY info message currently omits the source/target address. This > impedes the diagnosis of policy misconfigurations. Currently the message > looks like this: > {{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u', > rhost '10.128.6.1', vhost 'vv' based on link target name}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1414) Include source/target address in the policy DENY info messages
[ https://issues.apache.org/jira/browse/DISPATCH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16926013#comment-16926013 ] Chuck Rolke commented on DISPATCH-1414: --- In the log entry the '' field is the name of the requested source or target. Attached find a text file that shows two trace snippets. Each has the proton trace of the attach frame and policy log of the denial. There you can correlate the name requested by the attach and the policy message showing the name when the request was denied. > Include source/target address in the policy DENY info messages > -- > > Key: DISPATCH-1414 > URL: https://issues.apache.org/jira/browse/DISPATCH-1414 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Keith Wall >Priority: Major > > The policy DENY info message currently omits the source/target address. This > impedes the diagnosis of policy misconfigurations. Currently the message > looks like this: > {{POLICY (info) [1228]: DENY AMQP Attach sender link '' for user 'u', > rhost '10.128.6.1', vhost 'vv' based on link target name}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1412) Policy C code performance issue: reload python module for each call
Chuck Rolke created DISPATCH-1412: - Summary: Policy C code performance issue: reload python module for each call Key: DISPATCH-1412 URL: https://issues.apache.org/jira/browse/DISPATCH-1412 Project: Qpid Dispatch Issue Type: Improvement Components: Policy Engine Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Chuck Rolke The module could be loaded once for the lifetime of the router instance. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1407. --- Fix Version/s: 1.9.0 Resolution: Fixed Fixed at 0ed5d5 > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.9.0 > > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16925174#comment-16925174 ] Chuck Rolke commented on DISPATCH-1407: --- Router policy also allows controlling clients with a maxSessions limit. This limit is enforced differently and will not produce a memory leak. For sessions the limit is negotiated at the AMQP level. The router has no handlers for denying sessions because it is a protocol violation for the client to exceed that limit. An AmqpDotnetLite client attempting to open 256 sessions when the router limit is 2 will see: ``` Exception Amqp.AmqpException: remote channel 2 is above negotiated channel_max 1. at Amqp.Connection.ThrowIfClosed(String operation) at Amqp.Connection.AddSession(Session session) at Amqp.Session..ctor(Connection connection, Begin begin, OnBegin onBegin) at Amqp.Session..ctor(Connection connection) at Examples.Interop.SessionHammer.Main(String[] args) in /home/chug/Downloads/amq-dotnet-2.5.0-core-sdk/examples/Interop.SessionHammer/Interop.SessionHammer.cs:line 54. ``` > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16924995#comment-16924995 ] Chuck Rolke commented on DISPATCH-1407: --- Thanks Gordon. Indeed that fixes it and in a place that logically fits. Please go ahead an commit this. > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16924651#comment-16924651 ] Chuck Rolke commented on DISPATCH-1407: --- Analysis to date: * Valgrind shows only python-related mallocs; this is inconclusive. Valgrind shows no actionable C-language malloc leaks. * The same problem is present in 1.7.0, 1.6.0, 1.5.0, and 1.4.x * Policy code was modified not to include setting pn_condition to signal the error - still has memory growth * Container code was modified to call pn_condition_clear for local and remote conditions when link is detached - no change * Tried making a policy.c static python module load and not loading only when needed - no change > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16924642#comment-16924642 ] Chuck Rolke commented on DISPATCH-1407: --- With A.conf and default.json in your cwd, run _qdrouterd -c A.conf_ Then open a disallowed source or target. > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1407: -- Attachment: default.json > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1407) Memory leak on link policy denial
[ https://issues.apache.org/jira/browse/DISPATCH-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1407: -- Attachment: A.conf > Memory leak on link policy denial > - > > Key: DISPATCH-1407 > URL: https://issues.apache.org/jira/browse/DISPATCH-1407 > Project: Qpid Dispatch > Issue Type: Bug > Components: Policy Engine >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: A.conf, default.json > > > A router with a simple policy that denies most addresses starts and uses 10M > bytes of memory. A test client loops 25k times opening a link to a denied > address over a single connection and session. Now the router uses 276 Mbytes. > An example policy is > ``` > [ >["vhost", { > "hostname": "$default", > "allowUnknownUser": true, > "groups" : { >"$default": { > "remoteHosts": "*", > "allowDynamicSource": true, > "allowAnonymousSender": true, > "sources": "$management, examples, q1", > "targets": "$management, examples, q1" >} > } >}] > ] > ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1407) Memory leak on link policy denial
Chuck Rolke created DISPATCH-1407: - Summary: Memory leak on link policy denial Key: DISPATCH-1407 URL: https://issues.apache.org/jira/browse/DISPATCH-1407 Project: Qpid Dispatch Issue Type: Bug Components: Policy Engine Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Chuck Rolke A router with a simple policy that denies most addresses starts and uses 10M bytes of memory. A test client loops 25k times opening a link to a denied address over a single connection and session. Now the router uses 276 Mbytes. An example policy is ``` [ ["vhost", { "hostname": "$default", "allowUnknownUser": true, "groups" : { "$default": { "remoteHosts": "*", "allowDynamicSource": true, "allowAnonymousSender": true, "sources": "$management, examples, q1", "targets": "$management, examples, q1" } } }] ] ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1405) Display local addresses at startup
Chuck Rolke created DISPATCH-1405: - Summary: Display local addresses at startup Key: DISPATCH-1405 URL: https://issues.apache.org/jira/browse/DISPATCH-1405 Project: Qpid Dispatch Issue Type: Improvement Components: Management Agent Affects Versions: 1.8.0 Reporter: Chuck Rolke At boot time the router could display its local addresses. This would help debugging certain issues. An example of the information is from hawtio: ``` [io.hawt.system.ProxyWhitelist] Probing local addresses ... [io.hawt.system.ProxyWhitelist] Initial proxy whitelist: [localhost, 127.0.0.1, 10.10.111.222, ovpn-111-222.gw.example.com, 192.168.100.100, unused] ``` -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1383) system_tests_policy is timing out
[ https://issues.apache.org/jira/browse/DISPATCH-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1383. --- Fix Version/s: 1.9.0 Resolution: Fixed > system_tests_policy is timing out > - > > Key: DISPATCH-1383 > URL: https://issues.apache.org/jira/browse/DISPATCH-1383 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.8.0 >Reporter: Fernando Giorgetti >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.9.0 > > > We are seeing system_tests_policy timing out on RHEL6, RHEL7 and RHEL8 > platforms. > This is happening with latest bits from master branch and latest proton > (downstream). -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1400) [tools] Scraper fails with log file BOM byte order marks
Chuck Rolke created DISPATCH-1400: - Summary: [tools] Scraper fails with log file BOM byte order marks Key: DISPATCH-1400 URL: https://issues.apache.org/jira/browse/DISPATCH-1400 Project: Qpid Dispatch Issue Type: Bug Components: Tools Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Logs captured from downloading Openshift pod logs have BOMs. Scraper fails right away. A workaround is to process the log with dos2unix: {{ dos2unix PVT.log}} -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1393) Router link logging on interQDR connection is skipped on connecting router
Chuck Rolke created DISPATCH-1393: - Summary: Router link logging on interQDR connection is skipped on connecting router Key: DISPATCH-1393 URL: https://issues.apache.org/jira/browse/DISPATCH-1393 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 1.8.0 Environment: In test directory build/tests/system_test.dir/system_tests_edge_router/EdgeRouterTest/setUpClass grep "Link attached" INT*.log and see that the log lines are only in INT.A.log Reporter: Chuck Rolke A useful ROUTER info log message describing interrouter links is emitted at the end of function qdr_link_inbound_first_attach_CT. Thus the link messages are logged only on the router that is listening. The connecting router should log the same link details so that connection and link pairs are more easily correlated. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1388) Authorization doc fails to describe vhost abstraction clearly
[ https://issues.apache.org/jira/browse/DISPATCH-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1388. --- Resolution: Fixed Fix Version/s: 1.9.0 Fixed at Commit ab6657 > Authorization doc fails to describe vhost abstraction clearly > - > > Key: DISPATCH-1388 > URL: https://issues.apache.org/jira/browse/DISPATCH-1388 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Affects Versions: 1.8.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.9.0 > > > Security documentation misses an important point when describing policy and > how policy is effected by vhost settings: Access policy is applied at the > point of ingress to a router network. Once access is granted to a resource > then all resources with that name anywhere in the network are accessible. > Access restrictions are specified in a policy vhost object. The vhost > contains the restrictions that get applied to a connection when the > connection is established. Reading the doc it sounds as if there are vhost > objects that may contain addresses somewhere in the router. That conceptual > model is the issue in the doc that needs to be fixed. > Methods for Specifying Vhost Policy Source and Target Addresses is a good > example. In the table the first item is titled _Allow all users in the user > group to access all source or target addresses on the vhost_ . In reality the > addresses are not _on the vhost but are in the router network_. > Throughout the document the text "on a vhost" could be changed to "through a > vhost" or "specified by a vhost", or could be removed entirely. > h4. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1388) Authorization doc fails to describe vhost abstraction clearly
Chuck Rolke created DISPATCH-1388: - Summary: Authorization doc fails to describe vhost abstraction clearly Key: DISPATCH-1388 URL: https://issues.apache.org/jira/browse/DISPATCH-1388 Project: Qpid Dispatch Issue Type: Improvement Components: Documentation Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Security documentation misses an important point when describing policy and how policy is effected by vhost settings: Access policy is applied at the point of ingress to a router network. Once access is granted to a resource then all resources with that name anywhere in the network are accessible. Access restrictions are specified in a policy vhost object. The vhost contains the restrictions that get applied to a connection when the connection is established. Reading the doc it sounds as if there are vhost objects that may contain addresses somewhere in the router. That conceptual model is the issue in the doc that needs to be fixed. Methods for Specifying Vhost Policy Source and Target Addresses is a good example. In the table the first item is titled _Allow all users in the user group to access all source or target addresses on the vhost_ . In reality the addresses are not _on the vhost but are in the router network_. Throughout the document the text "on a vhost" could be changed to "through a vhost" or "specified by a vhost", or could be removed entirely. h4. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1379) Message receive performance improvements
Chuck Rolke created DISPATCH-1379: - Summary: Message receive performance improvements Key: DISPATCH-1379 URL: https://issues.apache.org/jira/browse/DISPATCH-1379 Project: Qpid Dispatch Issue Type: Improvement Components: Router Node Affects Versions: 1.8.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Code inspection reveals three function calls per message that may be eliminated and a buffer free that could be executed outside of holding the content lock. * Message allocator initializes object in memory ascending order Despite the size of the code, setting the required fields to zero directly is faster that calling ZERO. * Eliminate redundant calls to pn_link_get_context * Free empty pending buffer outside of content lock -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1377) system_tests_topology_disposition failing on machine with python3 only
[ https://issues.apache.org/jira/browse/DISPATCH-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16875080#comment-16875080 ] Chuck Rolke commented on DISPATCH-1377: --- The failing system has 'python3' but it does not have 'python' linked to it. The test launches scraper with {{/usr/bin/env python /root/qpid-dispatch/build/tests/scraper/scraper.py -f ../setUpClass/A.log ../setUpClass/B.log ../setUpClass/C.log ../setUpClass/D.log}} {{/usr/bin/env: ‘python’: No such file or directory}} Other tests that pass launch 'python3'. > system_tests_topology_disposition failing on machine with python3 only > -- > > Key: DISPATCH-1377 > URL: https://issues.apache.org/jira/browse/DISPATCH-1377 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Tests >Affects Versions: 1.8.0 >Reporter: Ganesh Murthy >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.9.0 > > > The following is the output of the test failure > > {noformat} > Stacktrace > test_01_delete_spurious_connector > (system_tests_topology_disposition.TopologyDispositionTests) ... ok > test_02_topology_disposition > (system_tests_topology_disposition.TopologyDispositionTests) ... ok > test_03_connection_id_propagation > (system_tests_topology_disposition.TopologyDispositionTests) ... ok > test_04_scraper_tool > (system_tests_topology_disposition.TopologyDispositionTests) ... FAIL > == > FAIL: test_04_scraper_tool > (system_tests_topology_disposition.TopologyDispositionTests) > -- > Traceback (most recent call last): > File "/opt/interconnect-src/tests/system_tests_topology_disposition.py", > line 459, in test_04_scraper_tool > self.assertEqual ( None, error ) > AssertionError: None != 'Process 7713 error: exit code 126, expec[311 > chars]'{noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1371) qd_alloc can reuse instances in LIFO order
[ https://issues.apache.org/jira/browse/DISPATCH-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16865856#comment-16865856 ] Chuck Rolke commented on DISPATCH-1371: --- When trying to figure out a use-after-free bug it is harder when the most recently used object is put back in service immediately this way. If this change is known to be a faster way to go overall then I won't object to it. With the DEQ of objects doesn't adding an object to end of a queue also change the pointer at the head of the queue? If so then maybe there is not that much cache advantage to adding or removing from the tail instead of the head. > qd_alloc can reuse instances in LIFO order > -- > > Key: DISPATCH-1371 > URL: https://issues.apache.org/jira/browse/DISPATCH-1371 > Project: Qpid Dispatch > Issue Type: Improvement >Affects Versions: 1.8.0 >Reporter: Francesco Nigro >Priority: Minor > > qd_dealloc is inserting instances on the tail of the thread local free_list > while qd_alloc is reading from the head, always causing cache misses unless > free_list size is 1. > qd_alloc could instead reuse the last inserted instance ie the tail, using > free_list as a stack (with LIFO accesses). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (DISPATCH-1359) Set ctest timeout to 300 seconds.
[ https://issues.apache.org/jira/browse/DISPATCH-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke reopened DISPATCH-1359: --- Assignee: Chuck Rolke (was: Ganesh Murthy) The fix so as committed has an issue wherein it nullifies the effect of cmake command line option "-- timeout N" (See note 1). Test developers depend on temporarily overriding the test timeout. Note 1: The timeout can be changed by running ccmake and editing option DART_TESTING_TIMEOUT. However, if cmake sets the test timeout property then that value cannot be overridden. > Set ctest timeout to 300 seconds. > - > > Key: DISPATCH-1359 > URL: https://issues.apache.org/jira/browse/DISPATCH-1359 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.7.0 >Reporter: Ganesh Murthy >Assignee: Chuck Rolke >Priority: Minor > Fix For: 1.9.0 > > > Currently when running system tests, ctest has a default timeout of 1500 > seconds which is way too long. So for example, system_tests_edge_router if it > should hang for some reason, gets terminated by ctest only after 1500 seconds > (25 mins). This is way too long. > We need to set a smaller more reasonable timeout per test for ctest. > system_tests_edge_router is the longest executing test in the test suite. > Looking at how long it takes to execute on a slow Travis system, we have > reached the conclusion that 300 seconds would be a good timeout value for > ctest. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1366) Performance improvement in qd_parse_as functions
Chuck Rolke created DISPATCH-1366: - Summary: Performance improvement in qd_parse_as functions Key: DISPATCH-1366 URL: https://issues.apache.org/jira/browse/DISPATCH-1366 Project: Qpid Dispatch Issue Type: Improvement Components: Router Node Affects Versions: 1.8.0 Reporter: Chuck Rolke Fix For: Backlog Most of the calls to qd_iterator_octet in file parse.c could be avoided when enough of the field's data is in the current underlying buffer. The objective is to use the same technques used in DISPATCH-1354 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-480) Default tests timeout is too short for some machines
[ https://issues.apache.org/jira/browse/DISPATCH-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-480. -- Resolution: Fixed Fix Version/s: (was: Backlog) 1.9.0 Fixed at Commit 03e59d3131 (2019-06-12) > Default tests timeout is too short for some machines > > > Key: DISPATCH-480 > URL: https://issues.apache.org/jira/browse/DISPATCH-480 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Tests >Affects Versions: 0.7.0 >Reporter: Jiri Daněk >Priority: Major > Fix For: 1.9.0 > > > I created a Docker image on hub.docker.com. The website offers the following > free service: you provide a Dockerfile and it builds the image for you on > some IaaS platform. Problem is, their VMs are slow and Dispatch tests tend to > timeout. > I ran the build more than 10 times already and not once did the tests succeed. > For example, see this build, > https://hub.docker.com/r/jdanekrh/dispatch-console-tests/builds/be4azv4jnyywc93nstyti8g/, > scroll to the bottom to see the build log. > Would it be possible to increase the test timeout? Is it actually already > configurable somehow? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1359) Set ctest timeout to 300 seconds.
[ https://issues.apache.org/jira/browse/DISPATCH-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1359. --- Resolution: Fixed Fix Version/s: 1.9.0 Fixed at Commit 03e59d3131 > Set ctest timeout to 300 seconds. > - > > Key: DISPATCH-1359 > URL: https://issues.apache.org/jira/browse/DISPATCH-1359 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.7.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 1.9.0 > > > Currently when running system tests, ctest has a default timeout of 1500 > seconds which is way too long. So for example, system_tests_edge_router if it > should hang for some reason, gets terminated by ctest only after 1500 seconds > (25 mins). This is way too long. > We need to set a smaller more reasonable timeout per test for ctest. > system_tests_edge_router is the longest executing test in the test suite. > Looking at how long it takes to execute on a slow Travis system, we have > reached the conclusion that 300 seconds would be a good timeout value for > ctest. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1359) Set ctest timeout to 300 seconds.
[ https://issues.apache.org/jira/browse/DISPATCH-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860319#comment-16860319 ] Chuck Rolke commented on DISPATCH-1359: --- A good improvement would be to make the timeout adjustable for each test. If a test normally takes 0.85 seconds then the value of 300 seems pretty outrageous. Also, some time ago there was a request https://issues.apache.org/jira/browse/DISPATCH-480 to *raise* the default test timeout. > Set ctest timeout to 300 seconds. > - > > Key: DISPATCH-1359 > URL: https://issues.apache.org/jira/browse/DISPATCH-1359 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.7.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Minor > > Currently when running system tests, ctest has a default timeout of 1500 > seconds which is way too long. So for example, system_tests_edge_router if it > should hang for some reason, gets terminated by ctest only after 1500 seconds > (25 mins). This is way too long. > We need to set a smaller more reasonable timeout per test for ctest. > system_tests_edge_router is the longest executing test in the test suite. > Looking at how long it takes to execute on a slow Travis system, we have > reached the conclusion that 300 seconds would be a good timeout value for > ctest. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1354) Interrouter annotation processing uses slow methods
[ https://issues.apache.org/jira/browse/DISPATCH-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1354. --- Resolution: Fixed Fix Version/s: 1.9.0 > Interrouter annotation processing uses slow methods > --- > > Key: DISPATCH-1354 > URL: https://issues.apache.org/jira/browse/DISPATCH-1354 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 1.7.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.9.0 > > > Message annotation processing on received messages stages key names byte by > byte into a flat buffer and then uses strcmp to check them. > Easy improvements are: > * Use name in raw buffer if it does not cross a buffer boundary > * If name crosses a boundary then use memmoves to get the name in chunks > * Check the name prefix only once and then check variable parts of name > strings > * Don't create unnecessary qd_iterators and qd_parsed_fields > * Don't check names whose lengths differ from the given keys -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1354) Interrouter annotation processing uses slow methods
Chuck Rolke created DISPATCH-1354: - Summary: Interrouter annotation processing uses slow methods Key: DISPATCH-1354 URL: https://issues.apache.org/jira/browse/DISPATCH-1354 Project: Qpid Dispatch Issue Type: Improvement Components: Router Node Affects Versions: 1.7.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Message annotation processing on received messages stages key names byte by byte into a flat buffer and then uses strcmp to check them. Easy improvements are: * Use name in raw buffer if it does not cross a buffer boundary * If name crosses a boundary then use memmoves to get the name in chunks * Check the name prefix only once and then check variable parts of name strings * Don't create unnecessary qd_iterators and qd_parsed_fields * Don't check names whose lengths differ from the given keys -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8319) QMF requests rerouted to QMF exchange may crash with invalid connection
Chuck Rolke created QPID-8319: - Summary: QMF requests rerouted to QMF exchange may crash with invalid connection Key: QPID-8319 URL: https://issues.apache.org/jira/browse/QPID-8319 Project: Qpid Issue Type: Improvement Components: C++ Broker Affects Versions: qpid-cpp-1.39.0 Reporter: Chuck Rolke Reported by Pavel in [https://bugzilla.redhat.com/show_bug.cgi?id=1713560] Description of problem: User story: when running concurrently 2 times a program that: 1) Creates a queue on the broker "HelloQueue" 2) Creates a second queue called "HelloQueue.AutoDelete" with auto-delete set and alternate exchange set to "qmf.default.direct" and hold open the Receiver that is subscribed to it. 3) Puts a QMF message into the "HelloQueue.AutoDelete" queue that will delete the "HelloQueue" queue when it is processed. 4) Waits 10 seconds. 5) Closes the receiver, triggering the auto-delete of "HelloQueue.AutoDelete". Then the QMF message will be sent to "qmf.default.direct" because of the alternate exchange, resulting in the deletion of "HelloQueue" regardless of whether or not there are other subscribers connected to it. And with some high probability, the 2nd QMF request from just dropped connection will attempt to be processed, but causes segfault. Version-Release number of selected component (if applicable): qpid-cpp 1.36.0-15 (or -21 or -21+hf2), I expect any How reproducible: 75% in my case Steps to Reproduce: 1. Compile attached program. 2. qpidd & 3. ./QmfBrokerCrashRepro localhost:5672 & ./QmfBrokerCrashRepro localhost:5672 & Actual results: client program aborts every time (unhandled exception, no deal), but very often qpidd segfaults as well, with backtrace: {code:java} (gdb) bt #0 0x in ?? () #1 0x7f9b5cdca752 in qpid::management::(anonymous namespace)::ScopedManagementContext::getUserId (this=) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/management/ManagementAgent.cpp:105 #2 0x7f9b5cde8055 in qpid::management::ManagementAgent::dispatchAgentCommand (this=0x1680930, msg=..., viaLocal=true) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/management/ManagementAgent.cpp:2347 #3 0x7f9b5cde8958 in qpid::management::ManagementAgent::dispatchCommand (this=0x1680930, deliverable=, routingKey="broker", topic=false, qmfVersion=2) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/management/ManagementAgent.cpp:1255 #4 0x7f9b5cdfb219 in qpid::broker::ManagementDirectExchange::route (this=0x168b6f0, msg=...) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/management/ManagementDirectExchange.cpp:48 #5 0x7f9b5cccfa2a in qpid::broker::Exchange::routeWithAlternate (this=0x168b768, msg=...) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Exchange.cpp:410 #6 0x7f9b5ccfddb5 in qpid::broker::Queue::reroute (e=, m=) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1761 #7 0x7f9b5ccfe006 in qpid::broker::Queue::abandoned (this=0x16ba740, message=) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1156 #8 0x7f9b5ccf16cd in operator() (this=0x16ba740, maxCount=0, p=..., f=..., type=, triggerAutoDelete=false, maxTests=0) at /usr/include/boost/function/function_template.hpp:1013 #9 qpid::broker::Queue::remove (this=0x16ba740, maxCount=0, p=..., f=..., type=, triggerAutoDelete=false, maxTests=0) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:795 #10 0x7f9b5ccf49d5 in qpid::broker::Queue::destroyed (this=0x16ba740) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1167 #11 0x7f9b5cd73b09 in qpid::broker::QueueRegistry::destroyIfUntouched (this=0x167f2f8, targetQ=, version=, connectionId="", userId="") at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/QueueRegistry.cpp:156 #12 0x7f9b5ccee336 in qpid::broker::Queue::tryAutoDelete (this=0x16ba740, expectedVersion=1) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1358 #13 0x7f9b5ccee834 in qpid::broker::Queue::scheduleAutoDelete (this=0x16ba740, immediate=false) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:1342 #14 0x7f9b5ccef626 in qpid::broker::Queue::cancel (this=0x16ba740, c=..., connectionId="qpid.[::1]:5672-[::1]:54658", userId="anonymous@QPID") at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/Queue.cpp:638 #15 0x7f9b5cd90eca in qpid::broker::SemanticState::cancel (this=0x7f9b4c00a078, c=...) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/SemanticState.cpp:475 #16 0x7f9b5cd98775 in qpid::broker::SemanticState::closed (this=0x7f9b4c00a078) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/SemanticState.cpp:111 #17 0x7f9b5cdb0301 in qpid::broker::SessionState::~SessionState (this=0x7f9b4c009eb0, __in_chrg=) at /usr/src/debug/qpid-cpp-1.36.0/src/qpid/broker/SessionState.cpp:107 #18 0x7f9b5cdb08a9 in qpid::broker::SessionStat
[jira] [Created] (DISPATCH-1336) Deliveries settled out of order in simple test case
Chuck Rolke created DISPATCH-1336: - Summary: Deliveries settled out of order in simple test case Key: DISPATCH-1336 URL: https://issues.apache.org/jira/browse/DISPATCH-1336 Project: Qpid Dispatch Issue Type: Improvement Components: Router Node Affects Versions: 1.7.0 Environment: Fedora 29, Python 3 Debug builds Proton git: branch master @ 0481a507c Dispatch git: branch master @ 7b3a8e25 Reporter: Chuck Rolke 1. A router is started with a simple qdrouterd 2. A single qpid-proton-c sender sends 100,000 messages to port 5672 3. A simple qpid-proton-c receiver receives the messages and accepts them. 4. In the sender's on_accept method occasionally the message IDs appear out of order. In this snippet the message id numbers are marching along in the correct order. Then settlements 77441..77459 jump ahead of settlement 77430. After that the streams get synchronized again and match for the remainder of the run. This is not necessarily wrong from an AMQP standpoint. But one might expect that the settlements would propagate from the receiver back to the sender in order every time. Can anyone explain how this happens? {code:java} Fail to match message id 77430 with settlement id 77441 Fail to match message id 77431 with settlement id 77442 Fail to match message id 77432 with settlement id 77443 Fail to match message id 77433 with settlement id 77444 Fail to match message id 77434 with settlement id 77445 Fail to match message id 77435 with settlement id 77446 Fail to match message id 77436 with settlement id 77447 Fail to match message id 77437 with settlement id 77448 Fail to match message id 77438 with settlement id 77449 Fail to match message id 77439 with settlement id 77450 Fail to match message id 77440 with settlement id 77451 Fail to match message id 77441 with settlement id 77452 Fail to match message id 77442 with settlement id 77453 Fail to match message id 77443 with settlement id 77454 Fail to match message id 77444 with settlement id 77455 Fail to match message id 77445 with settlement id 77456 Fail to match message id 77446 with settlement id 77457 Fail to match message id 77447 with settlement id 77458 Fail to match message id 77448 with settlement id 77459 Fail to match message id 77449 with settlement id 77430 Fail to match message id 77450 with settlement id 77431 Fail to match message id 77451 with settlement id 77432 Fail to match message id 77452 with settlement id 77433 Fail to match message id 77453 with settlement id 77434 Fail to match message id 77454 with settlement id 77435 Fail to match message id 77455 with settlement id 77436 Fail to match message id 77456 with settlement id 77437 Fail to match message id 77457 with settlement id 77438 Fail to match message id 77458 with settlement id 77439 Fail to match message id 77459 with settlement id 77440 {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-1333) Console test fails printing to file with python 3
[ https://issues.apache.org/jira/browse/DISPATCH-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke reassigned DISPATCH-1333: - Assignee: Chuck Rolke > Console test fails printing to file with python 3 > - > > Key: DISPATCH-1333 > URL: https://issues.apache.org/jira/browse/DISPATCH-1333 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.7.0 > Environment: Fedora 29, Python 3, proton and dispatch master branches >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: console-test.patch, run_console_test.out.txt > > > {code:java} > test 53 > Start 53: system_tests_console > 53: Test command: /bin/python > "/home/chug/git/qpid-dispatch/build/tests/run.py" "unit2" "-v" > "system_tests_console" > 53: Test timeout computed to be: 1500 > 53: test_console (system_tests_console.ConsoleTest) ... ERROR > 53: > 53: == > 53: ERROR: test_console (system_tests_console.ConsoleTest) > 53: -- > 53: Traceback (most recent call last): > 53: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 706, in > wrap > 53: return f(*args, **kwargs) > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 132, in test_console > 53: self.run_console_test() > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 116, in run_console_test > 53: popenfile.writelines(out) > 53: TypeError: write() argument must be str, not int > 53: > 53: -- > 53: Ran 1 test in 0.959s > 53: > 53: FAILED (errors=1) > 1/1 Test #53: system_tests_console .***Failed 1.63 sec > 0% tests passed, 1 tests failed out of 1 > {code} > The test passes with the attached patch. > The content of the failed printout is attached. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1333) Console test fails printing to file with python 3
[ https://issues.apache.org/jira/browse/DISPATCH-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1333: -- Attachment: run_console_test.out.txt > Console test fails printing to file with python 3 > - > > Key: DISPATCH-1333 > URL: https://issues.apache.org/jira/browse/DISPATCH-1333 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.7.0 > Environment: Fedora 29, Python 3, proton and dispatch master branches >Reporter: Chuck Rolke >Priority: Major > Attachments: console-test.patch, run_console_test.out.txt > > > {code:java} > test 53 > Start 53: system_tests_console > 53: Test command: /bin/python > "/home/chug/git/qpid-dispatch/build/tests/run.py" "unit2" "-v" > "system_tests_console" > 53: Test timeout computed to be: 1500 > 53: test_console (system_tests_console.ConsoleTest) ... ERROR > 53: > 53: == > 53: ERROR: test_console (system_tests_console.ConsoleTest) > 53: -- > 53: Traceback (most recent call last): > 53: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 706, in > wrap > 53: return f(*args, **kwargs) > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 132, in test_console > 53: self.run_console_test() > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 116, in run_console_test > 53: popenfile.writelines(out) > 53: TypeError: write() argument must be str, not int > 53: > 53: -- > 53: Ran 1 test in 0.959s > 53: > 53: FAILED (errors=1) > 1/1 Test #53: system_tests_console .***Failed 1.63 sec > 0% tests passed, 1 tests failed out of 1 > {code} > The test passes with the attached patch. > The content of the failed printout is attached. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1333) Console test fails printing to file with python 3
[ https://issues.apache.org/jira/browse/DISPATCH-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1333: -- Attachment: (was: run_console_test.out) > Console test fails printing to file with python 3 > - > > Key: DISPATCH-1333 > URL: https://issues.apache.org/jira/browse/DISPATCH-1333 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.7.0 > Environment: Fedora 29, Python 3, proton and dispatch master branches >Reporter: Chuck Rolke >Priority: Major > Attachments: console-test.patch, run_console_test.out.txt > > > {code:java} > test 53 > Start 53: system_tests_console > 53: Test command: /bin/python > "/home/chug/git/qpid-dispatch/build/tests/run.py" "unit2" "-v" > "system_tests_console" > 53: Test timeout computed to be: 1500 > 53: test_console (system_tests_console.ConsoleTest) ... ERROR > 53: > 53: == > 53: ERROR: test_console (system_tests_console.ConsoleTest) > 53: -- > 53: Traceback (most recent call last): > 53: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 706, in > wrap > 53: return f(*args, **kwargs) > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 132, in test_console > 53: self.run_console_test() > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 116, in run_console_test > 53: popenfile.writelines(out) > 53: TypeError: write() argument must be str, not int > 53: > 53: -- > 53: Ran 1 test in 0.959s > 53: > 53: FAILED (errors=1) > 1/1 Test #53: system_tests_console .***Failed 1.63 sec > 0% tests passed, 1 tests failed out of 1 > {code} > The test passes with the attached patch. > The content of the failed printout is attached. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1333) Console test fails printing to file with python 3
[ https://issues.apache.org/jira/browse/DISPATCH-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1333: -- Attachment: run_console_test.out > Console test fails printing to file with python 3 > - > > Key: DISPATCH-1333 > URL: https://issues.apache.org/jira/browse/DISPATCH-1333 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.7.0 > Environment: Fedora 29, Python 3, proton and dispatch master branches >Reporter: Chuck Rolke >Priority: Major > Attachments: console-test.patch, run_console_test.out > > > {code:java} > test 53 > Start 53: system_tests_console > 53: Test command: /bin/python > "/home/chug/git/qpid-dispatch/build/tests/run.py" "unit2" "-v" > "system_tests_console" > 53: Test timeout computed to be: 1500 > 53: test_console (system_tests_console.ConsoleTest) ... ERROR > 53: > 53: == > 53: ERROR: test_console (system_tests_console.ConsoleTest) > 53: -- > 53: Traceback (most recent call last): > 53: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 706, in > wrap > 53: return f(*args, **kwargs) > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 132, in test_console > 53: self.run_console_test() > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 116, in run_console_test > 53: popenfile.writelines(out) > 53: TypeError: write() argument must be str, not int > 53: > 53: -- > 53: Ran 1 test in 0.959s > 53: > 53: FAILED (errors=1) > 1/1 Test #53: system_tests_console .***Failed 1.63 sec > 0% tests passed, 1 tests failed out of 1 > {code} > The test passes with the attached patch. > The content of the failed printout is attached. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1333) Console test fails printing to file with python 3
[ https://issues.apache.org/jira/browse/DISPATCH-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1333: -- Attachment: console-test.patch > Console test fails printing to file with python 3 > - > > Key: DISPATCH-1333 > URL: https://issues.apache.org/jira/browse/DISPATCH-1333 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.7.0 > Environment: Fedora 29, Python 3, proton and dispatch master branches >Reporter: Chuck Rolke >Priority: Major > Attachments: console-test.patch > > > {code:java} > test 53 > Start 53: system_tests_console > 53: Test command: /bin/python > "/home/chug/git/qpid-dispatch/build/tests/run.py" "unit2" "-v" > "system_tests_console" > 53: Test timeout computed to be: 1500 > 53: test_console (system_tests_console.ConsoleTest) ... ERROR > 53: > 53: == > 53: ERROR: test_console (system_tests_console.ConsoleTest) > 53: -- > 53: Traceback (most recent call last): > 53: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 706, in > wrap > 53: return f(*args, **kwargs) > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 132, in test_console > 53: self.run_console_test() > 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line > 116, in run_console_test > 53: popenfile.writelines(out) > 53: TypeError: write() argument must be str, not int > 53: > 53: -- > 53: Ran 1 test in 0.959s > 53: > 53: FAILED (errors=1) > 1/1 Test #53: system_tests_console .***Failed 1.63 sec > 0% tests passed, 1 tests failed out of 1 > {code} > The test passes with the attached patch. > The content of the failed printout is attached. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1333) Console test fails printing to file with python 3
Chuck Rolke created DISPATCH-1333: - Summary: Console test fails printing to file with python 3 Key: DISPATCH-1333 URL: https://issues.apache.org/jira/browse/DISPATCH-1333 Project: Qpid Dispatch Issue Type: Bug Components: Tests Affects Versions: 1.7.0 Environment: Fedora 29, Python 3, proton and dispatch master branches Reporter: Chuck Rolke Attachments: console-test.patch {code:java} test 53 Start 53: system_tests_console 53: Test command: /bin/python "/home/chug/git/qpid-dispatch/build/tests/run.py" "unit2" "-v" "system_tests_console" 53: Test timeout computed to be: 1500 53: test_console (system_tests_console.ConsoleTest) ... ERROR 53: 53: == 53: ERROR: test_console (system_tests_console.ConsoleTest) 53: -- 53: Traceback (most recent call last): 53: File "/home/chug/git/qpid-dispatch/tests/system_test.py", line 706, in wrap 53: return f(*args, **kwargs) 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line 132, in test_console 53: self.run_console_test() 53: File "/home/chug/git/qpid-dispatch/tests/system_tests_console.py", line 116, in run_console_test 53: popenfile.writelines(out) 53: TypeError: write() argument must be str, not int 53: 53: -- 53: Ran 1 test in 0.959s 53: 53: FAILED (errors=1) 1/1 Test #53: system_tests_console .***Failed 1.63 sec 0% tests passed, 1 tests failed out of 1 {code} The test passes with the attached patch. The content of the failed printout is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1332) Reconcile install directories and content
[ https://issues.apache.org/jira/browse/DISPATCH-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1332: -- Attachment: opt-local-tree-full.txt > Reconcile install directories and content > - > > Key: DISPATCH-1332 > URL: https://issues.apache.org/jira/browse/DISPATCH-1332 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Tools >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Priority: Major > Attachments: opt-local-tree-full.txt > > > An installation of qpid-proton and qpid-dispatch is created with a cmake > install where both projects use: > {{cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/opt/local}} > qpid-dispatch places a 64-bit .so file in /opt/local/lib when it rightfully > belongs in /opt/local/lib64. > Further investigation of the install directories reveals some discrepancies > between qpid-proton and qpid-dispatch installation hierarchies. Please see > attached _tree_ listing. One might expect them to be symmetric where > possible. The current arrangement is confusing and makes it unnecessarily > difficult to use them both. Note that self tests force PATH and PYTHONPATH to > reflect the discovered locations but the values they use are not always > practical for simple stand-alone product usage. Using the /opt/local install > prefix then requires a PYTHONPATH like this; > {{/opt/local/lib/python3.7/site-packages}} > {{/opt/local/lib64/proton/bindings/python}} > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1332) Reconcile install directories and content
Chuck Rolke created DISPATCH-1332: - Summary: Reconcile install directories and content Key: DISPATCH-1332 URL: https://issues.apache.org/jira/browse/DISPATCH-1332 Project: Qpid Dispatch Issue Type: Improvement Components: Tools Affects Versions: 1.6.0 Reporter: Chuck Rolke An installation of qpid-proton and qpid-dispatch is created with a cmake install where both projects use: {{cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/opt/local}} qpid-dispatch places a 64-bit .so file in /opt/local/lib when it rightfully belongs in /opt/local/lib64. Further investigation of the install directories reveals some discrepancies between qpid-proton and qpid-dispatch installation hierarchies. Please see attached _tree_ listing. One might expect them to be symmetric where possible. The current arrangement is confusing and makes it unnecessarily difficult to use them both. Note that self tests force PATH and PYTHONPATH to reflect the discovered locations but the values they use are not always practical for simple stand-alone product usage. Using the /opt/local install prefix then requires a PYTHONPATH like this; {{/opt/local/lib/python3.7/site-packages}} {{/opt/local/lib64/proton/bindings/python}} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2042) Occasional engine.c:691: pni_add_work: Assertion `!delivery->local.settled' failed
[ https://issues.apache.org/jira/browse/PROTON-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834165#comment-16834165 ] Chuck Rolke commented on PROTON-2042: - This failure is triggered by the same subsection (test_06_message_route_abort_two_routers) of the same qpid-dispatch self test (system_tests_delivery_abort) as PROTON-2005. > Occasional engine.c:691: pni_add_work: Assertion `!delivery->local.settled' > failed > -- > > Key: PROTON-2042 > URL: https://issues.apache.org/jira/browse/PROTON-2042 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: To reproduce (I'm on fedora 29) > 1) build both qpid-dispatch and qpid-proton with -DCMAKE_BUILD_TYPE=Debug > 2) run the delivery abort Qpid dispatch router unit test in a loop: > $ while ctest -VV -R system_tests_delivery_abort; do date; done > The assert usually fires after a few minutes. >Reporter: Ken Giusti >Priority: Major > Fix For: proton-c-0.28.0 > > > When running the Qpid Dispatch Router's unit tests (written in python), > occasionally we see the test client (reactor based) core dump on the > following (abbreviated) assert: > Program terminated with signal SIGABRT, Aborted. > #0 0x7fc515270efb in raise () from /lib64/libc.so.6 > Missing separate debuginfos, use: dnf debuginfo-install > bzip2-libs-1.0.6-26.fc28.x86_64 compat-openssl10-1.0.2o-1.fc28.x86_64 > glibc-2.27-38.fc28.x86_64 krb5-libs-1.16.1-25.fc28.x86_64 > libdb-5.3.28-30.fc28.x86_64 libuuid-2.32.1-1.fc28.x86_64 > libxcrypt-4.4.4-2.fc28.x86_64 pcre2-10.33-1.fc28.x86_64 > (gdb) bt > #0 0x7fc515270efb in raise () from /lib64/libc.so.6 > #1 0x7fc51525b5b9 in abort () from /lib64/libc.so.6 > #2 0x7fc51525b491 in __assert_fail_base.cold.0 () from /lib64/libc.so.6 > #3 0x7fc515269662 in __assert_fail () from /lib64/libc.so.6 > #4 0x7fc5047512d8 in pni_add_work (connection=0x5651b44603e0, > delivery=0x5651b44d4920) at > /home/kgiusti/work/proton/qpid-proton/c/src/core/engine.c:691 > #5 0x7fc5047514cf in pn_work_update (connection=0x5651b44603e0, > delivery=0x5651b44d4920) at > /home/kgiusti/work/proton/qpid-proton/c/src/core/engine.c:715 > #6 0x7fc50475437f in pn_link_advance (link=0x5651b4441af0) at > /home/kgiusti/work/proton/qpid-proton/c/src/core/engine.c:1796 > #7 0x7fc5049c57ac in _wrap_pn_link_advance (self=0x0, > args=(,)) > at > /home/kgiusti/work/proton/qpid-proton/BUILD/python/CMakeFiles/_cproton.dir/cprotonPYTHON_wrap.c:9539 > #8 0x7fc5161216bb in call_function (oparg=, > pp_stack=0x7ffcfa109470) at > /usr/src/debug/python2-2.7.15-4.fc28.x86_64/Python/ceval.c:4449 > #9 PyEval_EvalFrameEx ( > f=f@entry=Frame 0x7fc5014d1578, for file > /opt/kgiusti/lib64/proton/bindings/python/proton/_endpoints.py, line 497, in > advance (self=, > _record=, _attrs={'tag_generator': > , 'condition': None}) at remote > 0x7fc5015078d0>), throwflag=throwflag@entry=0) at > /usr/src/debug/python2-2.7.15-4.fc28.x86_64/Python/ceval.c:3083 > #10 0x7fc516121e72 in PyEval_EvalCodeEx (co=, > globals=, locals=, args=, > argcount=, > kws=, kwcount=0, defs=0x0, defcount=0, closure=0x0) at > /usr/src/debug/python2-2.7.15-4.fc28.x86_64/Python/ceval.c:3681 > #11 0x7fc51611eaac in fast_function (nk=, na= out>, n=, pp_stack=0x7ffcfa109630, func= 0x7fc501ec5d70>) > at /usr/src/debug/python2-2.7.15-4.fc28.x86_64/Python/ceval.c:4544 > #12 call_function (oparg=, pp_stack=0x7ffcfa109630) at > /usr/src/debug/python2-2.7.15-4.fc28.x86_64/Python/ceval.c:4469 > #13 PyEval_EvalFrameEx ( > f=f@entry=Frame 0x7fc501a05400, for file > /opt/kgiusti/lib64/proton/bindings/python/proton/_message.py, line 405, in > send (self= 0x7fc501509de0>, annotations=None, _correlation_id= at remote 0x7fc501509c60>, _free=False) at remote 0x7fc5014fa710>, > _id=, _free=False) at > remote 0x7fc5014fab48>, properties=None, instructions=None) at remote > 0x7fc5000900d0>, sender= 0x7fc501509630>, _record=, > _attrs={'tag_generator': , 'condition': > None}) at remote 0x7fc5015078d0>, tag=None, dlv= at remote 0x7fc5015097e0>, _record=, > _attrs={'remote': , > _condition=None, _data=None, local=False, _annotations=None) at remote > 0x7fc5000902d0>, 'local': throwflag=throwflag@entry=0) at > /usr/src/debug/python2-2.7.15-4.fc28.x86_64/Python/ceval.c:3083 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1312) Remove cmake option USE_MEMORY_POOL
[ https://issues.apache.org/jira/browse/DISPATCH-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1312. --- Resolution: Fixed Fix Version/s: 1.8.0 Fixed at Commit 9500b4 > Remove cmake option USE_MEMORY_POOL > --- > > Key: DISPATCH-1312 > URL: https://issues.apache.org/jira/browse/DISPATCH-1312 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.8.0 > > > Memory pool must be ON and is no longer optional. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-2039) Python listener.close leaves socket in time_wait
[ https://issues.apache.org/jira/browse/PROTON-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke reassigned PROTON-2039: --- Assignee: Chuck Rolke > Python listener.close leaves socket in time_wait > > > Key: PROTON-2039 > URL: https://issues.apache.org/jira/browse/PROTON-2039 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: Fedora 29, python 3.7.3 > Fedora 28, python 2.7.15 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Attachments: PROTON-2039.patch > > > To demonstrate: execute python/examples/helloworld_direct.py two times within > a few seconds. The first time works and the second time fails with an > 'Address already in use' error. > The expectation is that this program can be run many times in quick > succession. > > {code:java} > (M=713c3 ?7) chug@unused examples> pwd > /home/chug/git/qpid-proton/python/examples > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Hello World! > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Traceback (most recent call last): > File "./helloworld_direct.py", line 48, in > Container(HelloWorld("localhost:/examples")).run() > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 181, in run > while self.process(): pass > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 238, in process > event.dispatch(handler) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, > in dispatch > self.dispatch(h, type) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, > in dispatch > _dispatch(handler, type.method, self) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, > in _dispatch > m(*args) > File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line > 476, in on_reactor_init > self.on_start(event) > File "./helloworld_direct.py", line 32, in on_start > self.acceptor = event.container.listen(self.url) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 1166, in listen > acceptor = self.acceptor(url.host, url.port) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 304, in acceptor > a = Acceptor(self, unicode2utf8(host), int(port), impl) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 678, in __init__ > sock = IO.listen(host, port) > File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in > listen > s.bind((host, port)) > OSError: [Errno 98] Address already in use > 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep > TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 > > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1324) [tools] Scraper uses deprecated cgi.escape function
[ https://issues.apache.org/jira/browse/DISPATCH-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1324. --- Resolution: Fixed Fixed at Commit ed1deb5 > [tools] Scraper uses deprecated cgi.escape function > --- > > Key: DISPATCH-1324 > URL: https://issues.apache.org/jira/browse/DISPATCH-1324 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.7.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.8.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2039) Python listener.close leaves socket in time_wait
[ https://issues.apache.org/jira/browse/PROTON-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated PROTON-2039: Summary: Python listener.close leaves socket in time_wait (was: Python listener.close does not close socket) > Python listener.close leaves socket in time_wait > > > Key: PROTON-2039 > URL: https://issues.apache.org/jira/browse/PROTON-2039 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: Fedora 29, python 3.7.3 > Fedora 28, python 2.7.15 >Reporter: Chuck Rolke >Priority: Major > Attachments: PROTON-2039.patch > > > To demonstrate: execute python/examples/helloworld_direct.py two times within > a few seconds. The first time works and the second time fails with an > 'Address already in use' error. > The expectation is that this program can be run many times in quick > succession. > > {code:java} > (M=713c3 ?7) chug@unused examples> pwd > /home/chug/git/qpid-proton/python/examples > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Hello World! > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Traceback (most recent call last): > File "./helloworld_direct.py", line 48, in > Container(HelloWorld("localhost:/examples")).run() > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 181, in run > while self.process(): pass > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 238, in process > event.dispatch(handler) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, > in dispatch > self.dispatch(h, type) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, > in dispatch > _dispatch(handler, type.method, self) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, > in _dispatch > m(*args) > File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line > 476, in on_reactor_init > self.on_start(event) > File "./helloworld_direct.py", line 32, in on_start > self.acceptor = event.container.listen(self.url) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 1166, in listen > acceptor = self.acceptor(url.host, url.port) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 304, in acceptor > a = Acceptor(self, unicode2utf8(host), int(port), impl) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 678, in __init__ > sock = IO.listen(host, port) > File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in > listen > s.bind((host, port)) > OSError: [Errno 98] Address already in use > 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep > TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 > > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2039) Python listener.close does not close socket
[ https://issues.apache.org/jira/browse/PROTON-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated PROTON-2039: Attachment: (was: PROTON-2039.patch) > Python listener.close does not close socket > --- > > Key: PROTON-2039 > URL: https://issues.apache.org/jira/browse/PROTON-2039 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: Fedora 29, python 3.7.3 > Fedora 28, python 2.7.15 >Reporter: Chuck Rolke >Priority: Major > Attachments: PROTON-2039.patch > > > To demonstrate: execute python/examples/helloworld_direct.py two times within > a few seconds. The first time works and the second time fails with an > 'Address already in use' error. > The expectation is that this program can be run many times in quick > succession. > > {code:java} > (M=713c3 ?7) chug@unused examples> pwd > /home/chug/git/qpid-proton/python/examples > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Hello World! > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Traceback (most recent call last): > File "./helloworld_direct.py", line 48, in > Container(HelloWorld("localhost:/examples")).run() > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 181, in run > while self.process(): pass > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 238, in process > event.dispatch(handler) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, > in dispatch > self.dispatch(h, type) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, > in dispatch > _dispatch(handler, type.method, self) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, > in _dispatch > m(*args) > File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line > 476, in on_reactor_init > self.on_start(event) > File "./helloworld_direct.py", line 32, in on_start > self.acceptor = event.container.listen(self.url) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 1166, in listen > acceptor = self.acceptor(url.host, url.port) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 304, in acceptor > a = Acceptor(self, unicode2utf8(host), int(port), impl) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 678, in __init__ > sock = IO.listen(host, port) > File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in > listen > s.bind((host, port)) > OSError: [Errno 98] Address already in use > 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep > TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 > > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2039) Python listener.close does not close socket
[ https://issues.apache.org/jira/browse/PROTON-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated PROTON-2039: Attachment: PROTON-2039.patch > Python listener.close does not close socket > --- > > Key: PROTON-2039 > URL: https://issues.apache.org/jira/browse/PROTON-2039 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: Fedora 29, python 3.7.3 > Fedora 28, python 2.7.15 >Reporter: Chuck Rolke >Priority: Major > Attachments: PROTON-2039.patch > > > To demonstrate: execute python/examples/helloworld_direct.py two times within > a few seconds. The first time works and the second time fails with an > 'Address already in use' error. > The expectation is that this program can be run many times in quick > succession. > > {code:java} > (M=713c3 ?7) chug@unused examples> pwd > /home/chug/git/qpid-proton/python/examples > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Hello World! > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Traceback (most recent call last): > File "./helloworld_direct.py", line 48, in > Container(HelloWorld("localhost:/examples")).run() > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 181, in run > while self.process(): pass > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 238, in process > event.dispatch(handler) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, > in dispatch > self.dispatch(h, type) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, > in dispatch > _dispatch(handler, type.method, self) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, > in _dispatch > m(*args) > File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line > 476, in on_reactor_init > self.on_start(event) > File "./helloworld_direct.py", line 32, in on_start > self.acceptor = event.container.listen(self.url) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 1166, in listen > acceptor = self.acceptor(url.host, url.port) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 304, in acceptor > a = Acceptor(self, unicode2utf8(host), int(port), impl) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 678, in __init__ > sock = IO.listen(host, port) > File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in > listen > s.bind((host, port)) > OSError: [Errno 98] Address already in use > 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep > TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 > > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2039) Python listener.close does not close socket
[ https://issues.apache.org/jira/browse/PROTON-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16831898#comment-16831898 ] Chuck Rolke commented on PROTON-2039: - Setting socket option SO_REUSEADDR along with TCP_NODELAY resolves the issue. See PROTON-2039.patch. > Python listener.close does not close socket > --- > > Key: PROTON-2039 > URL: https://issues.apache.org/jira/browse/PROTON-2039 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: Fedora 29, python 3.7.3 > Fedora 28, python 2.7.15 >Reporter: Chuck Rolke >Priority: Major > Attachments: PROTON-2039.patch > > > To demonstrate: execute python/examples/helloworld_direct.py two times within > a few seconds. The first time works and the second time fails with an > 'Address already in use' error. > The expectation is that this program can be run many times in quick > succession. > > {code:java} > (M=713c3 ?7) chug@unused examples> pwd > /home/chug/git/qpid-proton/python/examples > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Hello World! > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Traceback (most recent call last): > File "./helloworld_direct.py", line 48, in > Container(HelloWorld("localhost:/examples")).run() > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 181, in run > while self.process(): pass > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 238, in process > event.dispatch(handler) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, > in dispatch > self.dispatch(h, type) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, > in dispatch > _dispatch(handler, type.method, self) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, > in _dispatch > m(*args) > File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line > 476, in on_reactor_init > self.on_start(event) > File "./helloworld_direct.py", line 32, in on_start > self.acceptor = event.container.listen(self.url) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 1166, in listen > acceptor = self.acceptor(url.host, url.port) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 304, in acceptor > a = Acceptor(self, unicode2utf8(host), int(port), impl) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 678, in __init__ > sock = IO.listen(host, port) > File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in > listen > s.bind((host, port)) > OSError: [Errno 98] Address already in use > 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep > TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 > > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2039) Python listener.close does not close socket
[ https://issues.apache.org/jira/browse/PROTON-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated PROTON-2039: Attachment: PROTON-2039.patch > Python listener.close does not close socket > --- > > Key: PROTON-2039 > URL: https://issues.apache.org/jira/browse/PROTON-2039 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.1 > Environment: Fedora 29, python 3.7.3 > Fedora 28, python 2.7.15 >Reporter: Chuck Rolke >Priority: Major > Attachments: PROTON-2039.patch > > > To demonstrate: execute python/examples/helloworld_direct.py two times within > a few seconds. The first time works and the second time fails with an > 'Address already in use' error. > The expectation is that this program can be run many times in quick > succession. > > {code:java} > (M=713c3 ?7) chug@unused examples> pwd > /home/chug/git/qpid-proton/python/examples > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Hello World! > (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py > Traceback (most recent call last): > File "./helloworld_direct.py", line 48, in > Container(HelloWorld("localhost:/examples")).run() > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 181, in run > while self.process(): pass > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 238, in process > event.dispatch(handler) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, > in dispatch > self.dispatch(h, type) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, > in dispatch > _dispatch(handler, type.method, self) > File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, > in _dispatch > m(*args) > File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line > 476, in on_reactor_init > self.on_start(event) > File "./helloworld_direct.py", line 32, in on_start > self.acceptor = event.container.listen(self.url) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 1166, in listen > acceptor = self.acceptor(url.host, url.port) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 304, in acceptor > a = Acceptor(self, unicode2utf8(host), int(port), impl) > File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line > 678, in __init__ > sock = IO.listen(host, port) > File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in > listen > s.bind((host, port)) > OSError: [Errno 98] Address already in use > 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep > TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 > > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2039) Python listener.close does not close socket
Chuck Rolke created PROTON-2039: --- Summary: Python listener.close does not close socket Key: PROTON-2039 URL: https://issues.apache.org/jira/browse/PROTON-2039 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: proton-c-0.27.1 Environment: Fedora 29, python 3.7.3 Fedora 28, python 2.7.15 Reporter: Chuck Rolke To demonstrate: execute python/examples/helloworld_direct.py two times within a few seconds. The first time works and the second time fails with an 'Address already in use' error. The expectation is that this program can be run many times in quick succession. {code:java} (M=713c3 ?7) chug@unused examples> pwd /home/chug/git/qpid-proton/python/examples (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py Hello World! (M=713c3 ?7) chug@unused examples> ./helloworld_direct.py Traceback (most recent call last): File "./helloworld_direct.py", line 48, in Container(HelloWorld("localhost:/examples")).run() File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line 181, in run while self.process(): pass File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line 238, in process event.dispatch(handler) File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 138, in dispatch self.dispatch(h, type) File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 135, in dispatch _dispatch(handler, type.method, self) File "/opt/local/lib64/proton/bindings/python/proton/_events.py", line 115, in _dispatch m(*args) File "/opt/local/lib64/proton/bindings/python/proton/_handlers.py", line 476, in on_reactor_init self.on_start(event) File "./helloworld_direct.py", line 32, in on_start self.acceptor = event.container.listen(self.url) File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line 1166, in listen acceptor = self.acceptor(url.host, url.port) File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line 304, in acceptor a = Acceptor(self, unicode2utf8(host), int(port), impl) File "/opt/local/lib64/proton/bindings/python/proton/_reactor.py", line 678, in __init__ sock = IO.listen(host, port) File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 46, in listen s.bind((host, port)) OSError: [Errno 98] Address already in use 1 (M=713c3 ?7) chug@unused examples> ss -t -a -n | grep TIME-WAIT 0 0 127.0.0.1: 127.0.0.1:42648 {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1329) Edge router system test needs skip test convenience switches
[ https://issues.apache.org/jira/browse/DISPATCH-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1329. --- Resolution: Fixed Assignee: Chuck Rolke Fix Version/s: 1.8.0 Commit 797f3bd > Edge router system test needs skip test convenience switches > > > Key: DISPATCH-1329 > URL: https://issues.apache.org/jira/browse/DISPATCH-1329 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.8.0 > > > See system_tests_topology_disposition.py cls.skip and the application to > skipTest for a model. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (DISPATCH-1324) [tools] Scraper uses deprecated cgi.escape function
[ https://issues.apache.org/jira/browse/DISPATCH-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke reopened DISPATCH-1324: --- commit b1b17b did not work for all users > [tools] Scraper uses deprecated cgi.escape function > --- > > Key: DISPATCH-1324 > URL: https://issues.apache.org/jira/browse/DISPATCH-1324 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.7.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.8.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1329) Edge router system test needs skip test convenience switches
Chuck Rolke created DISPATCH-1329: - Summary: Edge router system test needs skip test convenience switches Key: DISPATCH-1329 URL: https://issues.apache.org/jira/browse/DISPATCH-1329 Project: Qpid Dispatch Issue Type: Improvement Reporter: Chuck Rolke See system_tests_topology_disposition.py cls.skip and the application to skipTest for a model. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1324) [tools] Scraper uses deprecated cgi.escape function
[ https://issues.apache.org/jira/browse/DISPATCH-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1324. --- Resolution: Fixed Fixed at Commit b1b17b4 > [tools] Scraper uses deprecated cgi.escape function > --- > > Key: DISPATCH-1324 > URL: https://issues.apache.org/jira/browse/DISPATCH-1324 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 1.7.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.8.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2033) qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test
[ https://issues.apache.org/jira/browse/PROTON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved PROTON-2033. - Resolution: Not A Bug Subtle timing changes exposed bug in qpid-dispatch mission code. > qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test > - > > Key: PROTON-2033 > URL: https://issues.apache.org/jira/browse/PROTON-2033 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: proton-c-0.28.0 > Environment: Fedora 29, python 3.7, proton and dispatch debug builds >Reporter: Chuck Rolke >Assignee: Andrew Stitcher >Priority: Major > > While cleaning up qpid-dispatch for a 1.6 follow-on release an intermittent > failure in one of the tests was exposed. Analysis of the failure is in > https://issues.apache.org/jira/browse/DISPATCH-1322 in an attached text > document > https://issues.apache.org/jira/secure/attachment/12965891/DISPATCH-1322-analysis.txt > Another part of the cleanup was fixing the failing test to better report what > went wrong. See https://issues.apache.org/jira/browse/DISPATCH-1318 > These issues happened using qpid-proton master @9ff0a. Temporarily the > qpid-proton version was reverted to branch 0.27.x @560ba. Using proton 0.27.x > branch the qpid-dispatch self test does not fail. It passed several thousand > times in a loop. Moving proton back to the master branch brought the dispatch > failures back. > From the qpid-dispatch perspective this issue is serious. If a receiver > detaches a link while a sender is sending to it then the sender may lose a > disposition. > No attempt yet has been made to bisect proton to see where the different > behavior starts showing up. That may be the next best avenue of research. > Another theory for the error is that qpid-dispatch has been mishandling links > all along. > To help expose the problem one may clone > [https://github.com/ChugR/qpid-dispatch] , or add it as a remote, and then > check out branch DISPATCH-1318-cwip. Test system_tests_edge_router has been > gutted to run only test_12 in a loop and to print details of the error(s). > {{ cd build}} > {{ make}} > {{ ctest -VV -R edge}} > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1318) edge_router system test failing
[ https://issues.apache.org/jira/browse/DISPATCH-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1318. --- Resolution: Fixed Fix Version/s: 1.8.0 Fixed at Commit 350a139 > edge_router system test failing > > > Key: DISPATCH-1318 > URL: https://issues.apache.org/jira/browse/DISPATCH-1318 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.8.0 > > > {quote}{{0: > ==}} > {{50: FAIL: test_22_mobile_address_edge_sender_two_interior_receivers > (system_tests_edge_router.RouterTest)}} > {{50: > --}} > {{50: Traceback (most recent call last):}} > {{50: File > "/home/chug/git/qpid-dispatch/tests/system_tests_edge_router.py", line 451, > in test_22_mobile_address_edge_sender_two_interior_receivers}} > {{50: self.assertEqual(None, test.error)}} > {{50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 > chars]t_22'}} > \{{50: }} > {{50: > --}} > {{50: Ran 48 tests in 84.066s}} > \{{50: }} > {{50: FAILED (failures=1)}} > {{1/1 Test #50: system_tests_edge_router .***Failed 84.37 sec}} > {quote} > This test also suffers from the test framework eliding important text in the > error message: > 50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 > chars]t_22' > Seeing the *[36* chars] is a vital to the test showing what went wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1327) Router stops forwarding multicast deliveries (large messages) to connected receivers after a receiver closes its connection
[ https://issues.apache.org/jira/browse/DISPATCH-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16827310#comment-16827310 ] Chuck Rolke commented on DISPATCH-1327: --- Test this again after master commit 39309ea3 which fixed a similar issue in DISPATCH-1322 > Router stops forwarding multicast deliveries (large messages) to connected > receivers after a receiver closes its connection > --- > > Key: DISPATCH-1327 > URL: https://issues.apache.org/jira/browse/DISPATCH-1327 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.7.0 >Reporter: Fernando Giorgetti >Priority: Major > > The problem can be observed running > *test_40_drop_rx_client_multicast_large_message*** from > *system_tests_edge_router*. > It does not happen all the time, but after some attempts it will fail and we > can observe receivers won't get all sent messages and then test times out. > Further info to be attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2033) qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test
[ https://issues.apache.org/jira/browse/PROTON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16827294#comment-16827294 ] Chuck Rolke commented on PROTON-2033: - Working out the analysis proves that post-0.27 proton did not 'break dispatch self tests'. * Dispatch had a latent bug and some (presumably) proton timing changes exposed that bug. * Dispatch self tests were unprepared for the python receiver to get on_settled callbacks. That said, before dismissing this issue a discussion of the timing change and the on_settled callbacks is in order. h3. Test Overview For review, how did the test work? {code:java} +-+ ++ | INT.A | | EA1 | +---+ +---+ +---+ edge | +---+ +---+ | receiver |<--+ 21001 | | 21000 |<* | 21002 |<--+ sender | +---+ +---+ +---+ | +---+ +---+ | interior | | edge | +-+ ++ ^ ^ ^ CONN1 CONN2 CONN3 {code} From a single reactor container a proton python sender and receiver connect to two routers respectively. * The test injects some number of messages at the sender and verifies that they are all accepted. * Then the receiver is closed (connection stays open) and 50 messages are injected by the sender. * The expectation is that all the 50 messages are released. h3. Timing Change A significant change was measured between when the receiver client called receiver.close() and when the corresponding detach was received by INT.A port 21001. ||Time mS||0.27.x||master|| |run 1|3.2|14.5| |run 2|3.3|17.3| These timings are reflected in the self test behavior: * The 0.27.x code is "so fast" that it detaches the receiver before any of the messages in the 50-message storm get through INT.A. All of the messages are released by the router network. No messages were released or modified by the receiver. * The master branch is "so slow" that one or possibly up to a dozen messages are sent to the receiver by INT.A. Now the receiver is dealing with a receiver close in the face of incoming messages. Now some messages are seen as 'modified' by the sender and not just released. Is there an explanation for why the client response to the receiver.close() is so slow compared to 0.27.x? h3. Receiver on_settled callbacks These appear when the receiver is closing in the face of incoming messages. This may not be a new issue as dispatch self tests never had to deal with them before. If it *is* an new issue some consideration must be given for how existing clients (like dispatch self tests) must be modified to deal with them. > qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test > - > > Key: PROTON-2033 > URL: https://issues.apache.org/jira/browse/PROTON-2033 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: proton-c-0.28.0 > Environment: Fedora 29, python 3.7, proton and dispatch debug builds >Reporter: Chuck Rolke >Priority: Major > > While cleaning up qpid-dispatch for a 1.6 follow-on release an intermittent > failure in one of the tests was exposed. Analysis of the failure is in > https://issues.apache.org/jira/browse/DISPATCH-1322 in an attached text > document > https://issues.apache.org/jira/secure/attachment/12965891/DISPATCH-1322-analysis.txt > Another part of the cleanup was fixing the failing test to better report what > went wrong. See https://issues.apache.org/jira/browse/DISPATCH-1318 > These issues happened using qpid-proton master @9ff0a. Temporarily the > qpid-proton version was reverted to branch 0.27.x @560ba. Using proton 0.27.x > branch the qpid-dispatch self test does not fail. It passed several thousand > times in a loop. Moving proton back to the master branch brought the dispatch > failures back. > From the qpid-dispatch perspective this issue is serious. If a receiver > detaches a link while a sender is sending to it then the sender may lose a > disposition. > No attempt yet has been made to bisect proton to see where the different > behavior starts showing up. That may be the next best avenue of research. > Another theory for the error is that qpid-dispatch has been mishandling links > all along. > To help expose the problem one may clone > [https://github.com/ChugR/qpid-dispatch] , or add it as a remote, and then > check out branch DISPATCH-1318-cwip. Test system_tests_edge_router has been > gutted to run only test_12 in a
[jira] [Updated] (DISPATCH-1325) Sender connections to edge router that connect 'too soon' never get credit
[ https://issues.apache.org/jira/browse/DISPATCH-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1325: -- Attachment: DISPATCH-1325-test-hang.html > Sender connections to edge router that connect 'too soon' never get credit > -- > > Key: DISPATCH-1325 > URL: https://issues.apache.org/jira/browse/DISPATCH-1325 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.7.0 > Environment: Fedora 29, python 3.7 > Dispatch master of today. > Proton 0.27.x branch > Source code in repository [https://github.com/ChugR/qpid-dispatch] > branch crolke-DISPATCH-1322 > directory tools/DISPATCH-1322 > >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1325-test-hang.html > > > A stand-alone self test was extracted from system_tests_edge_router. Running > the test involves starting the routers and then running the client. If this > is repeated in a script then there must be a fairly long delay between > starting the routers and running the client. > If the delay is 6 seconds then the client sender seems to run fine every time. > If the delay is 4 seconds then the client sender routinely (half the time?) > fails to get an on_sendable event as no credit is ever issued by the edge > router. A protocol trace to be attached. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1325) Sender connections to edge router that connect 'too soon' never get credit
Chuck Rolke created DISPATCH-1325: - Summary: Sender connections to edge router that connect 'too soon' never get credit Key: DISPATCH-1325 URL: https://issues.apache.org/jira/browse/DISPATCH-1325 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 1.7.0 Environment: Fedora 29, python 3.7 Dispatch master of today. Proton 0.27.x branch Source code in repository [https://github.com/ChugR/qpid-dispatch] branch crolke-DISPATCH-1322 directory tools/DISPATCH-1322 Reporter: Chuck Rolke A stand-alone self test was extracted from system_tests_edge_router. Running the test involves starting the routers and then running the client. If this is repeated in a script then there must be a fairly long delay between starting the routers and running the client. If the delay is 6 seconds then the client sender seems to run fine every time. If the delay is 4 seconds then the client sender routinely (half the time?) fails to get an on_sendable event as no credit is ever issued by the edge router. A protocol trace to be attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1324) [tools] Scraper uses deprecated cgi.escape function
Chuck Rolke created DISPATCH-1324: - Summary: [tools] Scraper uses deprecated cgi.escape function Key: DISPATCH-1324 URL: https://issues.apache.org/jira/browse/DISPATCH-1324 Project: Qpid Dispatch Issue Type: Bug Components: Tools Affects Versions: 1.7.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Fix For: 1.8.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1322) Edge router drops disposition when remote receiver closes
[ https://issues.apache.org/jira/browse/DISPATCH-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825455#comment-16825455 ] Chuck Rolke commented on DISPATCH-1322: --- A standalone test program is available at remote [https://github.com/ChugR/qpid-dispatch] branch crolke-DISPATCH-1322 files tools/DISPATCH-1322 > Edge router drops disposition when remote receiver closes > - > > Key: DISPATCH-1322 > URL: https://issues.apache.org/jira/browse/DISPATCH-1322 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1322-analysis.txt > > > The test is available in system_tests_edge_router. > The analysis is attached as a file. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1230) System test failing with OpenSSL >= 1.1 - system_tests_ssl
[ https://issues.apache.org/jira/browse/DISPATCH-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1230. --- Resolution: Fixed Fix Version/s: 1.8.0 Now detects OpenSSL version from CLI, Python, and Proton to skip or to run tests as appropriate. > System test failing with OpenSSL >= 1.1 - system_tests_ssl > -- > > Key: DISPATCH-1230 > URL: https://issues.apache.org/jira/browse/DISPATCH-1230 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.6.0 >Reporter: Fernando Giorgetti >Assignee: Fernando Giorgetti >Priority: Major > Fix For: 1.8.0 > > > A system test is failing when OpenSSL >= 1.1 is installed on running system: > system_tests_ssl. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2033) qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test
[ https://issues.apache.org/jira/browse/PROTON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16821447#comment-16821447 ] Chuck Rolke commented on PROTON-2033: - It looks like the python receive client starts getting confused during shutdown in the face of incoming traffic. After further instrumenting the test a run will fail: {code:java} 50: ??? Receiver on_settled. remote: 0, local: RELEASED 50: Bad sender settlement: 0, n_accepted: 300, n_rel_or_mod: 0 50: MobileAddressTest fail: Timeout Expired 50: address test_12_19 50: n_sent = 350. Expected total:350 normal=300, extra=50 50: n_rcvd = 300. Expected 300 50: n_accepted = 300. Expected 300 50: n_rel_or_mod = 49. Expected 50 {code} * The receiver should not receive settlements. A single receive settlement was processed. * The sender settlement of 0 arises at the test expects all settlements to be sender settlements and this one was not. * The test failed because the sender is missing one settlement. The test code is available in branch DISPATCH-1318-2, repo [https://github.com/ChugR/qpid-dispatch.git] The test fails with command *ctest -VV -R edge* > qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test > - > > Key: PROTON-2033 > URL: https://issues.apache.org/jira/browse/PROTON-2033 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: proton-c-0.28.0 > Environment: Fedora 29, python 3.7, proton and dispatch debug builds >Reporter: Chuck Rolke >Priority: Major > > While cleaning up qpid-dispatch for a 1.6 follow-on release an intermittent > failure in one of the tests was exposed. Analysis of the failure is in > https://issues.apache.org/jira/browse/DISPATCH-1322 in an attached text > document > https://issues.apache.org/jira/secure/attachment/12965891/DISPATCH-1322-analysis.txt > Another part of the cleanup was fixing the failing test to better report what > went wrong. See https://issues.apache.org/jira/browse/DISPATCH-1318 > These issues happened using qpid-proton master @9ff0a. Temporarily the > qpid-proton version was reverted to branch 0.27.x @560ba. Using proton 0.27.x > branch the qpid-dispatch self test does not fail. It passed several thousand > times in a loop. Moving proton back to the master branch brought the dispatch > failures back. > From the qpid-dispatch perspective this issue is serious. If a receiver > detaches a link while a sender is sending to it then the sender may lose a > disposition. > No attempt yet has been made to bisect proton to see where the different > behavior starts showing up. That may be the next best avenue of research. > Another theory for the error is that qpid-dispatch has been mishandling links > all along. > To help expose the problem one may clone > [https://github.com/ChugR/qpid-dispatch] , or add it as a remote, and then > check out branch DISPATCH-1318-cwip. Test system_tests_edge_router has been > gutted to run only test_12 in a loop and to print details of the error(s). > {{ cd build}} > {{ make}} > {{ ctest -VV -R edge}} > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2033) qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test
[ https://issues.apache.org/jira/browse/PROTON-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819486#comment-16819486 ] Chuck Rolke commented on PROTON-2033: - Things start failing at commit 1d6e14 {{PROTON-1992: [Python] Remove dependency on Proton Reactor API 2019-01-15 16:41:57}} Immediately before this commit the Dispatch self test runs thousands of passes OK. After this commit the tests fail after at most a few hundred passes. This is with Python 3.7.2 on Fedora 29 > qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test > - > > Key: PROTON-2033 > URL: https://issues.apache.org/jira/browse/PROTON-2033 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c, python-binding >Affects Versions: proton-c-0.28.0 > Environment: Fedora 29, python 3.7, proton and dispatch debug builds >Reporter: Chuck Rolke >Priority: Major > > While cleaning up qpid-dispatch for a 1.6 follow-on release an intermittent > failure in one of the tests was exposed. Analysis of the failure is in > https://issues.apache.org/jira/browse/DISPATCH-1322 in an attached text > document > https://issues.apache.org/jira/secure/attachment/12965891/DISPATCH-1322-analysis.txt > Another part of the cleanup was fixing the failing test to better report what > went wrong. See https://issues.apache.org/jira/browse/DISPATCH-1318 > These issues happened using qpid-proton master @9ff0a. Temporarily the > qpid-proton version was reverted to branch 0.27.x @560ba. Using proton 0.27.x > branch the qpid-dispatch self test does not fail. It passed several thousand > times in a loop. Moving proton back to the master branch brought the dispatch > failures back. > From the qpid-dispatch perspective this issue is serious. If a receiver > detaches a link while a sender is sending to it then the sender may lose a > disposition. > No attempt yet has been made to bisect proton to see where the different > behavior starts showing up. That may be the next best avenue of research. > Another theory for the error is that qpid-dispatch has been mishandling links > all along. > To help expose the problem one may clone > [https://github.com/ChugR/qpid-dispatch] , or add it as a remote, and then > check out branch DISPATCH-1318-cwip. Test system_tests_edge_router has been > gutted to run only test_12 in a loop and to print details of the error(s). > {{ cd build}} > {{ make}} > {{ ctest -VV -R edge}} > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2033) qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test
Chuck Rolke created PROTON-2033: --- Summary: qpid-proton changes 0.27.x to master(9ff0a) break qpid-dispatch self test Key: PROTON-2033 URL: https://issues.apache.org/jira/browse/PROTON-2033 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: proton-c-0.28.0 Environment: Fedora 29, python 3.7, proton and dispatch debug builds Reporter: Chuck Rolke While cleaning up qpid-dispatch for a 1.6 follow-on release an intermittent failure in one of the tests was exposed. Analysis of the failure is in https://issues.apache.org/jira/browse/DISPATCH-1322 in an attached text document https://issues.apache.org/jira/secure/attachment/12965891/DISPATCH-1322-analysis.txt Another part of the cleanup was fixing the failing test to better report what went wrong. See https://issues.apache.org/jira/browse/DISPATCH-1318 These issues happened using qpid-proton master @9ff0a. Temporarily the qpid-proton version was reverted to branch 0.27.x @560ba. Using proton 0.27.x branch the qpid-dispatch self test does not fail. It passed several thousand times in a loop. Moving proton back to the master branch brought the dispatch failures back. >From the qpid-dispatch perspective this issue is serious. If a receiver >detaches a link while a sender is sending to it then the sender may lose a >disposition. No attempt yet has been made to bisect proton to see where the different behavior starts showing up. That may be the next best avenue of research. Another theory for the error is that qpid-dispatch has been mishandling links all along. To help expose the problem one may clone [https://github.com/ChugR/qpid-dispatch] , or add it as a remote, and then check out branch DISPATCH-1318-cwip. Test system_tests_edge_router has been gutted to run only test_12 in a loop and to print details of the error(s). {{ cd build}} {{ make}} {{ ctest -VV -R edge}} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1322) Edge router drops disposition when remote receiver closes
[ https://issues.apache.org/jira/browse/DISPATCH-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1322: -- Attachment: (was: DISPATCH-1322-analysis.txt) > Edge router drops disposition when remote receiver closes > - > > Key: DISPATCH-1322 > URL: https://issues.apache.org/jira/browse/DISPATCH-1322 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1322-analysis.txt > > > The test is available in system_tests_edge_router. > The analysis is attached as a file. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1322) Edge router drops disposition when remote receiver closes
[ https://issues.apache.org/jira/browse/DISPATCH-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1322: -- Attachment: DISPATCH-1322-analysis.txt > Edge router drops disposition when remote receiver closes > - > > Key: DISPATCH-1322 > URL: https://issues.apache.org/jira/browse/DISPATCH-1322 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1322-analysis.txt > > > The test is available in system_tests_edge_router. > The analysis is attached as a file. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1322) Edge router drops disposition when remote receiver closes
[ https://issues.apache.org/jira/browse/DISPATCH-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1322: -- Attachment: DISPATCH-1322-analysis.txt > Edge router drops disposition when remote receiver closes > - > > Key: DISPATCH-1322 > URL: https://issues.apache.org/jira/browse/DISPATCH-1322 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1322-analysis.txt > > > The test is available in system_tests_edge_router. > The analysis is attached as a file. > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1322) Edge router drops disposition when remote receiver closes
Chuck Rolke created DISPATCH-1322: - Summary: Edge router drops disposition when remote receiver closes Key: DISPATCH-1322 URL: https://issues.apache.org/jira/browse/DISPATCH-1322 Project: Qpid Dispatch Issue Type: Bug Components: Routing Engine Affects Versions: 1.6.0 Reporter: Chuck Rolke The test is available in system_tests_edge_router. The analysis is attached as a file. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1318) edge_router system test failing
[ https://issues.apache.org/jira/browse/DISPATCH-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817484#comment-16817484 ] Chuck Rolke commented on DISPATCH-1318: --- This Jira will focus on the small issues: * dispositions of 'modified' are not counted * Error messages are truncated by the test framework > edge_router system test failing > > > Key: DISPATCH-1318 > URL: https://issues.apache.org/jira/browse/DISPATCH-1318 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > > {quote}{{0: > ==}} > {{50: FAIL: test_22_mobile_address_edge_sender_two_interior_receivers > (system_tests_edge_router.RouterTest)}} > {{50: > --}} > {{50: Traceback (most recent call last):}} > {{50: File > "/home/chug/git/qpid-dispatch/tests/system_tests_edge_router.py", line 451, > in test_22_mobile_address_edge_sender_two_interior_receivers}} > {{50: self.assertEqual(None, test.error)}} > {{50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 > chars]t_22'}} > \{{50: }} > {{50: > --}} > {{50: Ran 48 tests in 84.066s}} > \{{50: }} > {{50: FAILED (failures=1)}} > {{1/1 Test #50: system_tests_edge_router .***Failed 84.37 sec}} > {quote} > This test also suffers from the test framework eliding important text in the > error message: > 50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 > chars]t_22' > Seeing the *[36* chars] is a vital to the test showing what went wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1318) edge_router system test failing
[ https://issues.apache.org/jira/browse/DISPATCH-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1318: -- Description: {quote}{{0: ==}} {{50: FAIL: test_22_mobile_address_edge_sender_two_interior_receivers (system_tests_edge_router.RouterTest)}} {{50: --}} {{50: Traceback (most recent call last):}} {{50: File "/home/chug/git/qpid-dispatch/tests/system_tests_edge_router.py", line 451, in test_22_mobile_address_edge_sender_two_interior_receivers}} {{50: self.assertEqual(None, test.error)}} {{50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 chars]t_22'}} \{{50: }} {{50: --}} {{50: Ran 48 tests in 84.066s}} \{{50: }} {{50: FAILED (failures=1)}} {{1/1 Test #50: system_tests_edge_router .***Failed 84.37 sec}} {quote} This test also suffers from the test framework eliding important text in the error message: 50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 chars]t_22' Seeing the *[36* chars] is a vital to the test showing what went wrong. was: {quote}{{0: ==}} {{50: FAIL: test_22_mobile_address_edge_sender_two_interior_receivers (system_tests_edge_router.RouterTest)}} {{50: --}} {{50: Traceback (most recent call last):}} {{50: File "/home/chug/git/qpid-dispatch/tests/system_tests_edge_router.py", line 451, in test_22_mobile_address_edge_sender_two_interior_receivers}} {{50: self.assertEqual(None, test.error)}} {{50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 chars]t_22'}} {{50: }} {{50: --}} {{50: Ran 48 tests in 84.066s}} {{50: }} {{50: FAILED (failures=1)}} {{1/1 Test #50: system_tests_edge_router .***Failed 84.37 sec}}{quote} Summary: edge_router system test failing (was: edge_router system test failing - timeout with n_sent too big) > edge_router system test failing > > > Key: DISPATCH-1318 > URL: https://issues.apache.org/jira/browse/DISPATCH-1318 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > > {quote}{{0: > ==}} > {{50: FAIL: test_22_mobile_address_edge_sender_two_interior_receivers > (system_tests_edge_router.RouterTest)}} > {{50: > --}} > {{50: Traceback (most recent call last):}} > {{50: File > "/home/chug/git/qpid-dispatch/tests/system_tests_edge_router.py", line 451, > in test_22_mobile_address_edge_sender_two_interior_receivers}} > {{50: self.assertEqual(None, test.error)}} > {{50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 > chars]t_22'}} > \{{50: }} > {{50: > --}} > {{50: Ran 48 tests in 84.066s}} > \{{50: }} > {{50: FAILED (failures=1)}} > {{1/1 Test #50: system_tests_edge_router .***Failed 84.37 sec}} > {quote} > This test also suffers from the test framework eliding important text in the > error message: > 50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 > chars]t_22' > Seeing the *[36* chars] is a vital to the test showing what went wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1318) edge_router system test failing - timeout with n_sent too big
Chuck Rolke created DISPATCH-1318: - Summary: edge_router system test failing - timeout with n_sent too big Key: DISPATCH-1318 URL: https://issues.apache.org/jira/browse/DISPATCH-1318 Project: Qpid Dispatch Issue Type: Bug Components: Tests Affects Versions: 1.6.0 Reporter: Chuck Rolke Assignee: Chuck Rolke {quote}{{0: ==}} {{50: FAIL: test_22_mobile_address_edge_sender_two_interior_receivers (system_tests_edge_router.RouterTest)}} {{50: --}} {{50: Traceback (most recent call last):}} {{50: File "/home/chug/git/qpid-dispatch/tests/system_tests_edge_router.py", line 451, in test_22_mobile_address_edge_sender_two_interior_receivers}} {{50: self.assertEqual(None, test.error)}} {{50: AssertionError: None != 'Timeout Expired - n_sent=350 n_rcvd=300 [36 chars]t_22'}} {{50: }} {{50: --}} {{50: Ran 48 tests in 84.066s}} {{50: }} {{50: FAILED (failures=1)}} {{1/1 Test #50: system_tests_edge_router .***Failed 84.37 sec}}{quote} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1283) Router crash when link gets freed before its deliveries are freed
[ https://issues.apache.org/jira/browse/DISPATCH-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1283: -- Attachment: ea1.html > Router crash when link gets freed before its deliveries are freed > - > > Key: DISPATCH-1283 > URL: https://issues.apache.org/jira/browse/DISPATCH-1283 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.5.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > Attachments: ea1.html > > > {noformat} > (gdb) bt > #0 0x7ff1db20d060 in qdr_delete_delivery_internal_CT (core=0x1416180, > delivery=0x7ff1c80d2fe8) at > /home/gmurthy/opensource/qpid-dispatch/src/router_core/transfer.c:613 > #1 0x7ff1db20e9b6 in qdr_delete_delivery_CT (core=0x1416180, > action=0x7ff1bc33d828, discard=false) at > /home/gmurthy/opensource/qpid-dispatch/src/router_core/transfer.c:1221 > #2 0x7ff1db206ec0 in router_core_thread (arg=0x1416180) at > /home/gmurthy/opensource/qpid-dispatch/src/router_core/router_core_thread.c:148 > #3 0x7ff1db11858e in start_thread () from /lib64/libpthread.so.0 > #4 0x7ff1dabc06a3 in clone () from /lib64/libc.so.6 > (gdb){noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1283) Router crash when link gets freed before its deliveries are freed
[ https://issues.apache.org/jira/browse/DISPATCH-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814904#comment-16814904 ] Chuck Rolke commented on DISPATCH-1283: --- Self test system_tests_edge_router exposes this issue. In the failed run 'test_11' appears to complete ok but 'test_12' is ERROR. The problem is that test_11 crashed router EA1. In RouterTest/setUpClass directory is a core dump. This file shows a back trace similar to the base jira. The core identifies router EA1 as the crashed router. Scraper tool is run on EA1.log and the output is attached as file ea1.html. In this run: * edge router EA1 has a long-lived connection A0_1 to interior router INT.A * edge router EA1 has a client connection to receiver peer_9 Examining the web file ea1.html: * 2019-04-10 15:48:11.998243 peer_9 closes the receiver link to router EA1. * EA1 responds by detaching its link to peer_9 * 2019-04-10 15:48:11.998529 Edge EA1 has no open clients so it detaches its link [0,7] to interior INT.A * INT.A hasn't heard about the closed link yet and blasts transfers 1208..1256 to edge EA1. * 2019-04-10 15:48:12.007543 INT.A closes link [0,7] Now the Edge EA1 and interior INT.A behavior gets a little sketchy: * 2019-04-10 15:48:12.007543 EA1 sends receiver dispositions for 1208..1256 back to INT.A Note that these dispositions have no final state. * 2019-04-10 15:48:12.009673 INT.A, receiving dispositions with no state sends _sender_ dispositions back to EA1. As soon as EA1 starts receiving the sender dispositions it crashes. === >From a protocol standpoint both routers would be better off if they didn't >respond at all to transfers or dispositions after they sent the detach to close the links. > Router crash when link gets freed before its deliveries are freed > - > > Key: DISPATCH-1283 > URL: https://issues.apache.org/jira/browse/DISPATCH-1283 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 1.5.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy >Priority: Major > > {noformat} > (gdb) bt > #0 0x7ff1db20d060 in qdr_delete_delivery_internal_CT (core=0x1416180, > delivery=0x7ff1c80d2fe8) at > /home/gmurthy/opensource/qpid-dispatch/src/router_core/transfer.c:613 > #1 0x7ff1db20e9b6 in qdr_delete_delivery_CT (core=0x1416180, > action=0x7ff1bc33d828, discard=false) at > /home/gmurthy/opensource/qpid-dispatch/src/router_core/transfer.c:1221 > #2 0x7ff1db206ec0 in router_core_thread (arg=0x1416180) at > /home/gmurthy/opensource/qpid-dispatch/src/router_core/router_core_thread.c:148 > #3 0x7ff1db11858e in start_thread () from /lib64/libpthread.so.0 > #4 0x7ff1dabc06a3 in clone () from /lib64/libc.so.6 > (gdb){noformat} -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1309) Various crashes in 1.6 release
[ https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1309. --- Resolution: Fixed Commits 57c3603 and c27d73b put the router back on track. * When the console disconnects it usually emits a query immediately (200 uS) before detaching the links and closing the connection. This ensured that there was a work item in the router to be processed as the link/session/connection closed and created the opportunity to perform work on a closed link. Commit 57c3603 fixed that. * Commit c27d7eb fixed an issue where code on one thread freed an object in use by another thread. The result was random memory corruption that manifested itself in a variety of ways. > Various crashes in 1.6 release > -- > > Key: DISPATCH-1309 > URL: https://issues.apache.org/jira/browse/DISPATCH-1309 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.6.0 > Environment: System 'unused':( > Fedora 5.0.3-200.fc29.x86_64, > Python 2.7.15, > Proton master @ eab1f. > System 'taj':( > Fedora 4.18.16-200.fc28.x86_64, > Python 3.6.6, > Proton master @ 68b38 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1309-backtraces.txt, > DISPATCH-1309-gen_configs_linear.py > > > qpid-dispatch master @ 51244, which is very close to the 1.6 release, has > various crashes. > The test network is 12 routers spread over two systems. (Configuration > generator to be attached.) Four interior routers are in linear arrangement > with A and C on one system ('unused'), and B and D on the other system > ('taj'). Each system then attaches four edge routers, one to each interior > router. > Running lightweight tests, like proton cpp simple_send and simple_recv to > ports on INTA and INTB interior routers leads to a crash on INTC. The crashes > typically look like reuse of structures after they have been freed (addresses > are 0x). Other crashes hint of general memory corruption > (crashes in malloc.c). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1312) Remove cmake option USE_MEMORY_POOL
Chuck Rolke created DISPATCH-1312: - Summary: Remove cmake option USE_MEMORY_POOL Key: DISPATCH-1312 URL: https://issues.apache.org/jira/browse/DISPATCH-1312 Project: Qpid Dispatch Issue Type: Bug Components: Tools Affects Versions: 1.6.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Memory pool must be ON and is no longer optional. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1309) Various crashes in 1.6 release
[ https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809845#comment-16809845 ] Chuck Rolke commented on DISPATCH-1309: --- A console disconnect can crash a stand-alone interior router with no client traffic. Start a router with: {{router {}} {{ debugDumpFile: qddebug-INTB.txt}} {{ mode: interior}} {{ id: INTB}} {{}}} {{listener {}} {{ http: true}} {{ port: 5672}} {{}}} {{log {}} {{ outputFile: INTB.log}} {{ enable: trace+}} {{ module: DEFAULT}} {{}}} Connect your browser to 127.0.0.1:5672 In the Connect tab repeatedly disconnect and connect. After some small number of tries my router crashes with one of a wide variety of core dumps. Note this this is an issue with release 1.5.0 as well. > Various crashes in 1.6 release > -- > > Key: DISPATCH-1309 > URL: https://issues.apache.org/jira/browse/DISPATCH-1309 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.6.0 > Environment: System 'unused':( > Fedora 5.0.3-200.fc29.x86_64, > Python 2.7.15, > Proton master @ eab1f. > System 'taj':( > Fedora 4.18.16-200.fc28.x86_64, > Python 3.6.6, > Proton master @ 68b38 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1309-backtraces.txt, > DISPATCH-1309-gen_configs_linear.py > > > qpid-dispatch master @ 51244, which is very close to the 1.6 release, has > various crashes. > The test network is 12 routers spread over two systems. (Configuration > generator to be attached.) Four interior routers are in linear arrangement > with A and C on one system ('unused'), and B and D on the other system > ('taj'). Each system then attaches four edge routers, one to each interior > router. > Running lightweight tests, like proton cpp simple_send and simple_recv to > ports on INTA and INTB interior routers leads to a crash on INTC. The crashes > typically look like reuse of structures after they have been freed (addresses > are 0x). Other crashes hint of general memory corruption > (crashes in malloc.c). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1309) Various crashes in 1.6 release
[ https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16808111#comment-16808111 ] Chuck Rolke commented on DISPATCH-1309: --- I tried git bisecting from 1.5.0 to 1.6.0 release tags and got no errors. Then eventually I got the following backtrace trying to log "Computed valid origins {}" from python run-time code. The crashes I saw earlier happened when a console was attached to an http-enabled listener. During my bisect exercise I had no consoles attached. I'll go back and try some with consoles attached where I can. {{(gdb) bt}} {{#0 malloc_consolidate (av=av@entry=0x7f970820) at malloc.c:4469}} {{#1 0x7f972b97d098 in _int_malloc (av=av@entry=0x7f970820, bytes=bytes@entry=2288) at malloc.c:3695}} {{#2 0x7f972b97dd7b in _int_memalign (av=av@entry=0x7f970820, alignment=alignment@entry=64, bytes=bytes@entry=2176) at malloc.c:4726}} {{#3 0x7f972b97ef7a in _mid_memalign (alignment=64, bytes=2176, address=) at malloc.c:3306}} {{#4 0x7f972b98052c in __posix_memalign (size=, alignment=, memptr=0x7f9717ffd830) at malloc.c:5401}} {{#5 __posix_memalign (memptr=0x7f9717ffd830, alignment=, size=) at malloc.c:5388}} {{#6 0x7f972be8b3c4 in qd_alloc (desc=0x7f972beb5dc0 <__desc_qd_log_entry_t>, tpool=0x7f9717fff578) at /home/chug/git/qpid-dispatch/src/alloc_pool.c:181}} {{#7 0x7f972be336ab in new_qd_log_entry_t () at /home/chug/git/qpid-dispatch/src/log.c:61}} {{#8 0x7f972be3491d in qd_vlog_impl (source=0x8c0bb0, level=QD_LOG_INFO, }} {{ file=0x7f971df1d3d4 "/opt/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py", line=162, fmt=0x7f972be928df "%s", ap=0x7f9717ffd8e8)}} {{ at /home/chug/git/qpid-dispatch/src/log.c:416}} {{#9 0x7f972be34ba1 in qd_log_impl (source=0x8c0bb0, level=QD_LOG_INFO, }} {{ file=0x7f971df1d3d4 "/opt/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py", line=162, fmt=0x7f972be928df "%s")}} {{ at /home/chug/git/qpid-dispatch/src/log.c:435}} {{#10 0x7f972be460a8 in qd_python_log (self=, }} {{ args=(4L, u'Computed valid origins: {}', '/opt/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py', 162))}} {{ at /home/chug/git/qpid-dispatch/src/python_embedded.c:429}} {{#11 0x7f972bc6314b in call_function (oparg=, pp_stack=0x7f9717ffdab0) at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:4449}} {{#12 PyEval_EvalFrameEx (}} {{ f=f@entry=Frame 0x7f971d714bf0, for file /opt/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/engine.py, line 229, in log_ls (self=, nodes_by_link_id=\{0: , parent=<...>, neighbor_refresh_time=, keep_alive_count=0, adapter=, valid_origins=[], peer_link_id=None, link_state=) at remote 0x7f971c4952d0>, instance=1554232196L, version=1L, next_hop_router=None, mobile_address_sequence=8, need_mobile_request=False, id=u'INTC', maskbit=1, need_ls_request=False) at remote 0x7f971d7c2790>}, maskbits=[True, True, True, True, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None, None,...(truncated), throwflag=throwflag@entry=0)}} {{ at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:3083}} {{#13 0x7f972bc63902 in PyEval_EvalCodeEx (co=, globals=, locals=locals@entry=0x0, args=, }} {{ argcount=, kws=, kwcount=0, defs=0x0, defcount=0, closure=0x0)}} {{ at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:3681}} {{#14 0x7f972bc6053c in fast_function (nk=, na=, n=, pp_stack=0x7f9717ffdc70, }} {{ func=) at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:4544}} {{#15 call_function (oparg=, pp_stack=0x7f9717ffdc70) at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:4469}} {{#16 PyEval_EvalFrameEx (}} {{ f=f@entry=Frame 0x7f970404cc40, for file /opt/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py, line 162, in tick (self=, domain=u'domain', _log_hello=, area=u'0', mobile_address_engine=, 2: }, container=<...>, deleted_addrs=[], treatments=\{u'HED1': 3L, u'HED2': 3L}, added_addrs=[], node_tracker=<...>, local_addrs=[u'HED2', u'HED1'], mobile_seq=2, id=u'INTD') at remote 0x7f971d70cd10>, _config=, globals=, locals=locals@entry=0x0, args=, }} {{ argcount=, kws=, kwcount=0, defs=0x0, defcount=0, closure=0x0)}} {{ at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:3681}} {{#18 0x7f972bc6053c in fast_function (nk=, na=, n=, pp_stack=0x7f9717ffde30, }} {{--Type for more, q to quit, c to continue without paging--}} {{ func=) at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:4544}} {{#19 call_function (oparg=, pp_stack=0x7f9717ffde30) at /usr/src/debug/python2-2.7.15-11.fc29.x86_64/Python/ceval.c:4469}} {{#20 PyEval_EvalFrameEx (}} {{ f=f@entry=Frame 0x7f971d75e988, for file /opt/local/li
[jira] [Updated] (DISPATCH-1309) Various crashes in 1.6 release
[ https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1309: -- Environment: System 'unused':( Fedora 5.0.3-200.fc29.x86_64, Python 2.7.15, Proton master @ eab1f. System 'taj':( Fedora 4.18.16-200.fc28.x86_64, Python 3.6.6, Proton master @ 68b38 > Various crashes in 1.6 release > -- > > Key: DISPATCH-1309 > URL: https://issues.apache.org/jira/browse/DISPATCH-1309 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.6.0 > Environment: System 'unused':( > Fedora 5.0.3-200.fc29.x86_64, > Python 2.7.15, > Proton master @ eab1f. > System 'taj':( > Fedora 4.18.16-200.fc28.x86_64, > Python 3.6.6, > Proton master @ 68b38 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1309-backtraces.txt, > DISPATCH-1309-gen_configs_linear.py > > > qpid-dispatch master @ 51244, which is very close to the 1.6 release, has > various crashes. > The test network is 12 routers spread over two systems. (Configuration > generator to be attached.) Four interior routers are in linear arrangement > with A and C on one system ('unused'), and B and D on the other system > ('taj'). Each system then attaches four edge routers, one to each interior > router. > Running lightweight tests, like proton cpp simple_send and simple_recv to > ports on INTA and INTB interior routers leads to a crash on INTC. The crashes > typically look like reuse of structures after they have been freed (addresses > are 0x). Other crashes hint of general memory corruption > (crashes in malloc.c). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1309) Various crashes in 1.6 release
[ https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1309: -- Attachment: DISPATCH-1309-gen_configs_linear.py > Various crashes in 1.6 release > -- > > Key: DISPATCH-1309 > URL: https://issues.apache.org/jira/browse/DISPATCH-1309 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1309-backtraces.txt, > DISPATCH-1309-gen_configs_linear.py > > > qpid-dispatch master @ 51244, which is very close to the 1.6 release, has > various crashes. > The test network is 12 routers spread over two systems. (Configuration > generator to be attached.) Four interior routers are in linear arrangement > with A and C on one system ('unused'), and B and D on the other system > ('taj'). Each system then attaches four edge routers, one to each interior > router. > Running lightweight tests, like proton cpp simple_send and simple_recv to > ports on INTA and INTB interior routers leads to a crash on INTC. The crashes > typically look like reuse of structures after they have been freed (addresses > are 0x). Other crashes hint of general memory corruption > (crashes in malloc.c). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1309) Various crashes in 1.6 release
[ https://issues.apache.org/jira/browse/DISPATCH-1309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated DISPATCH-1309: -- Attachment: DISPATCH-1309-backtraces.txt > Various crashes in 1.6 release > -- > > Key: DISPATCH-1309 > URL: https://issues.apache.org/jira/browse/DISPATCH-1309 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Priority: Major > Attachments: DISPATCH-1309-backtraces.txt > > > qpid-dispatch master @ 51244, which is very close to the 1.6 release, has > various crashes. > The test network is 12 routers spread over two systems. (Configuration > generator to be attached.) Four interior routers are in linear arrangement > with A and C on one system ('unused'), and B and D on the other system > ('taj'). Each system then attaches four edge routers, one to each interior > router. > Running lightweight tests, like proton cpp simple_send and simple_recv to > ports on INTA and INTB interior routers leads to a crash on INTC. The crashes > typically look like reuse of structures after they have been freed (addresses > are 0x). Other crashes hint of general memory corruption > (crashes in malloc.c). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1309) Various crashes in 1.6 release
Chuck Rolke created DISPATCH-1309: - Summary: Various crashes in 1.6 release Key: DISPATCH-1309 URL: https://issues.apache.org/jira/browse/DISPATCH-1309 Project: Qpid Dispatch Issue Type: Bug Affects Versions: 1.6.0 Reporter: Chuck Rolke qpid-dispatch master @ 51244, which is very close to the 1.6 release, has various crashes. The test network is 12 routers spread over two systems. (Configuration generator to be attached.) Four interior routers are in linear arrangement with A and C on one system ('unused'), and B and D on the other system ('taj'). Each system then attaches four edge routers, one to each interior router. Running lightweight tests, like proton cpp simple_send and simple_recv to ports on INTA and INTB interior routers leads to a crash on INTC. The crashes typically look like reuse of structures after they have been freed (addresses are 0x). Other crashes hint of general memory corruption (crashes in malloc.c). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1307) [tools] Scraper process is not tested by self test
[ https://issues.apache.org/jira/browse/DISPATCH-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1307. --- Resolution: Fixed Fix Version/s: 1.7.0 Fixed at Commit 512449 > [tools] Scraper process is not tested by self test > -- > > Key: DISPATCH-1307 > URL: https://issues.apache.org/jira/browse/DISPATCH-1307 > Project: Qpid Dispatch > Issue Type: Test > Components: Tests, Tools >Affects Versions: 1.5.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.7.0 > > > Scraper could be run in both normal and split modes to verify that the > scraper process finishes normally. This would possibly help alert users to > changes in log file format or in code syntax errors that the developer didn't > catch. > Testing that scraper finds and displays what it is supposed to find and > display is a harder problem and the subject of another Jira issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-2022) Python3 reactor listener client fails with 'Bad file descriptor' exception
[ https://issues.apache.org/jira/browse/PROTON-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved PROTON-2022. - Resolution: Not A Bug @astitcher Good observation. The calling program was modified to call Listener.close on the event call back thread and the reported bad behavior disappears. > Python3 reactor listener client fails with 'Bad file descriptor' exception > -- > > Key: PROTON-2022 > URL: https://issues.apache.org/jira/browse/PROTON-2022 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.0 > Environment: Fedora 29 or 28. Python 3. > qpid-dispatch master @f359aea 1.6.0-rc2 >Reporter: Chuck Rolke >Priority: Major > Attachments: authz.txt > > > Qpid-dispatch self tests run a helper program > qpid-dispatch/tests/authservice.py.in > With Python 2 this test program works normally. > With Python 3 the test fails with an 'OSError Errno 9, Bad file descriptor' > exception. > Control is passed from the application to a MessagingHandler with > Container(handler).run() > The stack trace is posted as an attached file. > To reproduce: from the build directory > ctest -VV -R authz > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1307) [tools] Scraper process is not tested by self test
Chuck Rolke created DISPATCH-1307: - Summary: [tools] Scraper process is not tested by self test Key: DISPATCH-1307 URL: https://issues.apache.org/jira/browse/DISPATCH-1307 Project: Qpid Dispatch Issue Type: Test Components: Tests, Tools Affects Versions: 1.5.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Scraper could be run in both normal and split modes to verify that the scraper process finishes normally. This would possibly help alert users to changes in log file format or in code syntax errors that the developer didn't catch. Testing that scraper finds and displays what it is supposed to find and display is a harder problem and the subject of another Jira issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2020) _io.py error path syntax error in python3
[ https://issues.apache.org/jira/browse/PROTON-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802229#comment-16802229 ] Chuck Rolke commented on PROTON-2020: - [~astitcher] A qpid-dispatch self test has been running fine (for me) with Python 2 for about a year. [https://github.com/apache/qpid-dispatch/blob/master/tests/authservice.py.in] Whatever signal is being emitted by select it is "not iterable" and referring to it with 'e[0]' generates a new exception that hides the original exception. With that repaired by this issue the fundamental issue is exposed at PROTON-2022 > _io.py error path syntax error in python3 > - > > Key: PROTON-2020 > URL: https://issues.apache.org/jira/browse/PROTON-2020 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.27.0 > Environment: python 3 > Fedora 29 > Proton master > qpid-dispatch master @88e25 > self test system_tests_authz_service_plugin >Reporter: Chuck Rolke >Priority: Major > Fix For: proton-c-0.28.0 > > > * > 39: File "/opt/local/lib64/proton/bindings/python/proton/_io.py", line 138, > in select > * > 39: if e[0] != errno.EINTR: > * > 39: TypeError: 'OSError' object is not subscriptable > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1306) [tools] Scraper does not account for changes to log format
[ https://issues.apache.org/jira/browse/DISPATCH-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1306. --- Resolution: Fixed Fixed at Commit 004fa473 > [tools] Scraper does not account for changes to log format > -- > > Key: DISPATCH-1306 > URL: https://issues.apache.org/jira/browse/DISPATCH-1306 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tools >Affects Versions: 0.6.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > > DISPATCH-1289 changed the connection number in the log from, say, [5] to > [C5]. Scraper expects an integer and gets tripped up. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1306) [tools] Scraper does not account for changes to log format
Chuck Rolke created DISPATCH-1306: - Summary: [tools] Scraper does not account for changes to log format Key: DISPATCH-1306 URL: https://issues.apache.org/jira/browse/DISPATCH-1306 Project: Qpid Dispatch Issue Type: Bug Components: Tools Affects Versions: 0.6.0 Reporter: Chuck Rolke Assignee: Chuck Rolke DISPATCH-1289 changed the connection number in the log from, say, [5] to [C5]. Scraper expects an integer and gets tripped up. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (DISPATCH-1265) Delivery_abort test causes inter-router session error
[ https://issues.apache.org/jira/browse/DISPATCH-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke reopened DISPATCH-1265: --- Dispatch can't fix this as the underlying problem is in Proton. This issue is reopened so we can track the progress again when proton gets fixed. > Delivery_abort test causes inter-router session error > - > > Key: DISPATCH-1265 > URL: https://issues.apache.org/jira/browse/DISPATCH-1265 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.5.0 > Environment: Fedora 29, Python 3. > branch DISPATCH-1264#a5aab9 > ctest -VV -R system_tests_delivery_abort >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Critical > Fix For: 1.6.0 > > Attachments: DISPATCH-1265_ctest-log.txt, > DISPATCH-1265_scraped-logs-timeout.html > > > Inter-router connection closes with: > error :"amqp:session:invalid-field" "sequencing error, expected delivery-id > 24, got 23" -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org