Ernest Bartosevic created QPIDJMS-287:
-----------------------------------------

             Summary: 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-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Reply via email to