I wrote the new JMS implementation, but please note that it has not
been made the default Axis2 JMS implementation yet.. As I come from the
Synapse background, my main concerns were to be able to listen on
multiple JMS destinations (probably using different JMS servers) by
different services. I really appreciate your feedback and apologize for
the delay in replying to this email thread as I was at ApacheCon last
So.. as I guess you are not alone anymore in the JMS space.. can we
take things one by one and get them resolved? Nothing would make me
happier than to also see you get involved in fixing some of these
issues you have discovered with your suggested resolutions :-) I will
answer the following questions from the new JMS implementation
perspective as I do not have much experience with the current
The new JMS implementation allows you to define one or more connection
factories that you could listen on. You can provide the user name and
password to be used to get the context through the
java.naming.security.principal and java.naming.security.credentials
properties set on the connection factory. I believe that the
javax.jms.ConnectionFactory.createConnection() now uses the above, as
the default user identity.
New JMS Implementation
- [New Feature] Handling connections to security enabled brokers 
- There is no support for authenticated connections. But in real life;
- Each connection may require username and password
- Each binding/broker(transport.jms.ConnectionFactoryJNDIName) may
require a different username & password
- There is a need for a place to store connection username & password
(probably within axis2.xml )
<parameter name="myQueueConnectionFactory" locked="false">
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?
- [New Feature] ConnectionFactory cache 
- 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
- AFAIK, old JMS implementation uses connectors to achive this.
The new code does not go into vendor specifics.. hence if a vendor does
have optimizations, they will be used through the standard JMS code we
- [New Feature] Connection pool 
- I'm not 100% sure here. Caching ConnectionFactory would be suffient if
vendor specific ConnectionFactory internally supports connection pool.
Or, perhaps, a ConnectionPool which internally holds connections
and uses ConnectionFactory cache may be written.
I think the fireAndForget() should set the appropriate settings. Do you
think so too?
Common for both Implementation
- [Bug?] fireAndForget () waits for response when it comes to JMS
- In JMSSender.invoke(), there is waitForResponse variable that is set
according to the separate channel use. Because of this, I need to
pass true to options.setUseSeparateListener() before calling
fireAndForget (). Does it logically correct? I mean, don't we expect
fireAndForget() to be used for one-way messaging? I think fireAndForget()
should be irrelevant to the response message and so the listener.
I'm sure any help on such features would be very welcome by the
- [New Feature] Message driven beans as service endpoints
- That would be a great feature. JBossWS supports MDBs.
Agreed.. will need some time though as I'm working more on Synapse
right now.. again any help is most welcome
- [Improvement] JMS URL concept/proposal/tutorial should be clarified/updated
- There is one proposal for Axis1 and none for Axis2. It seems, some of
the parameters are not used in Axis2.