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 [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 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.
