You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Hans Drexler <Ha...@HumanInference.com> on 2008/08/18 11:24:11 UTC
axis2 JMS transport support status?
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.
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?
Hans Drexler
Application Architect
<http://www.humaninference.com/images/hi_logo.gif>
Utrechtseweg 310
P.O. Box 3047
NL-6802 DA Arnhem
The Netherlands
Phone +31 (0)26 355 06 55
Fax +31 (0)26 355 06 66
Hans.Drexler@HumanInference.com
<ma...@HumanInference.com>
http://www.humaninference.com <http://www.humaninference.com/>
Human Inference B.V. - Chamber of Commerce NL - 09106800
The information contained in this communication is confidential and is
intended solely for the person and/or entity addressed above. If you are
not an intended recipient you are hereby notified that the content of
this message may not be disclosed, copied or distributed to any other
party than the addressee. Human Inference does not guarantee that this
communication is free of viruses or that other parties than the intended
recipient will not intercept this communication. Human Inference assumes
no liability for the proper and complete transmission of the information
contained in this communication or any delay in the receipt of this
communication by the addressee.
Re: axis2 JMS transport support status?
Posted by "Asankha C. Perera" <as...@wso2.com>.
Hi Hans
> 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
> code.
Yes
> 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 sense...
>
> Is there a forum/repository where we can track the progress on the
> merging of the code bases of the axis2 and synapse projects?
Not yet.. we have been busy lately with other defects and enhancements
and unfortunately moving transports out into another project lies with
lower priority right now.. and thus my rough estimate of a few months
before we could get things in place and sorted out clearly..
asankha
--
Asankha C. Perera
WSO2 - http://wso2.org
http://esbmagic.blogspot.com
RE: axis2 JMS transport support status?
Posted by Hans Drexler <Ha...@HumanInference.com>.
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
code.
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
sense...
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 [mailto:asankha@wso2.com]
Sent: maandag 18 augustus 2008 13:09
To: axis-user@ws.apache.org
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
away..
asankha
--
Asankha C. Perera
WSO2 - http://wso2.org
http://esbmagic.blogspot.com
Re: axis2 JMS transport support status?
Posted by "Asankha C. Perera" <as...@wso2.com>.
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
away..
asankha
--
Asankha C. Perera
WSO2 - http://wso2.org
http://esbmagic.blogspot.com
Re: axis2 JMS transport support status?
Posted by Anthony Bull <an...@bcsoft.co.nz>.
Hans, I'm using JMS for Axis 2 with WebSphere MQ 6.0.2 in production and
found some severe limitations with the Axis 2 implementation also -
whoever wrote the actual Axis 2 driver has only implemented the bare
basics of JMS, and it hasn't been tested with WebSphere at all.
I'm using it over publish subscribe and had to switch the transport to
perform explicit message acknowledgement so that it didn't lose messages
and so that it would work with durable subscriptions. I also added
durable subscription support so that if Axis 2 is down, it gets all the
missed messages when it reconnects. Additionally the JMS Sender
transport class has memory leaks where it creates a new JNDI context
with every message sent and then never cleans it up, causing the actual
MQ server to eventually fall over or stop accepting connections (meaning
a server reboot).
Also a major issue is that Axis 2 does not handle JMS errors, such as
the MQ server or network connections being unavailable. If this happens
at all, you need to restart your Axis 2 once the MQ becomes visible again.
I've fixed up a lot of these problems myself, except for the last one.
If you're interested, check them out at:
http://thejavamonkey.blogspot.com/2008/08/modding-axis-2-durable-subscriptions.html
http://thejavamonkey.blogspot.com/2008/08/modding-axis-2-jms-transportweb-sphere.html
I'm not sure if they'll fix your loading issue or not, but it would be
possible to also mod the JMS transport to behave differently under your
load problems also.
Hans Drexler wrote:
> 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.
>
> 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?
>
>
> Hans Drexler
> Application Architect
>
>
>
> Utrechtseweg 310
> P.O. Box 3047
> NL-6802 DA Arnhem
> The Netherlands
>
> Phone +31 (0)26 355 06 55
> Fax +31 (0)26 355 06 66
>
>
> Hans.Drexler@HumanInference.com <ma...@HumanInference.com>
> http://www.humaninference.com <http://www.humaninference.com/>
>
>
>
> Human Inference B.V. - Chamber of Commerce NL - 09106800
>
> The information contained in this communication is confidential and is
> intended solely for the person and/or entity addressed above. If you
> are not an intended recipient you are hereby notified that the content
> of this message may not be disclosed, copied or distributed to any
> other party than the addressee. Human Inference does not guarantee
> that this communication is free of viruses or that other parties than
> the intended recipient will not intercept this communication. Human
> Inference assumes no liability for the proper and complete
> transmission of the information contained in this communication or any
> delay in the receipt of this communication by the addressee.
>
>
--
Anthony
-------------------------------------
Anthony Bull
Senior Developer
Black Coffee Software Ltd
PO Box 10-192 The Terrace
Wellington, New Zealand
anthony.bull@bcsoft.co.nz
Ph +64 4 472 8818
Fax +64 4 472 8811
-------------------------------------
www.bcsoft.co.nz
---------------------------------------------------------------
This email may contain confidential or privileged information,
and is intended for use only by the addressee, or addressees.
If you are not the intended recipient please advise the sender
immediately and do not copy, use or disclose the contents to
any other person or organisation.
Black Coffee Software Ltd accepts no responsibility for viruses
received with this email, or to any changes made to the original
content. Any views or opinions expressed in this email may be
personal to the sender and are not necessarily those of Black
Coffee Software Ltd.
---------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org