synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (JIRA)" <>
Subject [jira] Commented: (SYNAPSE-439) JMS transport mixes JNDI names and destination names
Date Sun, 07 Sep 2008 13:33:46 GMT


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

> JMS transport mixes JNDI names and destination names
> ----------------------------------------------------
>                 Key: SYNAPSE-439
>                 URL:
>             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:
For additional commands, e-mail:

View raw message