axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ali Sadik Kumlali <>
Subject Re: [Axis2] JMS support improvements
Date Thu, 06 Jul 2006 23:30:37 GMT
Hi Asankha,

Sorry for the late response. I was busy with:
1) Examining the listener part of the new JMS implementation
2) Discovering the security settings of the SonicMQ
3) Creating authenticated connections to the SonicMQ from Hermes[1] and Axis2
4) Preparing unit tests

I opened a JIRA issue[2] and attached my work. We may discuss all the topics step by step
over this.

BTW, it's good to know there is someone else in this space ;P

Ali Sadik Kumlali


----- Original Message ----
From: Asankha C. Perera <>
Sent: Tuesday, July 4, 2006 8:57:12 AM
Subject: Re: [Axis2] JMS support improvements

      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 and 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="" locked="false">myuser</parameter>
             <parameter name="" locked="false">mypassword</parameter>
             <parameter name="transport.jms.ConnectionFactoryJNDIName" locked="false">QueueConnectionFactory</parameter>
    - [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 
  - 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
   --------------------------------------------------------------------- To unsubscribe, e-mail: For additional commands, e-mail:

View raw message