[ 
https://issues.apache.org/jira/browse/SYNAPSE-439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12677226#action_12677226
 ] 

Asankha C. Perera commented on SYNAPSE-439:
-------------------------------------------

Andreas, is this still an issue with the updated JMS transport?

> 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]

Reply via email to