I gave a try to compare the performance of Mercury and Sandesha2. I should say, that I am bit skeptical of the performance of the Mercury due to its state maintenance. What I believe is that the RM is a heavy duty module which needs to alter the message routing inside the axis2. So IMHO, a queuing strategy is a must.
So here is what I did. I deployed Axis2(version 1.4) in Tomcat 5.5.26. Then I deployed Mercury in Axis2. The details of the machines I used ------------------------------------------------------------------------------------ Server : Dual Processor (Intel Cloverton quad core) machine with 2.3GHz and 8GB of memory. Client : Intel M Processor 1.6 GHz, 1 GB of memory. (laptop) ------------------------------------------------------------------------------------ I thought of comparing the InOnly operation (simple Ping operation) to see how it performs. Therefore, I use the org.wso2.mercury.sample1.client.InOnlySample and check if it works fine. Everything worked perfectly fine! Next I did a simple modification to the for loop so that it sends 250 messages for the RM sequence instead of 10. I got the following error at the server. "Jun 3, 2008 12:38:44 PM org.apache.tomcat.util.threads.ThreadPool logFull SEVERE: All threads (150) are currently busy, waiting. Increase maxThreads (150) or check the servlet status" Then I performed a similar test for Sandesha2. This time, I use Sandesha 2 (version 1.3) and same Axis2 in Tomcat server. I use the sandesha2.samples.userguide.AsyncPingClient. I used that client in 4 threads (4 sequences) each thread sending 250 messages(total 1000) messages, and still it worked fine. IMO the reason for this is that Mercury is trying to perform the RM operations without buffering the messages and hence block all the threads. As I have mentioned earlier, RM requirements do not suite well for a single pipeline style operation, where a single thread works till the end of the invocation, specially the INORDER delivery assurance require us to block threads. Therefore, it seems like, Mercury needs some more work in this area. So, Amila, what you need is a set of good comparisons validating the Mercury effort. Till then, I am +1 for letting Mercury to be in a separate branch of Sandesha under Apache. I also would like to clarify the following from your post. "For an example If I come up with a Sandasha2 improvement which community does not agree at first time" Is this something you assume or something that happened actually? Please let us know. Thanks, Jaliya I have some clarifications regarding your post. You mentioned the following "For an example If I come up with a Sandasha2 improvement which community does not agree at first time" So, is it something you think would have happen or something that actually happend? ----- Original Message ----- From: Amila Suriarachchi To: [EMAIL PROTECTED] Cc: Sanjiva Weerawarana ; [email protected] Sent: Tuesday, June 03, 2008 7:35 AM Subject: Re: Mercury, a new WS-RM implementation On Tue, Jun 3, 2008 at 3:05 PM, ant elder <[EMAIL PROTECTED]> wrote: On Tue, Jun 3, 2008 at 10:10 AM, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: ant elder wrote: While things are as they are I do think things like Mercury announcements should be kept off the Apache mailing lists, so no more posts like: http://apache.markmail.org/message/ounhpi54rx543vqw Why? Who's rules are you trying to enforce with that? Mercury is an RM module for Axis2 and its open source and under Apache license. Feel free to ignore it but there's nothing wrong with that email. There are no "rules" about it, but I don't think its going to help things. Any revolutionary rewrite like this by a subset of the community is going to make an uncomfortable situation. It seems like everyone agrees ideally this will end up again with one RM module being developed at Apache in the WS project with all the existing community behind it. So with that aim it would help if everyone could try to be sensitive. Maybe as a start everyone could read the "rules for revolutionaries" - http://incubator.apache.org/learn/rules-for-revolutionaries.html As I understood this revolutionary talks about doing a substantial improvement to an existing code base. For an example If I come up with a Sandasha2 improvement which community does not agree at first time, I can create a branch of existing Sandesha2 code base and implement my improvement. Then I can ask from the community to review it and merge it to the main trunk. But here the case is different. Mercury is completely different from Sandesha2. It is not an improvement to Sandesha2. AFAIK Apache in general does not have a policy to handle this kind of situations. For an example If I came up with this idea when I wrote the Simulator People would have said This is not a real implementation and a real implementation would be more complex. On the other hand If I put a complete implementation then people would have said This has happened without telling to the community. So it becomes a chicken and egg problem. IMHO the correct solution is to keep both implementations and Let people to contribute/use to whatever they prefer. And when the time goes we can decide whether to go ahead with Sandesha2, Mercury or both. thanks, Amila. ...ant -- Amila Suriarachchi, WSO2 Inc.
