axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hans Drexler" <>
Subject RE: axis2 JMS transport support status?
Date Mon, 18 Aug 2008 14:09:00 GMT
Thanks for the reply, Asanka
Changing axis2 1.4 ourselves is not really an option for us, since we
want to use vanilla components, not modified ones. We could try to
modify the JMS transport (to make it block instead of build a large
queue), but we don't know all ins and outs of this (Is this desired in
the case of publish/subscribe, for example?). Since the current JMS
classes are going to be replaced by the Synapse code base we think it
might not be worth the trouble to change it in the axis2 jms transport
We have also installed Synapse and managed to get it invoking our
webservices using JMS without problems. Yet, this works differently.
Synapse translates the JMS message into a HTTP SOAP message and passes
that message to axis2. So, axis2 and synapse are going to share the code
that manages the connection factory and incoming messages. That makes
Is there a forum/repository where we can track the progress on the
merging of the code bases of the axis2 and synapse projects? 


From: Asankha C. Perera [] 
Sent: maandag 18 augustus 2008 13:09
Subject: Re: axis2 JMS transport support status?

Hi Hans

	We have implemented a connection between MQ Series 5-7 and axis2
using the axis2 1.4 JMS connectivity and a point-to-point set-up. The
implementation basically works, but some  questions remain. 
	As long as we use a request/response pattern in the client
connecting to our service via jms all is well. In this scenario, the
client generates requests at a rate not higher than it receives results.
	But if we split the client in a separate request Sender and
Response reader the following happens:
	1) The request sender sends a fixed number (e.g. 10000) messages
to the MQ Series request queue.
	2) Axis2 immediately starts eating messages out of the queue.
Since the JMS worker is single threaded by nature it can handle at most
1 request at a time. The JMS listener starts queueing messages read from
MQ Series at the maximum rate it can. This it can do faster than the
single JMS worker can handle the requests.
	3) As a result, the queue inside axis2 grows until all available
memory is exhausted and then it crashes with an Out Of Memory exception.
All messages that were loaded in the axis2 queue but not processed by
the service are lost.
	Would it not be better if the JMS Listener would not keep a
(long) queue of messages, but block instead until the previous request
was finished? That would keep the memory consumption of Tomcat constant
and avoids loosing messages. Maybe things are different in a
Publish/Subscribe scenario.

Yes, your suggestion is good..

	Also, in a post on axis2-dev, Asanka Perera says jms transport
in axis2 is deprecated. Is this true? Are there any recommendations
regarding the use of jms transport in combination with axis2?

The reason for this confusion is since we developed the JMS transport
(and a few other transports such as File, non-blocking http/s, mail,
etc) on the Apache Synapse project and checked in this code into the
Axis2 SVN creating a copy.. which was not properly maintained. The
Synapse version evolved and enhanced, while the Axis2 code basically was
not properly maintained. We also have plans under Apache Synapse to
support JTA and the new SOAP/JMS spec and many other enhancements as
well.. and to consolidate the two versions into one common transport
developed outside both of those projects. This however, is a few months


Asankha C. Perera 

WSO2 -

View raw message