[jira] [Updated] (DISPATCH-341) router did not respond to request to drain a message-routed consumers link credit
[
https://issues.apache.org/jira/browse/DISPATCH-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-341:
--
Fix Version/s: (was: 0.7.0)
0.6.1
> router did not respond to request to drain a message-routed consumers link
> credit
> -
>
> Key: DISPATCH-341
> URL: https://issues.apache.org/jira/browse/DISPATCH-341
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.6.0
> Environment: Qpid Dispatch 0.6.0 RC3
> Qpid JMS 0.10.0-SNAPSHOT
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
> Fix For: 0.6.1
>
>
> With a router using the provided default config (updated only to set
> saslMechanisms to ANONYMOUS), and attaching a sender and receiver (using the
> JMS client Sender and Receiver examples) to the address "queue" (so
> presumably using messge routing), it could be seen that Dispatch didn't
> respond to requests to drain the receivers link.
> In one case, after receiving some messages, a 'drain requst' flow is issued,
> but neither enough messages to use the credit (expected since no more were
> sent) or a 'drain reponse' flow are received, just heartbeating back and
> forth.
> {noformat}
> [1925974223:1] -> Disposition{role=RECEIVER, first=8, last=8, settled=true,
> state=Accepted{}, batchable=false}
> [1925974223:1] -> Flow{nextIncomingId=9, incomingWindow=2047,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=9,
> linkCredit=991, available=null, drain=true, echo=false, properties=null}
> [1925974223:0] -> Empty Frame
> [1925974223:0] -> Empty Frame
> [1925974223:0] <- Empty Frame
> {noformat}
> In another case, after flowing some credit but not receiving any messages, a
> 'drain request' is issued, but neither enough messages to use the credit
> (expected since none were sent) or a 'drain reponse' flow are received, just
> heartbeating back and forth.
> {noformat}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
> linkCredit=1000, available=null, drain=false, echo=false, properties=null}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
> linkCredit=1000, available=null, drain=true, echo=false, properties=null}
> [2111953084:0] -> Empty Frame
> [2111953084:0] -> Empty Frame
> [2111953084:0] <- Empty Frame
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-365) Standalone router crashes if an interior router attempts to connect to it
[ https://issues.apache.org/jira/browse/DISPATCH-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-365: -- Fix Version/s: (was: 0.6.0) 0.6.1 > Standalone router crashes if an interior router attempts to connect to it > - > > Key: DISPATCH-365 > URL: https://issues.apache.org/jira/browse/DISPATCH-365 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Assignee: Ted Ross >Priority: Critical > Fix For: 0.6.1 > > Attachments: config1_standalone.conf, config2_nossl.conf > > > I accidentally pointed my interior router to a standalone router. The > standalone router did not ignore the connection request and crashed. The > attached config files reproduce the crash. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-364) Inter-router listeners should not permit normal endpoint traffic
[ https://issues.apache.org/jira/browse/DISPATCH-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-364: -- Fix Version/s: 0.6.1 > Inter-router listeners should not permit normal endpoint traffic > > > Key: DISPATCH-364 > URL: https://issues.apache.org/jira/browse/DISPATCH-364 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.6.1 > > > A router network can be configured such that normal clients connect to the > network using listeners designated with the inter-router role. Since there > can be only a limited number of routers in a network (128 in 0.6.0), it > doesn't take many connected clients to clog up the inter-router connection > space. > The router node should be modified such that normal links attaching over > inter-router connections are forbidden. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-385) Router crashes when on-demand host is no longer reachable
[ https://issues.apache.org/jira/browse/DISPATCH-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328190#comment-15328190 ] Ganesh Murthy commented on DISPATCH-385: Same case with the VPN. Did not observe any crashes in the router > Router crashes when on-demand host is no longer reachable > - > > Key: DISPATCH-385 > URL: https://issues.apache.org/jira/browse/DISPATCH-385 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy > Attachments: A.conf, B.conf, C.conf, D.conf, X.conf, Y.conf > > > Router will crash if the host for an on-demand connector is unreachable. > To reproduce: > start the 6 router configs in qpid-dispatch/tests/config-6 > start a broker on a different box (I used a qpidd on port 11000 on mrg30) > create an on-demand connector to the broker on one of the routers (I use Y) > verify a connection to the broker has been automatically created and is open > kill/block the communications to the broker (I stop my vpn, but there may be > better ways) > after a few minutes, the router that the broker was connected to will crash > here is the bt: > #0 0x76b9ea28 in raise () from /lib64/libc.so.6 > #1 0x76ba062a in abort () from /lib64/libc.so.6 > #2 0x76b97227 in __assert_fail_base () from /lib64/libc.so.6 > #3 0x76b972d2 in __assert_fail () from /lib64/libc.so.6 > #4 0x77b9face in sys_mutex_lock (mutex=0x7fffd4003e00) > at /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71 > #5 0x77bac174 in qdr_forward_deliver_CT (core=0x9264d0, > link=0x7fffe403a4c0, dlv=0x7fffe4072ec0) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:132 > #6 0x77bacfeb in qdr_forward_closest_CT (core=0x9264d0, > addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, > exclude_inprocess=true, control=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:405 > #7 0x77badd3a in qdr_forward_message_CT (core=0x9264d0, > addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, > exclude_inprocess=true, control=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:707 > #8 0x77bb73f6 in qdr_send_to_CT (core=0x9264d0, action=0x9749d0, > discard=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:581 > #9 0x77bb18ea in router_core_thread (arg=0x9264d0) > at > /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:71 > #10 0x7770d60a in start_thread () from /lib64/libpthread.so.0 > #11 0x76c6c59d in clone () from /lib64/libc.so.6 > I'm using master qpid-proton 0.14.0-SNAPSHOT > master qpid-dispatch 0.7.0 > Here is the routers debug output after the vpn was killed and just before the > crash > Mon Jun 13 11:34:14 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:23 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:34 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:44 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link removed > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link removed > Mon Jun 13 11:35:10 2016 ROUTER (trace) Entered Router Flux Mode > Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link set: link_id=0 > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link set: link_id=1 > qdrouterd: /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71: > sys_mutex_lock: Assertion `result == 0' failed. > Program received signal SIGABRT, Aborted. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-380) Router stops receiving messages from multiple senders publishing to multiple queues in parallel
[ https://issues.apache.org/jira/browse/DISPATCH-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-380: -- Fix Version/s: (was: 0.6.0) > Router stops receiving messages from multiple senders publishing to multiple > queues in parallel > --- > > Key: DISPATCH-380 > URL: https://issues.apache.org/jira/browse/DISPATCH-380 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine > Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate > machines >Reporter: Vishal Sharda >Priority: Critical > Attachments: AWS_hung_at_round_figures.png, > AWS_hung_for_4_seconds.png, AWS_uneven_start.png, Senders_1.png, > Senders_2.png, Senders_3_10_Queues.png, Senders_4_10_queues.png, > Single_router_testing_results.pdf, qdstat_wrong_output.png > > > I am running a Java Client against a cluster of 3 interior routers connected > to each other. 2-way SSL is enabled for all the connections. > There were 20 simultaneous queues with 20 senders on each queue and each > sender publishing 1000 messages. All the senders were connected to Router 1. > 20 receivers were connected to Router 2 with 1 receiver receiving from each > queue. > In the first run, router stopped receiving incoming messages after delivering > 386,339 out of 400K "Hello World!" messages. > In the second run, 388,781 messages out of 400K were delivered. > I reduced the number of queues to 10 (halving total number of messages to > 200K) and the issue occurred again. > I ran the Java client on an 8 CPU machine again with 10 queues and the issue > occurred again after delivering just 54K out of 200K messages. > All the senders were hung (still connected) with no messages flowing at all. > Connection information from qdstat: > When the messages are flowing properly and I run "qdstat -c", I see all the > senders as secure and authenticated. > After they hang and I run "qdstat -c", it erroneously shows all the clients > as insecure and unauthenticated. > Shortly after the clients hang, all the queues are deleted from the router > network but connections are still shown until I terminate the clients. > I saw this erroneous situation before also when "qdstat -c" showed some > senders as secure and authentic but some as insecure/unauthentic. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-256) Documentation Updates for 0.6
[ https://issues.apache.org/jira/browse/DISPATCH-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-256. --- Resolution: Fixed > Documentation Updates for 0.6 > - > > Key: DISPATCH-256 > URL: https://issues.apache.org/jira/browse/DISPATCH-256 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Reporter: Ted Ross > Fix For: 0.6.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-367) balanced distribution needs to be more... balanced.
[ https://issues.apache.org/jira/browse/DISPATCH-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-367: -- Fix Version/s: (was: 0.6.0) > balanced distribution needs to be more... balanced. > --- > > Key: DISPATCH-367 > URL: https://issues.apache.org/jira/browse/DISPATCH-367 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ken Giusti >Assignee: Ganesh Murthy > > When blocking sends are done to a balanced address with multiple consumers on > the same router all the messages go to one of the consumers. > I would expect that the messages would be evenly distributed across all > _locally_attached_ consumers. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-385) Router crashes when on-demand host is no longer reachable
[ https://issues.apache.org/jira/browse/DISPATCH-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328080#comment-15328080 ] Ganesh Murthy commented on DISPATCH-385: I will try this over VPN when on the Redhat guest wireless network. > Router crashes when on-demand host is no longer reachable > - > > Key: DISPATCH-385 > URL: https://issues.apache.org/jira/browse/DISPATCH-385 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy > Attachments: A.conf, B.conf, C.conf, D.conf, X.conf, Y.conf > > > Router will crash if the host for an on-demand connector is unreachable. > To reproduce: > start the 6 router configs in qpid-dispatch/tests/config-6 > start a broker on a different box (I used a qpidd on port 11000 on mrg30) > create an on-demand connector to the broker on one of the routers (I use Y) > verify a connection to the broker has been automatically created and is open > kill/block the communications to the broker (I stop my vpn, but there may be > better ways) > after a few minutes, the router that the broker was connected to will crash > here is the bt: > #0 0x76b9ea28 in raise () from /lib64/libc.so.6 > #1 0x76ba062a in abort () from /lib64/libc.so.6 > #2 0x76b97227 in __assert_fail_base () from /lib64/libc.so.6 > #3 0x76b972d2 in __assert_fail () from /lib64/libc.so.6 > #4 0x77b9face in sys_mutex_lock (mutex=0x7fffd4003e00) > at /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71 > #5 0x77bac174 in qdr_forward_deliver_CT (core=0x9264d0, > link=0x7fffe403a4c0, dlv=0x7fffe4072ec0) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:132 > #6 0x77bacfeb in qdr_forward_closest_CT (core=0x9264d0, > addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, > exclude_inprocess=true, control=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:405 > #7 0x77badd3a in qdr_forward_message_CT (core=0x9264d0, > addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, > exclude_inprocess=true, control=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:707 > #8 0x77bb73f6 in qdr_send_to_CT (core=0x9264d0, action=0x9749d0, > discard=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:581 > #9 0x77bb18ea in router_core_thread (arg=0x9264d0) > at > /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:71 > #10 0x7770d60a in start_thread () from /lib64/libpthread.so.0 > #11 0x76c6c59d in clone () from /lib64/libc.so.6 > I'm using master qpid-proton 0.14.0-SNAPSHOT > master qpid-dispatch 0.7.0 > Here is the routers debug output after the vpn was killed and just before the > crash > Mon Jun 13 11:34:14 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:23 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:34 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:44 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link removed > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link removed > Mon Jun 13 11:35:10 2016 ROUTER (trace) Entered Router Flux Mode > Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link set: link_id=0 > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link set: link_id=1 > qdrouterd: /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71: > sys_mutex_lock: Assertion `result == 0' failed. > Program received signal SIGABRT, Aborted. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-385) Router crashes when on-demand host is no longer reachable
[ https://issues.apache.org/jira/browse/DISPATCH-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328078#comment-15328078 ] Ganesh Murthy commented on DISPATCH-385: Ernie, were you sending any messages to the broker via the router when your VPN crashed? > Router crashes when on-demand host is no longer reachable > - > > Key: DISPATCH-385 > URL: https://issues.apache.org/jira/browse/DISPATCH-385 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy > Attachments: A.conf, B.conf, C.conf, D.conf, X.conf, Y.conf > > > Router will crash if the host for an on-demand connector is unreachable. > To reproduce: > start the 6 router configs in qpid-dispatch/tests/config-6 > start a broker on a different box (I used a qpidd on port 11000 on mrg30) > create an on-demand connector to the broker on one of the routers (I use Y) > verify a connection to the broker has been automatically created and is open > kill/block the communications to the broker (I stop my vpn, but there may be > better ways) > after a few minutes, the router that the broker was connected to will crash > here is the bt: > #0 0x76b9ea28 in raise () from /lib64/libc.so.6 > #1 0x76ba062a in abort () from /lib64/libc.so.6 > #2 0x76b97227 in __assert_fail_base () from /lib64/libc.so.6 > #3 0x76b972d2 in __assert_fail () from /lib64/libc.so.6 > #4 0x77b9face in sys_mutex_lock (mutex=0x7fffd4003e00) > at /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71 > #5 0x77bac174 in qdr_forward_deliver_CT (core=0x9264d0, > link=0x7fffe403a4c0, dlv=0x7fffe4072ec0) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:132 > #6 0x77bacfeb in qdr_forward_closest_CT (core=0x9264d0, > addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, > exclude_inprocess=true, control=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:405 > #7 0x77badd3a in qdr_forward_message_CT (core=0x9264d0, > addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, > exclude_inprocess=true, control=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:707 > #8 0x77bb73f6 in qdr_send_to_CT (core=0x9264d0, action=0x9749d0, > discard=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:581 > #9 0x77bb18ea in router_core_thread (arg=0x9264d0) > at > /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:71 > #10 0x7770d60a in start_thread () from /lib64/libpthread.so.0 > #11 0x76c6c59d in clone () from /lib64/libc.so.6 > I'm using master qpid-proton 0.14.0-SNAPSHOT > master qpid-dispatch 0.7.0 > Here is the routers debug output after the vpn was killed and just before the > crash > Mon Jun 13 11:34:14 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:23 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:34 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:44 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link removed > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link removed > Mon Jun 13 11:35:10 2016 ROUTER (trace) Entered Router Flux Mode > Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link set: link_id=0 > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link set: link_id=1 > qdrouterd: /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71: > sys_mutex_lock: Assertion `result == 0' failed. > Program received signal SIGABRT, Aborted. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-385) Router crashes when on-demand host is no longer reachable
[
https://issues.apache.org/jira/browse/DISPATCH-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328076#comment-15328076
]
Ganesh Murthy commented on DISPATCH-385:
I am on master proton and dispatch. I added this to my router config file -
{noformat}
connector {
name: broker
host: mrg30.lab.bos.redhat.com
role: on-demand
port: 11000
saslMechanisms: ANONYMOUS
}
{noformat}
and then started the router. The Router started successfully -
Mon Jun 13 15:39:09 2016 CONN_MGR (info) Configured Connector: 0.0.0.0:20004
proto=any role=inter-router
Mon Jun 13 15:39:09 2016 CONN_MGR (info) Configured Connector:
mrg30.lab.bos.redhat.com:11000 proto=any role=on-demand
Mon Jun 13 15:39:09 2016 POLICY (info) Policy configured maximumConnections: 0,
policyFolder: '', access rules enabled: 'false'
Mon Jun 13 15:39:09 2016 POLICY (info) Policy fallback defaultApplication is
disabled
Mon Jun 13 15:39:09 2016 SERVER (info) Operational, 4 Threads Running
Mon Jun 13 15:39:09 2016 SERVER (info) Running in DEBUG Mode
Now, I unplugged my Ethernet connector and turned off wireless
I see this every 10 seconds -
{noformat}
Mon Jun 13 15:39:42 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com,
11000): No address associated with hostname
Mon Jun 13 15:39:51 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com,
11000): No address associated with hostname
Mon Jun 13 15:40:01 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com,
11000): No address associated with hostname
..
..
..
Mon Jun 13 15:54:01 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com,
11000): No address associated with hostname
Mon Jun 13 15:54:11 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com,
11000): No address associated with hostname
Mon Jun 13 15:54:21 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com,
11000): No address associated with hostname
{noformat}
I do not see any crash
When I replugged my Ethernet connection, the above error stopped
> Router crashes when on-demand host is no longer reachable
> -
>
> Key: DISPATCH-385
> URL: https://issues.apache.org/jira/browse/DISPATCH-385
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 0.7.0
>Reporter: Ernest Allen
>Assignee: Ganesh Murthy
> Attachments: A.conf, B.conf, C.conf, D.conf, X.conf, Y.conf
>
>
> Router will crash if the host for an on-demand connector is unreachable.
> To reproduce:
> start the 6 router configs in qpid-dispatch/tests/config-6
> start a broker on a different box (I used a qpidd on port 11000 on mrg30)
> create an on-demand connector to the broker on one of the routers (I use Y)
> verify a connection to the broker has been automatically created and is open
> kill/block the communications to the broker (I stop my vpn, but there may be
> better ways)
> after a few minutes, the router that the broker was connected to will crash
> here is the bt:
> #0 0x76b9ea28 in raise () from /lib64/libc.so.6
> #1 0x76ba062a in abort () from /lib64/libc.so.6
> #2 0x76b97227 in __assert_fail_base () from /lib64/libc.so.6
> #3 0x76b972d2 in __assert_fail () from /lib64/libc.so.6
> #4 0x77b9face in sys_mutex_lock (mutex=0x7fffd4003e00)
> at /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71
> #5 0x77bac174 in qdr_forward_deliver_CT (core=0x9264d0,
> link=0x7fffe403a4c0, dlv=0x7fffe4072ec0)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:132
> #6 0x77bacfeb in qdr_forward_closest_CT (core=0x9264d0,
> addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0,
> exclude_inprocess=true, control=false)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:405
> #7 0x77badd3a in qdr_forward_message_CT (core=0x9264d0,
> addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0,
> exclude_inprocess=true, control=false)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:707
> #8 0x77bb73f6 in qdr_send_to_CT (core=0x9264d0, action=0x9749d0,
> discard=false)
> at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:581
> #9 0x77bb18ea in router_core_thread (arg=0x9264d0)
> at
> /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:71
> #10 0x7770d60a in start_thread () from /lib64/libpthread.so.0
> #11 0x76c6c59d in clone () from /lib64/libc.so.6
> I'm using master qpid-proton 0.14.0-SNAPSHOT
> master qpid-dispatch 0.7.0
> Here is the routers debug output after the vpn was killed and just before the
> crash
> Mon Jun 13 11:34:14 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com,
> 11000): No address associated with
[jira] [Comment Edited] (PROTON-1224) Proton-J SSL uses deprecated Bouncy Castle functionality
[ https://issues.apache.org/jira/browse/PROTON-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328068#comment-15328068 ] Jem Day edited comment on PROTON-1224 at 6/13/16 7:56 PM: -- Robbie, I closed out the original PR and created a new one, the CI jobs appear now to be failing during the Python tests. I am able to run the cmake build locally. Jem.. was (Author: jday): Robbie, I close out the original PR and created a new one, the CI jobs appear now to be failing during the Python tests. I am able to run the cmake build locally. Jem.. > Proton-J SSL uses deprecated Bouncy Castle functionality > > > Key: PROTON-1224 > URL: https://issues.apache.org/jira/browse/PROTON-1224 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.12.2 >Reporter: Jem Day > > The BouncyCastle project deprecated functionality used by the proton-j driver > in version 1.48. This causes run-time issues for us as our application > containers are using newer BC versions. > I've submitted a PR for this change and verified that all tests run using > both BC 1.48 and 1.54. > Note: The CI pipeline for the PR is flagging an error but i am able to > build/test locally with no reported errors - build log is attached to the PR > comments. > https://github.com/apache/qpid-proton/pull/74 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1224) Proton-J SSL uses deprecated Bouncy Castle functionality
[ https://issues.apache.org/jira/browse/PROTON-1224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328068#comment-15328068 ] Jem Day commented on PROTON-1224: - Robbie, I close out the original PR and created a new one, the CI jobs appear now to be failing during the Python tests. I am able to run the cmake build locally. Jem.. > Proton-J SSL uses deprecated Bouncy Castle functionality > > > Key: PROTON-1224 > URL: https://issues.apache.org/jira/browse/PROTON-1224 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: 0.12.2 >Reporter: Jem Day > > The BouncyCastle project deprecated functionality used by the proton-j driver > in version 1.48. This causes run-time issues for us as our application > containers are using newer BC versions. > I've submitted a PR for this change and verified that all tests run using > both BC 1.48 and 1.54. > Note: The CI pipeline for the PR is flagging an error but i am able to > build/test locally with no reported errors - build log is attached to the PR > comments. > https://github.com/apache/qpid-proton/pull/74 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-386) Router crashes in qd_link_pn
[ https://issues.apache.org/jira/browse/DISPATCH-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327995#comment-15327995 ] Ganesh Murthy commented on DISPATCH-386: "Each sender has 60 threads. Each receiver has 60 threads." - Not sure what you mean by that. Can you please attach your sender and receiver programs to this ticket with instructions on how to run them? Can you please verify if you can reproduce this problem without SSL in the mix? > Router crashes in qd_link_pn > > > Key: DISPATCH-386 > URL: https://issues.apache.org/jira/browse/DISPATCH-386 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate > machines >Reporter: Eric Leu > > Network: A network of 3 interior routers built using the latest trunk and > connected to each other using 2-way SSL, same as in DISPATCH-383. > Run 3 pairs of senders and receivers on three different destination > addresses. Each sender has 60 threads. Each receiver has 60 threads. > Seg fault happened with either of of the two traces: > (1) > Program received signal SIGSEGV, Segmentation fault. > 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > (gdb) bt > #0 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #1 0x77ad70cc in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #2 0x77acc906 in qdr_connection_process () from > /usr/local/lib/qpid-dispatch/libqpid- > dispatch.so > #3 0x77ab3b28 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #4 0x77adad55 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #5 0x77adb272 in qd_server_run () from > /usr/local/lib/qpid-dispatch/libqpid- > dispatch.so > #6 0x00401a47 in _start () > (2) > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x70d1f700 (LWP 27862)] > 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > (gdb) bt > #0 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #1 0x77ad71b3 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #2 0x77acc988 in qdr_connection_process () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #3 0x77ab3b28 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #4 0x77adad55 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #5 0x775d10a4 in start_thread (arg=0x70d1f700) at > pthread_create.c:309 > #6 0x7697587d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-385) Router crashes when on-demand host is no longer reachable
[ https://issues.apache.org/jira/browse/DISPATCH-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen updated DISPATCH-385: -- Attachment: Y.conf X.conf D.conf C.conf B.conf A.conf These are the same files that are in qpid-dispatch/tests/config-6. I'm attaching the qpid broker to QDR.Y. > Router crashes when on-demand host is no longer reachable > - > > Key: DISPATCH-385 > URL: https://issues.apache.org/jira/browse/DISPATCH-385 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy > Attachments: A.conf, B.conf, C.conf, D.conf, X.conf, Y.conf > > > Router will crash if the host for an on-demand connector is unreachable. > To reproduce: > start the 6 router configs in qpid-dispatch/tests/config-6 > start a broker on a different box (I used a qpidd on port 11000 on mrg30) > create an on-demand connector to the broker on one of the routers (I use Y) > verify a connection to the broker has been automatically created and is open > kill/block the communications to the broker (I stop my vpn, but there may be > better ways) > after a few minutes, the router that the broker was connected to will crash > here is the bt: > #0 0x76b9ea28 in raise () from /lib64/libc.so.6 > #1 0x76ba062a in abort () from /lib64/libc.so.6 > #2 0x76b97227 in __assert_fail_base () from /lib64/libc.so.6 > #3 0x76b972d2 in __assert_fail () from /lib64/libc.so.6 > #4 0x77b9face in sys_mutex_lock (mutex=0x7fffd4003e00) > at /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71 > #5 0x77bac174 in qdr_forward_deliver_CT (core=0x9264d0, > link=0x7fffe403a4c0, dlv=0x7fffe4072ec0) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:132 > #6 0x77bacfeb in qdr_forward_closest_CT (core=0x9264d0, > addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, > exclude_inprocess=true, control=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:405 > #7 0x77badd3a in qdr_forward_message_CT (core=0x9264d0, > addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, > exclude_inprocess=true, control=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:707 > #8 0x77bb73f6 in qdr_send_to_CT (core=0x9264d0, action=0x9749d0, > discard=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:581 > #9 0x77bb18ea in router_core_thread (arg=0x9264d0) > at > /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:71 > #10 0x7770d60a in start_thread () from /lib64/libpthread.so.0 > #11 0x76c6c59d in clone () from /lib64/libc.so.6 > I'm using master qpid-proton 0.14.0-SNAPSHOT > master qpid-dispatch 0.7.0 > Here is the routers debug output after the vpn was killed and just before the > crash > Mon Jun 13 11:34:14 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:23 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:34 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:44 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link removed > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link removed > Mon Jun 13 11:35:10 2016 ROUTER (trace) Entered Router Flux Mode > Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link set: link_id=0 > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link set: link_id=1 > qdrouterd: /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71: > sys_mutex_lock: Assertion `result == 0' failed. > Program received signal SIGABRT, Aborted. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1231) python: proton.utils.BlockingConnection hides disconnect error info
[ https://issues.apache.org/jira/browse/PROTON-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327978#comment-15327978 ] ASF subversion and git services commented on PROTON-1231: - Commit 118a5c3d9da962318d2ebcc5401b368046c8c5b2 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=118a5c3 ] PROTON-1231: Fixed failing proton_tests..test_allowed_mechs_external The test was comparing exact error message text, changed by previous fix to include the transport error. Modified to check for a reliable substring. > python: proton.utils.BlockingConnection hides disconnect error info > --- > > Key: PROTON-1231 > URL: https://issues.apache.org/jira/browse/PROTON-1231 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.2 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.14.0 > > > proton.utils.BlockingConnection does not report the transport.condition error > information on a disconnect. This makes it very difficult to figure out what > is going on e.g. if the client cannot connect because of an authentication > problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-385) Router crashes when on-demand host is no longer reachable
[ https://issues.apache.org/jira/browse/DISPATCH-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327971#comment-15327971 ] Ganesh Murthy commented on DISPATCH-385: Ernie, can you please attach your router config file to this ticket? > Router crashes when on-demand host is no longer reachable > - > > Key: DISPATCH-385 > URL: https://issues.apache.org/jira/browse/DISPATCH-385 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy > > Router will crash if the host for an on-demand connector is unreachable. > To reproduce: > start the 6 router configs in qpid-dispatch/tests/config-6 > start a broker on a different box (I used a qpidd on port 11000 on mrg30) > create an on-demand connector to the broker on one of the routers (I use Y) > verify a connection to the broker has been automatically created and is open > kill/block the communications to the broker (I stop my vpn, but there may be > better ways) > after a few minutes, the router that the broker was connected to will crash > here is the bt: > #0 0x76b9ea28 in raise () from /lib64/libc.so.6 > #1 0x76ba062a in abort () from /lib64/libc.so.6 > #2 0x76b97227 in __assert_fail_base () from /lib64/libc.so.6 > #3 0x76b972d2 in __assert_fail () from /lib64/libc.so.6 > #4 0x77b9face in sys_mutex_lock (mutex=0x7fffd4003e00) > at /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71 > #5 0x77bac174 in qdr_forward_deliver_CT (core=0x9264d0, > link=0x7fffe403a4c0, dlv=0x7fffe4072ec0) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:132 > #6 0x77bacfeb in qdr_forward_closest_CT (core=0x9264d0, > addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, > exclude_inprocess=true, control=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:405 > #7 0x77badd3a in qdr_forward_message_CT (core=0x9264d0, > addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, > exclude_inprocess=true, control=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:707 > #8 0x77bb73f6 in qdr_send_to_CT (core=0x9264d0, action=0x9749d0, > discard=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:581 > #9 0x77bb18ea in router_core_thread (arg=0x9264d0) > at > /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:71 > #10 0x7770d60a in start_thread () from /lib64/libpthread.so.0 > #11 0x76c6c59d in clone () from /lib64/libc.so.6 > I'm using master qpid-proton 0.14.0-SNAPSHOT > master qpid-dispatch 0.7.0 > Here is the routers debug output after the vpn was killed and just before the > crash > Mon Jun 13 11:34:14 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:23 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:34 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:44 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link removed > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link removed > Mon Jun 13 11:35:10 2016 ROUTER (trace) Entered Router Flux Mode > Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link set: link_id=0 > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link set: link_id=1 > qdrouterd: /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71: > sys_mutex_lock: Assertion `result == 0' failed. > Program received signal SIGABRT, Aborted. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-383) Intermittent router crashes when restarting one router in the network with different number of threads
[ https://issues.apache.org/jira/browse/DISPATCH-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327955#comment-15327955 ] Vishal Sharda commented on DISPATCH-383: These are intermittent crashes and I do not yet have a test case that can reliably reproduce them. 1. If I restarted R1 with different number of threads, both R2 and R3 crashed with the same backtrace which is attached here. On a later run, I saw crash only in R2. 2. Yes, this could most likely be timing issue with multithreading on. There is no way for us to control/prevent this from occurring again. The steps involved were simple - interrupting the router, editing the configuration file and starting it again. 3. I have not tested this without SSL but the intermittent crashes that I was seeing due to SASL (DISPATCH-358) no longer appear after upgrading to Proton-0.13.0-RC. Hence, I keep 2-way SSL enabled for all inter-router communication during my tests. > Intermittent router crashes when restarting one router in the network with > different number of threads > -- > > Key: DISPATCH-383 > URL: https://issues.apache.org/jira/browse/DISPATCH-383 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate > machines >Reporter: Vishal Sharda >Assignee: Ganesh Murthy >Priority: Critical > Attachments: Crash_route_tables_1.png, Crash_route_tables_2.png, > Crash_route_tables_3.png > > > Network: A network of 3 interior routers built using the latest trunk and > connected to each other using 2-way SSL. > Stopping one router in the network, changing its number of threads in the > configuration file and starting it again to join the network causes > intermittent crash in other routers in the network. > I was able to reproduce the crash three times and collect the backtraces > inside gdb (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-383) Intermittent router crashes when restarting one router in the network with different number of threads
[ https://issues.apache.org/jira/browse/DISPATCH-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327913#comment-15327913 ] Ganesh Murthy commented on DISPATCH-383: On a Debian 8.3 virtual machine, I followed the steps you mentioned in the issue description (using SSL for inter-router communication) trying to stop random routers and restarting after changing workerThreads to value different that the previous value but I am still unable to get the router to crash. 1. Is it a specific router that keeps crashing? 2. To me this looks like a timing issue, can you please list the exact steps that you are using to reproduce the problem 3. Are you able to reproduce this issue without involving SSL? > Intermittent router crashes when restarting one router in the network with > different number of threads > -- > > Key: DISPATCH-383 > URL: https://issues.apache.org/jira/browse/DISPATCH-383 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate > machines >Reporter: Vishal Sharda >Assignee: Ganesh Murthy >Priority: Critical > Attachments: Crash_route_tables_1.png, Crash_route_tables_2.png, > Crash_route_tables_3.png > > > Network: A network of 3 interior routers built using the latest trunk and > connected to each other using 2-way SSL. > Stopping one router in the network, changing its number of threads in the > configuration file and starting it again to join the network causes > intermittent crash in other routers in the network. > I was able to reproduce the crash three times and collect the backtraces > inside gdb (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-385) Router crashes when on-demand host is no longer reachable
[ https://issues.apache.org/jira/browse/DISPATCH-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-385: -- Assignee: Ganesh Murthy > Router crashes when on-demand host is no longer reachable > - > > Key: DISPATCH-385 > URL: https://issues.apache.org/jira/browse/DISPATCH-385 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy > > Router will crash if the host for an on-demand connector is unreachable. > To reproduce: > start the 6 router configs in qpid-dispatch/tests/config-6 > start a broker on a different box (I used a qpidd on port 11000 on mrg30) > create an on-demand connector to the broker on one of the routers (I use Y) > verify a connection to the broker has been automatically created and is open > kill/block the communications to the broker (I stop my vpn, but there may be > better ways) > after a few minutes, the router that the broker was connected to will crash > here is the bt: > #0 0x76b9ea28 in raise () from /lib64/libc.so.6 > #1 0x76ba062a in abort () from /lib64/libc.so.6 > #2 0x76b97227 in __assert_fail_base () from /lib64/libc.so.6 > #3 0x76b972d2 in __assert_fail () from /lib64/libc.so.6 > #4 0x77b9face in sys_mutex_lock (mutex=0x7fffd4003e00) > at /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71 > #5 0x77bac174 in qdr_forward_deliver_CT (core=0x9264d0, > link=0x7fffe403a4c0, dlv=0x7fffe4072ec0) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:132 > #6 0x77bacfeb in qdr_forward_closest_CT (core=0x9264d0, > addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, > exclude_inprocess=true, control=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:405 > #7 0x77badd3a in qdr_forward_message_CT (core=0x9264d0, > addr=0x7fffe4024fc0, msg=0x7fffe4060e50, in_delivery=0x0, > exclude_inprocess=true, control=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/forwarder.c:707 > #8 0x77bb73f6 in qdr_send_to_CT (core=0x9264d0, action=0x9749d0, > discard=false) > at /home/eallen/workspace/qpid-dispatch/src/router_core/transfer.c:581 > #9 0x77bb18ea in router_core_thread (arg=0x9264d0) > at > /home/eallen/workspace/qpid-dispatch/src/router_core/router_core_thread.c:71 > #10 0x7770d60a in start_thread () from /lib64/libpthread.so.0 > #11 0x76c6c59d in clone () from /lib64/libc.so.6 > I'm using master qpid-proton 0.14.0-SNAPSHOT > master qpid-dispatch 0.7.0 > Here is the routers debug output after the vpn was killed and just before the > crash > Mon Jun 13 11:34:14 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:23 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:34 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:34:44 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link removed > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link removed > Mon Jun 13 11:35:10 2016 ROUTER (trace) Entered Router Flux Mode > Mon Jun 13 11:35:10 2016 DRIVER (error) getaddrinfo(mrg30.lab.bos.redhat.com, > 11000): No address associated with hostname > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.D link set: link_id=0 > Mon Jun 13 11:35:10 2016 ROUTER (trace) Node QDR.C link set: link_id=1 > qdrouterd: /home/eallen/workspace/qpid-dispatch/src/posix/threading.c:71: > sys_mutex_lock: Assertion `result == 0' failed. > Program received signal SIGABRT, Aborted. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1233) Windows schannel: match OpenSSL and require non-null hostname for PN_SSL_VERIFY_PEER_NAME
[ https://issues.apache.org/jira/browse/PROTON-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed PROTON-1233. Resolution: Fixed > Windows schannel: match OpenSSL and require non-null hostname for > PN_SSL_VERIFY_PEER_NAME > - > > Key: PROTON-1233 > URL: https://issues.apache.org/jira/browse/PROTON-1233 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.14.0 > > > A user should not be permitted to omit setting the peer hostname and use > verify peer name at the same time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1233) Windows schannel: match OpenSSL and require non-null hostname for PN_SSL_VERIFY_PEER_NAME
[ https://issues.apache.org/jira/browse/PROTON-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327823#comment-15327823 ] ASF subversion and git services commented on PROTON-1233: - Commit 1f7ccdd551b344a5a67dfdee3840e16d10990577 in qpid-proton's branch refs/heads/master from Clifford Jansen [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1f7ccdd ] PROTON-1233: Add python SSL test for null hostname failure > Windows schannel: match OpenSSL and require non-null hostname for > PN_SSL_VERIFY_PEER_NAME > - > > Key: PROTON-1233 > URL: https://issues.apache.org/jira/browse/PROTON-1233 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.14.0 > > > A user should not be permitted to omit setting the peer hostname and use > verify peer name at the same time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-386) Router crashes in qd_link_pn
Eric Leu created DISPATCH-386: - Summary: Router crashes in qd_link_pn Key: DISPATCH-386 URL: https://issues.apache.org/jira/browse/DISPATCH-386 Project: Qpid Dispatch Issue Type: Bug Components: Routing Engine Affects Versions: 0.6.0 Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate machines Reporter: Eric Leu Network: A network of 3 interior routers built using the latest trunk and connected to each other using 2-way SSL, same as in DISPATCH-383. Run 3 pairs of senders and receivers on three different destination addresses. Each sender has 60 threads. Each receiver has 60 threads. Seg fault happened with either of of the two traces: (1) Program received signal SIGSEGV, Segmentation fault. 0x77ab4ee0 in qd_link_pn () from /usr/local/lib/qpid-dispatch/libqpid-dispatch.so (gdb) bt #0 0x77ab4ee0 in qd_link_pn () from /usr/local/lib/qpid-dispatch/libqpid-dispatch.so #1 0x77ad70cc in ?? () from /usr/local/lib/qpid-dispatch/libqpid-dispatch.so #2 0x77acc906 in qdr_connection_process () from /usr/local/lib/qpid-dispatch/libqpid- dispatch.so #3 0x77ab3b28 in ?? () from /usr/local/lib/qpid-dispatch/libqpid-dispatch.so #4 0x77adad55 in ?? () from /usr/local/lib/qpid-dispatch/libqpid-dispatch.so #5 0x77adb272 in qd_server_run () from /usr/local/lib/qpid-dispatch/libqpid- dispatch.so #6 0x00401a47 in _start () (2) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x70d1f700 (LWP 27862)] 0x77ab4ee0 in qd_link_pn () from /usr/local/lib/qpid-dispatch/libqpid-dispatch.so (gdb) bt #0 0x77ab4ee0 in qd_link_pn () from /usr/local/lib/qpid-dispatch/libqpid-dispatch.so #1 0x77ad71b3 in ?? () from /usr/local/lib/qpid-dispatch/libqpid-dispatch.so #2 0x77acc988 in qdr_connection_process () from /usr/local/lib/qpid-dispatch/libqpid-dispatch.so #3 0x77ab3b28 in ?? () from /usr/local/lib/qpid-dispatch/libqpid-dispatch.so #4 0x77adad55 in ?? () from /usr/local/lib/qpid-dispatch/libqpid-dispatch.so #5 0x775d10a4 in start_thread (arg=0x70d1f700) at pthread_create.c:309 #6 0x7697587d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7301) [Java Client] [Java Broker] JMS Selector parsing will not fail if a valid selector is followed by invalid text
[
https://issues.apache.org/jira/browse/QPID-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey updated QPID-7301:
--
Status: Reviewable (was: In Progress)
> [Java Client] [Java Broker] JMS Selector parsing will not fail if a valid
> selector is followed by invalid text
> --
>
> Key: QPID-7301
> URL: https://issues.apache.org/jira/browse/QPID-7301
> Project: Qpid
> Issue Type: Bug
> Components: Java Common
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> A JMS Selector which has a valid stem followed by invalid data will not cause
> a failure, and the selector will be parsed an executed as if only the valid
> stem were present.
> For example the selector
> {code}
> a = 1 AMD b = 2
> {code}
> will be treated as if the selector was
> {code}
> a = 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7301) [Java Client] [Java Broker] JMS Selector parsing will not fail if a valid selector is followed by invalid text
[
https://issues.apache.org/jira/browse/QPID-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327570#comment-15327570
]
ASF subversion and git services commented on QPID-7301:
---
Commit 1748254 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1748254 ]
QPID-7301 : Fix JMS selector grammar to ensure it fails when an invalid syntax
is used
> [Java Client] [Java Broker] JMS Selector parsing will not fail if a valid
> selector is followed by invalid text
> --
>
> Key: QPID-7301
> URL: https://issues.apache.org/jira/browse/QPID-7301
> Project: Qpid
> Issue Type: Bug
> Components: Java Common
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> A JMS Selector which has a valid stem followed by invalid data will not cause
> a failure, and the selector will be parsed an executed as if only the valid
> stem were present.
> For example the selector
> {code}
> a = 1 AMD b = 2
> {code}
> will be treated as if the selector was
> {code}
> a = 1
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7301) [Java Client] [Java Broker] JMS Selector parsing will not fail if a valid selector is followed by invalid text
Rob Godfrey created QPID-7301:
-
Summary: [Java Client] [Java Broker] JMS Selector parsing will not
fail if a valid selector is followed by invalid text
Key: QPID-7301
URL: https://issues.apache.org/jira/browse/QPID-7301
Project: Qpid
Issue Type: Bug
Components: Java Common
Reporter: Rob Godfrey
Assignee: Rob Godfrey
Fix For: qpid-java-6.1
A JMS Selector which has a valid stem followed by invalid data will not cause a
failure, and the selector will be parsed an executed as if only the valid stem
were present.
For example the selector
{code}
a = 1 AMD b = 2
{code}
will be treated as if the selector was
{code}
a = 1
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-184) dispatch do not stop when 'amqp' is not defined
[
https://issues.apache.org/jira/browse/DISPATCH-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324085#comment-15324085
]
Jiri Danek edited comment on DISPATCH-184 at 6/13/16 2:40 PM:
--
Issue is still present. If I delete my amqp lines from {{/etc/services}} as
well as if I remove the file alltogether, then with the default config this
happens:
{noformat}
mv /etc/services /etc/services_
qdrouterd &
Fri Jun 10 07:41:42 2016 SERVER (info) Container Name: Router.A
Fri Jun 10 07:41:42 2016 ROUTER (info) Router started in Standalone mode
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) Router Core thread running.
0/Router.A
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription
M/$management
Fri Jun 10 07:41:42 2016 AGENT (info) Activating management agent on
$_management_internal
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription
L/$management
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription
L/$_management_internal
Fri Jun 10 07:41:42 2016 DISPLAYNAME (info) Activating DisplayNameService on
$displayname
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription
L/$displayname
Fri Jun 10 07:41:42 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:amqp
proto=any role=normal
Fri Jun 10 07:41:42 2016 DRIVER (error) getaddrinfo(0.0.0.0, amqp): Servname
not supported for ai_socktype
Fri Jun 10 07:41:42 2016 POLICY (info) Policy configured maximumConnections: 0,
policyFolder: '', access rules enabled: 'false'
Fri Jun 10 07:41:42 2016 POLICY (info) Policy fallback defaultApplication is
disabled
Fri Jun 10 07:41:42 2016 SERVER (info) Operational, 4 Threads Running
# qdstat -g
Segmentation fault
{noformat}
(core from {{qdstat -g}} on Fedora 23 is attached)
Dispatch is supposed to work even without the amqp line in {{/etc/services}},
because
[qpid-dispatch/python/qpid_dispatch_internal/proton_future/__init__.py|https://github.com/apache/qpid-dispatch/blob/2b1d8f67f3ad5dd25edaf8fc71117988a14e102d/python/qpid_dispatch_internal/proton_future/__init__.py#L3782]
contains this function, which should be called to take care of the problem.
{code}
@staticmethod
def _port_int(value):
"""Convert service, an integer or a service name, into an integer port
number."""
try:
return int(value)
except ValueError:
try:
return socket.getservbyname(value)
except socket.error:
# Not every system has amqp/amqps defined as a service
if value == Url.AMQPS: return 5671
elif value == Url.AMQP: return 5672
else:
raise ValueError("Not a valid port number or service name: '%s'" %
value)
{code}
was (Author: jdanek):
Issue is still present. If I delete my amqp lines from {{/etc/services}}, then
with the default config this happens:
{noformat}
mv /etc/services /etc/services_
qdrouterd &
Fri Jun 10 07:41:42 2016 SERVER (info) Container Name: Router.A
Fri Jun 10 07:41:42 2016 ROUTER (info) Router started in Standalone mode
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) Router Core thread running.
0/Router.A
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription
M/$management
Fri Jun 10 07:41:42 2016 AGENT (info) Activating management agent on
$_management_internal
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription
L/$management
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription
L/$_management_internal
Fri Jun 10 07:41:42 2016 DISPLAYNAME (info) Activating DisplayNameService on
$displayname
Fri Jun 10 07:41:42 2016 ROUTER_CORE (info) In-process subscription
L/$displayname
Fri Jun 10 07:41:42 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:amqp
proto=any role=normal
Fri Jun 10 07:41:42 2016 DRIVER (error) getaddrinfo(0.0.0.0, amqp): Servname
not supported for ai_socktype
Fri Jun 10 07:41:42 2016 POLICY (info) Policy configured maximumConnections: 0,
policyFolder: '', access rules enabled: 'false'
Fri Jun 10 07:41:42 2016 POLICY (info) Policy fallback defaultApplication is
disabled
Fri Jun 10 07:41:42 2016 SERVER (info) Operational, 4 Threads Running
# qdstat -g
Segmentation fault
{noformat}
(core from {{qdstat -g}} on Fedora 23 is attached)
Dispatch is supposed to work even without the amqp line in {{/etc/services}},
because
[qpid-dispatch/python/qpid_dispatch_internal/proton_future/__init__.py|https://github.com/apache/qpid-dispatch/blob/2b1d8f67f3ad5dd25edaf8fc71117988a14e102d/python/qpid_dispatch_internal/proton_future/__init__.py#L3782]
contains this function, which should be called to take care of the problem.
{code}
@staticmethod
def _port_int(value):
"""Convert service, an integer or a service name, into an integer port
number."""
try:
return int(value)
except ValueError:
try:
return socket.getservbyname(value)
except socket.error:
[jira] [Assigned] (DISPATCH-383) Intermittent router crashes when restarting one router in the network with different number of threads
[ https://issues.apache.org/jira/browse/DISPATCH-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-383: -- Assignee: Ganesh Murthy > Intermittent router crashes when restarting one router in the network with > different number of threads > -- > > Key: DISPATCH-383 > URL: https://issues.apache.org/jira/browse/DISPATCH-383 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate > machines >Reporter: Vishal Sharda >Assignee: Ganesh Murthy >Priority: Critical > Attachments: Crash_route_tables_1.png, Crash_route_tables_2.png, > Crash_route_tables_3.png > > > Network: A network of 3 interior routers built using the latest trunk and > connected to each other using 2-way SSL. > Stopping one router in the network, changing its number of threads in the > configuration file and starting it again to join the network causes > intermittent crash in other routers in the network. > I was able to reproduce the crash three times and collect the backtraces > inside gdb (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-381) qdstat -g causes segfault
[
https://issues.apache.org/jira/browse/DISPATCH-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-381.
Resolution: Fixed
Fix Version/s: 0.7.0
> qdstat -g causes segfault
> -
>
> Key: DISPATCH-381
> URL: https://issues.apache.org/jira/browse/DISPATCH-381
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 0.7.0
>
>
> Using latest from master, start a router, connect with qpid-receive or
> qpid-receive, then do qdstat -g:
> {noformat}
> Core was generated by `./sbin/qdrouterd --conf
> ./etc/qpid-dispatch/router1-with-broker.conf'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x7f79dd616b3a in strlen () from /lib64/libc.so.6
> [Current thread is 1 (Thread 0x7f79cb7fe700 (LWP 7322))]
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-gssapi-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-lib-2.1.26-25.2.fc23.x86_64 cyrus-sasl-md5-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-plain-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-scram-2.1.26-25.2.fc23.x86_64 glibc-2.22-11.fc23.x86_64
> keyutils-libs-1.5.9-7.fc23.x86_64 krb5-libs-1.14.1-3.fc23.x86_64
> libcom_err-1.42.13-3.fc23.x86_64 libdb-5.3.28-13.fc23.x86_64
> libffi-3.1-8.fc23.x86_64 libselinux-2.4-4.fc23.x86_64
> nss-softokn-freebl-3.23.0-1.0.fc23.x86_64 openssl-libs-1.0.2g-2.fc23.x86_64
> pcre-8.38-7.fc23.x86_64 python-libs-2.7.10-8.fc23.x86_64
> sssd-client-1.13.3-5.fc23.x86_64 zlib-1.2.8-9.fc23.x86_64
> (gdb) thread apply all bt
> Thread 5 (Thread 0x7f79de9da180 (LWP 7319)):
> #0 0x7f79de12eb10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1 0x7f79de5b4faf in sys_cond_wait (cond=,
> held_mutex=0x1cdc3c0) at
> /home/gordon/projects/dispatch/src/posix/threading.c:107
> #2 0x7f79de5c8b24 in thread_run (arg=) at
> /home/gordon/projects/dispatch/src/server.c:906
> #3 0x7f79de5c9270 in qd_server_run (qd=0x1aff240) at
> /home/gordon/projects/dispatch/src/server.c:1431
> #4 0x00401ab7 in main_process
> (config_path=config_path@entry=0x7ffe87716143
> "./etc/qpid-dispatch/router1-with-broker.conf",
> python_pkgdir=python_pkgdir@entry=0x402458
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python",
> fd=fd@entry=2) at /home/gordon/projects/dispatch/router/src/main.c:145
> #5 0x004017a7 in main (argc=3, argv=0x7ffe87714838) at
> /home/gordon/projects/dispatch/router/src/main.c:345
> Thread 4 (Thread 0x7f79d0c92700 (LWP 7320)):
> #0 0x7f79de12eb10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1 0x7f79de5b4faf in sys_cond_wait (cond=,
> held_mutex=0x1e1fc60) at
> /home/gordon/projects/dispatch/src/posix/threading.c:107
> #2 0x7f79de5c02fd in router_core_thread (arg=0x1e1f930) at
> /home/gordon/projects/dispatch/src/router_core/router_core_thread.c:54
> #3 0x7f79de12960a in start_thread () from /lib64/libpthread.so.0
> #4 0x7f79dd68ea4d in clone () from /lib64/libc.so.6
> Thread 3 (Thread 0x7f79caffd700 (LWP 7323)):
> #0 0x7f79dd682fdd in poll () from /lib64/libc.so.6
> #1 0x7f79de5b4a00 in qdpn_driver_wait_2 (d=0x1d46c70, timeout= out>, timeout@entry=678) at
> /home/gordon/projects/dispatch/src/posix/driver.c:964
> #2 0x7f79de5c8609 in thread_run (arg=) at
> /home/gordon/projects/dispatch/src/server.c:932
> #3 0x7f79de12960a in start_thread () from /lib64/libpthread.so.0
> #4 0x7f79dd68ea4d in clone () from /lib64/libc.so.6
> Thread 2 (Thread 0x7f79cbfff700 (LWP 7321)):
> #0 0x7f79de12eb10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1 0x7f79de5b4faf in sys_cond_wait (cond=,
> held_mutex=0x1cdc3c0) at
> /home/gordon/projects/dispatch/src/posix/threading.c:107
> #2 0x7f79de5c8b24 in thread_run (arg=) at
> /home/gordon/projects/dispatch/src/server.c:906
> #3 0x7f79de12960a in start_thread () from /lib64/libpthread.so.0
> #4 0x7f79dd68ea4d in clone () from /lib64/libc.so.6
> Thread 1 (Thread 0x7f79cb7fe700 (LWP 7322)):
> #0 0x7f79dd616b3a in strlen () from /lib64/libc.so.6
> #1 0x7f79dd9e5900 in PyString_FromString () from
> /lib64/libpython2.7.so.1.0
> #2 0x7f79de5ab9ba in qd_entity_set_map_key_value
> (entity=entity@entry=0x7f79d0cc67f8, attribute=attribute@entry=0x7f79de5cb885
> "properties", key=, value=0x0)
> at /home/gordon/projects/dispatch/src/entity.c:174
> #3 0x7f79de5c7af1 in qd_set_connection_properties (conn=0x1e5afc0,
> entity=0x7f79d0cc67f8) at /home/gordon/projects/dispatch/src/server.c:383
> #4 qd_entity_refresh_connection (entity=0x7f79d0cc67f8, impl=0x1e5afc0) at
> /home/gordon/projects/dispatch/src/server.c:430
> #5 0x7f79d3bafd30 in ffi_call_unix64 () from /lib64/libffi.so.6
> #6
[jira] [Commented] (DISPATCH-381) qdstat -g causes segfault
[
https://issues.apache.org/jira/browse/DISPATCH-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327470#comment-15327470
]
ASF subversion and git services commented on DISPATCH-381:
--
Commit ea44b20d63622db68a43ca072a3534ff05ec942c in qpid-dispatch's branch
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=ea44b20 ]
DISPATCH-381 - Allow integer values to be specified in connection properties.
Regression caused by fix to issue DISPATCH-211
> qdstat -g causes segfault
> -
>
> Key: DISPATCH-381
> URL: https://issues.apache.org/jira/browse/DISPATCH-381
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
>
> Using latest from master, start a router, connect with qpid-receive or
> qpid-receive, then do qdstat -g:
> {noformat}
> Core was generated by `./sbin/qdrouterd --conf
> ./etc/qpid-dispatch/router1-with-broker.conf'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 0x7f79dd616b3a in strlen () from /lib64/libc.so.6
> [Current thread is 1 (Thread 0x7f79cb7fe700 (LWP 7322))]
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-gssapi-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-lib-2.1.26-25.2.fc23.x86_64 cyrus-sasl-md5-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-plain-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-scram-2.1.26-25.2.fc23.x86_64 glibc-2.22-11.fc23.x86_64
> keyutils-libs-1.5.9-7.fc23.x86_64 krb5-libs-1.14.1-3.fc23.x86_64
> libcom_err-1.42.13-3.fc23.x86_64 libdb-5.3.28-13.fc23.x86_64
> libffi-3.1-8.fc23.x86_64 libselinux-2.4-4.fc23.x86_64
> nss-softokn-freebl-3.23.0-1.0.fc23.x86_64 openssl-libs-1.0.2g-2.fc23.x86_64
> pcre-8.38-7.fc23.x86_64 python-libs-2.7.10-8.fc23.x86_64
> sssd-client-1.13.3-5.fc23.x86_64 zlib-1.2.8-9.fc23.x86_64
> (gdb) thread apply all bt
> Thread 5 (Thread 0x7f79de9da180 (LWP 7319)):
> #0 0x7f79de12eb10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1 0x7f79de5b4faf in sys_cond_wait (cond=,
> held_mutex=0x1cdc3c0) at
> /home/gordon/projects/dispatch/src/posix/threading.c:107
> #2 0x7f79de5c8b24 in thread_run (arg=) at
> /home/gordon/projects/dispatch/src/server.c:906
> #3 0x7f79de5c9270 in qd_server_run (qd=0x1aff240) at
> /home/gordon/projects/dispatch/src/server.c:1431
> #4 0x00401ab7 in main_process
> (config_path=config_path@entry=0x7ffe87716143
> "./etc/qpid-dispatch/router1-with-broker.conf",
> python_pkgdir=python_pkgdir@entry=0x402458
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python",
> fd=fd@entry=2) at /home/gordon/projects/dispatch/router/src/main.c:145
> #5 0x004017a7 in main (argc=3, argv=0x7ffe87714838) at
> /home/gordon/projects/dispatch/router/src/main.c:345
> Thread 4 (Thread 0x7f79d0c92700 (LWP 7320)):
> #0 0x7f79de12eb10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1 0x7f79de5b4faf in sys_cond_wait (cond=,
> held_mutex=0x1e1fc60) at
> /home/gordon/projects/dispatch/src/posix/threading.c:107
> #2 0x7f79de5c02fd in router_core_thread (arg=0x1e1f930) at
> /home/gordon/projects/dispatch/src/router_core/router_core_thread.c:54
> #3 0x7f79de12960a in start_thread () from /lib64/libpthread.so.0
> #4 0x7f79dd68ea4d in clone () from /lib64/libc.so.6
> Thread 3 (Thread 0x7f79caffd700 (LWP 7323)):
> #0 0x7f79dd682fdd in poll () from /lib64/libc.so.6
> #1 0x7f79de5b4a00 in qdpn_driver_wait_2 (d=0x1d46c70, timeout= out>, timeout@entry=678) at
> /home/gordon/projects/dispatch/src/posix/driver.c:964
> #2 0x7f79de5c8609 in thread_run (arg=) at
> /home/gordon/projects/dispatch/src/server.c:932
> #3 0x7f79de12960a in start_thread () from /lib64/libpthread.so.0
> #4 0x7f79dd68ea4d in clone () from /lib64/libc.so.6
> Thread 2 (Thread 0x7f79cbfff700 (LWP 7321)):
> #0 0x7f79de12eb10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1 0x7f79de5b4faf in sys_cond_wait (cond=,
> held_mutex=0x1cdc3c0) at
> /home/gordon/projects/dispatch/src/posix/threading.c:107
> #2 0x7f79de5c8b24 in thread_run (arg=) at
> /home/gordon/projects/dispatch/src/server.c:906
> #3 0x7f79de12960a in start_thread () from /lib64/libpthread.so.0
> #4 0x7f79dd68ea4d in clone () from /lib64/libc.so.6
> Thread 1 (Thread 0x7f79cb7fe700 (LWP 7322)):
> #0 0x7f79dd616b3a in strlen () from /lib64/libc.so.6
> #1 0x7f79dd9e5900 in PyString_FromString () from
> /lib64/libpython2.7.so.1.0
> #2 0x7f79de5ab9ba in qd_entity_set_map_key_value
> (entity=entity@entry=0x7f79d0cc67f8, attribute=attribute@entry=0x7f79de5cb885
> "properties", key=, value=0x0)
> at /home/gordon/projects/dispatch/src/entity.c:174
> #3 0x7f79de5c7af1 in
[jira] [Commented] (DISPATCH-211) Expose connection properties in management response
[ https://issues.apache.org/jira/browse/DISPATCH-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327471#comment-15327471 ] ASF subversion and git services commented on DISPATCH-211: -- Commit ea44b20d63622db68a43ca072a3534ff05ec942c in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=ea44b20 ] DISPATCH-381 - Allow integer values to be specified in connection properties. Regression caused by fix to issue DISPATCH-211 > Expose connection properties in management response > --- > > Key: DISPATCH-211 > URL: https://issues.apache.org/jira/browse/DISPATCH-211 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 0.6.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy > Fix For: 0.7.0 > > > The response for a management request for the .connection entity contains a > "properties" field, but it is always empty. > The connections properties should be returned. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1236) Reactor - segfault if connection address cannot be resolved
[
https://issues.apache.org/jira/browse/PROTON-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1236:
Priority: Critical (was: Major)
> Reactor - segfault if connection address cannot be resolved
> ---
>
> Key: PROTON-1236
> URL: https://issues.apache.org/jira/browse/PROTON-1236
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.13.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Critical
> Fix For: 0.13.1
>
>
> $ cd examples/python/reactor/send.py
> $ python ./send.py lolhost:/foo
> Segmentation fault (core dumped)
> Same action using 0.12.2 release:
> $ python ./send.py lolhost:/foo
> Condition('proton:io', 'getaddrinfo(lolhost, /amq.topic): Servname not
> supported for ai_socktype')
> $
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1236) Reactor - segfault if connection address cannot be resolved
[
https://issues.apache.org/jira/browse/PROTON-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1236:
Fix Version/s: (was: 0.13.0)
0.13.1
> Reactor - segfault if connection address cannot be resolved
> ---
>
> Key: PROTON-1236
> URL: https://issues.apache.org/jira/browse/PROTON-1236
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.13.0
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: 0.13.1
>
>
> $ cd examples/python/reactor/send.py
> $ python ./send.py lolhost:/foo
> Segmentation fault (core dumped)
> Same action using 0.12.2 release:
> $ python ./send.py lolhost:/foo
> Condition('proton:io', 'getaddrinfo(lolhost, /amq.topic): Servname not
> supported for ai_socktype')
> $
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7287) Query parser fails silently with expression such as a + b
[ https://issues.apache.org/jira/browse/QPID-7287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327394#comment-15327394 ] ASF subversion and git services commented on QPID-7287: --- Commit 1748229 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1748229 ] QPID-7287 : Parsing should only be successful if the entire query string is parsed > Query parser fails silently with expression such as a + b > - > > Key: QPID-7287 > URL: https://issues.apache.org/jira/browse/QPID-7287 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall >Priority: Minor > Fix For: qpid-java-6.1 > > > There is a defect in the order-by (and select) parsing when the input is in > the form a + b. It seems the parser fails, but the exception is not reported > back to the client, nor it is reported to the logs. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-378) Seg Fault in CORE_link_push
[
https://issues.apache.org/jira/browse/DISPATCH-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross reassigned DISPATCH-378:
-
Assignee: Ted Ross
> Seg Fault in CORE_link_push
> ---
>
> Key: DISPATCH-378
> URL: https://issues.apache.org/jira/browse/DISPATCH-378
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.6.1
> Environment: Latest master branch of dispatch, fedora 23
>Reporter: Gordon Sim
>Assignee: Ted Ross
>
> Doing some perf testing with a very simple two router setup, one router
> connecting to the other. Hit this once only so far (i.e. not readily
> reproducible) wasn't doing anything noticeably different at the time.
> {noformat}
> Core was generated by `./sbin/qdrouterd --conf
> ./etc/qpid-dispatch/router2.conf'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 qd_link_pn (link=0x0) at
> /home/gordon/projects/dispatch/src/container.c:862
> 862 return link->pn_link;
> [Current thread is 1 (Thread 0x7f07c4f53700 (LWP 27600))]
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-gssapi-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-lib-2.1.26-25.2.fc23.x86_64 cyrus-sasl-md5-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-plain-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-scram-2.1.26-25.2.fc23.x86_64 glibc-2.22-11.fc23.x86_64
> keyutils-libs-1.5.9-7.fc23.x86_64 krb5-libs-1.14.1-3.fc23.x86_64
> libcom_err-1.42.13-3.fc23.x86_64 libdb-5.3.28-13.fc23.x86_64
> libffi-3.1-8.fc23.x86_64 libselinux-2.4-4.fc23.x86_64
> nss-softokn-freebl-3.23.0-1.0.fc23.x86_64 openssl-libs-1.0.2g-2.fc23.x86_64
> pcre-8.38-7.fc23.x86_64 python-libs-2.7.10-8.fc23.x86_64
> sssd-client-1.13.3-5.fc23.x86_64 zlib-1.2.8-9.fc23.x86_64
> (gdb) bt
> #0 qd_link_pn (link=0x0) at
> /home/gordon/projects/dispatch/src/container.c:862
> #1 0x7f07d429b0fc in CORE_link_push (context=0xf11550,
> link=0x7f07bc035a70) at /home/gordon/projects/dispatch/src/router_node.c:808
> #2 0x7f07d429159e in qdr_connection_process (conn=0x7f07b80c3070) at
> /home/gordon/projects/dispatch/src/router_core/connections.c:175
> #3 0x7f07d427f728 in writable_handler (container=0xe3db70,
> container=0xe3db70, conn=, qd_conn=0x7f07bc02ea10) at
> /home/gordon/projects/dispatch/src/container.c:353
> #4 handler (handler_context=0xe3db70, conn_context=,
> event=, qd_conn=0x7f07bc02ea10) at
> /home/gordon/projects/dispatch/src/container.c:590
> #5 0x7f07d429ed85 in process_connector (cxtr=0x7f07bc021b40,
> qd_server=0xdd33f0) at /home/gordon/projects/dispatch/src/server.c:804
> #6 thread_run (arg=) at
> /home/gordon/projects/dispatch/src/server.c:1024
> #7 0x7f07d3dff60a in start_thread () from /lib64/libpthread.so.0
> #8 0x7f07d3364a4d in clone () from /lib64/libc.so.6
> (gdb) info threads
> Id Target Id Frame
> 5Thread 0x7f07d46b0180 (LWP 27596) 0x7f07d3e04b10 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 4Thread 0x7f07c5f55700 (LWP 27598) 0x7f07d3e04b10 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 3Thread 0x7f07c5754700 (LWP 27599) 0x7f07d3358fdd in poll () from
> /lib64/libc.so.6
> 2Thread 0x7f07c6968700 (LWP 27597) 0x7f07d3e04b10 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> * 1Thread 0x7f07c4f53700 (LWP 27600) qd_link_pn (link=0x0) at
> /home/gordon/projects/dispatch/src/container.c:862
> (gdb) thread 2
> [Switching to thread 2 (Thread 0x7f07c6968700 (LWP 27597))]
> #0 0x7f07d3e04b10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> (gdb) bt
> #0 0x7f07d3e04b10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1 0x7f07d428afaf in sys_cond_wait (cond=,
> held_mutex=0xf169a0) at
> /home/gordon/projects/dispatch/src/posix/threading.c:107
> #2 0x7f07d42962fd in router_core_thread (arg=0xf16670) at
> /home/gordon/projects/dispatch/src/router_core/router_core_thread.c:54
> #3 0x7f07d3dff60a in start_thread () from /lib64/libpthread.so.0
> #4 0x7f07d3364a4d in clone () from /lib64/libc.so.6
> (gdb) thread 3
> [Switching to thread 3 (Thread 0x7f07c5754700 (LWP 27599))]
> #0 0x7f07d3358fdd in poll () from /lib64/libc.so.6
> (gdb) bt
> #0 0x7f07d3358fdd in poll () from /lib64/libc.so.6
> #1 0x7f07d428aa00 in qdpn_driver_wait_2 (d=0xe468c0, timeout= out>, timeout@entry=64) at
> /home/gordon/projects/dispatch/src/posix/driver.c:964
> #2 0x7f07d429e609 in thread_run (arg=) at
> /home/gordon/projects/dispatch/src/server.c:932
> #3 0x7f07d3dff60a in start_thread () from /lib64/libpthread.so.0
> #4 0x7f07d3364a4d in clone () from /lib64/libc.so.6
> (gdb) thread 4
> [Switching to thread 4 (Thread 0x7f07c5f55700 (LWP 27598))]
> #0 0x7f07d3e04b10 in
[jira] [Resolved] (DISPATCH-384) qdrouter.conf manual : saslMechanisms as "Space separated list ..."
[ https://issues.apache.org/jira/browse/DISPATCH-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-384. Resolution: Fixed Fix Version/s: (was: 0.6.0) 0.7.0 This has been fixed in this commit - https://github.com/apache/qpid-dispatch/commit/d0364ceb8ef90f2457b54a50b18e622061e59835 > qdrouter.conf manual : saslMechanisms as "Space separated list ..." > --- > > Key: DISPATCH-384 > URL: https://issues.apache.org/jira/browse/DISPATCH-384 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Paolo Patierno >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 0.7.0 > > > The qdrouterd.conf manual says that "saslMechanisms" attribute is a "Comma > separated list ". Instead it should be a "Space separated list ..." -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-384) qdrouter.conf manual : saslMechanisms as "Space separated list ..."
[ https://issues.apache.org/jira/browse/DISPATCH-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-384: -- Assignee: Ganesh Murthy > qdrouter.conf manual : saslMechanisms as "Space separated list ..." > --- > > Key: DISPATCH-384 > URL: https://issues.apache.org/jira/browse/DISPATCH-384 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Paolo Patierno >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 0.6.0 > > > The qdrouterd.conf manual says that "saslMechanisms" attribute is a "Comma > separated list ". Instead it should be a "Space separated list ..." -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7108) [Java Broker] Test BDBHAVirtualHostNodeTest.testIntruderProtection is failing sporadically
[
https://issues.apache.org/jira/browse/QPID-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327127#comment-15327127
]
ASF subversion and git services commented on QPID-7108:
---
Commit 1748171 from oru...@apache.org in branch 'java/branches/6.0.x'
[ https://svn.apache.org/r1748171 ]
QPID-7108 : Fix intruder test for BDB HA VHN
merged from trunk using
svn merge -c 1732465 ^/qpid/java/trunk
> [Java Broker] Test BDBHAVirtualHostNodeTest.testIntruderProtection is failing
> sporadically
> --
>
> Key: QPID-7108
> URL: https://issues.apache.org/jira/browse/QPID-7108
> Project: Qpid
> Issue Type: Bug
> Components: Java Tests
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.1
>Reporter: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-6.1
>
> Attachments:
> TEST-org.apache.qpid.server.store.berkeleydb.BDBHAVirtualHostNodeTest.testIntruderProtection.txt
>
>
> The test BDBHAVirtualHostNodeTest.testIntruderProtection tries to remove the
> permitted node from a list of permitted nodes in order to make it an intruder
> node.
> That it is not allowed as currently on changing of permitted nodes an
> existing implementation verifies that specified permitted nodes includes all
> nodes in a group. See changes made in QPID-6090 ( [Java Broker] Prevent
> removal of existing group nodes from the permitted nodes attribute on VHN).
> The test should simply connect an intruder and verify that it cannot start up
> with intruder present.
> Here are the exception details for the test as it is reported in jenkins
> {noformat}
> The current group node 'localhost:10001' cannot be removed from
> 'permittedNodes' as its already a group member
> Stacktrace
> java.lang.IllegalArgumentException: The current group node 'localhost:10001'
> cannot be removed from 'permittedNodes' as its already a group member
> at
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl.validatePermittedNodes(BDBHAVirtualHostNodeImpl.java:1007)
> at
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl.validateChange(BDBHAVirtualHostNodeImpl.java:185)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$23.execute(AbstractConfiguredObject.java:2382)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$23.execute(AbstractConfiguredObject.java:2377)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:270)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:342)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:335)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7297) [Java Client] Using socket:// address to supply a preexisting existing socket to the client fails on the 0-10 path
[
https://issues.apache.org/jira/browse/QPID-7297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey resolved QPID-7297.
---
Resolution: Fixed
> [Java Client] Using socket:// address to supply a preexisting existing socket
> to the client fails on the 0-10 path
> --
>
> Key: QPID-7297
> URL: https://issues.apache.org/jira/browse/QPID-7297
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> The Java Client supports addresses in the form {{socket://}}
> where {{}} is a string naming a Socket that has been previously
> registered with the client with
> {{org.apache.qpid.transport.network.io.IoNetworkTransport#registerOpenSocket}}.
> This feature works in 0-8..0-91, but fails in 0-10 with the following stack
> trace.
> If the user wishes to use a protocol other than 0-10, they can workaround
> this problem by setting system property {{qpid.ampq.version}} e.g
> -Dqpid.ampq.version=0-9.
> The problem is the 0-10 protocol stack fails to propagate the protocol name
> from the broker details url, so it treats the address as if it were tcp:.
> {noformat}
> javax.jms.JMSException: Error creating connection: mysock: nodename nor
> servname provided, or not known
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:134)
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:57)
> at org.apache.qpid.example.Hello.runTest(Hello.java:69)
> at org.apache.qpid.example.Hello.main(Hello.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: org.apache.qpid.AMQUnresolvedAddressException: mysock:
> nodename nor servname provided, or not known Broker,
> "socket://mysock:5672"
> at org.apache.qpid.client.AMQConnection.makeConnection(AMQConnection.java:598)
> at org.apache.qpid.client.AMQConnection.(AMQConnection.java:484)
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:130)
> ... 8 more
> Caused by: org.apache.qpid.transport.TransportException: Error
> connecting to broker
> at
> org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:151)
> at
> org.apache.qpid.transport.network.io.IoNetworkTransport.connect(IoNetworkTransport.java:69)
> at org.apache.qpid.transport.Connection.connect(Connection.java:240)
> at
> org.apache.qpid.client.AMQConnectionDelegate_0_10.makeBrokerConnection(AMQConnectionDelegate_0_10.java:240)
> at
> org.apache.qpid.client.AMQConnection.makeBrokerConnection(AMQConnection.java:748)
> at org.apache.qpid.client.AMQConnection.makeConnection(AMQConnection.java:514)
> ... 10 more
> Caused by: java.net.UnknownHostException: mysock: nodename nor
> servname provided, or not known
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:901)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1295)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1248)
> at java.net.InetAddress.getAllByName(InetAddress.java:1164)
> at java.net.InetAddress.getAllByName(InetAddress.java:1098)
> at java.net.InetAddress.getByName(InetAddress.java:1048)
> at
> org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:128)
> ... 15 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7297) [Java Client] Using socket:// address to supply a preexisting existing socket to the client fails on the 0-10 path
[
https://issues.apache.org/jira/browse/QPID-7297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7297:
-
Fix Version/s: (was: qpid-java-6.0.4)
> [Java Client] Using socket:// address to supply a preexisting existing socket
> to the client fails on the 0-10 path
> --
>
> Key: QPID-7297
> URL: https://issues.apache.org/jira/browse/QPID-7297
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1
>
>
> The Java Client supports addresses in the form {{socket://}}
> where {{}} is a string naming a Socket that has been previously
> registered with the client with
> {{org.apache.qpid.transport.network.io.IoNetworkTransport#registerOpenSocket}}.
> This feature works in 0-8..0-91, but fails in 0-10 with the following stack
> trace.
> If the user wishes to use a protocol other than 0-10, they can workaround
> this problem by setting system property {{qpid.ampq.version}} e.g
> -Dqpid.ampq.version=0-9.
> The problem is the 0-10 protocol stack fails to propagate the protocol name
> from the broker details url, so it treats the address as if it were tcp:.
> {noformat}
> javax.jms.JMSException: Error creating connection: mysock: nodename nor
> servname provided, or not known
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:134)
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:57)
> at org.apache.qpid.example.Hello.runTest(Hello.java:69)
> at org.apache.qpid.example.Hello.main(Hello.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: org.apache.qpid.AMQUnresolvedAddressException: mysock:
> nodename nor servname provided, or not known Broker,
> "socket://mysock:5672"
> at org.apache.qpid.client.AMQConnection.makeConnection(AMQConnection.java:598)
> at org.apache.qpid.client.AMQConnection.(AMQConnection.java:484)
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:130)
> ... 8 more
> Caused by: org.apache.qpid.transport.TransportException: Error
> connecting to broker
> at
> org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:151)
> at
> org.apache.qpid.transport.network.io.IoNetworkTransport.connect(IoNetworkTransport.java:69)
> at org.apache.qpid.transport.Connection.connect(Connection.java:240)
> at
> org.apache.qpid.client.AMQConnectionDelegate_0_10.makeBrokerConnection(AMQConnectionDelegate_0_10.java:240)
> at
> org.apache.qpid.client.AMQConnection.makeBrokerConnection(AMQConnection.java:748)
> at org.apache.qpid.client.AMQConnection.makeConnection(AMQConnection.java:514)
> ... 10 more
> Caused by: java.net.UnknownHostException: mysock: nodename nor
> servname provided, or not known
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:901)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1295)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1248)
> at java.net.InetAddress.getAllByName(InetAddress.java:1164)
> at java.net.InetAddress.getAllByName(InetAddress.java:1098)
> at java.net.InetAddress.getByName(InetAddress.java:1048)
> at
> org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:128)
> ... 15 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7297) [Java Client] Using socket:// address to supply a preexisting existing socket to the client fails on the 0-10 path
[
https://issues.apache.org/jira/browse/QPID-7297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15327046#comment-15327046
]
ASF subversion and git services commented on QPID-7297:
---
Commit 1748149 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1748149 ]
QPID-7297: Address review comments from rgodf...@apache.org
> [Java Client] Using socket:// address to supply a preexisting existing socket
> to the client fails on the 0-10 path
> --
>
> Key: QPID-7297
> URL: https://issues.apache.org/jira/browse/QPID-7297
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Reporter: Keith Wall
>Priority: Minor
> Fix For: qpid-java-6.1, qpid-java-6.0.4
>
>
> The Java Client supports addresses in the form {{socket://}}
> where {{}} is a string naming a Socket that has been previously
> registered with the client with
> {{org.apache.qpid.transport.network.io.IoNetworkTransport#registerOpenSocket}}.
> This feature works in 0-8..0-91, but fails in 0-10 with the following stack
> trace.
> If the user wishes to use a protocol other than 0-10, they can workaround
> this problem by setting system property {{qpid.ampq.version}} e.g
> -Dqpid.ampq.version=0-9.
> The problem is the 0-10 protocol stack fails to propagate the protocol name
> from the broker details url, so it treats the address as if it were tcp:.
> {noformat}
> javax.jms.JMSException: Error creating connection: mysock: nodename nor
> servname provided, or not known
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:134)
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:57)
> at org.apache.qpid.example.Hello.runTest(Hello.java:69)
> at org.apache.qpid.example.Hello.main(Hello.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> Caused by: org.apache.qpid.AMQUnresolvedAddressException: mysock:
> nodename nor servname provided, or not known Broker,
> "socket://mysock:5672"
> at org.apache.qpid.client.AMQConnection.makeConnection(AMQConnection.java:598)
> at org.apache.qpid.client.AMQConnection.(AMQConnection.java:484)
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:130)
> ... 8 more
> Caused by: org.apache.qpid.transport.TransportException: Error
> connecting to broker
> at
> org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:151)
> at
> org.apache.qpid.transport.network.io.IoNetworkTransport.connect(IoNetworkTransport.java:69)
> at org.apache.qpid.transport.Connection.connect(Connection.java:240)
> at
> org.apache.qpid.client.AMQConnectionDelegate_0_10.makeBrokerConnection(AMQConnectionDelegate_0_10.java:240)
> at
> org.apache.qpid.client.AMQConnection.makeBrokerConnection(AMQConnection.java:748)
> at org.apache.qpid.client.AMQConnection.makeConnection(AMQConnection.java:514)
> ... 10 more
> Caused by: java.net.UnknownHostException: mysock: nodename nor
> servname provided, or not known
> at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:901)
> at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1295)
> at java.net.InetAddress.getAllByName0(InetAddress.java:1248)
> at java.net.InetAddress.getAllByName(InetAddress.java:1164)
> at java.net.InetAddress.getAllByName(InetAddress.java:1098)
> at java.net.InetAddress.getByName(InetAddress.java:1048)
> at
> org.apache.qpid.transport.network.io.IoNetworkTransport.connectTcp(IoNetworkTransport.java:128)
> ... 15 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-384) qdrouter.conf manual : saslMechanisms as "Space separated list ..."
Paolo Patierno created DISPATCH-384: --- Summary: qdrouter.conf manual : saslMechanisms as "Space separated list ..." Key: DISPATCH-384 URL: https://issues.apache.org/jira/browse/DISPATCH-384 Project: Qpid Dispatch Issue Type: Bug Reporter: Paolo Patierno Priority: Minor Fix For: 0.6.0 The qdrouterd.conf manual says that "saslMechanisms" attribute is a "Comma separated list ". Instead it should be a "Space separated list ..." -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
