[ https://issues.apache.org/jira/browse/CXF-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153965#comment-15153965 ]
Christian Schneider commented on CXF-6778: ------------------------------------------ I think the solution is to all to reset the destination to null. Either by a simple setter or by a special reset method. This method could then be called from the code that detects the error and reestablishs the connection. I think that should solve the problem. > 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 > > 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.3.4#6332)