-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for throwing my 2 cents out the window. i'll drop off this thread. Am glad to hear that everything has been thought thru. Good luck!
- -- dims Sanjiva Weerawarana wrote: | This is not a matter of test cases and fixing things. What we're talking | about is a radical rewrite. What you're suggesting is like saying Axis2 | should've started with test cases showing where Axis1 is broken. | | My suggestion was that we start with some core code driven around a | state machine model and built it. Why? Because at least Paul, Amila, and | I believe strongly that that's the right way to build an RM | implementation. Again, to take an Axis2 analogy- Axis2's design was | driven by the idea of using pull parsing (which was initially | implemented by Srinath and his team as AxisMora). | | Of course there's ideas in the current Sandesha code that can be used. | Frankly, however, I expect this'll be like Axis1 -> Axis2 .. there was | little (if any) code that moved over. Lots of ideas did but little code. | | Some Sandesha ideas that need to move over: abstraction layer for | storage (although that's sorta there with JDBC .. in-memory vs. on-disk | storage; and yes I'm totally against using an ORM layer here), threading | model, transaction model and so on. Most of these are known issues in | Mercury that Amila and others have started thinking thru but everyone | can surely benefit from the conversations here. | | Sanjiva. | | Davanum Srinivas wrote: | Amila, | | My 2 cents. YMMV. | | Yes, am all for starting a new RM Impl based on learning/concepts from | both existing implementations, but as we all know | such efforts fall flat in the face if no one pitches in and runs with | it. We have to take both the long view and the | short view. for sure, a new impl is going to take some time. What can | we do now with what we have is the question in my | mind. | | So let's start from the present, | #1: Can we write up test cases to illustrate broken scenarios? | #2: Is there *ANYTHING* that we can learn/incorporate into existing | sandesha code from Mercury? code or concepts? | (Basically #2 should help fix #1) | | If we can all show our faith and dedication by pitching in to come up | with a short term solution that works for all of | us, then I'd personally be more comfortable on what we could do in the | future. | | Thanks, | dims | | Jaliya Ekanayake wrote: | | Hi Amila, | | | | I did not intend to show that Mercury is bad or anything. | | As you have mentioned, "No one can write a Perfect RM implementation | in one | | step." | | | | The only reason I want to highlight was that you haven't consider the | | lessons from past. | | I participated few development cycles of RM and we have identified | the core | | requirements of buffering. | | | | Other scenarios such as breaking the channel, removing the network | cable are | | the core tests for RM. These are easy to verify and once developed | even the | | slowest implementation will be | | able to handle the requirements of the spec. I did not want to test | those to | | see if it works and I simply assume you have tested those. | | | | The problem, I tried to show you is that the single pipeline style | | architecture in which one thread perform the entire message processing | | without buffering the messages does not fit best with the | requirements of | | RM. InOnly operation is a very good example to test this, since it | has the | | minimum overhead for the RM implementation. As I have shown, with this | | minimum overhead, Mercury used all the threads in Tomcat. | | | | Hope you understand my point. | | | | You mentioned: | | So now you can understand just keeping Mercury as a dead project in a | | Sandesha2 branch won't do this. | | | | Why do we need to keep it a dead project? We can consider it as the | next | | phase of the RM implementation from Apache. As Sanjiva mentioned, we | can | | build this new version by incorporating best parts from both | approaches. | | Once convinced that it is going in the right direction, people will | jump in. | | | | Thanks, | | Jaliya | | | | | | ----- Original Message ----- | | *From:* Amila Suriarachchi <[EMAIL PROTECTED]> | | *To:* Jaliya Ekanayake <[EMAIL PROTECTED]> | | *Cc:* [EMAIL PROTECTED] ; Sanjiva Weerawarana | <[EMAIL PROTECTED]> ; | | [email protected] | | *Sent:* Wednesday, June 04, 2008 1:26 AM | | *Subject:* Re: Mercury, a new WS-RM implementation | | | | hi jaliya, | | | | Thank you very much for your comparison. | | | | As I guess you have tested the In Only Scenario in Duplex Mode. If | you just | | change the sequence to 10 to 250 this means you have use one | sequence in | | blocking mode. I'll have a more look at this scenario and see the exact | | reason. | | | | If you following the mails I have send this is exactly match what I | have | | said. No one can write a Perfect RM implementation in one step. Like | you | | have done here if Mercury can go independent releases, a lot of | people can | | report this type of issues and which finally make the project better. | | | | So now you can understand just keeping Mercury as a dead project in a | | Sandesha2 branch won't do this. | | | | If you going through those Mercury samples you can see there are | totally 12 | | scenarios. you have consider only 1 scenario. | | On the other hand just running this in the Reliable conditions does | not mean | | it is rm. So we can do following test for see the reliability. | | | | 1. Using tcp mon to break channels | | 2. Delaying the responses at the service | | 3. Put a message drop module which randomly drop packets with a | probability. | | | | Then we can go with security, MTOM etc. | | | | As a starting point can we do this kind of comparison between two. | Here I am | | not intended to start a fight between Sandesha2 and Mercury. But to | have | | comparison which ultimately benefit both. | | | | What do you think jaliya? | | | | | | On Tue, Jun 3, 2008 at 10:49 PM, Jaliya Ekanayake | <[EMAIL PROTECTED]> | | wrote: | | | |> 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. | |> | | | | Sorry If I have misunderstood you. Here I tried to explain my view | of the | | revolutionaries taking Sandesha2 as an example. So this is not | something | | that happened actually. | | | | thanks, | | Amila. | | | | | |> 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 <[EMAIL PROTECTED]> | |> *To:* [EMAIL PROTECTED] | |> *Cc:* Sanjiva Weerawarana <[EMAIL PROTECTED]> ; | |> [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. | |> | |> | | | | |> - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] |> |> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) iD8DBQFIR0YSgNg6eWEDv1kRAl/KAJ9n7IlSXcx+baVsdCMjW7drZxa3bgCcDDIK pjd86phKImGZx0Lp+uIjyrk= =3qhW -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
