[
https://issues.apache.org/jira/browse/CXF-5754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549013#comment-15549013
]
ARSLAN ALI commented on CXF-5754:
---------------------------------
on the same issue we are using cxf 3.0.5 and once TIBCO return null cxf class
JMSUtil throws Runtime exception and JMSConduit will not clear the
correlationMap. This causes a memory leak.
public static Message receive(Session session,
Destination replyToDestination,
String correlationId,
long receiveTimeout,
boolean pubSubNoLocal) {
ResourceCloser closer = new ResourceCloser();
try {
String messageSelector = correlationId == null ? null :
"JMSCorrelationID = '" + correlationId + "'";
javax.jms.Message replyMessage = consumer.receive(receiveTimeout);
if (replyMessage == null) {
throw new RuntimeException("Timeout receiving message with
correlationId "
+ correlationId);
}
in JMSConduit correlationMap.remove(correlationId); will not get called.
> 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
>
> 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.4#6332)