[
https://issues.apache.org/jira/browse/SYNAPSE-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628970#action_12628970
]
Andreas Veithen commented on SYNAPSE-439:
-----------------------------------------
Actually the situation is a bit more complicated than I thought initially
because some JMS providers (such as qpid) don't make a distinction between
queue and topic connections. With these providers it is possible to create a
QueueConnection using QueueConnectionFactory#createQueueConnection and later
cast it to a TopicConnection to create a TopicSession. The JMS transport
implicitly supports this, even if it is not obvious to see this by looking at
the code.
On the other hand it is not possible to mix queue and topic sessions. E.g. even
if qpid internally uses a single class for queue and topic sessions, it uses
AMQQueueSessionAdaptor and AMQTopicSessionAdapter wrappers to explicitly forbid
using a queue session to work with topics and vice-versa.
Therefore a single session pool is not sufficient and we would need to pool
sessions by destination type.
> JMS transport mixes JNDI names and destination names
> ----------------------------------------------------
>
> Key: SYNAPSE-439
> URL: https://issues.apache.org/jira/browse/SYNAPSE-439
> Project: Synapse
> Issue Type: Bug
> Components: Transports
> Affects Versions: 1.2
> Reporter: Andreas Veithen
> Assignee: Andreas Veithen
>
> JMSSender contains the following two instructions:
> session =
> jmsConnectionFactory.getSessionForDestination(JMSUtils.getDestination(targetAddress));
> session =
> jmsConnectionFactory.getSessionForDestination(jmsOut.getDestination().toString());
> While in the first case the lookup of the session is done using the JNDI name
> of the destination, in the second case the physical destination name is used.
> The documentation and code in JMSConnectionFactory#getSessionForDestination
> indicates that this method expects a JNDI name as argument.
> The whole principle of caching a session for each destination should be
> reviewed. Indeed:
> * A JMS session doesn't depend on the destination.
> * A client can specify destinations in the JMS Reply-To header. This means
> that the code adds a new session to the cache each time a client uses a
> reply-to destination the transport has not seen before. These sessions will
> only be freed when the transport is shut down. This is particularly bad if
> the client uses temporary queues.
> It would be better to have a pool of JMS sessions for each connection
> (factory).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
