Return-Path: Delivered-To: apmail-ws-axis-user-archive@www.apache.org Received: (qmail 33771 invoked from network); 18 Aug 2008 14:13:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 18 Aug 2008 14:13:27 -0000 Received: (qmail 97838 invoked by uid 500); 18 Aug 2008 14:13:16 -0000 Delivered-To: apmail-ws-axis-user-archive@ws.apache.org Received: (qmail 97810 invoked by uid 500); 18 Aug 2008 14:13:16 -0000 Mailing-List: contact axis-user-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-user@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-user@ws.apache.org Received: (qmail 97799 invoked by uid 99); 18 Aug 2008 14:13:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Aug 2008 07:13:16 -0700 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of Hans.Drexler@humaninference.com designates 193.173.20.180 as permitted sender) Received: from [193.173.20.180] (HELO mail.humaninference.com) (193.173.20.180) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Aug 2008 14:12:17 +0000 Received: from MailerDaemon by mail.humaninference.com with local-bsmtp (Exim 4.63) (envelope-from ) id 1KV5QN-00073n-H7 for axis-user@ws.apache.org; Mon, 18 Aug 2008 16:09:35 +0200 Received: from [192.168.0.221] (port=53438 helo=mail.humaninference.com) by mail.humaninference.com with esmtp (Exim 4.63) (envelope-from ) id 1KV5QN-00073Z-8F for axis-user@ws.apache.org; Mon, 18 Aug 2008 16:09:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9013C.0A7B162A" Subject: RE: axis2 JMS transport support status? Date: Mon, 18 Aug 2008 16:09:00 +0200 Message-ID: In-Reply-To: <48A95844.9010601@wso2.com> Thread-Topic: axis2 JMS transport support status? Thread-Index: AckBIwsclsbvMffjQOS+3yiut8Gp5QAFcRyw References: <48A95844.9010601@wso2.com> From: "Hans Drexler" To: X-cff-LastScanner: av X-Virus-Checked: Checked by ClamAV on apache.org ------_=_NextPart_001_01C9013C.0A7B162A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thanks for the reply, Asanka =20 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. =20 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... =20 Is there a forum/repository where we can track the progress on the merging of the code bases of the axis2 and synapse projects?=20 ________________________________ From: Asankha C. Perera [mailto:asankha@wso2.com]=20 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.=20 =20 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. =20 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. =20 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 --=20 Asankha C. Perera=20 WSO2 - http://wso2.org http://esbmagic.blogspot.com ------_=_NextPart_001_01C9013C.0A7B162A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Thanks for the reply, Asanka
 
Changing axis2 1.4 ourselves is not really an option for us, = since we=20 want to use vanilla components, not modified ones. We could try to = modify the=20 JMS transport (to make it block instead of build a large queue), but we = don't=20 know all ins and outs of this (Is this desired in the case of = publish/subscribe,=20 for example?). Since the current JMS classes are going to be replaced by = the=20 Synapse code base we think it might not be worth the trouble to change = it in the=20 axis2 jms transport code.
 
We have also installed Synapse and managed to get it invoking = our=20 webservices using JMS without problems. Yet, this works differently. = Synapse=20 translates the JMS message into a HTTP SOAP message and passes that = message to=20 axis2. So, axis2 and synapse are going to share the code that manages = the=20 connection factory and incoming messages. That makes=20 sense...
 
Is there a forum/repository where we can track the progress on = the=20 merging of the code bases of the axis2 and synapse projects?=20

From: Asankha C. Perera=20 [mailto:asankha@wso2.com]
Sent: maandag 18 augustus 2008=20 13:09
To: axis-user@ws.apache.org
Subject: Re: axis2 = JMS=20 transport support status?

Hi Hans
We = have=20 implemented a connection between MQ Series 5-7 and axis2 using the = axis2 1.4=20 JMS connectivity and a point-to-point set-up. The implementation = basically=20 works, but some  questions remain.
 
As = long as we use=20 a request/response pattern in the client connecting to our service via = jms all=20 is well. In this scenario, the client generates requests at a rate not = higher=20 than it receives results.
 
But = if we split=20 the client in a separate request Sender and Response reader the = following=20 happens:
1) = The request=20 sender sends a fixed number (e.g. 10000) messages to the MQ Series = request=20 queue.
2) = Axis2=20 immediately starts eating messages out of the queue. Since the JMS = worker is=20 single threaded by nature it can handle at most 1 request at a time. = The JMS=20 listener starts queueing messages read from MQ Series at the maximum = rate it=20 can. This it can do faster than the single JMS worker can handle the=20 requests.
3) = As a result,=20 the queue inside axis2 grows until all available memory is exhausted = and then=20 it crashes with an Out Of Memory exception. All messages that were = loaded in=20 the axis2 queue but not processed by the service are = lost.
 
Would it not be=20 better if the JMS Listener would not keep a (long) queue of messages, = but=20 block instead until the previous request was finished? That would keep = the=20 memory consumption of Tomcat constant and avoids loosing messages. = Maybe=20 things are different in a Publish/Subscribe=20 scenario.
Yes, your suggestion is=20 good..
Also, in a post=20 on axis2-dev, Asanka Perera says jms transport in axis2 is deprecated. = Is this=20 true? Are there any recommendations regarding the use of jms transport = in=20 combination with axis2?
The = reason for=20 this confusion is since we developed the JMS transport (and a few other=20 transports such as File, non-blocking http/s, mail, etc) on the Apache = Synapse=20 project and checked in this code into the Axis2 SVN creating a copy.. = which was=20 not properly maintained. The Synapse version evolved and enhanced, while = the=20 Axis2 code basically was not properly maintained. We also have plans = under=20 Apache Synapse to support JTA and the new SOAP/JMS spec and many other=20 enhancements as well.. and to consolidate the two versions into one = common=20 transport developed outside both of those projects. This however, is a = few=20 months away..

asankha

--
Asankha C. Perera

WSO2 - http://wso2.org
http://esbmagic.blogspot.com

------_=_NextPart_001_01C9013C.0A7B162A--