Ohh, I'm the one who did both things. Let me defend myself :-)

ant elder wrote:
Regarding Glen's 2nd point, I'd noticed it did seem a bit slow creating the
out MC in AbstractInOutSyncMessageReceiver (code now moved to the
InOutSyncReceiver and InOutAsync receiver both copies some stuff from the IN msgCtx to OUT msgCtx. So we basically had two copies of the same code. I had two option.
1. Creating an AbstractInOutMesssageReceiver which extends from Message AbstractMessageReceiver. And move the general code there. Then extend AbstractInOutAsyncMessageReceiver and AbstractInOutSyncMessageReceiver from AbstractInOutMesssageReceiver.
But the problem is that;  
    i) this will add one more level in the inheritance hierarchy
    ii) if there is other MEP which should need copy stuff from IN msgCtx to OUT msgCtx, we have to write the code there too.
2. Move the common code to the Util class and call that from any message receiver who needs copy the stuff.

So I selected option two, which seems, at least to me, the best option.
Delving into that this morning this is due
to the call to UUIDGenerator.getUUID(). That is _really_ slow, takes about
1ms on my machine, accounting for about 65% of the total service invocation!
Well, you all agree that we need a UUID generator. This is required for creating message ids, MTOM ids, Sandesha stuff, etc.. We could have easily taken the commons UUID generator, but that will add another jar to Axis2. When that happens you people will shout and say, Axis2 download is large. So I try my level best to avoid adding new jars.
Thilina and Dims were kind enough to write an acceptable level of UUID generator for Axis2 which we are using. If this is a performance killer, please please help us to have a better one. I'm a performance concern guy. So please be kind enough to help us, if possible. If you have better Axis2, you will have better Synapse as well ;-) .  If you all think that commons UUID generator is far better in performance than the existing one, then I also will compromise and will agree to put the commons one.

Hope that explanation helped you.

-- Chinthaka

On 10/14/05, Glen Daniels <gdaniels@sonicsoftware.com> wrote:
Two comments:

a) If indeed an MC can be "re-set" to pass through the engine again
without screwing anything up, that might be something good to look into.

b) MC's are inherently supposed to be as cheap as possible to set up and
tear down. So let's first do basic optimization of MC
creation/destruction, and *then* think about pooling and reuse after we
see how things perform. Clearly we don't want to be doing actual copies
of the message in any case - that we definitely need to be careful


-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
Sent: Thursday, October 13, 2005 7:53 PM
To: synapse-dev@ws.apache.org
Subject: Re: Mediators require unique MessageContexts?

On Thu, 2005-10-13 at 23:15 +0100, Paul Fremantle wrote:

Each rule applies the appropriate QoS handlers to the MC.
So each rule
is a pass through the Axis Engine.

However, I don't know Axis2 internals enough to be sure
that requires
a new MC.
MC's don't live in isolation in Axis2; they come into existence under
the guise of an operation context with a MEP etc.. The concern is that
by re-using the same MC we screw up the guts a bit .. but
maybe that can
be addressed. Need to think thru that a bit more.


To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org

To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org