[
https://issues.apache.org/jira/browse/CXF-5754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882656#comment-15882656
]
Dan Salt commented on CXF-5754:
-------------------------------
Further to Augusto's comments above (we are in the same team). The code
highlighted by [~kalarkar] does indeed appear to be the source of the issue,
and patching it to clear up the correlation map on timeouts/exceptions does
completely fix the memory leak. This same code also appears in 3.0.12, which we
are in the process of moving to (we have deployments on both 3.0.4 and 3.0.12).
I actually added code in two places in sendAndReceiveMessage:
- A catch/rethrow around the call to JMSUtil.receive(..), because it will throw
an uncaught JMSException on timeout. If the correlation Id is not null, remove
the item from the map and rethrow the exception.
- In the call to exchange.wait(jmsConfig.getReceiveTimeout()). Code added to
remove (if correlationId is not null) the entry from the map in two cases (a)
if an InterruptedException is caught, just before we throw a RuntimeException,
and (b) in the clause "if (exchange.get(CORRELATED) != Boolean.TRUE)", just
before throwing a RuntimeException.
Resulting code snip looks like:
{code:title=JMSConduit.java}
if (exchange.isSynchronous()) {
if (useSyncReceive) {
// TODO Not sure if replyToDestination is correct here
try {
javax.jms.Message replyMessage =
JMSUtil.receive(session, replyToDestination,
correlationId,
jmsConfig.getReceiveTimeout(),
jmsConfig.isPubSubNoLocal());
correlationMap.remove(correlationId);
processReplyMessage(exchange, replyMessage);
} catch (RuntimeException e) {
if (correlationId != null) {
correlationMap.remove(correlationId);
}
throw e;
}
} else {
try {
exchange.wait(jmsConfig.getReceiveTimeout());
} catch (InterruptedException e) {
if (correlationId != null) {
correlationMap.remove(correlationId);
}
throw new RuntimeException("Interrupted while
correlating", e);
}
if (exchange.get(CORRELATED) != Boolean.TRUE) {
if (correlationId != null) {
correlationMap.remove(correlationId);
}
throw new RuntimeException("Timeout receiving message
with correlationId "
+ correlationId);
}
}
}
{code}
> JMSConduit - temporary queue not beeing closed if relpyMessage is null
> (timeout)
> --------------------------------------------------------------------------------
>
> Key: CXF-5754
> URL: https://issues.apache.org/jira/browse/CXF-5754
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Affects Versions: 2.7.11
> Reporter: Philipp Hahn
> Attachments: eclipse-mem-analyzer.png,
> memory-leak-due-to-timeouts-4hrs.png
>
>
> Our implementation:
> CXF 2.7.11
> JMS Queue on TIBCO
> We have the problem, that if a timeout is raised the temporary queue is not
> been deleted.
> After code review of the JmsConduit class we have seen, that in case of a
> timeout, cxf is only raises only an RuntimeException (JmsConduit line 256)
> {code}
> javax.jms.Message replyMessage =
> jmsTemplate.receiveSelected(replyToDestination, messageSelector);
> if (replyMessage == null) {
> throw new RuntimeException("Timeout receiving message
> with correlationId " + correlationId);
> } else {
> doReplyMessage(exchange, replyMessage);
> }
> {code}
> Is this the problem why the temporary queue is not been closed in case of a
> timeout? Is there an solution for this problem?
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
