[jira] [Comment Edited] (CXF-6778) Invalid replyDestination is cached after jms connection has been reset

["Prithviraj Patil (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CXF-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16064887#comment-16064887 ] 

Prithviraj Patil edited comment on CXF-6778 at 6/27/17 2:16 PM:
----------------------------------------------------------------

We are facing similar issues with CXF 2.7.17 (which is bundled inside JBOSS EAP 6.4). As CXF 3.2.0 is not yet released, we can not migrate to 3.2.0 release yet.

Is it possible to resolve this issue by setting connection expiry time or by some other configuration way? We are using IBM WMQ resource adapter as messaging and queuing middleware.

Bdw, we are setting following timeouts using JMS config:

{{final JMSConduit jmsConduit = (JMSConduit) conduit;
final JMSConfiguration jmsConfig = jmsConduit.getJmsConfig();
jmsConfig.setServerReceiveTimeout(timeout);
jmsConfig.setReceiveTimeout(timeout);
jmsConfig.setTimeToLive(ttl);}}

Please let us know, if you require more information.
Thanks,


was (Author: prithvipatil):
We are facing similar issues with CXF 2.7.17 (which is bundled inside JBOSS EAP 6.4). As CXF 3.2.0 is not yet released, we can not migrate to 3.2.0 release yet.

Is it possible to resolve this issue by setting connection expiry time or by some other configuration way? We are using IBM WMQ resource adapter as messaging and queuing middleware.

Please let us know, if you require more information.
Thanks,

> Invalid replyDestination is cached after jms connection has been reset
> ----------------------------------------------------------------------
>
>                 Key: CXF-6778
>                 URL: https://issues.apache.org/jira/browse/CXF-6778
>             Project: CXF
>          Issue Type: Bug
>          Components: JMS, Transports
>    Affects Versions: 3.1.5, 3.0.8
>            Reporter: Jerome Waibel
>            Assignee: Christian Schneider
>            Priority: Critical
>             Fix For: 3.2.0
>
>
> We have a spring boot application that is doing SOAP over JMS with a tibco backend.
> Whenever the JMS connection is reset our application fails to receive the answer for the SOA request until the application server is restarted.
> From the logs we see that re-establishing the jms connection is working fine:
> {quote}
> 2016-02-05 12:59:03.458  WARN 5662 --- [TIBCO EMS TCPLink Reader (Server-608470)] o.s.j.c.CachingConnectionFactory         : Encountered a JMSException - resetting the underlying JMS Connection
> javax.jms.JMSException: Connection has been terminated
>         at com.tibco.tibjms.Tibjmsx.buildException(Tibjmsx.java:509)
>         at com.tibco.tibjms.TibjmsConnection._invokeOnExceptionCallback(TibjmsConnection.java:2025)
>         at com.tibco.tibjms.TibjmsConnection._onDisconnected(TibjmsConnection.java:2394)
>         at com.tibco.tibjms.TibjmsConnection$ServerLinkEventHandler.onEventDisconnected(TibjmsConnection.java:349)
>          at com.tibco.tibjms.TibjmsxLinkTcp$LinkReader.work(TibjmsxLinkTcp.java:330)
>          at com.tibco.tibjms.TibjmsxLinkTcp$LinkReader.run(TibjmsxLinkTcp.java:259)
> 2016-02-05 12:59:04.701  INFO 5662 --- [ajp-bio-18009-exec-1] o.s.j.c.CachingConnectionFactory: Established shared JMS Connection: QueueConnection[ClientId=null Connected=tcp://ems2-k:12004, URL=tcp://ems2-k:12004]
> {quote}
> After the connection has been reset when our application does the next SOAP call sending the request works fine, but when CXF waits for the reply the following exception occurs:
> {quote}
> javax.xml.ws.soap.SOAPFaultException: Timeout receiving message with correlationId b02ad4683421442db439b54797fcc7350000000000000003
> at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:161)
> {quote}
> Debugging shows that the problem seems to be located in _public Destination getReplyDestination(Session session) in org.apache.cxf.transport.jms.JMSConfiguration_. There a Destination object for receiving the answer is created once and cached forever. There is no way this cached destination will ever be dropped and recreated. This destination object (implemented by a temporary queue in our case) contains a reference to the jms connection. So after a reset of the connection it still contains the old, invalid jms connection object. This is why after a connection reset it is impossible to receive any more replies.
> Using a debugger, setting a breakpoint in this method and manually setting replyDestinationDest to null forces this method to recreate the temporary queue. After that receiving replies is working again after a jms connection reset. This is of course not possible for our live environment, there all servers have to be restarted after a jms connection reset.
> This behaviour was introduced in CXF3. Before upgrading we used CXF 2 where the temporary response queue seems not to be cached but created and deleted for every request. With CXF 2 our application worked fine when the jms connection was reset.
> Steps for reproducing this error (sorry, no example project yet):
> * Have a SOAP server
> * Have a SOAP client using Spring so that CachingConnectionFactory will do a proper connection reset
> * Have a SOAP over JMS broker
> * Make one successful client request so that the replyDestinationDest gets created and cached.
> * Force a JMS connection reset (e.g. drop connection from the broker admin console)
> * Try another client request. The client will reconnect but re-use the old replyDestinationDest and never be able to receive the reply again.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)