You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by David Illsley <da...@gmail.com> on 2008/06/03 09:59:53 UTC
Re: Mercury, a new WS-RM implementation
Hi Glen,
This is a difficult situation, and one that's made more difficult by
the amount of code that already exists.
I would take exception to you saying that Sandesha2 doesn't support
secure, asynchronous scenarios. It does, and I've seen the results of
interop testing with WCF (for example) with those scenarios. I
understand that there have been problems using Sandesha2 with SMTP and
the RM 1.0 replay model - both underspecified areas, so to be honest
that's not a surprise. If the problems extend beyond a problem in a
particular customer environment, I'd really like to know what they are
so we can fix Sandesha2.
That said, I'd agree that Sandesha2 is complex :-) and that we'll need
a follow project at some point. Right now, I think that Mercury is
heading the wrong direction to be that follow on project - It's based
on the requirements of a single customer using esoteric and back level
specifications, and takes, in my opinion, many of the same design
decisions from Sandesha2 which resulted in the complexity of
Sandesha2. As I've said before, I think we're still a while away from
having enough shared production experience to get the building blocks
of the next generation of Sandesha right.
I do recognise that Mercury is a necessary tactical solution for WSO2
to satisfy a particular customer, and I'm not criticising that move -
it's probably the right move for WSO2 as a business, I just don't
think it's the right move for Apache.
That said, no-one has objected to a revolutionary branch, but clearly
that does place limits on what/how WSO2 can release... not entirely
sure what the best options for that are... perhaps repackaging before
release... eclipse would probably make that easy enough.
I'm more than happy to continue this discussion on list or have an IRC
or telecon if more of a real-time discussion is needed.
David
On Sat, May 31, 2008 at 4:50 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> (sorry for the late response)
>
> Hi Sanjiva, all:
>
> Sanjiva Weerawarana wrote:
>>
>> David, just to be clear .. the only reason we went down a new impl path is
>> because we had SUCH a terrible time getting Sandesha to interop over SMTP,
>> which is a crucial requirement for this customer. SecureRM over SMTP was
>> just not working out :(.
>
> While that may be true, I'm disappointed that the work moved so far
> forward before being brought to the Sandesha community, and I would
> *really* like to find some navigable path that brings us eventually to a
> single implementation of RM-over-Axis2, in Apache. Having two
> implementations, whether both in Apache or elsewhere, does two things,
> neither of which are good - 1) it confuses the user base 2) it
> splits the cycles of the active development community, when everyone
> could be cooperating.
>
> As I see it right now we have two implementations, both of which have
> flaws. Sandesha is extremely complex, and clearly can't handle
> some critical secure and asychronous scenarios. Mercury is new, untested
> (in the real world), and has potential architectural issues as mentioned by
> David (lack of 1.1, lots of synchronized methods, etc). The quicker we can
> get to the point where we've settled on one, the better able we'll be to fix
> the flaws.
>
> So here's a strawman for what we *might* do here, with at least one open
> issue:
>
> * Get the Mercury code over to the Sandesha SVN, in a revolutionary
> branch exactly as dims suggested, and continue all work there for now, so
> that the Sandesha team can a) see the work, and b) contribute to it if they
> desire.
>
> * WSO2 clearly needs to be able to continue doing releases of this code, so
> I guess we should leave the package names org.wso2... for now. This means
> a) org.wso2 code in Apache svn (I think there's precedent for that kind of
> thing), and b) releasing stuff based on code in an unofficial branch.
>
> --- OPEN ISSUE - I *think* this is ok, but we need to confirm (should we ask
> legal-discuss?). We wouldn't be doing *Apache* releases, mind you - we'd
> just be taking a copy of the code from the Apache SVN and
> releasing/supporting it under the auspices of WSO2.
>
> * Without being presumptive, we continue work on Mercury with the hope that
> the Sandesha community will eventually accept it as Sandesha.next (whatever
> it's called, we all move to working on that code). This involves
> conversations and almost certainly some refactoring, but if everyone
> involved starts off with the goal of a single implementation and remains
> open to input, we can hopefully get there - maybe this looks like Mercury
> with some fixes/changes, and maybe this looks like Sandesha with some
> fixes/changes, I don't know yet.
>
> * Eventually either a) we EOL Sandesha and move to Sandesha3/Mercury as the
> Apache-provided RM implementation over Axis2, or b) we find we're at
> loggerheads and can't come to a consensus, at which point we declare defeat
> and continue with two separate implementations.
>
> Dealing with forks/merges like this is never an easy process, but the
> results can be well worth it for both the developers and the users. I'd
> like to try it. What do you think? If we don't have real commitment on
> both sides to get it happening, it's not going to work, so please consider
> this when replying.
>
> Thanks,
> --Glen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by Deepal jayasinghe <de...@gmail.com>.
> 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.
I also think it is ok to send a note about Axis2 related products
releases on axis-dev and axis-user list. We should encourage that . And
this is not the first time something like that happen [1] ;-)
[1] : http://marc.info/?l=axis-user&m=118730248328664&w=2
-Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by David Illsley <da...@gmail.com>.
+1
David
On Tue, Jun 3, 2008 at 10:10 AM, Sanjiva Weerawarana
<sa...@opensource.lk> 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.
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by Deepal jayasinghe <de...@gmail.com>.
Hi Ant,
>
>
>
> There are no "rules" about it, but I don't think its going to help
> things.
Well yes , if the people are happy with Sandesha then they can use that
, if they are not happy then they can try the new implementation and
deiced what good for them. So if the new one is good then we can figure
out making that as the new sandesha else we can throw that away. Simple
as that.
> Any revolutionary rewrite like this by a subset of the community is
> going to make an uncomfortable situation.
If you look back the Axis2 history then you can make the same argument
for Axis2 too. When we start Axis2 everyone from Axis1 did not jump and
contribute it was also a subset of people. But I remember all most all
the others contribute for that giving there past experiences and various
opinions (Not at the code level). So I think exact same thing happening
here as well.
Thank you!
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by Amila Suriarachchi <am...@gmail.com>.
On Thu, Jun 5, 2008 at 10:30 AM, Jaliya Ekanayake <jn...@gmail.com>
wrote:
> Hi Amila
>
> From my code walk through, I found that Mercury uses the thread pool from
> Axis2.
> So it cannot have this behavior unless the threads are waiting.
>
Good point. But at least it would be using the maximum number of threads.
>
> I tried to interoperate Mercury and Sandesha and it did not work.
>
>
As I told you this needs more investigation. I'll have a look on this.
thanks,
Amila.
> Thanks,
> Jaliya
>
> ----- Original Message -----
> *From:* Amila Suriarachchi <am...@gmail.com>
> *To:* sandesha-dev@ws.apache.org
> *Sent:* Thursday, June 05, 2008 12:26 AM
> *Subject:* Re: Mercury, a new WS-RM implementation
>
> hi jaliya
>
> On Wed, Jun 4, 2008 at 10:36 PM, Jaliya Ekanayake <jn...@gmail.com>
> wrote:
>
>> I am open to sharing my knowledge in any means possible. That is the
>> sole reason I did this comparision instead of discussion without any
>> results.
>>
>
>>
>> So the way I tested is as follows.
>>
>> As I have mentioned, i deployed Mercury in Axis2 which is deployed in
>> Tomcat and tested it with Mercury samples.
>> Then I deployed Sandesha in Axis2 which is deployed in Tomcat and tested
>> it using Sandesha2 samples.
>>
>
> I am not sure about how Sandesha2 works. But this is how Mercury works.
>
> In In only cases The client thread put this message to the RMSSequence
> (which buffers this message) and immediately returns. Then RMSSequenceWorker
> (an independent thread) start working on this and send these messages using
> a separate thread for each message (MessageWorker). So if we send 1000
> messages (using any number of threads at client level) which basically
> creates 1000 threads to send the messages.
> So here effectively you try to access a Server have 150 maxthreads with
> 1000 simultaneous threads.
>
> Here I agree with you that Mercury needs a Window Approach as with TCP to
> limit the number of messages with out flooding the network at once.
>
> But if sandesha2 uses only 4 threads then it does not flood the server as
> such.
>
> If this is the case Mercury should be able to use that performance
> improvement (not building messages in inmemory mode). But need to have more
> investigation.
>
> So the correct experiment is to
> 1. Use Mercury client --> with Mercury Sample service by changing Mercury
> and Sandesha2 jars
> 2. Use Sandesha2 client --> with Sandesha2 Sample service by changing
> Mercury and Sandesha2 jars
>
> I am also bit busy these days and I'll do this test on next week.
>
>
>
>> I did not do any changes to the server side codings.
>>
>> I am attaching the two clients that I used for testing Mercury and
>> Sandesha
>>
>> HTH
>>
>> Btw; I checked the code but could not find a place where I can see, the
>> application messages are buffered and the incoming thread is released.
>> Where is the place you do this? I went upto RMDContext but could not find
>> it.
>>
>
> At the server side first RMSSequence receives the message and it buffers it
> in the InvokerBuffer.
>
> See InvokerBuffer.java : 242
>
> synchronized(rmdSequence.getInvokerBuffer()){
> newMessageReceived =
> rmdSequence.applicationMessageReceived(
> sequence.getMessageNumber(),
> mercuryMessageContext);
> }
>
> Then go to inside of this method.
> See RMDSequence.java 254
>
> this.invokerBuffer.applicatinMessageReceived(messageNumber,
> mercuryMessageContext, this.persistanceDto);
>
> it calls the invoker buffer
>
> See InvokerBuffer.java 208
> this.messageBuffer.put(new Long(messageNumber), mercuryMessageContext);
> this.receivedMessageNumbers.add(new Long(messageNumber));
>
> As you can see it stores the message and returned the thread.
>
> Then it waits here MecuryInHandler.java 337
>
> if (newMessageReceived) {
> // We have to wait only if a new message
> received
> synchronized (mercuryMessageContext) {
> try {
> mercuryMessageContext.wait();
> } catch (InterruptedException e) {
> }
> }
> }
>
> this is where it wait and where I did the change.
>
> thanks,
> Amila.
>
>>
>> Thanks,
>> Jaliya
>>
>>
>> ----- Original Message -----
>> *From:* Amila Suriarachchi <am...@gmail.com>
>> *To:* Jaliya Ekanayake <ja...@apache.org>
>> *Sent:* Wednesday, June 04, 2008 12:03 PM
>> *Subject:* Re: Mercury, a new WS-RM implementation
>>
>>
>>
>> On Wed, Jun 4, 2008 at 7:37 PM, Jaliya Ekanayake <jn...@gmail.com>
>> 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.
>>>
>>
>> I have a closer look at this problem. Here is the problem.
>> Infact Mecury do the buffering. See the Invoker Buffer.
>> Mercury does not build the messages when it works in the in memory model.
>> I though this is a performance improvement when considering the Data binding
>> frameworks like ADB. Since it does not build the message it waits until
>> finish the service invocation.
>> But As chamikara once told me Sandesha2 builds the message when ever it
>> receives the message. Then I changed the code to build the message and
>> return the thread without waiting for service invocation.
>>
>> msgContext.getEnvelope().build();
>> // Here if we return the thread the input stream
>> may be closed.
>> // So have to wait until user finish with the
>> input message.
>> // We make this thread wait at the invoker buffer.
>> // if (newMessageReceived) {
>> // // We have to wait only if a new message
>> received
>> // synchronized (mercuryMessageContext) {
>> // try {
>> // mercuryMessageContext.wait();
>> // } catch (InterruptedException e) {
>> // }
>> // }
>> // }
>>
>> Then I tested with two 500 message sequences (paralely) and it worked
>> fine. But goes beyond that again was problematic.
>>
>> Could you please tell me one thing.
>> Did you run Sandesha2 Client --> Sandheas2 server (sample)
>> Mercury Client --> Mercury server (sample)
>>
>> or any other way.
>>
>> I agree that doing Sandesha for many years you have gathered a lot of
>> knowledge. What I suggested was to share that if you don't mind :).
>>
>> thanks,
>> Amila.
>>
>>
>>
>>> 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 <am...@gmail.com>
>>> *To:* Jaliya Ekanayake <ja...@apache.org>
>>> *Cc:* ant.elder@gmail.com ; Sanjiva Weerawarana <sa...@opensource.lk>;
>>> sandesha-dev@ws.apache.org
>>> *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 <jn...@gmail.com>
>>> 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 <am...@gmail.com>
>>>> *To:* ant.elder@gmail.com
>>>> *Cc:* Sanjiva Weerawarana <sa...@opensource.lk> ;
>>>> sandesha-dev@ws.apache.org
>>>> *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 <an...@apache.org>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Jun 3, 2008 at 10:10 AM, Sanjiva Weerawarana <
>>>>> sanjiva@opensource.lk> 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.
>>>>
>>>>
>>>>
>>>>
>>>> <http://incubator.apache.org/learn/rules-for-revolutionaries.html>
>>>>>
>>>>> ...ant
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Amila Suriarachchi,
>>>> WSO2 Inc.
>>>>
>>>>
>>>
>>>
>>> --
>>> Amila Suriarachchi,
>>> WSO2 Inc.
>>>
>>>
>>
>>
>> --
>> Amila Suriarachchi,
>> WSO2 Inc.
>>
>>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: Mercury, a new WS-RM implementation
Posted by Amila Suriarachchi <am...@gmail.com>.
hi jaliya
On Wed, Jun 4, 2008 at 10:36 PM, Jaliya Ekanayake <jn...@gmail.com>
wrote:
> I am open to sharing my knowledge in any means possible. That is the sole
> reason I did this comparision instead of discussion without any results.
>
>
> So the way I tested is as follows.
>
> As I have mentioned, i deployed Mercury in Axis2 which is deployed in
> Tomcat and tested it with Mercury samples.
> Then I deployed Sandesha in Axis2 which is deployed in Tomcat and tested it
> using Sandesha2 samples.
>
I am not sure about how Sandesha2 works. But this is how Mercury works.
In In only cases The client thread put this message to the RMSSequence
(which buffers this message) and immediately returns. Then RMSSequenceWorker
(an independent thread) start working on this and send these messages using
a separate thread for each message (MessageWorker). So if we send 1000
messages (using any number of threads at client level) which basically
creates 1000 threads to send the messages.
So here effectively you try to access a Server have 150 maxthreads with 1000
simultaneous threads.
Here I agree with you that Mercury needs a Window Approach as with TCP to
limit the number of messages with out flooding the network at once.
But if sandesha2 uses only 4 threads then it does not flood the server as
such.
If this is the case Mercury should be able to use that performance
improvement (not building messages in inmemory mode). But need to have more
investigation.
So the correct experiment is to
1. Use Mercury client --> with Mercury Sample service by changing Mercury
and Sandesha2 jars
2. Use Sandesha2 client --> with Sandesha2 Sample service by changing
Mercury and Sandesha2 jars
I am also bit busy these days and I'll do this test on next week.
> I did not do any changes to the server side codings.
>
> I am attaching the two clients that I used for testing Mercury and Sandesha
>
> HTH
>
> Btw; I checked the code but could not find a place where I can see, the
> application messages are buffered and the incoming thread is released.
> Where is the place you do this? I went upto RMDContext but could not find
> it.
>
At the server side first RMSSequence receives the message and it buffers it
in the InvokerBuffer.
See InvokerBuffer.java : 242
synchronized(rmdSequence.getInvokerBuffer()){
newMessageReceived =
rmdSequence.applicationMessageReceived(
sequence.getMessageNumber(),
mercuryMessageContext);
}
Then go to inside of this method.
See RMDSequence.java 254
this.invokerBuffer.applicatinMessageReceived(messageNumber,
mercuryMessageContext, this.persistanceDto);
it calls the invoker buffer
See InvokerBuffer.java 208
this.messageBuffer.put(new Long(messageNumber), mercuryMessageContext);
this.receivedMessageNumbers.add(new Long(messageNumber));
As you can see it stores the message and returned the thread.
Then it waits here MecuryInHandler.java 337
if (newMessageReceived) {
// We have to wait only if a new message
received
synchronized (mercuryMessageContext) {
try {
mercuryMessageContext.wait();
} catch (InterruptedException e) {
}
}
}
this is where it wait and where I did the change.
thanks,
Amila.
>
> Thanks,
> Jaliya
>
>
> ----- Original Message -----
> *From:* Amila Suriarachchi <am...@gmail.com>
> *To:* Jaliya Ekanayake <ja...@apache.org>
> *Sent:* Wednesday, June 04, 2008 12:03 PM
> *Subject:* Re: Mercury, a new WS-RM implementation
>
>
>
> On Wed, Jun 4, 2008 at 7:37 PM, Jaliya Ekanayake <jn...@gmail.com>
> 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.
>>
>
> I have a closer look at this problem. Here is the problem.
> Infact Mecury do the buffering. See the Invoker Buffer.
> Mercury does not build the messages when it works in the in memory model. I
> though this is a performance improvement when considering the Data binding
> frameworks like ADB. Since it does not build the message it waits until
> finish the service invocation.
> But As chamikara once told me Sandesha2 builds the message when ever it
> receives the message. Then I changed the code to build the message and
> return the thread without waiting for service invocation.
>
> msgContext.getEnvelope().build();
> // Here if we return the thread the input stream
> may be closed.
> // So have to wait until user finish with the input
> message.
> // We make this thread wait at the invoker buffer.
> // if (newMessageReceived) {
> // // We have to wait only if a new message
> received
> // synchronized (mercuryMessageContext) {
> // try {
> // mercuryMessageContext.wait();
> // } catch (InterruptedException e) {
> // }
> // }
> // }
>
> Then I tested with two 500 message sequences (paralely) and it worked fine.
> But goes beyond that again was problematic.
>
> Could you please tell me one thing.
> Did you run Sandesha2 Client --> Sandheas2 server (sample)
> Mercury Client --> Mercury server (sample)
>
> or any other way.
>
> I agree that doing Sandesha for many years you have gathered a lot of
> knowledge. What I suggested was to share that if you don't mind :).
>
> thanks,
> Amila.
>
>
>
>> 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 <am...@gmail.com>
>> *To:* Jaliya Ekanayake <ja...@apache.org>
>> *Cc:* ant.elder@gmail.com ; Sanjiva Weerawarana <sa...@opensource.lk> ;
>> sandesha-dev@ws.apache.org
>> *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 <jn...@gmail.com>
>> 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 <am...@gmail.com>
>>> *To:* ant.elder@gmail.com
>>> *Cc:* Sanjiva Weerawarana <sa...@opensource.lk> ;
>>> sandesha-dev@ws.apache.org
>>> *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 <an...@apache.org> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Jun 3, 2008 at 10:10 AM, Sanjiva Weerawarana <
>>>> sanjiva@opensource.lk> 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.
>>>
>>>
>>>
>>>
>>> <http://incubator.apache.org/learn/rules-for-revolutionaries.html>
>>>>
>>>> ...ant
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Amila Suriarachchi,
>>> WSO2 Inc.
>>>
>>>
>>
>>
>> --
>> Amila Suriarachchi,
>> WSO2 Inc.
>>
>>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: Mercury, a new WS-RM implementation
Posted by ant elder <an...@gmail.com>.
On Wed, Jun 4, 2008 at 12:07 PM, Glen Daniels <gl...@thoughtcraft.com> wrote:
<snip>
>
> The most important and positive thing I've gotten from this discussion is
>>> that there's a vibrant and caring community around Sandesha. I have no
>>> interest in trying to replicate that elsewhere and fracture this community.
>>>
>>
> Well said, sir!
>
>
+1 to that
...ant
Re: Mercury, a new WS-RM implementation
Posted by Chamikara Jayalath <ch...@gmail.com>.
On Wed, Jun 4, 2008 at 7:07 AM, Glen Daniels <gl...@thoughtcraft.com> wrote:
> Hi guys,
>
> Jaliya Ekanayake wrote:
>
>> ----- Original Message ----- From: "Sanjiva Weerawarana"
>>
>>> That said, there are many areas of Mercury that still require serious
>>> work: threading model, transactions, persistence model etc.. Maybe if we
>>> combine the two and do a new version of Sandesha that'll be better all
>>> around. That is, use Mercury as a source of ideas and code but not continue
>>> "Mercury" in ASF but rather start a new effort to cut-n-paste stuff from
>>> wherever and get a damned good RM impl out to our users.
>>>
>>> A big +1 for this.
>>
>
> +1 from me, assuming we can get the cycles from people to make this happen.
> Love to hear others' take on this - David? Ant? Amila?
>
+1
Chamikara
>
> Mercury can remain in wso2.org and we can EOL as the new one comes up and
>>> starts working properly.
>>>
>>
> +1. Solve our immediate problems now, and also plan for the future we'd
> really like to see.
>
> The most important and positive thing I've gotten from this discussion is
>>> that there's a vibrant and caring community around Sandesha. I have no
>>> interest in trying to replicate that elsewhere and fracture this community.
>>>
>>
> Well said, sir!
>
> --Glen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
Re: Mercury, a new WS-RM implementation
Posted by Andrew K Gatford <GA...@uk.ibm.com>.
Andrew Gatford
Technical Project Lead
Websphere ESB Foundation Technologies
Hursley MP211
IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN
Telephone :
Internal (7) 245743
External 01962 815743
Internet : gatfora@uk.ibm.com
Glen Daniels <gl...@thoughtcraft.com> wrote on 04/06/2008 12:07:38:
> [image removed]
>
> Re: Mercury, a new WS-RM implementation
>
> Glen Daniels
>
> to:
>
> sandesha-dev
>
> 04/06/2008 12:11
>
> Hi guys,
>
> Jaliya Ekanayake wrote:
> > ----- Original Message ----- From: "Sanjiva Weerawarana"
> >> That said, there are many areas of Mercury that still require serious
> >> work: threading model, transactions, persistence model etc.. Maybe if
> >> we combine the two and do a new version of Sandesha that'll be better
> >> all around. That is, use Mercury as a source of ideas and code but
not
> >> continue "Mercury" in ASF but rather start a new effort to
cut-n-paste
> >> stuff from wherever and get a damned good RM impl out to our users.
> >>
> > A big +1 for this.
>
> +1 from me, assuming we can get the cycles from people to make this
> happen. Love to hear others' take on this - David? Ant? Amila?
>
> >> Mercury can remain in wso2.org and we can EOL as the new one comes up
> >> and starts working properly.
>
> +1. Solve our immediate problems now, and also plan for the future we'd
> really like to see.
+1 from me. Although I don't think that just copying the best bits from
both is the right starting point. I think we need to generate a list of
requirements and white board the solution as a better starting point
without any reference to the 2 implementations that we currently have. If
at the end of this we can copy bits from either of the solutions I would
be more comfortable knowing that we were doing it for the right reason.
>
> >> The most important and positive thing I've gotten from this
discussion
> >> is that there's a vibrant and caring community around Sandesha. I
have
> >> no interest in trying to replicate that elsewhere and fracture this
> >> community.
>
> Well said, sir!
>
> --Glen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi guys,
Jaliya Ekanayake wrote:
> ----- Original Message ----- From: "Sanjiva Weerawarana"
>> That said, there are many areas of Mercury that still require serious
>> work: threading model, transactions, persistence model etc.. Maybe if
>> we combine the two and do a new version of Sandesha that'll be better
>> all around. That is, use Mercury as a source of ideas and code but not
>> continue "Mercury" in ASF but rather start a new effort to cut-n-paste
>> stuff from wherever and get a damned good RM impl out to our users.
>>
> A big +1 for this.
+1 from me, assuming we can get the cycles from people to make this
happen. Love to hear others' take on this - David? Ant? Amila?
>> Mercury can remain in wso2.org and we can EOL as the new one comes up
>> and starts working properly.
+1. Solve our immediate problems now, and also plan for the future we'd
really like to see.
>> The most important and positive thing I've gotten from this discussion
>> is that there's a vibrant and caring community around Sandesha. I have
>> no interest in trying to replicate that elsewhere and fracture this
>> community.
Well said, sir!
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by Jaliya Ekanayake <jn...@gmail.com>.
----- Original Message -----
From: "Sanjiva Weerawarana" <sa...@opensource.lk>
To: "Jeremy Hughes" <hu...@apache.org>
Cc: <sa...@ws.apache.org>
Sent: Tuesday, June 03, 2008 10:55 PM
Subject: Re: Mercury, a new WS-RM implementation
> Jeremy Hughes wrote:
>>> AFAIK Apache in general does not have a policy to handle this kind of
>>> situations.
>>
>> Yes, it does. It's the Apache Incubator.
>
> There is also the option of a software grant to an existing project. This
> was done for a new version of Muse (WS-Management stuff; can't remember
> the details) from IBM around an year ago.
>
>> Another option would have been to start a revolutionary branch in
>> Apache SVN after -dev list discussions on the issues with Sandesha2 /
>> SMTP. Then Mercury's development from scratch would have been in full
>> view of the Sandesha2 community from the start.
>
> +1 .. in 20/20 hindsight I totally agree with you that'd have been a MUCH
> better way to have done this :(.
>
>> That would imply a new project, seeded with a contribution from a
>> third party, so should go through the incubator. There are good
>> reasons for this - e.g. name checking the name 'Mercury'. If a
>> separate project is what people want, we should *at least* have the
>> discussion with the Incubator PMC / general list on whether an
>> incubator podling is required. I feel uncomfortable starting a new WS
>> subproject seeded with a relatively large body of code that wasn't
>> developed at Apache, without it going through the rigor that the
> incubator brings.
>
> Fair enough.
>
>> My preference though would be that we don't have a fork and that there
>> is either a clear distinction between the goals of Mercury vs
>> Sandesha2, or even better a combined project with perhaps multiple
>> modules.
>
> I think Jaliya's measurements show that Mercury is not a done-deal
> project. Maybe the right thing to do is start a variation of Mercury in
> Apache as a "revolutionary fork" and really combine the two effectively.
>
> The fundamental difference is that Mercury is based on a state machine
> model and that appears to be a better architectural approach doing an RM
> implementation than the approach in Sandesha2.
>
> That said, there are many areas of Mercury that still require serious
> work: threading model, transactions, persistence model etc.. Maybe if we
> combine the two and do a new version of Sandesha that'll be better all
> around. That is, use Mercury as a source of ideas and code but not
> continue "Mercury" in ASF but rather start a new effort to cut-n-paste
> stuff from wherever and get a damned good RM impl out to our users.
>
A big +1 for this.
Thanks,
Jaliya
> Mercury can remain in wso2.org and we can EOL as the new one comes up and
> starts working properly.
>
> Thoughts?
>
> ---
>
> The most important and positive thing I've gotten from this discussion is
> that there's a vibrant and caring community around Sandesha. I have no
> interest in trying to replicate that elsewhere and fracture this
> community.
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Jeremy Hughes wrote:
>> AFAIK Apache in general does not have a policy to handle this kind of
>> situations.
>
> Yes, it does. It's the Apache Incubator.
There is also the option of a software grant to an existing project. This
was done for a new version of Muse (WS-Management stuff; can't remember
the details) from IBM around an year ago.
> Another option would have been to start a revolutionary branch in
> Apache SVN after -dev list discussions on the issues with Sandesha2 /
> SMTP. Then Mercury's development from scratch would have been in full
> view of the Sandesha2 community from the start.
+1 .. in 20/20 hindsight I totally agree with you that'd have been a MUCH
better way to have done this :(.
> That would imply a new project, seeded with a contribution from a
> third party, so should go through the incubator. There are good
> reasons for this - e.g. name checking the name 'Mercury'. If a
> separate project is what people want, we should *at least* have the
> discussion with the Incubator PMC / general list on whether an
> incubator podling is required. I feel uncomfortable starting a new WS
> subproject seeded with a relatively large body of code that wasn't
> developed at Apache, without it going through the rigor that the
incubator brings.
Fair enough.
> My preference though would be that we don't have a fork and that there
> is either a clear distinction between the goals of Mercury vs
> Sandesha2, or even better a combined project with perhaps multiple
> modules.
I think Jaliya's measurements show that Mercury is not a done-deal
project. Maybe the right thing to do is start a variation of Mercury in
Apache as a "revolutionary fork" and really combine the two effectively.
The fundamental difference is that Mercury is based on a state machine
model and that appears to be a better architectural approach doing an RM
implementation than the approach in Sandesha2.
That said, there are many areas of Mercury that still require serious
work: threading model, transactions, persistence model etc.. Maybe if we
combine the two and do a new version of Sandesha that'll be better all
around. That is, use Mercury as a source of ideas and code but not
continue "Mercury" in ASF but rather start a new effort to cut-n-paste
stuff from wherever and get a damned good RM impl out to our users.
Mercury can remain in wso2.org and we can EOL as the new one comes up and
starts working properly.
Thoughts?
---
The most important and positive thing I've gotten from this discussion is
that there's a vibrant and caring community around Sandesha. I have no
interest in trying to replicate that elsewhere and fracture this community.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by Jeremy Hughes <hu...@apache.org>.
2008/6/3 Amila Suriarachchi <am...@gmail.com>:
...
> As I understood this revolutionary talks about doing a substantial
> improvement to an existing code base.
I think that is the norm, but not required. If it's not a branch it
becomes (much) more difficult to merge it back with the trunk. It is
possible for the revolutionary branch to replace the trunk (but this
is IMHO just an extreme case of a merge).
>
> 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.
It sounds like you'd like a new project to run in parallel with
Sandesha2. This would imply building a community around it etc etc.
>
> AFAIK Apache in general does not have a policy to handle this kind of
> situations.
Yes, it does. It's the Apache Incubator.
>
> 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.
Another option would have been to start a revolutionary branch in
Apache SVN after -dev list discussions on the issues with Sandesha2 /
SMTP. Then Mercury's development from scratch would have been in full
view of the Sandesha2 community from the start.
>
> 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.
That would imply a new project, seeded with a contribution from a
third party, so should go through the incubator. There are good
reasons for this - e.g. name checking the name 'Mercury'. If a
separate project is what people want, we should *at least* have the
discussion with the Incubator PMC / general list on whether an
incubator podling is required. I feel uncomfortable starting a new WS
subproject seeded with a relatively large body of code that wasn't
developed at Apache, without it going through the rigor that the
incubator brings.
My preference though would be that we don't have a fork and that there
is either a clear distinction between the goals of Mercury vs
Sandesha2, or even better a combined project with perhaps multiple
modules.
Cheers,
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by Amila Suriarachchi <am...@gmail.com>.
On Wed, Jun 4, 2008 at 7:37 PM, Jaliya Ekanayake <jn...@gmail.com>
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.
>
I have a closer look at this problem. Here is the problem.
Infact Mecury do the buffering. See the Invoker Buffer.
Mercury does not build the messages when it works in the in memory model. I
though this is a performance improvement when considering the Data binding
frameworks like ADB. Since it does not build the message it waits until
finish the service invocation.
But As chamikara once told me Sandesha2 builds the message when ever it
receives the message. Then I changed the code to build the message and
return the thread without waiting for service invocation.
msgContext.getEnvelope().build();
// Here if we return the thread the input stream may
be closed.
// So have to wait until user finish with the input
message.
// We make this thread wait at the invoker buffer.
// if (newMessageReceived) {
// // We have to wait only if a new message
received
// synchronized (mercuryMessageContext) {
// try {
// mercuryMessageContext.wait();
// } catch (InterruptedException e) {
// }
// }
// }
Then I tested with two 500 message sequences (paralely) and it worked fine.
But goes beyond that again was problematic.
Could you please tell me one thing.
Did you run Sandesha2 Client --> Sandheas2 server (sample)
Mercury Client --> Mercury server (sample)
or any other way.
I agree that doing Sandesha for many years you have gathered a lot of
knowledge. What I suggested was to share that if you don't mind :).
>
> 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 <am...@gmail.com>
> *To:* Jaliya Ekanayake <ja...@apache.org>
> *Cc:* ant.elder@gmail.com ; Sanjiva Weerawarana <sa...@opensource.lk> ;
> sandesha-dev@ws.apache.org
> *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 <jn...@gmail.com>
> 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 <am...@gmail.com>
>> *To:* ant.elder@gmail.com
>> *Cc:* Sanjiva Weerawarana <sa...@opensource.lk> ;
>> sandesha-dev@ws.apache.org
>> *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 <an...@apache.org> wrote:
>>
>>>
>>>
>>> On Tue, Jun 3, 2008 at 10:10 AM, Sanjiva Weerawarana <
>>> sanjiva@opensource.lk> 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.
>>
>>
>>
>>
>> <http://incubator.apache.org/learn/rules-for-revolutionaries.html>
>>>
>>> ...ant
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Amila Suriarachchi,
>> WSO2 Inc.
>>
>>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: Mercury, a new WS-RM implementation
Posted by Amila Suriarachchi <am...@gmail.com>.
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 <jn...@gmail.com>
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 <am...@gmail.com>
> *To:* ant.elder@gmail.com
> *Cc:* Sanjiva Weerawarana <sa...@opensource.lk> ;
> sandesha-dev@ws.apache.org
> *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 <an...@apache.org> wrote:
>
>>
>>
>> On Tue, Jun 3, 2008 at 10:10 AM, Sanjiva Weerawarana <
>> sanjiva@opensource.lk> 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.
>
>
>
>
> <http://incubator.apache.org/learn/rules-for-revolutionaries.html>
>>
>> ...ant
>>
>>
>>
>>
>>
>>
>
>
> --
> Amila Suriarachchi,
> WSO2 Inc.
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: Mercury, a new WS-RM implementation
Posted by Jaliya Ekanayake <jn...@gmail.com>.
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: ant.elder@gmail.com
Cc: Sanjiva Weerawarana ; sandesha-dev@ws.apache.org
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 <an...@apache.org> wrote:
On Tue, Jun 3, 2008 at 10:10 AM, Sanjiva Weerawarana <sa...@opensource.lk> 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.
Re: Mercury, a new WS-RM implementation
Posted by Amila Suriarachchi <am...@gmail.com>.
On Tue, Jun 3, 2008 at 3:05 PM, ant elder <an...@apache.org> wrote:
>
>
> On Tue, Jun 3, 2008 at 10:10 AM, Sanjiva Weerawarana <
> sanjiva@opensource.lk> 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.
<http://incubator.apache.org/learn/rules-for-revolutionaries.html>
>
> ...ant
>
>
>
>
>
>
--
Amila Suriarachchi,
WSO2 Inc.
Re: Mercury, a new WS-RM implementation
Posted by ant elder <an...@apache.org>.
On Tue, Jun 3, 2008 at 10:10 AM, Sanjiva Weerawarana <sa...@opensource.lk>
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
...ant
Re: Mercury, a new WS-RM implementation
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Paul,
On Tue, Jun 3, 2008 at 1:08 PM, Paul Fremantle <pz...@gmail.com> wrote:
> Chamikara
>
> I think we are a long way from a feature complete Mercury :-)
It does not have to be feature complete to be brought into Apache. But it
will have to have the missing features before becoming a replacement for
Sandesha2.
> I also
> think you should be thinking of other criteria than just performance:
> code cleanliness, maintainability, community involvement, stability,
> production quality, all these and more are criteria on which people
> will judge whether this is a better implementation than Sandesha2.
+1. But as Jaliya had mentioned architecture & performance should be the No.
1 factor.
Thanks,
Chamikara
>
>
> Paul
>
> On Tue, Jun 3, 2008 at 5:50 PM, Chamikara Jayalath
> <ch...@gmail.com> wrote:
> > Hi All,
> >
> > As I mentioned earlied, I am really eager to see Mercury being brought
> into
> > Apache (either as a branch in Sandesha2 or as a seperate WS project).
> What I
> > really want to see is a comparison between two implementations. If a
> feature
> > complete Mercury version outperforms Sandesha2 I would be more than happy
> to
> > accept it as a replacement for Sandsha2.
> >
> > Thanks,
> > Chamikara
> >
> >
> >
> >
> > On Tue, Jun 3, 2008 at 10:24 AM, Sanjiva Weerawarana <
> sanjiva@opensource.lk>
> > wrote:
> >>
> >> No objection at all, as long as its not castrated .. i.e., it must be ok
> >> to release. Is that ok with everyone?
> >>
> >> Sanjiva.
> >>
> >> Paul Fremantle wrote:
> >>>
> >>> Ant
> >>>
> >>> I completely agree. I think the best outcome is to move the code into
> >>> ASF SVN, move the discussion over, and simply treat this as a new and
> >>> different codebase from Sandesha, with no implication about how this
> >>> pans out in the future.
> >>>
> >>> Paul
> >>>
> >>> On Tue, Jun 3, 2008 at 12:23 PM, ant elder <an...@apache.org>
> wrote:
> >>>>
> >>>> Just for the record I'd like to point out I've been talking as a WS
> PMC
> >>>> member. I've no idea what IBMs views are on this and haven't spoken to
> >>>> anyone in IBM about it. Also I'm fine with this code coming into the
> >>>> apache
> >>>> svn, that would be better than being developed at wso2 imho. I do
> think
> >>>> for
> >>>> now until there's consensus on it there should be no implication yet
> >>>> that
> >>>> its the "next" version, as outline in the rules for revolutions doc.
> >>>>
> >>>> ...ant
> >>>>
> >>>> On Tue, Jun 3, 2008 at 12:12 PM, Sanjiva Weerawarana
> >>>> <sa...@opensource.lk>
> >>>> wrote:
> >>>>>
> >>>>> I'd like to hear what non-IBM Sandesha community members also think
> >>>>> about
> >>>>> this idea. If the entire community doesn't want this code coming
> here,
> >>>>> well,
> >>>>> then its ABSOLUTELY fine!
> >>>>>
> >>>>> Life will go on .. and if WSO2 wants to it can certainly contrib it
> and
> >>>>> start an alternative RM impl in Apache too. Apache does not have a
> >>>>> position
> >>>>> saying "only one of one thing".
> >>>>>
> >>>>> Sanjiva.
> >>>>>
> >>>>> Paul Fremantle wrote:
> >>>>>>
> >>>>>> 1. I agree that this code should not be in Apache with a org.wso2
> >>>>>> package namespace.
> >>>>>> 2. I don't agree that the timing of this is so bad. There is always
> a
> >>>>>> balance between starting something completely in the open and
> pushing
> >>>>>> a finished object onto the community. When Amila started this, it
> >>>>>> wasn't a conscious decision to replace Sandesha2 - it was simply an
> >>>>>> experiment. Amila got it to the point where the experiment proved
> that
> >>>>>> this particular approach could work and then brought it to the
> >>>>>> community. And I don't think this code is that complete - there is a
> >>>>>> lot of work to do on it. To be honest I think there are mixed
> >>>>>> messages. On the one hand I'm hearing that its too complete and we
> >>>>>> should have engaged the community earlier. On the other hand I'm
> >>>>>> hearing that because it doesn't implement 1.1. it still hasn't
> proven
> >>>>>> it can be a cleaner design that Sandesha2. Frankly I don't think
> there
> >>>>>> is any perfect answer here.
> >>>>>> 3. Apache has a strong history of allowing multiple implementations
> of
> >>>>>> the same thing and I don't see any reason why we shouldn't have two
> >>>>>> implementations of RM. Whether or not Mercury is a "replacement" for
> >>>>>> Sandesha seems to be something that will only will be decided if the
> >>>>>> community wants it to be that way. I think its *way* too early to
> tell
> >>>>>> at this point if Mercury is going to enthuse the community or not.
> So
> >>>>>> far it only implements about half of the features of Sandesha2.
> >>>>>> 4. I personally think that the right thing to do here is to engage
> the
> >>>>>> community. I think the right way to do that is to move the code to
> >>>>>> org.apache.something, and move the discussions to sandesha-dev with
> a
> >>>>>> prefix in the subject like [MERCURY]. This is what we have done time
> >>>>>> and again. Either it will engage a wider audience in the design and
> >>>>>> implementation or it won't, but unless we do this we can't know.
> >>>>>> 5. I don't think it really matters whether Sandesha2 has bugs or
> not.
> >>>>>> The question in my mind is whether this new implementation can be
> kept
> >>>>>> cleaner, faster, and more maintainable than Sandesha2. If it can be
> >>>>>> then it will gain support, and if not it won't. Its as simple as
> that.
> >>>>>> But I honestly believe in the Apache way, and I don't think it will
> >>>>>> end up better without the input of this community, who frankly know
> >>>>>> WSRM implementation as well as anyone in the world.
> >>>>>> 6. I *COMPLETELY* disagree with Ant's point about announcements.
> This
> >>>>>> is a module that works with Axis2 and there is absolutely nothing
> >>>>>> wrong with announcing it to the Axis2 community with an [ANN]
> header.
> >>>>>> That would be true if this was a commercial extension to Axis2. But
> >>>>>> this is an Apache Licensed open source project. Further, a version
> of
> >>>>>> this code has been donated to Apache. So unless I have somehow an
> >>>>>> utter misunderstanding of Apache's mailing lists I cannot see any
> >>>>>> reason at all not to post this announcement.
> >>>>>>
> >>>>>> Paul
> >>>>>>
> >>>>>> On Tue, Jun 3, 2008 at 9:18 AM, ant elder <an...@gmail.com>
> wrote:
> >>>>>>>>
> >>>>>>>> On Sat, May 31, 2008 at 4:50 PM, Glen Daniels
> >>>>>>>> <gl...@thoughtcraft.com>
> >>>>>>>> wrote:
> >>>>>>>
> >>>>>>> <snip>
> >>>>>>>
> >>>>>>>>> While that may be true, I'm disappointed that the work moved so
> far
> >>>>>>>>> forward before being brought to the Sandesha community, and I
> would
> >>>>>>>>> *really* like to find some navigable path that brings us
> eventually
> >>>>>>>>> to
> >>>>>>>>> a
> >>>>>>>>> single implementation of RM-over-Axis2, in Apache.
> >>>>>>>
> >>>>>>> Agree with that completely, this seems a really sad thing to have
> >>>>>>> happened.
> >>>>>>> Is there really no way to get Sandesha working with SecureRM over
> >>>>>>> SMTP,
> >>>>>>> there didn't seem to be much discussion about what the issues are
> >>>>>>> with
> >>>>>>> doing
> >>>>>>> that?
> >>>>>>>
> >>>>>>> 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
> >>>>>>>
> >>>>>>> ...ant
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>> --
> >>>>> Sanjiva Weerawarana, Ph.D.
> >>>>> Founder & Director; Lanka Software Foundation;
> >>>>> http://www.opensource.lk/
> >>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> >>>>> Member; Apache Software Foundation; http://www.apache.org/
> >>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> >>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> Sanjiva Weerawarana, Ph.D.
> >> Founder & Director; Lanka Software Foundation;
> http://www.opensource.lk/
> >> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> >> Member; Apache Software Foundation; http://www.apache.org/
> >> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
> >>
> >
> >
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
Re: Mercury, a new WS-RM implementation
Posted by Jaliya Ekanayake <jn...@gmail.com>.
Hi Paul,
I totally agree with these
>code cleanliness, maintainability, community involvement, stability,
> production quality, all these and more are criteria on which people
> will judge whether this is a better implementation than Sandesha2
However, I do not agree that it they can use to overcome an architecture
that is not sound with respect to the performance.
If the architecture is sound and the performance is good( I am +1 to replace
the Sandesha2 ), the rest is just a matter of few review cycles
Thanks,
Jaliya
----- Original Message -----
From: "Paul Fremantle" <pz...@gmail.com>
To: "Chamikara Jayalath" <ch...@gmail.com>
Cc: <sa...@ws.apache.org>
Sent: Tuesday, June 03, 2008 1:08 PM
Subject: Re: Mercury, a new WS-RM implementation
> Chamikara
>
> I think we are a long way from a feature complete Mercury :-) I also
> think you should be thinking of other criteria than just performance:
> code cleanliness, maintainability, community involvement, stability,
> production quality, all these and more are criteria on which people
> will judge whether this is a better implementation than Sandesha2.
>
> Paul
>
> On Tue, Jun 3, 2008 at 5:50 PM, Chamikara Jayalath
> <ch...@gmail.com> wrote:
>> Hi All,
>>
>> As I mentioned earlied, I am really eager to see Mercury being brought
>> into
>> Apache (either as a branch in Sandesha2 or as a seperate WS project).
>> What I
>> really want to see is a comparison between two implementations. If a
>> feature
>> complete Mercury version outperforms Sandesha2 I would be more than happy
>> to
>> accept it as a replacement for Sandsha2.
>>
>> Thanks,
>> Chamikara
>>
>>
>>
>>
>> On Tue, Jun 3, 2008 at 10:24 AM, Sanjiva Weerawarana
>> <sa...@opensource.lk>
>> wrote:
>>>
>>> No objection at all, as long as its not castrated .. i.e., it must be ok
>>> to release. Is that ok with everyone?
>>>
>>> Sanjiva.
>>>
>>> Paul Fremantle wrote:
>>>>
>>>> Ant
>>>>
>>>> I completely agree. I think the best outcome is to move the code into
>>>> ASF SVN, move the discussion over, and simply treat this as a new and
>>>> different codebase from Sandesha, with no implication about how this
>>>> pans out in the future.
>>>>
>>>> Paul
>>>>
>>>> On Tue, Jun 3, 2008 at 12:23 PM, ant elder <an...@apache.org> wrote:
>>>>>
>>>>> Just for the record I'd like to point out I've been talking as a WS
>>>>> PMC
>>>>> member. I've no idea what IBMs views are on this and haven't spoken to
>>>>> anyone in IBM about it. Also I'm fine with this code coming into the
>>>>> apache
>>>>> svn, that would be better than being developed at wso2 imho. I do
>>>>> think
>>>>> for
>>>>> now until there's consensus on it there should be no implication yet
>>>>> that
>>>>> its the "next" version, as outline in the rules for revolutions doc.
>>>>>
>>>>> ...ant
>>>>>
>>>>> On Tue, Jun 3, 2008 at 12:12 PM, Sanjiva Weerawarana
>>>>> <sa...@opensource.lk>
>>>>> wrote:
>>>>>>
>>>>>> I'd like to hear what non-IBM Sandesha community members also think
>>>>>> about
>>>>>> this idea. If the entire community doesn't want this code coming
>>>>>> here,
>>>>>> well,
>>>>>> then its ABSOLUTELY fine!
>>>>>>
>>>>>> Life will go on .. and if WSO2 wants to it can certainly contrib it
>>>>>> and
>>>>>> start an alternative RM impl in Apache too. Apache does not have a
>>>>>> position
>>>>>> saying "only one of one thing".
>>>>>>
>>>>>> Sanjiva.
>>>>>>
>>>>>> Paul Fremantle wrote:
>>>>>>>
>>>>>>> 1. I agree that this code should not be in Apache with a org.wso2
>>>>>>> package namespace.
>>>>>>> 2. I don't agree that the timing of this is so bad. There is always
>>>>>>> a
>>>>>>> balance between starting something completely in the open and
>>>>>>> pushing
>>>>>>> a finished object onto the community. When Amila started this, it
>>>>>>> wasn't a conscious decision to replace Sandesha2 - it was simply an
>>>>>>> experiment. Amila got it to the point where the experiment proved
>>>>>>> that
>>>>>>> this particular approach could work and then brought it to the
>>>>>>> community. And I don't think this code is that complete - there is a
>>>>>>> lot of work to do on it. To be honest I think there are mixed
>>>>>>> messages. On the one hand I'm hearing that its too complete and we
>>>>>>> should have engaged the community earlier. On the other hand I'm
>>>>>>> hearing that because it doesn't implement 1.1. it still hasn't
>>>>>>> proven
>>>>>>> it can be a cleaner design that Sandesha2. Frankly I don't think
>>>>>>> there
>>>>>>> is any perfect answer here.
>>>>>>> 3. Apache has a strong history of allowing multiple implementations
>>>>>>> of
>>>>>>> the same thing and I don't see any reason why we shouldn't have two
>>>>>>> implementations of RM. Whether or not Mercury is a "replacement" for
>>>>>>> Sandesha seems to be something that will only will be decided if the
>>>>>>> community wants it to be that way. I think its *way* too early to
>>>>>>> tell
>>>>>>> at this point if Mercury is going to enthuse the community or not.
>>>>>>> So
>>>>>>> far it only implements about half of the features of Sandesha2.
>>>>>>> 4. I personally think that the right thing to do here is to engage
>>>>>>> the
>>>>>>> community. I think the right way to do that is to move the code to
>>>>>>> org.apache.something, and move the discussions to sandesha-dev with
>>>>>>> a
>>>>>>> prefix in the subject like [MERCURY]. This is what we have done time
>>>>>>> and again. Either it will engage a wider audience in the design and
>>>>>>> implementation or it won't, but unless we do this we can't know.
>>>>>>> 5. I don't think it really matters whether Sandesha2 has bugs or
>>>>>>> not.
>>>>>>> The question in my mind is whether this new implementation can be
>>>>>>> kept
>>>>>>> cleaner, faster, and more maintainable than Sandesha2. If it can be
>>>>>>> then it will gain support, and if not it won't. Its as simple as
>>>>>>> that.
>>>>>>> But I honestly believe in the Apache way, and I don't think it will
>>>>>>> end up better without the input of this community, who frankly know
>>>>>>> WSRM implementation as well as anyone in the world.
>>>>>>> 6. I *COMPLETELY* disagree with Ant's point about announcements.
>>>>>>> This
>>>>>>> is a module that works with Axis2 and there is absolutely nothing
>>>>>>> wrong with announcing it to the Axis2 community with an [ANN]
>>>>>>> header.
>>>>>>> That would be true if this was a commercial extension to Axis2. But
>>>>>>> this is an Apache Licensed open source project. Further, a version
>>>>>>> of
>>>>>>> this code has been donated to Apache. So unless I have somehow an
>>>>>>> utter misunderstanding of Apache's mailing lists I cannot see any
>>>>>>> reason at all not to post this announcement.
>>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>> On Tue, Jun 3, 2008 at 9:18 AM, ant elder <an...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Sat, May 31, 2008 at 4:50 PM, Glen Daniels
>>>>>>>>> <gl...@thoughtcraft.com>
>>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> <snip>
>>>>>>>>
>>>>>>>>>> While that may be true, I'm disappointed that the work moved so
>>>>>>>>>> far
>>>>>>>>>> forward before being brought to the Sandesha community, and I
>>>>>>>>>> would
>>>>>>>>>> *really* like to find some navigable path that brings us
>>>>>>>>>> eventually
>>>>>>>>>> to
>>>>>>>>>> a
>>>>>>>>>> single implementation of RM-over-Axis2, in Apache.
>>>>>>>>
>>>>>>>> Agree with that completely, this seems a really sad thing to have
>>>>>>>> happened.
>>>>>>>> Is there really no way to get Sandesha working with SecureRM over
>>>>>>>> SMTP,
>>>>>>>> there didn't seem to be much discussion about what the issues are
>>>>>>>> with
>>>>>>>> doing
>>>>>>>> that?
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> ...ant
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Sanjiva Weerawarana, Ph.D.
>>>>>> Founder & Director; Lanka Software Foundation;
>>>>>> http://www.opensource.lk/
>>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Sanjiva Weerawarana, Ph.D.
>>> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>> Member; Apache Software Foundation; http://www.apache.org/
>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>
>>
>>
>
>
>
> --
> Paul Fremantle
> Co-Founder and CTO, WSO2
> Apache Synapse PMC Chair
> OASIS WS-RX TC Co-chair
>
> blog: http://pzf.fremantle.org
> paul@wso2.com
>
> "Oxygenating the Web Service Platform", www.wso2.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by Paul Fremantle <pz...@gmail.com>.
Chamikara
I think we are a long way from a feature complete Mercury :-) I also
think you should be thinking of other criteria than just performance:
code cleanliness, maintainability, community involvement, stability,
production quality, all these and more are criteria on which people
will judge whether this is a better implementation than Sandesha2.
Paul
On Tue, Jun 3, 2008 at 5:50 PM, Chamikara Jayalath
<ch...@gmail.com> wrote:
> Hi All,
>
> As I mentioned earlied, I am really eager to see Mercury being brought into
> Apache (either as a branch in Sandesha2 or as a seperate WS project). What I
> really want to see is a comparison between two implementations. If a feature
> complete Mercury version outperforms Sandesha2 I would be more than happy to
> accept it as a replacement for Sandsha2.
>
> Thanks,
> Chamikara
>
>
>
>
> On Tue, Jun 3, 2008 at 10:24 AM, Sanjiva Weerawarana <sa...@opensource.lk>
> wrote:
>>
>> No objection at all, as long as its not castrated .. i.e., it must be ok
>> to release. Is that ok with everyone?
>>
>> Sanjiva.
>>
>> Paul Fremantle wrote:
>>>
>>> Ant
>>>
>>> I completely agree. I think the best outcome is to move the code into
>>> ASF SVN, move the discussion over, and simply treat this as a new and
>>> different codebase from Sandesha, with no implication about how this
>>> pans out in the future.
>>>
>>> Paul
>>>
>>> On Tue, Jun 3, 2008 at 12:23 PM, ant elder <an...@apache.org> wrote:
>>>>
>>>> Just for the record I'd like to point out I've been talking as a WS PMC
>>>> member. I've no idea what IBMs views are on this and haven't spoken to
>>>> anyone in IBM about it. Also I'm fine with this code coming into the
>>>> apache
>>>> svn, that would be better than being developed at wso2 imho. I do think
>>>> for
>>>> now until there's consensus on it there should be no implication yet
>>>> that
>>>> its the "next" version, as outline in the rules for revolutions doc.
>>>>
>>>> ...ant
>>>>
>>>> On Tue, Jun 3, 2008 at 12:12 PM, Sanjiva Weerawarana
>>>> <sa...@opensource.lk>
>>>> wrote:
>>>>>
>>>>> I'd like to hear what non-IBM Sandesha community members also think
>>>>> about
>>>>> this idea. If the entire community doesn't want this code coming here,
>>>>> well,
>>>>> then its ABSOLUTELY fine!
>>>>>
>>>>> Life will go on .. and if WSO2 wants to it can certainly contrib it and
>>>>> start an alternative RM impl in Apache too. Apache does not have a
>>>>> position
>>>>> saying "only one of one thing".
>>>>>
>>>>> Sanjiva.
>>>>>
>>>>> Paul Fremantle wrote:
>>>>>>
>>>>>> 1. I agree that this code should not be in Apache with a org.wso2
>>>>>> package namespace.
>>>>>> 2. I don't agree that the timing of this is so bad. There is always a
>>>>>> balance between starting something completely in the open and pushing
>>>>>> a finished object onto the community. When Amila started this, it
>>>>>> wasn't a conscious decision to replace Sandesha2 - it was simply an
>>>>>> experiment. Amila got it to the point where the experiment proved that
>>>>>> this particular approach could work and then brought it to the
>>>>>> community. And I don't think this code is that complete - there is a
>>>>>> lot of work to do on it. To be honest I think there are mixed
>>>>>> messages. On the one hand I'm hearing that its too complete and we
>>>>>> should have engaged the community earlier. On the other hand I'm
>>>>>> hearing that because it doesn't implement 1.1. it still hasn't proven
>>>>>> it can be a cleaner design that Sandesha2. Frankly I don't think there
>>>>>> is any perfect answer here.
>>>>>> 3. Apache has a strong history of allowing multiple implementations of
>>>>>> the same thing and I don't see any reason why we shouldn't have two
>>>>>> implementations of RM. Whether or not Mercury is a "replacement" for
>>>>>> Sandesha seems to be something that will only will be decided if the
>>>>>> community wants it to be that way. I think its *way* too early to tell
>>>>>> at this point if Mercury is going to enthuse the community or not. So
>>>>>> far it only implements about half of the features of Sandesha2.
>>>>>> 4. I personally think that the right thing to do here is to engage the
>>>>>> community. I think the right way to do that is to move the code to
>>>>>> org.apache.something, and move the discussions to sandesha-dev with a
>>>>>> prefix in the subject like [MERCURY]. This is what we have done time
>>>>>> and again. Either it will engage a wider audience in the design and
>>>>>> implementation or it won't, but unless we do this we can't know.
>>>>>> 5. I don't think it really matters whether Sandesha2 has bugs or not.
>>>>>> The question in my mind is whether this new implementation can be kept
>>>>>> cleaner, faster, and more maintainable than Sandesha2. If it can be
>>>>>> then it will gain support, and if not it won't. Its as simple as that.
>>>>>> But I honestly believe in the Apache way, and I don't think it will
>>>>>> end up better without the input of this community, who frankly know
>>>>>> WSRM implementation as well as anyone in the world.
>>>>>> 6. I *COMPLETELY* disagree with Ant's point about announcements. This
>>>>>> is a module that works with Axis2 and there is absolutely nothing
>>>>>> wrong with announcing it to the Axis2 community with an [ANN] header.
>>>>>> That would be true if this was a commercial extension to Axis2. But
>>>>>> this is an Apache Licensed open source project. Further, a version of
>>>>>> this code has been donated to Apache. So unless I have somehow an
>>>>>> utter misunderstanding of Apache's mailing lists I cannot see any
>>>>>> reason at all not to post this announcement.
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>> On Tue, Jun 3, 2008 at 9:18 AM, ant elder <an...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On Sat, May 31, 2008 at 4:50 PM, Glen Daniels
>>>>>>>> <gl...@thoughtcraft.com>
>>>>>>>> wrote:
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>>> While that may be true, I'm disappointed that the work moved so far
>>>>>>>>> forward before being brought to the Sandesha community, and I would
>>>>>>>>> *really* like to find some navigable path that brings us eventually
>>>>>>>>> to
>>>>>>>>> a
>>>>>>>>> single implementation of RM-over-Axis2, in Apache.
>>>>>>>
>>>>>>> Agree with that completely, this seems a really sad thing to have
>>>>>>> happened.
>>>>>>> Is there really no way to get Sandesha working with SecureRM over
>>>>>>> SMTP,
>>>>>>> there didn't seem to be much discussion about what the issues are
>>>>>>> with
>>>>>>> doing
>>>>>>> that?
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>> ...ant
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Sanjiva Weerawarana, Ph.D.
>>>>> Founder & Director; Lanka Software Foundation;
>>>>> http://www.opensource.lk/
>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>> Member; Apache Software Foundation; http://www.apache.org/
>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi All,
As I mentioned earlied, I am really eager to see Mercury being brought into
Apache (either as a branch in Sandesha2 or as a seperate WS project). What I
really want to see is a comparison between two implementations. If a feature
complete Mercury version outperforms Sandesha2 I would be more than happy to
accept it as a replacement for Sandsha2.
Thanks,
Chamikara
On Tue, Jun 3, 2008 at 10:24 AM, Sanjiva Weerawarana <sa...@opensource.lk>
wrote:
> No objection at all, as long as its not castrated .. i.e., it must be ok to
> release. Is that ok with everyone?
>
> Sanjiva.
>
>
> Paul Fremantle wrote:
>
>> Ant
>>
>> I completely agree. I think the best outcome is to move the code into
>> ASF SVN, move the discussion over, and simply treat this as a new and
>> different codebase from Sandesha, with no implication about how this
>> pans out in the future.
>>
>> Paul
>>
>> On Tue, Jun 3, 2008 at 12:23 PM, ant elder <an...@apache.org> wrote:
>>
>>> Just for the record I'd like to point out I've been talking as a WS PMC
>>> member. I've no idea what IBMs views are on this and haven't spoken to
>>> anyone in IBM about it. Also I'm fine with this code coming into the
>>> apache
>>> svn, that would be better than being developed at wso2 imho. I do think
>>> for
>>> now until there's consensus on it there should be no implication yet that
>>> its the "next" version, as outline in the rules for revolutions doc.
>>>
>>> ...ant
>>>
>>> On Tue, Jun 3, 2008 at 12:12 PM, Sanjiva Weerawarana <
>>> sanjiva@opensource.lk>
>>> wrote:
>>>
>>>> I'd like to hear what non-IBM Sandesha community members also think
>>>> about
>>>> this idea. If the entire community doesn't want this code coming here,
>>>> well,
>>>> then its ABSOLUTELY fine!
>>>>
>>>> Life will go on .. and if WSO2 wants to it can certainly contrib it and
>>>> start an alternative RM impl in Apache too. Apache does not have a
>>>> position
>>>> saying "only one of one thing".
>>>>
>>>> Sanjiva.
>>>>
>>>> Paul Fremantle wrote:
>>>>
>>>>> 1. I agree that this code should not be in Apache with a org.wso2
>>>>> package namespace.
>>>>> 2. I don't agree that the timing of this is so bad. There is always a
>>>>> balance between starting something completely in the open and pushing
>>>>> a finished object onto the community. When Amila started this, it
>>>>> wasn't a conscious decision to replace Sandesha2 - it was simply an
>>>>> experiment. Amila got it to the point where the experiment proved that
>>>>> this particular approach could work and then brought it to the
>>>>> community. And I don't think this code is that complete - there is a
>>>>> lot of work to do on it. To be honest I think there are mixed
>>>>> messages. On the one hand I'm hearing that its too complete and we
>>>>> should have engaged the community earlier. On the other hand I'm
>>>>> hearing that because it doesn't implement 1.1. it still hasn't proven
>>>>> it can be a cleaner design that Sandesha2. Frankly I don't think there
>>>>> is any perfect answer here.
>>>>> 3. Apache has a strong history of allowing multiple implementations of
>>>>> the same thing and I don't see any reason why we shouldn't have two
>>>>> implementations of RM. Whether or not Mercury is a "replacement" for
>>>>> Sandesha seems to be something that will only will be decided if the
>>>>> community wants it to be that way. I think its *way* too early to tell
>>>>> at this point if Mercury is going to enthuse the community or not. So
>>>>> far it only implements about half of the features of Sandesha2.
>>>>> 4. I personally think that the right thing to do here is to engage the
>>>>> community. I think the right way to do that is to move the code to
>>>>> org.apache.something, and move the discussions to sandesha-dev with a
>>>>> prefix in the subject like [MERCURY]. This is what we have done time
>>>>> and again. Either it will engage a wider audience in the design and
>>>>> implementation or it won't, but unless we do this we can't know.
>>>>> 5. I don't think it really matters whether Sandesha2 has bugs or not.
>>>>> The question in my mind is whether this new implementation can be kept
>>>>> cleaner, faster, and more maintainable than Sandesha2. If it can be
>>>>> then it will gain support, and if not it won't. Its as simple as that.
>>>>> But I honestly believe in the Apache way, and I don't think it will
>>>>> end up better without the input of this community, who frankly know
>>>>> WSRM implementation as well as anyone in the world.
>>>>> 6. I *COMPLETELY* disagree with Ant's point about announcements. This
>>>>> is a module that works with Axis2 and there is absolutely nothing
>>>>> wrong with announcing it to the Axis2 community with an [ANN] header.
>>>>> That would be true if this was a commercial extension to Axis2. But
>>>>> this is an Apache Licensed open source project. Further, a version of
>>>>> this code has been donated to Apache. So unless I have somehow an
>>>>> utter misunderstanding of Apache's mailing lists I cannot see any
>>>>> reason at all not to post this announcement.
>>>>>
>>>>> Paul
>>>>>
>>>>> On Tue, Jun 3, 2008 at 9:18 AM, ant elder <an...@gmail.com> wrote:
>>>>>
>>>>>> On Sat, May 31, 2008 at 4:50 PM, Glen Daniels <gl...@thoughtcraft.com>
>>>>>>> wrote:
>>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>> While that may be true, I'm disappointed that the work moved so far
>>>>>>>> forward before being brought to the Sandesha community, and I would
>>>>>>>> *really* like to find some navigable path that brings us eventually
>>>>>>>> to
>>>>>>>> a
>>>>>>>> single implementation of RM-over-Axis2, in Apache.
>>>>>>>>
>>>>>>> Agree with that completely, this seems a really sad thing to have
>>>>>> happened.
>>>>>> Is there really no way to get Sandesha working with SecureRM over
>>>>>> SMTP,
>>>>>> there didn't seem to be much discussion about what the issues are with
>>>>>> doing
>>>>>> that?
>>>>>>
>>>>>> 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
>>>>>>
>>>>>> ...ant
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>> Sanjiva Weerawarana, Ph.D.
>>>> Founder & Director; Lanka Software Foundation;
>>>> http://www.opensource.lk/
>>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>
>>
>>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
Re: Mercury, a new WS-RM implementation
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
No objection at all, as long as its not castrated .. i.e., it must be ok
to release. Is that ok with everyone?
Sanjiva.
Paul Fremantle wrote:
> Ant
>
> I completely agree. I think the best outcome is to move the code into
> ASF SVN, move the discussion over, and simply treat this as a new and
> different codebase from Sandesha, with no implication about how this
> pans out in the future.
>
> Paul
>
> On Tue, Jun 3, 2008 at 12:23 PM, ant elder <an...@apache.org> wrote:
>> Just for the record I'd like to point out I've been talking as a WS PMC
>> member. I've no idea what IBMs views are on this and haven't spoken to
>> anyone in IBM about it. Also I'm fine with this code coming into the apache
>> svn, that would be better than being developed at wso2 imho. I do think for
>> now until there's consensus on it there should be no implication yet that
>> its the "next" version, as outline in the rules for revolutions doc.
>>
>> ...ant
>>
>> On Tue, Jun 3, 2008 at 12:12 PM, Sanjiva Weerawarana <sa...@opensource.lk>
>> wrote:
>>> I'd like to hear what non-IBM Sandesha community members also think about
>>> this idea. If the entire community doesn't want this code coming here, well,
>>> then its ABSOLUTELY fine!
>>>
>>> Life will go on .. and if WSO2 wants to it can certainly contrib it and
>>> start an alternative RM impl in Apache too. Apache does not have a position
>>> saying "only one of one thing".
>>>
>>> Sanjiva.
>>>
>>> Paul Fremantle wrote:
>>>> 1. I agree that this code should not be in Apache with a org.wso2
>>>> package namespace.
>>>> 2. I don't agree that the timing of this is so bad. There is always a
>>>> balance between starting something completely in the open and pushing
>>>> a finished object onto the community. When Amila started this, it
>>>> wasn't a conscious decision to replace Sandesha2 - it was simply an
>>>> experiment. Amila got it to the point where the experiment proved that
>>>> this particular approach could work and then brought it to the
>>>> community. And I don't think this code is that complete - there is a
>>>> lot of work to do on it. To be honest I think there are mixed
>>>> messages. On the one hand I'm hearing that its too complete and we
>>>> should have engaged the community earlier. On the other hand I'm
>>>> hearing that because it doesn't implement 1.1. it still hasn't proven
>>>> it can be a cleaner design that Sandesha2. Frankly I don't think there
>>>> is any perfect answer here.
>>>> 3. Apache has a strong history of allowing multiple implementations of
>>>> the same thing and I don't see any reason why we shouldn't have two
>>>> implementations of RM. Whether or not Mercury is a "replacement" for
>>>> Sandesha seems to be something that will only will be decided if the
>>>> community wants it to be that way. I think its *way* too early to tell
>>>> at this point if Mercury is going to enthuse the community or not. So
>>>> far it only implements about half of the features of Sandesha2.
>>>> 4. I personally think that the right thing to do here is to engage the
>>>> community. I think the right way to do that is to move the code to
>>>> org.apache.something, and move the discussions to sandesha-dev with a
>>>> prefix in the subject like [MERCURY]. This is what we have done time
>>>> and again. Either it will engage a wider audience in the design and
>>>> implementation or it won't, but unless we do this we can't know.
>>>> 5. I don't think it really matters whether Sandesha2 has bugs or not.
>>>> The question in my mind is whether this new implementation can be kept
>>>> cleaner, faster, and more maintainable than Sandesha2. If it can be
>>>> then it will gain support, and if not it won't. Its as simple as that.
>>>> But I honestly believe in the Apache way, and I don't think it will
>>>> end up better without the input of this community, who frankly know
>>>> WSRM implementation as well as anyone in the world.
>>>> 6. I *COMPLETELY* disagree with Ant's point about announcements. This
>>>> is a module that works with Axis2 and there is absolutely nothing
>>>> wrong with announcing it to the Axis2 community with an [ANN] header.
>>>> That would be true if this was a commercial extension to Axis2. But
>>>> this is an Apache Licensed open source project. Further, a version of
>>>> this code has been donated to Apache. So unless I have somehow an
>>>> utter misunderstanding of Apache's mailing lists I cannot see any
>>>> reason at all not to post this announcement.
>>>>
>>>> Paul
>>>>
>>>> On Tue, Jun 3, 2008 at 9:18 AM, ant elder <an...@gmail.com> wrote:
>>>>>> On Sat, May 31, 2008 at 4:50 PM, Glen Daniels <gl...@thoughtcraft.com>
>>>>>> wrote:
>>>>> <snip>
>>>>>
>>>>>>> While that may be true, I'm disappointed that the work moved so far
>>>>>>> forward before being brought to the Sandesha community, and I would
>>>>>>> *really* like to find some navigable path that brings us eventually to
>>>>>>> a
>>>>>>> single implementation of RM-over-Axis2, in Apache.
>>>>> Agree with that completely, this seems a really sad thing to have
>>>>> happened.
>>>>> Is there really no way to get Sandesha working with SecureRM over SMTP,
>>>>> there didn't seem to be much discussion about what the issues are with
>>>>> doing
>>>>> that?
>>>>>
>>>>> 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
>>>>>
>>>>> ...ant
>>>>>
>>>>>
>>>>
>>>>
>>> --
>>> Sanjiva Weerawarana, Ph.D.
>>> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
>>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>>> Member; Apache Software Foundation; http://www.apache.org/
>>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>>
>>
>
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by Paul Fremantle <pz...@gmail.com>.
Ant
I completely agree. I think the best outcome is to move the code into
ASF SVN, move the discussion over, and simply treat this as a new and
different codebase from Sandesha, with no implication about how this
pans out in the future.
Paul
On Tue, Jun 3, 2008 at 12:23 PM, ant elder <an...@apache.org> wrote:
> Just for the record I'd like to point out I've been talking as a WS PMC
> member. I've no idea what IBMs views are on this and haven't spoken to
> anyone in IBM about it. Also I'm fine with this code coming into the apache
> svn, that would be better than being developed at wso2 imho. I do think for
> now until there's consensus on it there should be no implication yet that
> its the "next" version, as outline in the rules for revolutions doc.
>
> ...ant
>
> On Tue, Jun 3, 2008 at 12:12 PM, Sanjiva Weerawarana <sa...@opensource.lk>
> wrote:
>>
>> I'd like to hear what non-IBM Sandesha community members also think about
>> this idea. If the entire community doesn't want this code coming here, well,
>> then its ABSOLUTELY fine!
>>
>> Life will go on .. and if WSO2 wants to it can certainly contrib it and
>> start an alternative RM impl in Apache too. Apache does not have a position
>> saying "only one of one thing".
>>
>> Sanjiva.
>>
>> Paul Fremantle wrote:
>>>
>>> 1. I agree that this code should not be in Apache with a org.wso2
>>> package namespace.
>>> 2. I don't agree that the timing of this is so bad. There is always a
>>> balance between starting something completely in the open and pushing
>>> a finished object onto the community. When Amila started this, it
>>> wasn't a conscious decision to replace Sandesha2 - it was simply an
>>> experiment. Amila got it to the point where the experiment proved that
>>> this particular approach could work and then brought it to the
>>> community. And I don't think this code is that complete - there is a
>>> lot of work to do on it. To be honest I think there are mixed
>>> messages. On the one hand I'm hearing that its too complete and we
>>> should have engaged the community earlier. On the other hand I'm
>>> hearing that because it doesn't implement 1.1. it still hasn't proven
>>> it can be a cleaner design that Sandesha2. Frankly I don't think there
>>> is any perfect answer here.
>>> 3. Apache has a strong history of allowing multiple implementations of
>>> the same thing and I don't see any reason why we shouldn't have two
>>> implementations of RM. Whether or not Mercury is a "replacement" for
>>> Sandesha seems to be something that will only will be decided if the
>>> community wants it to be that way. I think its *way* too early to tell
>>> at this point if Mercury is going to enthuse the community or not. So
>>> far it only implements about half of the features of Sandesha2.
>>> 4. I personally think that the right thing to do here is to engage the
>>> community. I think the right way to do that is to move the code to
>>> org.apache.something, and move the discussions to sandesha-dev with a
>>> prefix in the subject like [MERCURY]. This is what we have done time
>>> and again. Either it will engage a wider audience in the design and
>>> implementation or it won't, but unless we do this we can't know.
>>> 5. I don't think it really matters whether Sandesha2 has bugs or not.
>>> The question in my mind is whether this new implementation can be kept
>>> cleaner, faster, and more maintainable than Sandesha2. If it can be
>>> then it will gain support, and if not it won't. Its as simple as that.
>>> But I honestly believe in the Apache way, and I don't think it will
>>> end up better without the input of this community, who frankly know
>>> WSRM implementation as well as anyone in the world.
>>> 6. I *COMPLETELY* disagree with Ant's point about announcements. This
>>> is a module that works with Axis2 and there is absolutely nothing
>>> wrong with announcing it to the Axis2 community with an [ANN] header.
>>> That would be true if this was a commercial extension to Axis2. But
>>> this is an Apache Licensed open source project. Further, a version of
>>> this code has been donated to Apache. So unless I have somehow an
>>> utter misunderstanding of Apache's mailing lists I cannot see any
>>> reason at all not to post this announcement.
>>>
>>> Paul
>>>
>>> On Tue, Jun 3, 2008 at 9:18 AM, ant elder <an...@gmail.com> wrote:
>>>>>
>>>>> On Sat, May 31, 2008 at 4:50 PM, Glen Daniels <gl...@thoughtcraft.com>
>>>>> wrote:
>>>>
>>>> <snip>
>>>>
>>>>>> While that may be true, I'm disappointed that the work moved so far
>>>>>> forward before being brought to the Sandesha community, and I would
>>>>>> *really* like to find some navigable path that brings us eventually to
>>>>>> a
>>>>>> single implementation of RM-over-Axis2, in Apache.
>>>>
>>>> Agree with that completely, this seems a really sad thing to have
>>>> happened.
>>>> Is there really no way to get Sandesha working with SecureRM over SMTP,
>>>> there didn't seem to be much discussion about what the issues are with
>>>> doing
>>>> that?
>>>>
>>>> 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
>>>>
>>>> ...ant
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
>> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
>> Member; Apache Software Foundation; http://www.apache.org/
>> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by ant elder <an...@apache.org>.
Just for the record I'd like to point out I've been talking as a WS PMC
member. I've no idea what IBMs views are on this and haven't spoken to
anyone in IBM about it. Also I'm fine with this code coming into the apache
svn, that would be better than being developed at wso2 imho. I do think for
now until there's consensus on it there should be no implication yet that
its the "next" version, as outline in the rules for revolutions doc.
...ant
On Tue, Jun 3, 2008 at 12:12 PM, Sanjiva Weerawarana <sa...@opensource.lk>
wrote:
> I'd like to hear what non-IBM Sandesha community members also think about
> this idea. If the entire community doesn't want this code coming here, well,
> then its ABSOLUTELY fine!
>
> Life will go on .. and if WSO2 wants to it can certainly contrib it and
> start an alternative RM impl in Apache too. Apache does not have a position
> saying "only one of one thing".
>
> Sanjiva.
>
>
> Paul Fremantle wrote:
>
>> 1. I agree that this code should not be in Apache with a org.wso2
>> package namespace.
>> 2. I don't agree that the timing of this is so bad. There is always a
>> balance between starting something completely in the open and pushing
>> a finished object onto the community. When Amila started this, it
>> wasn't a conscious decision to replace Sandesha2 - it was simply an
>> experiment. Amila got it to the point where the experiment proved that
>> this particular approach could work and then brought it to the
>> community. And I don't think this code is that complete - there is a
>> lot of work to do on it. To be honest I think there are mixed
>> messages. On the one hand I'm hearing that its too complete and we
>> should have engaged the community earlier. On the other hand I'm
>> hearing that because it doesn't implement 1.1. it still hasn't proven
>> it can be a cleaner design that Sandesha2. Frankly I don't think there
>> is any perfect answer here.
>> 3. Apache has a strong history of allowing multiple implementations of
>> the same thing and I don't see any reason why we shouldn't have two
>> implementations of RM. Whether or not Mercury is a "replacement" for
>> Sandesha seems to be something that will only will be decided if the
>> community wants it to be that way. I think its *way* too early to tell
>> at this point if Mercury is going to enthuse the community or not. So
>> far it only implements about half of the features of Sandesha2.
>> 4. I personally think that the right thing to do here is to engage the
>> community. I think the right way to do that is to move the code to
>> org.apache.something, and move the discussions to sandesha-dev with a
>> prefix in the subject like [MERCURY]. This is what we have done time
>> and again. Either it will engage a wider audience in the design and
>> implementation or it won't, but unless we do this we can't know.
>> 5. I don't think it really matters whether Sandesha2 has bugs or not.
>> The question in my mind is whether this new implementation can be kept
>> cleaner, faster, and more maintainable than Sandesha2. If it can be
>> then it will gain support, and if not it won't. Its as simple as that.
>> But I honestly believe in the Apache way, and I don't think it will
>> end up better without the input of this community, who frankly know
>> WSRM implementation as well as anyone in the world.
>> 6. I *COMPLETELY* disagree with Ant's point about announcements. This
>> is a module that works with Axis2 and there is absolutely nothing
>> wrong with announcing it to the Axis2 community with an [ANN] header.
>> That would be true if this was a commercial extension to Axis2. But
>> this is an Apache Licensed open source project. Further, a version of
>> this code has been donated to Apache. So unless I have somehow an
>> utter misunderstanding of Apache's mailing lists I cannot see any
>> reason at all not to post this announcement.
>>
>> Paul
>>
>> On Tue, Jun 3, 2008 at 9:18 AM, ant elder <an...@gmail.com> wrote:
>>
>>> On Sat, May 31, 2008 at 4:50 PM, Glen Daniels <gl...@thoughtcraft.com>
>>>> wrote:
>>>>
>>> <snip>
>>>
>>> While that may be true, I'm disappointed that the work moved so far
>>>>> forward before being brought to the Sandesha community, and I would
>>>>> *really* like to find some navigable path that brings us eventually to
>>>>> a
>>>>> single implementation of RM-over-Axis2, in Apache.
>>>>>
>>>> Agree with that completely, this seems a really sad thing to have
>>> happened.
>>> Is there really no way to get Sandesha working with SecureRM over SMTP,
>>> there didn't seem to be much discussion about what the issues are with
>>> doing
>>> that?
>>>
>>> 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
>>>
>>> ...ant
>>>
>>>
>>>
>>
>>
>>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
Re: Mercury, a new WS-RM implementation
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
I'd like to hear what non-IBM Sandesha community members also think about
this idea. If the entire community doesn't want this code coming here,
well, then its ABSOLUTELY fine!
Life will go on .. and if WSO2 wants to it can certainly contrib it and
start an alternative RM impl in Apache too. Apache does not have a
position saying "only one of one thing".
Sanjiva.
Paul Fremantle wrote:
> 1. I agree that this code should not be in Apache with a org.wso2
> package namespace.
> 2. I don't agree that the timing of this is so bad. There is always a
> balance between starting something completely in the open and pushing
> a finished object onto the community. When Amila started this, it
> wasn't a conscious decision to replace Sandesha2 - it was simply an
> experiment. Amila got it to the point where the experiment proved that
> this particular approach could work and then brought it to the
> community. And I don't think this code is that complete - there is a
> lot of work to do on it. To be honest I think there are mixed
> messages. On the one hand I'm hearing that its too complete and we
> should have engaged the community earlier. On the other hand I'm
> hearing that because it doesn't implement 1.1. it still hasn't proven
> it can be a cleaner design that Sandesha2. Frankly I don't think there
> is any perfect answer here.
> 3. Apache has a strong history of allowing multiple implementations of
> the same thing and I don't see any reason why we shouldn't have two
> implementations of RM. Whether or not Mercury is a "replacement" for
> Sandesha seems to be something that will only will be decided if the
> community wants it to be that way. I think its *way* too early to tell
> at this point if Mercury is going to enthuse the community or not. So
> far it only implements about half of the features of Sandesha2.
> 4. I personally think that the right thing to do here is to engage the
> community. I think the right way to do that is to move the code to
> org.apache.something, and move the discussions to sandesha-dev with a
> prefix in the subject like [MERCURY]. This is what we have done time
> and again. Either it will engage a wider audience in the design and
> implementation or it won't, but unless we do this we can't know.
> 5. I don't think it really matters whether Sandesha2 has bugs or not.
> The question in my mind is whether this new implementation can be kept
> cleaner, faster, and more maintainable than Sandesha2. If it can be
> then it will gain support, and if not it won't. Its as simple as that.
> But I honestly believe in the Apache way, and I don't think it will
> end up better without the input of this community, who frankly know
> WSRM implementation as well as anyone in the world.
> 6. I *COMPLETELY* disagree with Ant's point about announcements. This
> is a module that works with Axis2 and there is absolutely nothing
> wrong with announcing it to the Axis2 community with an [ANN] header.
> That would be true if this was a commercial extension to Axis2. But
> this is an Apache Licensed open source project. Further, a version of
> this code has been donated to Apache. So unless I have somehow an
> utter misunderstanding of Apache's mailing lists I cannot see any
> reason at all not to post this announcement.
>
> Paul
>
> On Tue, Jun 3, 2008 at 9:18 AM, ant elder <an...@gmail.com> wrote:
>>> On Sat, May 31, 2008 at 4:50 PM, Glen Daniels <gl...@thoughtcraft.com>
>>> wrote:
>> <snip>
>>
>>>> While that may be true, I'm disappointed that the work moved so far
>>>> forward before being brought to the Sandesha community, and I would
>>>> *really* like to find some navigable path that brings us eventually to a
>>>> single implementation of RM-over-Axis2, in Apache.
>> Agree with that completely, this seems a really sad thing to have happened.
>> Is there really no way to get Sandesha working with SecureRM over SMTP,
>> there didn't seem to be much discussion about what the issues are with doing
>> that?
>>
>> 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
>>
>> ...ant
>>
>>
>
>
>
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by Paul Fremantle <pz...@gmail.com>.
1. I agree that this code should not be in Apache with a org.wso2
package namespace.
2. I don't agree that the timing of this is so bad. There is always a
balance between starting something completely in the open and pushing
a finished object onto the community. When Amila started this, it
wasn't a conscious decision to replace Sandesha2 - it was simply an
experiment. Amila got it to the point where the experiment proved that
this particular approach could work and then brought it to the
community. And I don't think this code is that complete - there is a
lot of work to do on it. To be honest I think there are mixed
messages. On the one hand I'm hearing that its too complete and we
should have engaged the community earlier. On the other hand I'm
hearing that because it doesn't implement 1.1. it still hasn't proven
it can be a cleaner design that Sandesha2. Frankly I don't think there
is any perfect answer here.
3. Apache has a strong history of allowing multiple implementations of
the same thing and I don't see any reason why we shouldn't have two
implementations of RM. Whether or not Mercury is a "replacement" for
Sandesha seems to be something that will only will be decided if the
community wants it to be that way. I think its *way* too early to tell
at this point if Mercury is going to enthuse the community or not. So
far it only implements about half of the features of Sandesha2.
4. I personally think that the right thing to do here is to engage the
community. I think the right way to do that is to move the code to
org.apache.something, and move the discussions to sandesha-dev with a
prefix in the subject like [MERCURY]. This is what we have done time
and again. Either it will engage a wider audience in the design and
implementation or it won't, but unless we do this we can't know.
5. I don't think it really matters whether Sandesha2 has bugs or not.
The question in my mind is whether this new implementation can be kept
cleaner, faster, and more maintainable than Sandesha2. If it can be
then it will gain support, and if not it won't. Its as simple as that.
But I honestly believe in the Apache way, and I don't think it will
end up better without the input of this community, who frankly know
WSRM implementation as well as anyone in the world.
6. I *COMPLETELY* disagree with Ant's point about announcements. This
is a module that works with Axis2 and there is absolutely nothing
wrong with announcing it to the Axis2 community with an [ANN] header.
That would be true if this was a commercial extension to Axis2. But
this is an Apache Licensed open source project. Further, a version of
this code has been donated to Apache. So unless I have somehow an
utter misunderstanding of Apache's mailing lists I cannot see any
reason at all not to post this announcement.
Paul
On Tue, Jun 3, 2008 at 9:18 AM, ant elder <an...@gmail.com> wrote:
>
>> On Sat, May 31, 2008 at 4:50 PM, Glen Daniels <gl...@thoughtcraft.com>
>> wrote:
>
> <snip>
>
>>
>> > While that may be true, I'm disappointed that the work moved so far
>> > forward before being brought to the Sandesha community, and I would
>> > *really* like to find some navigable path that brings us eventually to a
>> > single implementation of RM-over-Axis2, in Apache.
>
> Agree with that completely, this seems a really sad thing to have happened.
> Is there really no way to get Sandesha working with SecureRM over SMTP,
> there didn't seem to be much discussion about what the issues are with doing
> that?
>
> 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
>
> ...ant
>
>
--
Paul Fremantle
Co-Founder and CTO, WSO2
Apache Synapse PMC Chair
OASIS WS-RX TC Co-chair
blog: http://pzf.fremantle.org
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: Mercury, a new WS-RM implementation
Posted by ant elder <an...@gmail.com>.
> On Sat, May 31, 2008 at 4:50 PM, Glen Daniels <gl...@thoughtcraft.com>
> wrote:
>
<snip>
> > While that may be true, I'm disappointed that the work moved so far
> > forward before being brought to the Sandesha community, and I would
> > *really* like to find some navigable path that brings us eventually to a
> > single implementation of RM-over-Axis2, in Apache.
>
Agree with that completely, this seems a really sad thing to have happened.
Is there really no way to get Sandesha working with SecureRM over SMTP,
there didn't seem to be much discussion about what the issues are with doing
that?
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
...ant