axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ali Sadik Kumlali (JIRA)" <>
Subject [jira] Commented: (AXIS2-869) New JMS Implementation - ConnectionFactory cache for client
Date Fri, 07 Jul 2006 14:30:31 GMT
    [ ] 

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:
>      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
> 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:
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message