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 Utils.createOutMessageContext). 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!

On 10/14/05, Glen Daniels <> 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 []
> Sent: Thursday, October 13, 2005 7:53 PM
> To:
> Subject: Re: Mediators require unique MessageContexts?
> On Thu, 2005-10-13 at 23:15 +0100, Paul Fremantle wrote:
> > Ant
> >
> > 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.
> Sanjiva.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail: