[ http://issues.apache.org/jira/browse/AXIS2-869?page=comments#action_12419723 ]
Ali Sadik Kumlali commented on AXIS2-869: ----------------------------------------- I've digged a little bit further into the new JMS implementation. What I've found there; - JMSListener creates and maintains a connection factory cache. Throughout the operation it - Reads connection factory descriptions found in axis2.xml through TransportInDescription, - Parses the descriptions, - Creates JMSConnectionFactory instance for each connection factory, - Retrieves the connection factory from the JMS Server's JNDI tree by calling jmsConFactory.connect() and store it in JMSConnectionFactory instance for later use. - Adds the JMSConnectionFactory instance to the connectionFactories map. Factories are keyed by name. I don't think default connection factory is enough for all the outgoing needs. Actually, I don't see any difference between sending and receiving the messages. So, if a message can be retrieved from different destinations, a client should be able to send a message to different destinations. For this, if the listener needs to store connection factories, the sender also needs to it as well. My suggestions (if I'm not missing something): - The same thing can/should be done for JMSSender - Instead of putting the same code into both JMSListener and JMSSender, a more general class can be used. For example, JMSConnectionFactoryManager can be used to initialize and store factories. Then it can be accessed from both JMSSender and JMSListener. > New JMS Implementation - ConnectionFactory cache for client > ----------------------------------------------------------- > > Key: AXIS2-869 > URL: http://issues.apache.org/jira/browse/AXIS2-869 > Project: Apache Axis 2.0 (Axis2) > Type: New Feature > Components: transports > Reporter: Ali Sadik Kumlali > Priority: Minor > > I'm creating this issue regarding discussion found at > http://www.mail-archive.com/axis-dev@ws.apache.org/msg18547.html > Following is the related excerpt from the mentioned discussion: > [Ali Sadik Kumlali] > - In SonicMQ, if ConnectionFactory is retrieved from the JNDI for each > connection, very high memory usage which prevents access to admin console > occurs during high message traffic. And sometimes the server crashes. > - AFAIK, old JMS implementation uses connectors to achive this. > [Asankha] > The JMS listener focuses on listening for JMS messages - and I believe that > the optimization that one could perform on outgoing JMS is limited - as > different messages may be destined for different JMS destinations. However, I > also think that we could use the "default" connection factory (if one is > defined) for outgoing messages with a minor patch.. Will this be ok? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
