[jira] [Commented] (QPIDJMS-103) After failover a pull consumer can block in receive
[ https://issues.apache.org/jira/browse/QPIDJMS-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14715788#comment-14715788 ] ASF subversion and git services commented on QPIDJMS-103: - Commit 214045ccd6ee08ba83feffed6975058153a58ec9 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=214045c ] QPIDJMS-103 pull consumer needs to recover after a failover. > After failover a pull consumer can block in receive > --- > > Key: QPIDJMS-103 > URL: https://issues.apache.org/jira/browse/QPIDJMS-103 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.4.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.5.0 > > > After a failover a consumer with zero prefetch (pull consumer) that was in a > blocking receive will not properly recover and will instead remain in the > receive forever. > The consumer needs to reissue a pull with the correct timeout options so that > the remote peer can handle the request. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-103) After failover a pull consumer can block in receive
Timothy Bish created QPIDJMS-103: Summary: After failover a pull consumer can block in receive Key: QPIDJMS-103 URL: https://issues.apache.org/jira/browse/QPIDJMS-103 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.4.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.5.0 After a failover a consumer with zero prefetch (pull consumer) that was in a blocking receive will not properly recover and will instead remain in the receive forever. The consumer needs to reissue a pull with the correct timeout options so that the remote peer can handle the request. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-100) SSL Connections can fire async errors prior to the connect call completion.
[ https://issues.apache.org/jira/browse/QPIDJMS-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14715367#comment-14715367 ] ASF subversion and git services commented on QPIDJMS-100: - Commit 27c3c2977e75de85400459ac993f940ecfa77c83 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=27c3c29 ] QPIDJMS-100 Fix the test to do a proper isConnected test on the Transport. > SSL Connections can fire async errors prior to the connect call completion. > --- > > Key: QPIDJMS-100 > URL: https://issues.apache.org/jira/browse/QPIDJMS-100 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.4.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.5.0 > > > During SSL connection establishment it is possible for error encountered in > the ssl handshake phase to be fired to the client's exception listener while > the connect call is still waiting for the full connect process to complete. > This can lead to contention to among the mechanisms that manage connection > failures especially when the failover transport is in use. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-98) Investigate random failures for tests in CI
[ https://issues.apache.org/jira/browse/QPIDJMS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14715290#comment-14715290 ] Robbie Gemmell commented on QPIDJMS-98: --- QPIDJMS-102 was also found while investigating a test failure for this JIRA. > Investigate random failures for tests in CI > --- > > Key: QPIDJMS-98 > URL: https://issues.apache.org/jira/browse/QPIDJMS-98 > Project: Qpid JMS > Issue Type: Test > Components: qpid-jms-client >Affects Versions: 0.4.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.5.0 > > > Some tests are failing randomly in CI like the Jms ClientId test and the > Netty SSL transport tests. Need to track these down and either fix the test > or the code behind it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-97) Pull Consumer in combination with RedeliveryPolicy enforcement can lead to stuck consumer
[ https://issues.apache.org/jira/browse/QPIDJMS-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14715278#comment-14715278 ] ASF subversion and git services commented on QPIDJMS-97: Commit aabcc42613f0c9aa49f6d58d38456b7bcea9386f in qpid-jms's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=aabcc42 ] QPIDJMS-97: reduce log level to trace for check diagnosis message. There is a debug level message showning the resulting action. > Pull Consumer in combination with RedeliveryPolicy enforcement can lead to > stuck consumer > - > > Key: QPIDJMS-97 > URL: https://issues.apache.org/jira/browse/QPIDJMS-97 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.5.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.5.0 > > > When the redelivery policy is used with a max redeliveries value and the > consumer is in pull mode the receive call can get stuck due to an incoming > message getting filtered due to exceeding its max redeliveries. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-102) initial onMessage deliveries may be delivered concurrently and in the wrong order
[ https://issues.apache.org/jira/browse/QPIDJMS-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14715279#comment-14715279 ] ASF subversion and git services commented on QPIDJMS-102: - Commit 27c7242168003586796a0f26d905df31e8bd7735 in qpid-jms's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=27c7242 ] QPIDJMS-102: synchronize creation of the executor to avoid concurrent creation and subsequent issues with initial async deliveries > initial onMessage deliveries may be delivered concurrently and in the wrong > order > - > > Key: QPIDJMS-102 > URL: https://issues.apache.org/jira/browse/QPIDJMS-102 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.4.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.5.0 > > > There is a publication issue with creation of the Executor used within the > Session to perform asynchronous onMessage deliveries. As a result, when > setting a MessageListener on an active Consumer two exectors may be created > and perform work for the initial asynchronous deliveries. This may lead to > some onMessage deliveries happening concurrently, which JMS forbids, and > Messages may as a result get processed in the wrong order too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-102) initial onMessage deliveries may be delivered concurrently and in the wrong order
Robbie Gemmell created QPIDJMS-102: -- Summary: initial onMessage deliveries may be delivered concurrently and in the wrong order Key: QPIDJMS-102 URL: https://issues.apache.org/jira/browse/QPIDJMS-102 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.4.0 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Priority: Critical Fix For: 0.5.0 There is a publication issue with creation of the Executor used within the Session to perform asynchronous onMessage deliveries. As a result, when setting a MessageListener on an active Consumer two exectors may be created and perform work for the initial asynchronous deliveries. This may lead to some onMessage deliveries happening concurrently, which JMS forbids, and Messages may as a result get processed in the wrong order too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-98) Investigate random failures for tests in CI
[ https://issues.apache.org/jira/browse/QPIDJMS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14714500#comment-14714500 ] Timothy Bish commented on QPIDJMS-98: - Fixes here resolve related issues. > Investigate random failures for tests in CI > --- > > Key: QPIDJMS-98 > URL: https://issues.apache.org/jira/browse/QPIDJMS-98 > Project: Qpid JMS > Issue Type: Test > Components: qpid-jms-client >Affects Versions: 0.4.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.5.0 > > > Some tests are failing randomly in CI like the Jms ClientId test and the > Netty SSL transport tests. Need to track these down and either fix the test > or the code behind it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-101) Close of the AMQP Provider should not forward exception if the close frame cannot be written
[ https://issues.apache.org/jira/browse/QPIDJMS-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-101. -- Resolution: Fixed Fixed in commit: 78711c1b7dbf098383c2926a0631b07a5a0659c7 https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=78711c1 > Close of the AMQP Provider should not forward exception if the close frame > cannot be written > > > Key: QPIDJMS-101 > URL: https://issues.apache.org/jira/browse/QPIDJMS-101 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.4.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.5.0 > > > When closing down the AMQP provider instance an exception should not be > propagated to the caller if the final close frames can't be written to the > transport. This would be a non-recoverable error and simply logging the > event is enough information. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-101) Close of the AMQP Provider should not forward exception if the close frame cannot be written
Timothy Bish created QPIDJMS-101: Summary: Close of the AMQP Provider should not forward exception if the close frame cannot be written Key: QPIDJMS-101 URL: https://issues.apache.org/jira/browse/QPIDJMS-101 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Affects Versions: 0.4.0 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor Fix For: 0.5.0 When closing down the AMQP provider instance an exception should not be propagated to the caller if the final close frames can't be written to the transport. This would be a non-recoverable error and simply logging the event is enough information. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-100) SSL Connections can fire async errors prior to the connect call completion.
[ https://issues.apache.org/jira/browse/QPIDJMS-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-100. -- Resolution: Fixed Fixed by commit: 2e89d0fb440203569fa352210589258124de42d6 https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=2e89d0f > SSL Connections can fire async errors prior to the connect call completion. > --- > > Key: QPIDJMS-100 > URL: https://issues.apache.org/jira/browse/QPIDJMS-100 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.4.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.5.0 > > > During SSL connection establishment it is possible for error encountered in > the ssl handshake phase to be fired to the client's exception listener while > the connect call is still waiting for the full connect process to complete. > This can lead to contention to among the mechanisms that manage connection > failures especially when the failover transport is in use. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-100) SSL Connections can fire async errors prior to the connect call completion.
Timothy Bish created QPIDJMS-100: Summary: SSL Connections can fire async errors prior to the connect call completion. Key: QPIDJMS-100 URL: https://issues.apache.org/jira/browse/QPIDJMS-100 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.4.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.5.0 During SSL connection establishment it is possible for error encountered in the ssl handshake phase to be fired to the client's exception listener while the connect call is still waiting for the full connect process to complete. This can lead to contention to among the mechanisms that manage connection failures especially when the failover transport is in use. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-99) Race on failure processing can lead to the wrong error being propagated.
Timothy Bish created QPIDJMS-99: --- Summary: Race on failure processing can lead to the wrong error being propagated. Key: QPIDJMS-99 URL: https://issues.apache.org/jira/browse/QPIDJMS-99 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.4.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.5.0 Processing of connection failures among others can lead to the client receiving an incorrect exception due to a race to update the error condition resulting in the original value being overwritten. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-99) Race on failure processing can lead to the wrong error being propagated.
[ https://issues.apache.org/jira/browse/QPIDJMS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-99. - Resolution: Fixed Fixed by commit: 894dce5c4cab093d1d84f6ad311f0e09367656eb > Race on failure processing can lead to the wrong error being propagated. > > > Key: QPIDJMS-99 > URL: https://issues.apache.org/jira/browse/QPIDJMS-99 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.4.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.5.0 > > > Processing of connection failures among others can lead to the client > receiving an incorrect exception due to a race to update the error condition > resulting in the original value being overwritten. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-157) add sasl tests to dispatch unit tests
michael goulish created DISPATCH-157:
Summary: add sasl tests to dispatch unit tests
Key: DISPATCH-157
URL: https://issues.apache.org/jira/browse/DISPATCH-157
Project: Qpid Dispatch
Issue Type: Improvement
Components: Tests
Affects Versions: 0.5
Reporter: michael goulish
Assignee: michael goulish
Fix For: 0.5
Add a complete set of sasl tests to the Dispatch unit test framework.
ensure correct behavior for cross-product of
authenticatePeer := { no, yes, insecureOk }
x
saslMechanisms:= { NONE, PLAIN, DIGEST-MD5, CRAM-MD5, GSSAPI, SRP }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6710) NPE masks IOException on running out of disk space
[
https://issues.apache.org/jira/browse/QPID-6710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14713494#comment-14713494
]
ASF subversion and git services commented on QPID-6710:
---
Commit 1697939 from oru...@apache.org in branch 'java/trunk'
[ https://svn.apache.org/r1697939 ]
QPID-6710: Remove redundant# setting of StateChangeListener on restart
> NPE masks IOException on running out of disk space
> --
>
> Key: QPID-6710
> URL: https://issues.apache.org/jira/browse/QPID-6710
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Lorenz Quack
> Attachments:
> 0001-QPID-6710-Java-Broker-NPE-masks-IOException-on-runni.patch
>
>
> When the broker is running out of disk space the following issue can occur.
> {noformat}
>
> #
> # Unhandled Exception org.apache.qpid.server.store.StoreException: Unexpected
> exception occurred on store operation in Thread virtualhost-default-iopool-55
> #
> # Exiting
> #
>
> org.apache.qpid.server.store.StoreException: Unexpected exception occurred on
> store operation
> at
> org.apache.qpid.server.store.berkeleydb.StandardEnvironmentFacade.handleDatabaseException(StandardEnvironmentFacade.java:287)
> at
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore.removeMessage(AbstractBDBMessageStore.java:317)
> at
> org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage.remove(AbstractBDBMessageStore.java:1234)
> at
> org.apache.qpid.server.message.AbstractServerMessageImpl.decrementReference(AbstractServerMessageImpl.java:101)
> at
> org.apache.qpid.server.message.AbstractServerMessageImpl.access$500(AbstractServerMessageImpl.java:37)
> at
> org.apache.qpid.server.message.AbstractServerMessageImpl$Reference.release(AbstractServerMessageImpl.java:275)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.deliverCurrentMessageIfComplete(AMQChannel.java:526)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.publishContentBody(AMQChannel.java:655)
> at
> org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveMessageContent(AMQChannel.java:2519)
> at org.apache.qpid.framing.ContentBody.process(ContentBody.java:105)
> at org.apache.qpid.codec.AMQDecoder.processFrame(AMQDecoder.java:394)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:114)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.access$000(BrokerDecoder.java:37)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:80)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:76)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:75)
> at org.apache.qpid.codec.AMQDecoder.processInput(AMQDecoder.java:370)
> at org.apache.qpid.codec.AMQDecoder.decodeBuffer(AMQDecoder.java:259)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8$2.run(AMQPConnection_0_8.java:319)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8$2.run(AMQPConnection_0_8.java:299)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8.received(AMQPConnection_0_8.java:298)
> at
> org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:138)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:465)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:45)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.processData(NonBlockingConnection.java:398)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.readAndProcessData(NonBlockingConnection.java:349)
> at
> org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.doRead(NonBlockingConnectionPlainDelegate.java:39)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:337)
> at
> org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:229)
> at
> org.apache.qpid.server.transport.NetworkConnectionScheduler.process
[jira] [Commented] (QPIDJMS-98) Investigate random failures for tests in CI
[ https://issues.apache.org/jira/browse/QPIDJMS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14712960#comment-14712960 ] ASF subversion and git services commented on QPIDJMS-98: Commit 62fba39e77b6c575c7ead755ed13faba2f0c3d8b in qpid-jms's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=62fba39 ] QPIDJMS-98: add some additional logging to get a better view on behaviour during test failure > Investigate random failures for tests in CI > --- > > Key: QPIDJMS-98 > URL: https://issues.apache.org/jira/browse/QPIDJMS-98 > Project: Qpid JMS > Issue Type: Test > Components: qpid-jms-client >Affects Versions: 0.4.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.5.0 > > > Some tests are failing randomly in CI like the Jms ClientId test and the > Netty SSL transport tests. Need to track these down and either fix the test > or the code behind it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-6711) [0-8..0-9-1] Client may send a ChannelOpen before connection establishment is complete
[
https://issues.apache.org/jira/browse/QPID-6711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-6711:
-
Attachment: repo.tar.bz2
> [0-8..0-9-1] Client may send a ChannelOpen before connection establishment
> is complete
> ---
>
> Key: QPID-6711
> URL: https://issues.apache.org/jira/browse/QPID-6711
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: qpid-java-6.0
> Environment: MacBookAir 1.7 GHz Intel Core i7
> Maximum Memory : 1,908,932,608 bytes
> Platform : JVM : Oracle Corporation version: 1.7.0_45-b18 OS : Mac OS X
> version: 10.10.4 arch: x86_64 cores: 4
>Reporter: Keith Wall
> Attachments: repo.tar.bz2
>
>
> I am seeing a sporadic issue on the legacy Qpid Client when using the
> 0-8..0-91 protocol with SSL. Occasionally, the client is seen to emit a
> ChannelOpen before the ConnectionOpenOk has been received. The Java Broker
> detects that illegal state and closes the connection.
> I have not checked if this is a regression. I am reproducing this issue
> running the Perftest profile VaryingNumberOfParticipantsSSL.js using a Java
> Broker configured with SSL using the canned test certs.
> After augmenting the Broker to log a stack trace
> AMQPConnection_0_8#assertState)
> {noformat}
> 2015-08-26 09:26:47,977 ERROR [IO-/127.0.0.1:51674]
> (o.a.q.s.p.v.AMQPConnection_0_8) - Connection is in the wrong state
> AWAIT_START_OK , expecting OPEN
> java.lang.Exception: null
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8.assertState(AMQPConnection_0_8.java:1061)
> [classes/:na]
> at
> org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8.receiveChannelOpen(AMQPConnection_0_8.java:1020)
> [classes/:na]
> at
> org.apache.qpid.framing.ChannelOpenBody.process(ChannelOpenBody.java:92)
> [classes/:na]
> at
> org.apache.qpid.codec.ServerDecoder.processMethod(ServerDecoder.java:122)
> [classes/:na]
> {noformat}
> And augmenting the Qpid Client to that IoSender and IoReceiver include the
> socket's localport:
> {noformat}
> 2015-08-26 09:26:47,972 DEBUG [Dispatcher-2-Conn-34]
> o.a.q.c.AMQProtocolHandler SEND: AMQP1109
> 2015-08-26 09:26:47,972 INFO [Dispatcher-2-Conn-34] o.a.q.c.AMQConnection
> Connection 82 now connected from /127.0.0.1:51674 to localhost/127.0.0.1:5671
> 2015-08-26 09:26:47,973 DEBUG [Dispatcher-2-Conn-34] o.a.q.c.AMQConnection
> Are we connected:true
> 2015-08-26 09:26:47,973 DEBUG [Dispatcher-2-Conn-34] o.a.q.c.AMQConnection
> Connected with ProtocolHandler Version:0-9
> 2015-08-26 09:26:47,974 DEBUG [Dispatcher-2-Conn-1]
> o.a.q.c.AMQProtocolHandler SEND: Frame channelId: 2, bodyFrame:
> [BasicAckBodyImpl: deliveryTag=81, multiple=false]
> 2015-08-26 09:26:47,974 DEBUG [Dispatcher-2-Conn-34]
> o.a.q.c.AMQProtocolHandler SEND:
> org.apache.qpid.framing.CompositeAMQDataBlock{ 0=[Frame channelId: 3,
> bodyFrame: [BasicPublishBodyImpl: ticket=0, exchange=amq.direct,
> routingKey=controllerqueue, mandatory=true, immediate=false]] 1=[Frame
> channelId: 3, bodyFrame: ContentHeaderBody{classId=60, weight=0, bodySize=0,
> properties=reply-to = null,propertyFlags = 47312,ApplicationID =
> null,ClusterID = null,UserId = guest,JMSMessageID =
> ID:448e77ea-0fde-3dd8-9133-1654cdb15fad,JMSCorrelationID =
> null,JMSDeliveryMode = 2,JMSExpiration = 0,JMSPriority = 4,JMSTimestamp =
> 1440577607974,JMSType = null}]}
> 2015-08-26 09:26:47,974 DEBUG [Dispatcher-2-Conn-34]
> o.a.q.c.AMQProtocolHandler SEND: Frame channelId: 2, bodyFrame:
> [BasicAckBodyImpl: deliveryTag=1, multiple=false]
> 2015-08-26 09:26:47,975 DEBUG [Dispatcher-2-Conn-34]
> o.a.q.c.AMQProtocolHandler SEND: Frame channelId: 1, bodyFrame:
> [ChannelOpenBody]
> 2015-08-26 09:26:47,976 DEBUG [IoRcvr-localhost/127.0.0.1:5671-51674]
> o.a.q.c.AMQProtocolHandler RECV: Frame channelId: 0, bodyFrame:
> [ConnectionStartBodyImpl: versionMajor=0, versionMinor=9,
> serverProperties={product=[LONG_STRING: qpid], version=[LONG_STRING:
> 6.0.0-SNAPSHOT], qpid.build=[LONG_STRING: Unversioned directory],
> qpid.instance_name=[LONG_STRING: Broker],
> qpid.close_when_no_route=[LONG_STRING: true],
> qpid.message_compression_supported=[LONG_STRING: true],
> qpid.confirmed_publish_supported=[LONG_STRING: true],
> qpid.virtualhost_properties_supported=[LONG_STRING: true]}, mechanisms=[80,
> 76, 65, 73, 78, 32, 67, 82, 65, 77, 45, 77, 68, 53], locales=[101, 110, 95,
> 85, 83]]
> 2015-08-26 09:26:47,977 DEBUG [IoRcvr-localhost/127.0.0.1:5671-51674]
> o.a.q.c.AMQProtocolHandler SEND: Frame channelId: 0, bodyFrame:
> [ConnectionStartOkBodyImpl: clientProperties={instance=[LONG_STRING:
> clientid], product=[LONG_STRING: qpid], version=[LONG_STRING:
> 6.0.0-SNAPSHOT], p
[jira] [Updated] (QPID-6711) [0-8..0-9-1] Client may send a ChannelOpen before connection establishment is complete
[
https://issues.apache.org/jira/browse/QPID-6711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-6711:
-
Description:
I am seeing a sporadic issue on the legacy Qpid Client when using the 0-8..0-91
protocol with SSL. Occasionally, the client is seen to emit a ChannelOpen
before the ConnectionOpenOk has been received. The Java Broker detects that
illegal state and closes the connection.
I have not checked if this is a regression. I am reproducing this issue
running the Perftest profile VaryingNumberOfParticipantsSSL.js using a Java
Broker configured with SSL using the canned test certs.
After augmenting the Broker to log a stack trace
AMQPConnection_0_8#assertState)
{noformat}
2015-08-26 09:26:47,977 ERROR [IO-/127.0.0.1:51674]
(o.a.q.s.p.v.AMQPConnection_0_8) - Connection is in the wrong state
AWAIT_START_OK , expecting OPEN
java.lang.Exception: null
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8.assertState(AMQPConnection_0_8.java:1061)
[classes/:na]
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8.receiveChannelOpen(AMQPConnection_0_8.java:1020)
[classes/:na]
at
org.apache.qpid.framing.ChannelOpenBody.process(ChannelOpenBody.java:92)
[classes/:na]
at
org.apache.qpid.codec.ServerDecoder.processMethod(ServerDecoder.java:122)
[classes/:na]
{noformat}
And augmenting the Qpid Client to that IoSender and IoReceiver include the
socket's localport:
{noformat}
2015-08-26 09:26:47,972 DEBUG [Dispatcher-2-Conn-34]
o.a.q.c.AMQProtocolHandler SEND: AMQP1109
2015-08-26 09:26:47,972 INFO [Dispatcher-2-Conn-34] o.a.q.c.AMQConnection
Connection 82 now connected from /127.0.0.1:51674 to localhost/127.0.0.1:5671
2015-08-26 09:26:47,973 DEBUG [Dispatcher-2-Conn-34] o.a.q.c.AMQConnection Are
we connected:true
2015-08-26 09:26:47,973 DEBUG [Dispatcher-2-Conn-34] o.a.q.c.AMQConnection
Connected with ProtocolHandler Version:0-9
2015-08-26 09:26:47,974 DEBUG [Dispatcher-2-Conn-1] o.a.q.c.AMQProtocolHandler
SEND: Frame channelId: 2, bodyFrame: [BasicAckBodyImpl: deliveryTag=81,
multiple=false]
2015-08-26 09:26:47,974 DEBUG [Dispatcher-2-Conn-34]
o.a.q.c.AMQProtocolHandler SEND: org.apache.qpid.framing.CompositeAMQDataBlock{
0=[Frame channelId: 3, bodyFrame: [BasicPublishBodyImpl: ticket=0,
exchange=amq.direct, routingKey=controllerqueue, mandatory=true,
immediate=false]] 1=[Frame channelId: 3, bodyFrame:
ContentHeaderBody{classId=60, weight=0, bodySize=0, properties=reply-to =
null,propertyFlags = 47312,ApplicationID = null,ClusterID = null,UserId =
guest,JMSMessageID = ID:448e77ea-0fde-3dd8-9133-1654cdb15fad,JMSCorrelationID =
null,JMSDeliveryMode = 2,JMSExpiration = 0,JMSPriority = 4,JMSTimestamp =
1440577607974,JMSType = null}]}
2015-08-26 09:26:47,974 DEBUG [Dispatcher-2-Conn-34]
o.a.q.c.AMQProtocolHandler SEND: Frame channelId: 2, bodyFrame:
[BasicAckBodyImpl: deliveryTag=1, multiple=false]
2015-08-26 09:26:47,975 DEBUG [Dispatcher-2-Conn-34]
o.a.q.c.AMQProtocolHandler SEND: Frame channelId: 1, bodyFrame:
[ChannelOpenBody]
2015-08-26 09:26:47,976 DEBUG [IoRcvr-localhost/127.0.0.1:5671-51674]
o.a.q.c.AMQProtocolHandler RECV: Frame channelId: 0, bodyFrame:
[ConnectionStartBodyImpl: versionMajor=0, versionMinor=9,
serverProperties={product=[LONG_STRING: qpid], version=[LONG_STRING:
6.0.0-SNAPSHOT], qpid.build=[LONG_STRING: Unversioned directory],
qpid.instance_name=[LONG_STRING: Broker],
qpid.close_when_no_route=[LONG_STRING: true],
qpid.message_compression_supported=[LONG_STRING: true],
qpid.confirmed_publish_supported=[LONG_STRING: true],
qpid.virtualhost_properties_supported=[LONG_STRING: true]}, mechanisms=[80, 76,
65, 73, 78, 32, 67, 82, 65, 77, 45, 77, 68, 53], locales=[101, 110, 95, 85, 83]]
2015-08-26 09:26:47,977 DEBUG [IoRcvr-localhost/127.0.0.1:5671-51674]
o.a.q.c.AMQProtocolHandler SEND: Frame channelId: 0, bodyFrame:
[ConnectionStartOkBodyImpl: clientProperties={instance=[LONG_STRING: clientid],
product=[LONG_STRING: qpid], version=[LONG_STRING: 6.0.0-SNAPSHOT],
platform=[LONG_STRING: Java(TM) SE Runtime Environment, 1.7.0_79-b15, Oracle
Corporation, x86_64, Mac OS X, 10.10.4, unknown],
qpid.client_process=[LONG_STRING: Qpid Java Client], qpid.client_pid=[INT:
1142], qpid.message_compression_supported=[LONG_STRING: false]},
mechanism=CRAM-MD5, response=null, locale=en_US]
2015-08-26 09:26:47,978 DEBUG [IoRcvr-localhost/127.0.0.1:5672-51588]
o.a.q.c.AMQProtocolHandler RECV: Frame channelId: 2, bodyFrame:
[BasicDeliverBodyImpl: consumerTag=1, deliveryTag=82, redelivered=false,
exchange=amq.direct, routingKey=controllerqueue]
2015-08-26 09:26:47,978 DEBUG [IoRcvr-localhost/127.0.0.1:5672-51588]
o.a.q.c.AMQProtocolHandler RECV: Frame channelId: 2, bodyFrame:
ContentHeaderBody{classId=60, weight=0, bodySize=0, properties=reply-to =
null,propertyFlags = 47312,ApplicationID = null,ClusterID = null,User
[jira] [Created] (QPID-6711) [0-8..0-9-1] Client may send a ChannelOpen before connection establishment is complete
Keith Wall created QPID-6711: Summary: [0-8..0-9-1] Client may send a ChannelOpen before connection establishment is complete Key: QPID-6711 URL: https://issues.apache.org/jira/browse/QPID-6711 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: qpid-java-6.0 Environment: MacBookAir 1.7 GHz Intel Core i7 Maximum Memory : 1,908,932,608 bytes Platform : JVM : Oracle Corporation version: 1.7.0_45-b18 OS : Mac OS X version: 10.10.4 arch: x86_64 cores: 4 Reporter: Keith Wall I am seeing a sporadic issue on the legacy Qpid Client when using the 0-8..0-91 protocol with SSL. Occasionally, the client is seen to emit a ChannelOpen before the ConnectionOpenOk has been received. The Java Broker detects that illegal state and closes the connection. I have not checked if this is a regression. I am reproducing this issue running the Perftest profile VaryingNumberOfParticipantsSSL.js using a Java Broker configured with SSL using the canned test certs. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
