You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Robbie Gemmell (JIRA)" <ji...@apache.org> on 2017/04/20 15:01:04 UTC
[jira] [Resolved] (QPIDJMS-287) Qpid-JMS 0.20.0 client hangs when
connecting to an IBM AMQP server
[ https://issues.apache.org/jira/browse/QPIDJMS-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robbie Gemmell resolved QPIDJMS-287.
------------------------------------
Resolution: Duplicate
Duplicate of QPIDJMS-282, which is fixed in the 0.22.0 release that is currently under vote and should probably be available from tomorrow.
Note however that connections might still fail due to a server bug noted in QPIDJMS-261 around which TCP frame the AMQP header is sent in.
> Qpid-JMS 0.20.0 client hangs when connecting to an IBM AMQP server
> ------------------------------------------------------------------
>
> Key: QPIDJMS-287
> URL: https://issues.apache.org/jira/browse/QPIDJMS-287
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 0.20.0
> Reporter: Ernest Bartosevic
>
> After updating from Qpid-JMS 0.11.1 to Qpid-JMS 0.20.0 the client hangs when connecting to an IBM AMQP server. The client fails with the following time out error:
> "org.apache.qpid.jms.JmsOperationTimedOutException: Request to open resource AmqpConnection { ID:80aa31d7-b06e-4beb-a64e-d3eb33672aaa:1 } timed out"
> This problem does not happen with Qpid-JMS 0.11.1.
> As a comparison both Qpid-JMS 0.11.1 and Qpid-JMS 0.20.0 clients successfully connect to the Qpid Broker for Java.
> Qpid Broker for Java comparison with IBM AMQP server
> ----------------------------------------------------------------
> Gathered diagnostics (IBM AMQP Trace and WireShark Capture) of the test have shown a slight difference in the AMQP OPEN frame exchange.
> The Qpid Broker for Java waited for the clients OPEN frame and only then sent its own OPEN frame, which leaded to opening a connection successfully.
> On the other hand IBM's AMQP server sent the OPEN frame before it received the clients OPEN Frame, which the client completely ignored and then hung.
> This seems the only noticeable difference in the behaviours.. So seems like the Qpid-JMS 0.20.0 now accepts the servers OPEN frame only after sending its own OPEN.
> Where as Qpid-JMS 0.11.1 accepts the OPEN frame from the server first.
> My interpretation of the AMQP spec is that it does not state the order in which the OPEN frames must be exchanged (for example: it does not seem to mandate that the client
> must be first peer to send the OPEN frame).
> Section 2.4.1 states:
> "After establishing or accepting a TCP connection and sending the protocol header, each peer MUST send an open frame before sending any other frames."
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transport-v1.0-os.html#toc
> Summary of observed behaviour
> ----------------------------------------------------------------
> 1. Qpid-JMS 0.11.0 connects either way.
> ** When the server sends the OPEN frame first.
> ** When the client sends the OPEN frame first.
> 2. Qpid-JMS 0.20.0 connects only if the server lets the client send the OPEN frame first.
> Why the sudden change in behaviour of the Qpid-JMS 0.20.0 client? I would expect the newer client behave the same as it did before and continue to function
> if receiving the OPEN frame from the server before sending its own OPEN frame.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org