You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Andreas Veithen (JIRA)" <ji...@apache.org> on 2009/02/27 14:43:14 UTC

[jira] Resolved: (SYNAPSE-439) JMS transport mixes JNDI names and destination names

     [ https://issues.apache.org/jira/browse/SYNAPSE-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andreas Veithen resolved SYNAPSE-439.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 1.3

No, I think this issue should have been solved by the changes in the 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
>             Fix For: 1.3
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org