Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Wed, 19 Apr 2017 20:58:41 +0000 (UTC)
From: "Grzegorz Majer (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12939474.1455622235000.322980.1492635521755@Atlassian.JIRA>
In-Reply-To: <JIRA.12939474.1455622235000@Atlassian.JIRA>
References: <JIRA.12939474.1455622235000@Atlassian.JIRA> <JIRA.12939474.1455622235149@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CXF-6778) Invalid replyDestination is cached
 after jms connection has been reset
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 19 Apr 2017 20:58:47 -0000


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

Grzegorz Majer commented on CXF-6778:
-------------------------------------

It doesn't fix the problem. As I described earlier apart from reset JMSConfiguration#replyDestinationDest, you have to reset also 
field staticReplyDestination in org.apache.cxf.transport.jms.JMSConduit. 
The problem is here:
    private void setupReplyDestination(Session session) throws JMSException {
        if (staticReplyDestination == null) {
            synchronized (this) {
                if (staticReplyDestination == null) {
                    staticReplyDestination = jmsConfig.getReplyDestination(session);
   ...
The easiest way to do it is moving your ExceptionListener from JMSFactory to JMSConduit where you have direct access to the field and where you must set staticReplyDestination = null.

> 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.3.15#6346)