qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (QPIDJMS-287) Qpid-JMS 0.20.0 client hangs when connecting to an IBM AMQP server
Date Thu, 20 Apr 2017 15:01:04 GMT

     [ 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


Mime
View raw message