[
https://issues.apache.org/jira/browse/QPIDJMS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238826#comment-17238826
]
Robbie Gemmell commented on QPIDJMS-520:
----------------------------------------
Some testing points to the issue being a server problem. The client sends a
session End frame, and the broker doesnt send the corresponding End frame back.
It does send heartbeats to satisfy the clients advertised idle-time. The client
awaits the End until it eventually times the close operation out after 60sec,
due to the jms.closeTimeout option default being 60000ms.
When the close timeout occurs at the client, and your code forces creation of
another session on the next loop, the client sends a new session Begin frame
using the same local channel number it had used before, since it has already
said isnt using that anymore. The server does then respond to that with a Begin
frame of its own, but using the same [remote] channel as it was already using
for the prior session it hadnt yet issued an End frame for. The client, or
rather proton-j underneath it, cant correlate this state (which is essentially
a protocol violation) as indicating the new JMS session is open, and thus keeps
waiting for it to become so, which it doesnt.
You can use the jms.requestTimeout option to also cause this subsequent session
creation to actually timeout, at which point the client will sends another End
for the channel number, and the broker does then send an End this time, again
on the same channel. This actually-even-more-broken state then manages to
unblock things, with a subsequent session creation (again, on the same channel)
then actually being able to progress.
> Exception when closing JMS sessions with a simple client. Connection blocked
> after error.
> -----------------------------------------------------------------------------------------
>
> Key: QPIDJMS-520
> URL: https://issues.apache.org/jira/browse/QPIDJMS-520
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
> Affects Versions: 0.54.0
> Reporter: Shaan Jayaratna
> Priority: Critical
> Attachments: qpid-close-timeout.zip
>
>
> Hi Dev Team,
> i wrote a small example Maven program to demonstrate the issue. It simply
> opens and closes jms sessions. On the x-th iteration the close operation
> failes with the following Exception:
> ****************************
> Exception in thread "main" org.apache.qpid.jms.JmsOperationTimedOutException:
> Timed Out Waiting for close response: AmqpSession \{
> ID:f41c6018-f5a6-4be0-a880-a3405a091e18:1:4697 }Exception in thread "main"
> org.apache.qpid.jms.JmsOperationTimedOutException: Timed Out Waiting for
> close response: AmqpSession \{ ID:f41c6018-f5a6-4be0-a880-a3405a091e18:1:4697
> } at
> org.apache.qpid.jms.provider.exceptions.ProviderOperationTimedOutException.toJMSException(ProviderOperationTimedOutException.java:39)
> at
> org.apache.qpid.jms.provider.exceptions.ProviderOperationTimedOutException.toJMSException(ProviderOperationTimedOutException.java:25)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:80)
> at
> org.apache.qpid.jms.exceptions.JmsExceptionSupport.create(JmsExceptionSupport.java:112)
> at org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:761)
> at org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:745)
> at org.apache.qpid.jms.JmsSession.doClose(JmsSession.java:306) at
> org.apache.qpid.jms.JmsSession.close(JmsSession.java:292) at
> example.OpenClose.main(OpenClose.java:31)
> ****************************
> If i catch the exception and ignore it, than the program will hang, when it
> tries to create another session on the same connection.
> Is this an intended behaviour? How should i close the session the proper way?
> I used:
> RabbitMq 3.8.9 with only one Plugin: rabbitmq_amqp1_0
> ->Erlang 23.1
> Qpid 0.54.0
> ->Java 1.8
> Kind Regards
> Shaan
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
