axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <>
Subject Re: [Axis2] JMS support improvements
Date Tue, 04 Jul 2006 05:57:12 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
Hi Ali<br>
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. <br>
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
  <pre wrap="">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 &amp; password
    - There is a need for a place to store connection username &amp; 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&nbsp;
javax.jms.ConnectionFactory.createConnection() now uses the above, as
the default user identity.<br>
&nbsp;&nbsp;&nbsp; &lt;transportReceiver name="jms"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;parameter name="myQueueConnectionFactory"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;parameter name="java.naming.factory.initial"
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&lt;parameter name="java.naming.provider.url"
&nbsp;&nbsp;&nbsp; <br>
<i>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
</i>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;/parameter&gt;<br>
&nbsp;&nbsp;&nbsp; &lt;/transportReceiver&gt;<br>
  <pre wrap="">- [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?<br>
  <pre wrap="">- [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.</pre>
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.<br>
  <pre wrap="">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.</pre>
I think the fireAndForget() should set the appropriate settings. Do you
think so too?<br>
  <pre wrap=""> 
  - [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 :-)<br>
  <pre wrap=""> - [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.</pre>
Agreed.. will need some time though as I'm working more on Synapse
right now.. again any help is most welcome<br>

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

View raw message