axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eran Chinthaka <chinth...@opensource.lk>
Subject Re: [Axis2] Mediators require unique MessageContexts?
Date Fri, 14 Oct 2005 16:25:45 GMT
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> 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]
>>>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