[jira] [Updated] (PROTON-1862) Idle timeout not working on Linux
[ https://issues.apache.org/jira/browse/PROTON-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy updated PROTON-1862: --- Description: We faced an issue with the idle timeout on linux. On windows, it seems to work. In our proton feature test suite, we test the idle timeout feature by doing a sleep in the method on_session_open. This should trigger a connection timeout. It works on windows, and it used to work with proton v0.16.0 on windows and linux. Removing the sleep from the on_session_open and putting it in on_connection_open, yields the same result. See attached file to reproduce. Machines: * Windows machine ** OS: Windows 7 ** Compiler: MSVC 2013 Version 12 Update 5 * Linux machine ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) was: We faced an issue with the idle timeout on Linux. On windows, it seems to work. In our proton feature test suite, we test the idle timeout feature by doing a sleep on session open. This should trigger a connection timeout. It used to with proton v0.16.0. Removing the sleep from the on_session_open and putting it in on_connection_open, yields the same result. See attached file to reproduce. Machines: * Windows machine ** OS: Windows 7 ** Compiler: MSVC 2013 Version 12 Update 5 * Linux machine ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) > Idle timeout not working on Linux > - > > Key: PROTON-1862 > URL: https://issues.apache.org/jira/browse/PROTON-1862 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.22.0 >Reporter: Jeremy >Priority: Critical > Attachments: test_case.cpp > > > We faced an issue with the idle timeout on linux. On windows, it seems to > work. > In our proton feature test suite, we test the idle timeout feature by doing a > sleep in the method on_session_open. > This should trigger a connection timeout. It works on windows, and it used to > work with proton v0.16.0 on windows and linux. > Removing the sleep from the on_session_open and putting it in > on_connection_open, yields the same result. > See attached file to reproduce. > Machines: > * Windows machine > ** OS: Windows 7 > ** Compiler: MSVC 2013 Version 12 Update 5 > * Linux machine > ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) > ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1862) Idle timeout not working on Linux
[ https://issues.apache.org/jira/browse/PROTON-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy updated PROTON-1862: --- Description: We faced an issue with the idle timeout on Linux. On windows, it seems to work. In our proton feature test suite, we test the idle timeout feature by doing a sleep on session open. This should trigger a connection timeout. It used to with proton v0.16.0. Removing the sleep from the on_session_open and putting it in on_connection_open, yields the same result. See attached file to reproduce. Machines: * Windows machine ** OS: Windows 7 ** Compiler: MSVC 2013 Version 12 Update 5 * Linux machine ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) was: We faced an issue with the idle timeout on Linux. On windows, it seems to work. On the session open, we added a sleep, which should trigger a connection timeout. Also, note that removing the sleep from the on_session_open and putting it in on_connection_open, yields the same result. See attached file to reproduce. Machines: * Windows machine ** OS: Windows 7 ** Compiler: MSVC 2013 Version 12 Update 5 * Linux machine ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) > Idle timeout not working on Linux > - > > Key: PROTON-1862 > URL: https://issues.apache.org/jira/browse/PROTON-1862 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.22.0 >Reporter: Jeremy >Priority: Critical > Attachments: test_case.cpp > > > We faced an issue with the idle timeout on Linux. On windows, it seems to > work. > In our proton feature test suite, we test the idle timeout feature by doing a > sleep on session open. This should trigger a connection timeout. It used to > with proton v0.16.0. > Removing the sleep from the on_session_open and putting it in > on_connection_open, yields the same result. > See attached file to reproduce. > Machines: > * Windows machine > ** OS: Windows 7 > ** Compiler: MSVC 2013 Version 12 Update 5 > * Linux machine > ** OS: Red Hat Enterprise Linux Server release 6.4 (Santiago) > ** Compiler: g++491 (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1020) Detach expiring links with closed=true when peer connectivity lost
[
https://issues.apache.org/jira/browse/DISPATCH-1020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517595#comment-16517595
]
Gordon Sim commented on DISPATCH-1020:
--
One possibility proposed here: https://reviews.apache.org/r/67661/
> Detach expiring links with closed=true when peer connectivity lost
> --
>
> Key: DISPATCH-1020
> URL: https://issues.apache.org/jira/browse/DISPATCH-1020
> Project: Qpid Dispatch
> Issue Type: Improvement
>Reporter: Keith Wall
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.2.0
>
>
> Currently, Dispatch responds to the loss of an underlying connection to a
> peer by detaching the links established over that connection in the following
> way.
> {noformat}
> @detach(22) [handle=0, closed=false, error=@error(29)
> [condition=:"qd:routed-link-lost", description="Connectivity to the peer
> container was lost”]]
> {noformat}
> As is makes no sense for link defined to expire to attached again, it would
> be an improvement to the dispatch's behaviour if those links were detached
> with {{closed=true}}. This would aid the timely clean-up of resources
> elsewhere in the AMQP network.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request 67661: propagate link-detach as expiry policy for link route if none was explicitly selected by client
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/67661/ --- Review request for qpid, Alan Conway and Ted Ross. Bugs: DISPATCH-1020 https://issues.apache.org/jira/browse/DISPATCH-1020 Repository: qpid-dispatch Description --- The default expiry policy for a terminus is session-end. Now that link routed links share a session by default, this is likely not what is wanted (terminus state on a broker would have to be kept until the session ended, which is when the connection between broker and router ends). This change propagates an explicit link-detach policy where none is explicitly requested by the client. If the client does request an explicit policy, that is propagated without alteration. Note this requires a change to proton PROTON-1866, https://reviews.apache.org/r/67659/ Diffs - include/qpid/dispatch/router_core.h 8f144b0 src/router_core/connections.c 5fdc3bf src/router_core/terminus.c 4c0e0a3 tests/system_tests_link_routes.py 57e6d41 Diff: https://reviews.apache.org/r/67661/diff/1/ Testing --- Automated tests added, all existing tests pass. Thanks, Gordon Sim
[jira] [Commented] (PROTON-1866) cannot tell whether peer specified expiry-policy on terminus
[ https://issues.apache.org/jira/browse/PROTON-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517591#comment-16517591 ] Gordon Sim commented on PROTON-1866: suggested fix: https://reviews.apache.org/r/67659/ > cannot tell whether peer specified expiry-policy on terminus > > > Key: PROTON-1866 > URL: https://issues.apache.org/jira/browse/PROTON-1866 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.23.0 >Reporter: Gordon Sim >Priority: Major > > This prevents anything using proton-c to behave differently if an explicit > policy is set. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request 67659: provide new function to test whether an explicit expiry policy was set on a terminus
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/67659/ --- Review request for qpid, Alan Conway and Andrew Stitcher. Bugs: PROTON-1866 https://issues.apache.org/jira/browse/PROTON-1866 Repository: qpid-proton-git Description --- This allows users of proton to determine whether an explicit expiry was requested or not. Diffs - c/include/proton/terminus.h b2344c0 c/src/core/engine-internal.h b1c6123 c/src/core/engine.c 070c751 c/src/core/transport.c bfa66c1 Diff: https://reviews.apache.org/r/67659/diff/1/ Testing --- All tests pass. Thanks, Gordon Sim
[jira] [Created] (PROTON-1866) cannot tell whether peer specified expiry-policy on terminus
Gordon Sim created PROTON-1866: -- Summary: cannot tell whether peer specified expiry-policy on terminus Key: PROTON-1866 URL: https://issues.apache.org/jira/browse/PROTON-1866 Project: Qpid Proton Issue Type: Bug Affects Versions: proton-c-0.23.0 Reporter: Gordon Sim This prevents anything using proton-c to behave differently if an explicit policy is set. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8210) [Broker-J] Consumer attach when message is being released and requeued can end-up in broker crash due to unhandled NullPointerException
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517456#comment-16517456
]
Alex Rudyy commented on QPID-8210:
--
Keith,
I made a change in commit
[a07e8fd80ea11f0458c0fcfe4bc7a0ec31b4a7bb|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=a07e8fd80ea11f0458c0fcfe4bc7a0ec31b4a7bb]
to make field {{QueueConsumerImpl#_queueConsumerNode}} volatile.
> [Broker-J] Consumer attach when message is being released and requeued can
> end-up in broker crash due to unhandled NullPointerException
>
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWor
[jira] [Updated] (QPID-8210) [Broker-J] Consumer attach when message is being released and requeued can end-up in broker crash due to unhandled NullPointerException
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8210:
-
Summary: [Broker-J] Consumer attach when message is being released and
requeued can end-up in broker crash due to unhandled NullPointerException
(was: [Broker-J] Set queue consumer node before adding consumer into queue
consumer manager)
> [Broker-J] Consumer attach when message is being released and requeued can
> end-up in broker crash due to unhandled NullPointerException
>
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
> at
> org.apache.
[jira] [Updated] (QPID-8210) [Broker-J] Set queue consumer node before adding consumer into queue consumer manager
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8210:
-
Description:
The consumer node is currently set after consumer is added into queue consumer
manager. When released message is requeued all consumers in consumer manager
are iterated and AbstractQueue#updateSubRequeueEntry is invoke for every of
them to update the released entry in consumer queue context if required. The
notification of consumer without a consumer node can result in
NullPointerException:
{noformat}
java.lang.NullPointerException
at
org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
at
org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
at
org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
at
org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
at
org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
at
org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
at
org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
at
org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
at
org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
at
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
at
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
at
org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
at
org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
at
org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
at
org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
at
org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
at
org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
at
org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
at
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
at
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575)
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366)
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
at
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:748)
{noformat}
The issue can happen in next scenarious:
* when previously acquired message is released due to
consumer/session/connection close and another consumer is attached to the queue
at the same time.
* when transaction is rolled back or message is released (for example, JMS
session Ses
[jira] [Comment Edited] (QPID-8210) [Broker-J] Set queue consumer node before adding consumer into queue consumer manager
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517377#comment-16517377
]
Keith Wall edited comment on QPID-8210 at 6/19/18 6:00 PM:
---
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
Also the last paragraphs on this Jira's description have been managed. The
Jira title should also be updated to reflect the problem, rather than the
solution.
was (Author: k-wall):
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
Also the last paragraphs on this Jira's description have been managed.
> [Broker-J] Set queue consumer node before adding consumer into queue consumer
> manager
> -
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.q
[jira] [Comment Edited] (QPID-8210) [Broker-J] Set queue consumer node before adding consumer into queue consumer manager
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517377#comment-16517377
]
Keith Wall edited comment on QPID-8210 at 6/19/18 5:57 PM:
---
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
Also the last paragraphs on this Jira's description have been managed.
was (Author: k-wall):
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
Also the last paragraphs on this Jira's description have been managed.
> [Broker-J] Set queue consumer node before adding consumer into queue consumer
> manager
> -
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
[jira] [Comment Edited] (QPID-8210) [Broker-J] Set queue consumer node before adding consumer into queue consumer manager
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517377#comment-16517377
]
Keith Wall edited comment on QPID-8210 at 6/19/18 5:56 PM:
---
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
Also the last paragraphs on this Jira's description have been managed.
was (Author: k-wall):
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
> [Broker-J] Set queue consumer node before adding consumer into queue consumer
> manager
> -
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
>
[jira] [Commented] (QPID-8210) [Broker-J] Set queue consumer node before adding consumer into queue consumer manager
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517377#comment-16517377
]
Keith Wall commented on QPID-8210:
--
Change looks reasonable to me, but I notice that
{{org.apache.qpid.server.queue.QueueConsumerImpl#_queueConsumerNode}} is
unsafely published. It is written by the config thread then observed from the
IO threads without a memory barrier. Unfortunately, I think it needs to be
volatile (or the code redesigned to avoid the cycle between
{{QueueConsumerImpl}} and the node, which is more than will be desired for
7.0.6).
> [Broker-J] Set queue consumer node before adding consumer into queue consumer
> manager
> -
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.
[jira] [Commented] (DISPATCH-476) qualified link routing
[ https://issues.apache.org/jira/browse/DISPATCH-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517339#comment-16517339 ] ASF GitHub Bot commented on DISPATCH-476: - Github user lulf closed the pull request at: https://github.com/apache/qpid-dispatch/pull/111 > qualified link routing > -- > > Key: DISPATCH-476 > URL: https://issues.apache.org/jira/browse/DISPATCH-476 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine >Reporter: Gordon Sim >Priority: Major > Fix For: Backlog > > > It might be useful to have the router be able to apply some matching logic > when doing link routing. A link could be qualified with information that the > router would then use to determine which connections were applicable. > This would save having to add lots of expliclit qualified link routes. > Another way to handle it could be to have connections identify themselves as > being sources/targets for link routing particular addresses. The router could > then automatically add link routes on processing the open of that connection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #111: DISPATCH-476: Add support for groupId prope...
Github user lulf closed the pull request at: https://github.com/apache/qpid-dispatch/pull/111 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-395) connection:forced leads to JMSException even though reconnect is enabled
[
https://issues.apache.org/jira/browse/QPIDJMS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517277#comment-16517277
]
Timothy Bish commented on QPIDJMS-395:
--
Would you not be testing for
[JMSSecurityException|https://docs.oracle.com/javaee/7/api/javax/jms/JMSSecurityException.html]
in that case?
> connection:forced leads to JMSException even though reconnect is enabled
>
>
> Key: QPIDJMS-395
> URL: https://issues.apache.org/jira/browse/QPIDJMS-395
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.33.0
>Reporter: Jiri Daněk
>Priority: Major
>
> Based on
> http://qpid.2158936.n2.nabble.com/Reconnect-and-amqp-connection-forced-td7659043.html,
> I believe that reconnect:force error should not be propagated to library
> user and the library should silently reconnect. This does not happen in the
> test below, when I am sending messages fast--I do get exception caused by
> connection:forced. Notice the commented out sleep() call.
> In ActiveMQ Artemis testsuite:
> {noformat}
> diff --git
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
>
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> index 81c28855ef..888171227b 100644
> ---
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> +++
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> @@ -86,6 +86,32 @@ public class AmqpFailoverEndpointDiscoveryTest extends
> FailoverTestBase {
>}
> }
>
> + @Test(timeout = 12)
> + public void testReconnectWhileSendingWithAMQP() throws Exception {
> + JmsConnectionFactory factory = getJmsConnectionFactory();
> + try (Connection connection = factory.createConnection()) {
> + connection.start();
> + Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> + javax.jms.Queue queue = session.createQueue(ADDRESS.toString());
> + MessageProducer producer = session.createProducer(queue);
> + Thread t = new Thread(() -> {
> +try {
> + while(true) {
> + System.out.println("sending message");
> + producer.send(session.createTextMessage("hello before
> failover"));
> +// Thread.sleep(1000); // comment out to send messages
> quickly
> + }
> +} catch (Exception e ) {
> + e.printStackTrace();
> +}
> + });
> + t.start();
> + Thread.sleep(2000); // simpler to read than actual synchronization
> + liveServer.crash(true, true);
> + Thread.sleep(2000);
> + }
> + }
> +
> private JmsConnectionFactory getJmsConnectionFactory() {
>if (protocol == 0) {
> return new
> JmsConnectionFactory("failover:(amqp://localhost:61616)");
> {noformat}
> The above will print (only print, there aren't asserts)
> {noformat}
> javax.jms.JMSException: Received error from remote peer without description
> [condition = amqp:connection:forced]
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:164)
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:117)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:262)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:971)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:105)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:854)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The PN_TRACE_FRM log for this is
> {noformat}
> [...]
> [1476077082:1] -> Transfer{handle=0, deliveryId=221, deliveryTag=\x00,
> messageFormat=0, settled=null, more
[jira] [Comment Edited] (QPIDJMS-395) connection:forced leads to JMSException even though reconnect is enabled
[
https://issues.apache.org/jira/browse/QPIDJMS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517274#comment-16517274
]
Jiri Daněk edited comment on QPIDJMS-395 at 6/19/18 4:19 PM:
-
I do need to inspect the exception I got from send, because I may also get
exception due to missing SEND permission to a queue, which I must handle
differently.
So I end up with
{code}
try {
msgProducer.send(message);
} catch (JMSException jex) {
if (jex.getMessage().contains("[condition =
amqp:connection:forced]")) {
LOG.warn("Resending message %d due to unblocking a
blocking send.", msgCounter);
msgProducer.send(message);
} else {
throw jex;
}
}
{code}
Edit: ok, I can catch JMSSecurityException for the send permission case, so
maybe I don't have to read the cause string after all.
was (Author: jdanek):
I do need to inspect the exception I got from send, because I may also get
exception due to missing SEND permission to a queue, which I must handle
differently.
So I end up with
{code}
try {
msgProducer.send(message);
} catch (JMSException jex) {
if (jex.getMessage().contains("[condition =
amqp:connection:forced]")) {
LOG.warn("Resending message %d due to unblocking a
blocking send.", msgCounter);
msgProducer.send(message);
} else {
throw jex;
}
}
{code}
> connection:forced leads to JMSException even though reconnect is enabled
>
>
> Key: QPIDJMS-395
> URL: https://issues.apache.org/jira/browse/QPIDJMS-395
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.33.0
>Reporter: Jiri Daněk
>Priority: Major
>
> Based on
> http://qpid.2158936.n2.nabble.com/Reconnect-and-amqp-connection-forced-td7659043.html,
> I believe that reconnect:force error should not be propagated to library
> user and the library should silently reconnect. This does not happen in the
> test below, when I am sending messages fast--I do get exception caused by
> connection:forced. Notice the commented out sleep() call.
> In ActiveMQ Artemis testsuite:
> {noformat}
> diff --git
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
>
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> index 81c28855ef..888171227b 100644
> ---
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> +++
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> @@ -86,6 +86,32 @@ public class AmqpFailoverEndpointDiscoveryTest extends
> FailoverTestBase {
>}
> }
>
> + @Test(timeout = 12)
> + public void testReconnectWhileSendingWithAMQP() throws Exception {
> + JmsConnectionFactory factory = getJmsConnectionFactory();
> + try (Connection connection = factory.createConnection()) {
> + connection.start();
> + Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> + javax.jms.Queue queue = session.createQueue(ADDRESS.toString());
> + MessageProducer producer = session.createProducer(queue);
> + Thread t = new Thread(() -> {
> +try {
> + while(true) {
> + System.out.println("sending message");
> + producer.send(session.createTextMessage("hello before
> failover"));
> +// Thread.sleep(1000); // comment out to send messages
> quickly
> + }
> +} catch (Exception e ) {
> + e.printStackTrace();
> +}
> + });
> + t.start();
> + Thread.sleep(2000); // simpler to read than actual synchronization
> + liveServer.crash(true, true);
> + Thread.sleep(2000);
> + }
> + }
> +
> private JmsConnectionFactory getJmsConnectionFactory() {
>if (protocol == 0) {
> return new
> JmsConnectionFactory("failover:(amqp://localhost:61616)");
> {noformat}
> The above will print (only print, there aren't asserts)
> {noformat}
> javax.jms.JMSException: Received error from remote peer without description
> [condition = amqp:connection:forced]
> at
> org.apache.qpid.jms.provider.a
[jira] [Commented] (QPIDJMS-395) connection:forced leads to JMSException even though reconnect is enabled
[
https://issues.apache.org/jira/browse/QPIDJMS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517274#comment-16517274
]
Jiri Daněk commented on QPIDJMS-395:
I do need to inspect the exception I got from send, because I may also get
exception due to missing SEND permission to a queue, which I must handle
differently.
So I end up with
{code}
try {
msgProducer.send(message);
} catch (JMSException jex) {
if (jex.getMessage().contains("[condition =
amqp:connection:forced]")) {
LOG.warn("Resending message %d due to unblocking a
blocking send.", msgCounter);
msgProducer.send(message);
} else {
throw jex;
}
}
{code}
> connection:forced leads to JMSException even though reconnect is enabled
>
>
> Key: QPIDJMS-395
> URL: https://issues.apache.org/jira/browse/QPIDJMS-395
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.33.0
>Reporter: Jiri Daněk
>Priority: Major
>
> Based on
> http://qpid.2158936.n2.nabble.com/Reconnect-and-amqp-connection-forced-td7659043.html,
> I believe that reconnect:force error should not be propagated to library
> user and the library should silently reconnect. This does not happen in the
> test below, when I am sending messages fast--I do get exception caused by
> connection:forced. Notice the commented out sleep() call.
> In ActiveMQ Artemis testsuite:
> {noformat}
> diff --git
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
>
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> index 81c28855ef..888171227b 100644
> ---
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> +++
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> @@ -86,6 +86,32 @@ public class AmqpFailoverEndpointDiscoveryTest extends
> FailoverTestBase {
>}
> }
>
> + @Test(timeout = 12)
> + public void testReconnectWhileSendingWithAMQP() throws Exception {
> + JmsConnectionFactory factory = getJmsConnectionFactory();
> + try (Connection connection = factory.createConnection()) {
> + connection.start();
> + Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> + javax.jms.Queue queue = session.createQueue(ADDRESS.toString());
> + MessageProducer producer = session.createProducer(queue);
> + Thread t = new Thread(() -> {
> +try {
> + while(true) {
> + System.out.println("sending message");
> + producer.send(session.createTextMessage("hello before
> failover"));
> +// Thread.sleep(1000); // comment out to send messages
> quickly
> + }
> +} catch (Exception e ) {
> + e.printStackTrace();
> +}
> + });
> + t.start();
> + Thread.sleep(2000); // simpler to read than actual synchronization
> + liveServer.crash(true, true);
> + Thread.sleep(2000);
> + }
> + }
> +
> private JmsConnectionFactory getJmsConnectionFactory() {
>if (protocol == 0) {
> return new
> JmsConnectionFactory("failover:(amqp://localhost:61616)");
> {noformat}
> The above will print (only print, there aren't asserts)
> {noformat}
> javax.jms.JMSException: Received error from remote peer without description
> [condition = amqp:connection:forced]
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:164)
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:117)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:262)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:971)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:105)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:854)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.uti
[jira] [Commented] (QPIDJMS-395) connection:forced leads to JMSException even though reconnect is enabled
[
https://issues.apache.org/jira/browse/QPIDJMS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517273#comment-16517273
]
Timothy Bish commented on QPIDJMS-395:
--
Having a JMS client specific exception would mean that those using it are now
tied to that client implementation. The other question I'd ask would be, what
exception that is thrown from send would indicate that a resend wasn't needed?
> connection:forced leads to JMSException even though reconnect is enabled
>
>
> Key: QPIDJMS-395
> URL: https://issues.apache.org/jira/browse/QPIDJMS-395
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.33.0
>Reporter: Jiri Daněk
>Priority: Major
>
> Based on
> http://qpid.2158936.n2.nabble.com/Reconnect-and-amqp-connection-forced-td7659043.html,
> I believe that reconnect:force error should not be propagated to library
> user and the library should silently reconnect. This does not happen in the
> test below, when I am sending messages fast--I do get exception caused by
> connection:forced. Notice the commented out sleep() call.
> In ActiveMQ Artemis testsuite:
> {noformat}
> diff --git
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
>
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> index 81c28855ef..888171227b 100644
> ---
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> +++
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> @@ -86,6 +86,32 @@ public class AmqpFailoverEndpointDiscoveryTest extends
> FailoverTestBase {
>}
> }
>
> + @Test(timeout = 12)
> + public void testReconnectWhileSendingWithAMQP() throws Exception {
> + JmsConnectionFactory factory = getJmsConnectionFactory();
> + try (Connection connection = factory.createConnection()) {
> + connection.start();
> + Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> + javax.jms.Queue queue = session.createQueue(ADDRESS.toString());
> + MessageProducer producer = session.createProducer(queue);
> + Thread t = new Thread(() -> {
> +try {
> + while(true) {
> + System.out.println("sending message");
> + producer.send(session.createTextMessage("hello before
> failover"));
> +// Thread.sleep(1000); // comment out to send messages
> quickly
> + }
> +} catch (Exception e ) {
> + e.printStackTrace();
> +}
> + });
> + t.start();
> + Thread.sleep(2000); // simpler to read than actual synchronization
> + liveServer.crash(true, true);
> + Thread.sleep(2000);
> + }
> + }
> +
> private JmsConnectionFactory getJmsConnectionFactory() {
>if (protocol == 0) {
> return new
> JmsConnectionFactory("failover:(amqp://localhost:61616)");
> {noformat}
> The above will print (only print, there aren't asserts)
> {noformat}
> javax.jms.JMSException: Received error from remote peer without description
> [condition = amqp:connection:forced]
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:164)
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:117)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:262)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:971)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:105)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:854)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The PN_TRACE_FRM log for this is
> {noformat}
> [...]
> [1476077082
[jira] [Commented] (DISPATCH-1043) In a two router network, qdstat -g is showing non-zero values for "Ingress Count" even when no messages are sent
[
https://issues.apache.org/jira/browse/DISPATCH-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517267#comment-16517267
]
Ganesh Murthy commented on DISPATCH-1043:
-
Looks for tests relating to this issue when the fix to
https://issues.apache.org/jira/browse/DISPATCH-1041 is checked in
> In a two router network, qdstat -g is showing non-zero values for "Ingress
> Count" even when no messages are sent
>
>
> Key: DISPATCH-1043
> URL: https://issues.apache.org/jira/browse/DISPATCH-1043
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.1.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.2.0
>
>
> Start a two router network and run qdstat like this ---
> {noformat}
> [gmurthy@localhost qpid-dispatch]$ qdstat -b 0.0.0.0:28641 -g
> Router Statistics
> attr value
> =
> Version 1.2.0-SNAPSHOT
> Mode interior
> Router Id QDR.B
> Area 0
> Link Routes 0
> Auto Links 0
> Links 6
> Nodes 1
> Addresses 10
> Connections 2
> Presettled Count 135
> Dropped Presettled Count 0
> Accepted Count 0
> Rejected Count 0
> Released Count 0
> Modified Count 0
> Ingress Count 136
> Egress Count 0
> Transit Count 12
> Deliveries from Route Container 0
> Deliveries to Route Container 0
> [gmurthy@localhost qpid-dispatch]$
> {noformat}
>
> Notice that the "Ingress Count" keeps increasing even if no messages were
> sent/received.
> The ingress count must not count the HELLO messages that the routers exchange
> over the inter-router control link
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1043) In a two router network, qdstat -g is showing non-zero values for "Ingress Count" even when no messages are sent
[
https://issues.apache.org/jira/browse/DISPATCH-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-1043.
-
Resolution: Fixed
> In a two router network, qdstat -g is showing non-zero values for "Ingress
> Count" even when no messages are sent
>
>
> Key: DISPATCH-1043
> URL: https://issues.apache.org/jira/browse/DISPATCH-1043
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 1.1.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.2.0
>
>
> Start a two router network and run qdstat like this ---
> {noformat}
> [gmurthy@localhost qpid-dispatch]$ qdstat -b 0.0.0.0:28641 -g
> Router Statistics
> attr value
> =
> Version 1.2.0-SNAPSHOT
> Mode interior
> Router Id QDR.B
> Area 0
> Link Routes 0
> Auto Links 0
> Links 6
> Nodes 1
> Addresses 10
> Connections 2
> Presettled Count 135
> Dropped Presettled Count 0
> Accepted Count 0
> Rejected Count 0
> Released Count 0
> Modified Count 0
> Ingress Count 136
> Egress Count 0
> Transit Count 12
> Deliveries from Route Container 0
> Deliveries to Route Container 0
> [gmurthy@localhost qpid-dispatch]$
> {noformat}
>
> Notice that the "Ingress Count" keeps increasing even if no messages were
> sent/received.
> The ingress count must not count the HELLO messages that the routers exchange
> over the inter-router control link
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-395) connection:forced leads to JMSException even though reconnect is enabled
[
https://issues.apache.org/jira/browse/QPIDJMS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517248#comment-16517248
]
Jiri Daněk commented on QPIDJMS-395:
I will just resend if I get such exception.
Artemis Core JMS is throwing a specific subclass of JMSException in this
situation. It is a bit clearer, but it makes the program JMS provider
specific... The Artemis Core JMS version would be something like
{code}
try {
msgProducer.send(message);
} catch (JMSException jex) {
if (jex.getCause() instanceof ActiveMQUnBlockedException) {
// Resend missed messages due to unblocking blocking
call.
// See "Handling Blocking Calls During Failover" in
link below
//
https://activemq.apache.org/artemis/docs/latest/ha.html
LOG.warn("Resending message %d due to unblocking a
blocking send.", msgCounter);
msgProducer.send(message);
} else {
throw jex;
}
}
{code}
> connection:forced leads to JMSException even though reconnect is enabled
>
>
> Key: QPIDJMS-395
> URL: https://issues.apache.org/jira/browse/QPIDJMS-395
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.33.0
>Reporter: Jiri Daněk
>Priority: Major
>
> Based on
> http://qpid.2158936.n2.nabble.com/Reconnect-and-amqp-connection-forced-td7659043.html,
> I believe that reconnect:force error should not be propagated to library
> user and the library should silently reconnect. This does not happen in the
> test below, when I am sending messages fast--I do get exception caused by
> connection:forced. Notice the commented out sleep() call.
> In ActiveMQ Artemis testsuite:
> {noformat}
> diff --git
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
>
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> index 81c28855ef..888171227b 100644
> ---
> a/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> +++
> b/tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/amqp/AmqpFailoverEndpointDiscoveryTest.java
> @@ -86,6 +86,32 @@ public class AmqpFailoverEndpointDiscoveryTest extends
> FailoverTestBase {
>}
> }
>
> + @Test(timeout = 12)
> + public void testReconnectWhileSendingWithAMQP() throws Exception {
> + JmsConnectionFactory factory = getJmsConnectionFactory();
> + try (Connection connection = factory.createConnection()) {
> + connection.start();
> + Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> + javax.jms.Queue queue = session.createQueue(ADDRESS.toString());
> + MessageProducer producer = session.createProducer(queue);
> + Thread t = new Thread(() -> {
> +try {
> + while(true) {
> + System.out.println("sending message");
> + producer.send(session.createTextMessage("hello before
> failover"));
> +// Thread.sleep(1000); // comment out to send messages
> quickly
> + }
> +} catch (Exception e ) {
> + e.printStackTrace();
> +}
> + });
> + t.start();
> + Thread.sleep(2000); // simpler to read than actual synchronization
> + liveServer.crash(true, true);
> + Thread.sleep(2000);
> + }
> + }
> +
> private JmsConnectionFactory getJmsConnectionFactory() {
>if (protocol == 0) {
> return new
> JmsConnectionFactory("failover:(amqp://localhost:61616)");
> {noformat}
> The above will print (only print, there aren't asserts)
> {noformat}
> javax.jms.JMSException: Received error from remote peer without description
> [condition = amqp:connection:forced]
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:164)
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:117)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:262)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:971)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:105)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.ja
[jira] [Created] (DISPATCH-1043) In a two router network, qdstat -g is showing non-zero values for "Ingress Count" even when no messages are sent
Ganesh Murthy created DISPATCH-1043:
---
Summary: In a two router network, qdstat -g is showing non-zero
values for "Ingress Count" even when no messages are sent
Key: DISPATCH-1043
URL: https://issues.apache.org/jira/browse/DISPATCH-1043
Project: Qpid Dispatch
Issue Type: Bug
Components: Container
Affects Versions: 1.1.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
Fix For: 1.2.0
Start a two router network and run qdstat like this ---
{noformat}
[gmurthy@localhost qpid-dispatch]$ qdstat -b 0.0.0.0:28641 -g
Router Statistics
attr value
=
Version 1.2.0-SNAPSHOT
Mode interior
Router Id QDR.B
Area 0
Link Routes 0
Auto Links 0
Links 6
Nodes 1
Addresses 10
Connections 2
Presettled Count 135
Dropped Presettled Count 0
Accepted Count 0
Rejected Count 0
Released Count 0
Modified Count 0
Ingress Count 136
Egress Count 0
Transit Count 12
Deliveries from Route Container 0
Deliveries to Route Container 0
[gmurthy@localhost qpid-dispatch]$
{noformat}
Notice that the "Ingress Count" keeps increasing even if no messages were
sent/received.
The ingress count must not count the HELLO messages that the routers exchange
over the inter-router control link
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1354) Disable problematic SASL mechanisms if they are not explicitly enabled
[ https://issues.apache.org/jira/browse/PROTON-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517189#comment-16517189 ] ASF GitHub Bot commented on PROTON-1354: Github user codecov-io commented on the issue: https://github.com/apache/qpid-proton/pull/148 # [Codecov](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=h1) Report > Merging [#148](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=desc) into [master](https://codecov.io/gh/apache/qpid-proton/commit/885d68aeaf522021a35b7b5cecb7c7c53663929b?src=pr&el=desc) will **increase** coverage by `<.01%`. > The diff coverage is `83.33%`. [](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=tree) ```diff @@Coverage Diff@@ ## master#148 +/- ## = + Coverage86.5% 86.5% +<.01% = Files 247 247 Lines 30397 30402 +5 = + Hits26294 26299 +5 Misses 41034103 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=tree) | Coverage Δ | | |---|---|---| | [c/src/sasl/sasl.c](https://codecov.io/gh/apache/qpid-proton/pull/148/diff?src=pr&el=tree#diff-Yy9zcmMvc2FzbC9zYXNsLmM=) | `86.66% <83.33%> (+0.14%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=footer). Last update [885d68a...1413b78](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). > Disable problematic SASL mechanisms if they are not explicitly enabled > -- > > Key: PROTON-1354 > URL: https://issues.apache.org/jira/browse/PROTON-1354 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Justin Ross >Assignee: Andrew Stitcher >Priority: Major > Labels: sasl, usability > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-proton issue #148: PROTON-1354: Don't allow SASL mechanisms GSSAPI or G...
Github user codecov-io commented on the issue: https://github.com/apache/qpid-proton/pull/148 # [Codecov](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=h1) Report > Merging [#148](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=desc) into [master](https://codecov.io/gh/apache/qpid-proton/commit/885d68aeaf522021a35b7b5cecb7c7c53663929b?src=pr&el=desc) will **increase** coverage by `<.01%`. > The diff coverage is `83.33%`. [](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=tree) ```diff @@Coverage Diff@@ ## master#148 +/- ## = + Coverage86.5% 86.5% +<.01% = Files 247 247 Lines 30397 30402 +5 = + Hits26294 26299 +5 Misses 41034103 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=tree) | Coverage Π| | |---|---|---| | [c/src/sasl/sasl.c](https://codecov.io/gh/apache/qpid-proton/pull/148/diff?src=pr&el=tree#diff-Yy9zcmMvc2FzbC9zYXNsLmM=) | `86.66% <83.33%> (+0.14%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Π= absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=footer). Last update [885d68a...1413b78](https://codecov.io/gh/apache/qpid-proton/pull/148?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1865) Improve split between general SASL code and the specific implementations
Andrew Stitcher created PROTON-1865: --- Summary: Improve split between general SASL code and the specific implementations Key: PROTON-1865 URL: https://issues.apache.org/jira/browse/PROTON-1865 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Andrew Stitcher Assignee: Andrew Stitcher There are a number of places where the SASL code needs to be tidied up since it was split into general and plugin implementations. Specifically checking for inclusion in the allowed mechanisms list only needs to happen in the common code and the specific implementations only need to receive a prefiltered list. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8208) [Broker-J] Improve handling of unexpected exceptions on establishing LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8208:
-
Attachment: (was:
0001-QPID-8208-Broker-J-Improve-exception-handling.patch)
> [Broker-J] Improve handling of unexpected exceptions on establishing LDAP
> connections in SimpleLDAPAuthenticationProvider
> --
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
>
> There is a weakness in Qpid exception handling when communication with
> external services like LDAP. The Broker should take a more defensive approach
> and handle unexpected exceptions thrown by underlying third-party API in
> addition to exceptions declared in API interfaces. The unexpected exceptions
> thrown by underlying API should not affect the stability of the Broker.
> It was reported that on establishment of connection with LDAP using default
> context factory {{com.sun.jndi.ldap.LdapCtxFactory}} the creation of
> {{InitialDirContext}} can end-up in unexpected exception thrown from
> {{com.sun.jndi.ldap.LdapClient}}. It looks like a defect in
> {{com.sun.jndi.ldap.LdapClient}}, but I could not find any existing open bug
> report raised against JVM with similar behaviour. I think that Broker should
> catch unexpected exception, log it and report authentication failure back to
> the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8208) [Broker-J] Improve handling of unexpected exceptions on establishing LDAP connections in SimpleLDAPAuthenticationProvider
[
https://issues.apache.org/jira/browse/QPID-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8208.
--
Resolution: Invalid
Fix Version/s: (was: qpid-java-broker-7.0.6)
Closing JIRA as invalid as the root cause of the issue is [JVM defect
JDK-8205330|https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8205330]
> [Broker-J] Improve handling of unexpected exceptions on establishing LDAP
> connections in SimpleLDAPAuthenticationProvider
> --
>
> Key: QPID-8208
> URL: https://issues.apache.org/jira/browse/QPID-8208
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-broker-7.0.3,
> qpid-java-broker-7.0.2, 0.32, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1,
> qpid-java-broker-7.0.4
>Reporter: Alex Rudyy
>Priority: Critical
> Attachments: 0001-QPID-8208-Broker-J-Improve-exception-handling.patch
>
>
> There is a weakness in Qpid exception handling when communication with
> external services like LDAP. The Broker should take a more defensive approach
> and handle unexpected exceptions thrown by underlying third-party API in
> addition to exceptions declared in API interfaces. The unexpected exceptions
> thrown by underlying API should not affect the stability of the Broker.
> It was reported that on establishment of connection with LDAP using default
> context factory {{com.sun.jndi.ldap.LdapCtxFactory}} the creation of
> {{InitialDirContext}} can end-up in unexpected exception thrown from
> {{com.sun.jndi.ldap.LdapClient}}. It looks like a defect in
> {{com.sun.jndi.ldap.LdapClient}}, but I could not find any existing open bug
> report raised against JVM with similar behaviour. I think that Broker should
> catch unexpected exception, log it and report authentication failure back to
> the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8210) [Broker-J] Set queue consumer node before adding consumer into queue consumer manager
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516795#comment-16516795
]
Alex Rudyy commented on QPID-8210:
--
The fix for the issue is committed
[0c4e41829d3f97eaa171fd1276e85e1685021cfc|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=0c4e41829d3f97eaa171fd1276e85e1685021cfc]
> [Broker-J] Set queue consumer node before adding consumer into queue consumer
> manager
> -
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consumer node is currently set after consumer is added into queue
> consumer manager. When released message is requeued all consumers in consumer
> manager are iterated and AbstractQueue#updateSubRequeueEntry is invoke for
> every of them to update the released entry in consumer queue context if
> required. The notification of consumer without a consumer node can result in
> NullPointerException:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
> at
> org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
> at
> org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
> at
> org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
> at
> org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
> at
> org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
> at
> org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at
> org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at
> org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
>
[jira] [Commented] (QPID-8210) [Broker-J] Set queue consumer node before adding consumer into queue consumer manager
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516790#comment-16516790
]
Alex Rudyy commented on QPID-8210:
--
Exception stack trace for another occurrence of the issue when message is
rejected with AMQP 0-9:
{noformat}
java.lang.NullPointerException: null
at
org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
at
org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
at
org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
at
org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
at
org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
at
org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
at
org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:897)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveBasicReject(AMQChannel.java:2084)
at
org.apache.qpid.server.protocol.v0_8.transport.BasicRejectBody.process(BasicRejectBody.java:119)
at
org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:197)
at
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
at
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
at
org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
at
org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
at
org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
at
org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
at
org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
at
org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
at
org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
at
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
at
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575)
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366)
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
at
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:745)
{noformat}
> [Broker-J] Set queue consumer node before adding consumer into queue consumer
> manager
> -
>
> Key: QPID-8210
> URL: https://issues.apache.org/jira/browse/QPID-8210
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2,
> qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4,
> qpid-java-broker-7.0.5
>Reporter: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-broker-7.0.6
>
>
> The consume
[jira] [Updated] (QPID-8210) [Broker-J] Set queue consumer node before adding consumer into queue consumer manager
[
https://issues.apache.org/jira/browse/QPID-8210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8210:
-
Description:
The consumer node is currently set after consumer is added into queue consumer
manager. When released message is requeued all consumers in consumer manager
are iterated and AbstractQueue#updateSubRequeueEntry is invoke for every of
them to update the released entry in consumer queue context if required. The
notification of consumer without a consumer node can result in
NullPointerException:
{noformat}
java.lang.NullPointerException
at
org.apache.qpid.server.queue.QueueConsumerManagerImpl.setNotified(QueueConsumerManagerImpl.java:151)
at
org.apache.qpid.server.queue.AbstractQueue.notifyConsumer(AbstractQueue.java:2268)
at
org.apache.qpid.server.queue.AbstractQueue.updateSubRequeueEntry(AbstractQueue.java:1382)
at
org.apache.qpid.server.queue.AbstractQueue.resetSubPointers(AbstractQueue.java:1413)
at
org.apache.qpid.server.queue.AbstractQueue.requeue(AbstractQueue.java:1399)
at
org.apache.qpid.server.queue.QueueEntryImpl.postRelease(QueueEntryImpl.java:446)
at
org.apache.qpid.server.queue.QueueEntryImpl.release(QueueEntryImpl.java:437)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.requeue(AMQChannel.java:896)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.close(AMQChannel.java:787)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:459)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.closeChannel(AMQPConnection_0_8Impl.java:430)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveChannelClose(AMQChannel.java:2167)
at
org.apache.qpid.server.protocol.v0_8.transport.ChannelCloseBody.process(ChannelCloseBody.java:140)
at
org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:132)
at
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
at
org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
at
org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
at
org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:257)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:249)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:248)
at
org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:135)
at
org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:610)
at
org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
at
org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:496)
at
org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
at
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:134)
at
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:575)
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:366)
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
at
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:533)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464)
at java.lang.Thread.run(Thread.java:748)
{noformat}
The issue can happen in next scenarious:
* when previously acquired message is released due to
consumer/session/connection close but another consumer is attached to the
* well when transaction is rolled back or message is released (for example,
JMS session Session#release() is c
