[
https://issues.apache.org/jira/browse/CXF-6778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15976448#comment-15976448
]
Grzegorz Majer commented on CXF-6778:
-------------------------------------
Now the main problem is:
{code:title=JMSConfiguration.java|borderStyle=solid}
public void resetCachedReplyDestination() {
synchronized (this) {
-- this.replyDestination = null;
++ this.replyDestinationDest = null;
}
}
{code}
The second problem is the JMSException in JMSConduit #sendExchange - it throws
exception after receiveTimeout (default 1 minute) which means that the library
doesn't work for 1 minute after restart EMS (there is a new connection but the
references do replay destination are still invalid). I think the best solution
is:
* move your changes to separate method (reseting ReplayDestination):
{code:title=JMSConduit.java|borderStyle=solid}
++ private void resetReplyDestination() {
++ this.staticReplyDestination = null;
++ jmsConfig.resetCachedReplyDestination();
++ }
{code}
* use it in 2 places:
{code:title=JMSConduit.java|borderStyle=solid}
public void sendExchange(final Exchange exchange, final Object request) {
...
} catch (JMSException e) {
// Close connection so it will be refreshed on next try
ResourceCloser.close(connection);
this.connection = null;
-- this.staticReplyDestination = null;
-- jmsConfig.resetCachedReplyDestination();
++ resetReplyDestination();
...
private Connection getConnection() throws JMSException {
...
result = JMSFactory.createConnection(jmsConfig);
result.start();
connection = result;
++ connection.setExceptionListener(new ExceptionListener() {
++ @Override
++ public void onException(JMSException exception) {
++ resetReplyDestination();
++ }
++ });
{code}
Now reseting of ReplyDestination take place ASAP and If some JMS provider
doesn't support ExceptionListener then it will reset after JMSException in
sendExchange.
> 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)
