Hi,
In last few weeks, I'm playing with two JMS implementations of Axis2
over SonicMQ and would like to share my thoughts. Many of them already
posted to the user list.
New JMS Implementation
----------------------------------------
- [New Feature] Handling connections to security enabled brokers [1]
- 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 [2])
- [New Feature] ConnectionFactory cache [3]
- 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.
- [New Feature] Connection pool [3]
- 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.
The Current JMS Implementation
-------------------------------------------------
- [Improvement] Some of the missing points I've figured out [4]
- Modules are loaded three times
- jndiName is lost
- username and password are lost
- Ambiguity and incompleteness in the code
- Configuration file is loaded many times
- There are lots of static definitions for the repository and
conf/axis2.xml
- These are found under integration module and not part of the core.
- Unclearness of the differences between connectorMap and cfMap
- Many TODO comments that indicate incomplete features
Common for both Implementation
-------------------------------------------------
- [Bug?] fireAndForget () waits for response when it comes to JMS[5]
- 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.
- [New Feature] Message driven beans as service endpoints
- That would be a great feature. JBossWS supports MDBs[6].
- [Improvement] JMS URL concept/proposal/tutorial should be
clarified/updated[7]
- There is one proposal for Axis1[8] and none for Axis2. It seems, some of
the parameters are not used in Axis2.
Regards,
Ali Sadik Kumlali
[1] http://www.mail-archive.com/[email protected]/msg15817.html
[2] http://www.mail-archive.com/[email protected]/msg15404.html
[3] http://www.mail-archive.com/axis-user%40ws.apache.org/msg15854.html
[4] http://www.mail-archive.com/[email protected]/msg15132.html
[5] http://www.mail-archive.com/[email protected]/msg15406.html
[6] http://labs.jboss.com/portal/jbossws/user-guide/en/html/jms-transport.html
[7] http://www.mail-archive.com/[email protected]/msg15257.html
[8] http://marc.theaimsgroup.com/?l=axis-dev&m=103617964921940&q=p3)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]