Re: [Axis2] JMS support improvements

[Asankha C. Perera]

Hi Ali 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 week. 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 implementation. 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]) 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.     <transportReceiver name="jms" class="org.apache.axis2.transport.njms.JMSListener">         <parameter name="myQueueConnectionFactory" locked="false">             <parameter name="java.naming.factory.initial" locked="false">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>             <parameter name="java.naming.provider.url" locked="false">tcp://localhost:61616</parameter>                        <parameter name="java.naming.security.principal" locked="false">myuser</parameter>             <parameter name="java.naming.security.credentials" locked="false">mypassword</parameter>             <parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">QueueConnectionFactory</parameter>         </parameter>     </transportReceiver> - [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. 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] 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 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 are using. 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. I think the fireAndForget() should set the appropriate settings. Do you think so too? - [New Feature] Message driven beans as service endpoints - That would be a great feature. JBossWS supports MDBs[6]. I'm sure any help on such features would be very welcome by the community :-) - [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. Agreed.. will need some time though as I'm working more on Synapse right now.. again any help is most welcome asankha --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]