synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <ant.el...@gmail.com>
Subject Re: [Axis2] Mediators require unique MessageContexts?
Date Fri, 14 Oct 2005 16:43:46 GMT
To make the UUID generator a bit faster how about doing all the complicated
computation to come up with a unique ID just the one time, then for all
subsequent requests just append an incrementing integer onto the original
unique id.

On 10/14/05, Eran Chinthaka <chinthaka@opensource.lk> wrote:
>
> 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
> Utils.createOutMessageContext).
>
>  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> <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.
> However...
>
> 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
> about.
>
> --G
>
>      -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk <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:
>
>  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: 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
>
>
>

Mime
View raw message