Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 5404 invoked from network); 14 Oct 2005 17:20:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 14 Oct 2005 17:20:00 -0000 Received: (qmail 23180 invoked by uid 500); 14 Oct 2005 17:19:58 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 23152 invoked by uid 500); 14 Oct 2005 17:19:58 -0000 Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@ws.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list axis-dev@ws.apache.org Received: (qmail 23137 invoked by uid 99); 14 Oct 2005 17:19:57 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Oct 2005 10:19:57 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [209.68.5.17] (HELO relay03.pair.com) (209.68.5.17) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 14 Oct 2005 10:19:58 -0700 Received: (qmail 17281 invoked from network); 14 Oct 2005 17:19:34 -0000 Received: from unknown (HELO ?127.0.0.1?) (unknown) by unknown with SMTP; 14 Oct 2005 17:19:34 -0000 X-pair-Authenticated: 220.247.230.227 Message-ID: <434FE894.8050701@opensource.lk> Date: Fri, 14 Oct 2005 23:19:16 +0600 From: Eran Chinthaka Reply-To: chinthaka@opensource.lk User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: synapse-dev@ws.apache.org, axis-dev@ws.apache.org Subject: Re: [Axis2] Mediators require unique MessageContexts? References: <80A43FC052CE3949A327527DCD5D6B2701592FF8@MAIL01.bedford.progress.com> <71e1b5740510140052m259a9ab0xdd9897f599a64f68@mail.gmail.com> <434FDC09.7080702@opensource.lk> <71e1b5740510140943m4399416aw1c9f62ed0bed5460@mail.gmail.com> <19e0530f0510140953n26bbe58fqefb80beccbb4d1ed@mail.gmail.com> In-Reply-To: <19e0530f0510140953n26bbe58fqefb80beccbb4d1ed@mail.gmail.com> X-Enigmail-Version: 0.93.0.0 Content-Type: multipart/alternative; boundary="------------050309040301000703040408" X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. --------------050309040301000703040408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Created a JIRA for this issue here : http://issues.apache.org/jira/browse/AXIS2-282 Ant, you can either attach your patch to the above issue or send the patch to Axis2 dev list. If you have problems let us know. Chinthaka Davanum Srinivas wrote: >ant, > >+1, please submit a patch against latest SVN for axis2. > >thanks, >dims > >On 10/14/05, ant elder wrote: > > >>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 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 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 >>> >>> >>> >>> >>> >>> >>> >>> >> >> > > >-- >Davanum Srinivas : http://wso2.com/blogs/ > >--------------------------------------------------------------------- >To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org >For additional commands, e-mail: synapse-dev-help@ws.apache.org > > > > > --------------050309040301000703040408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Created a JIRA for this issue here :  http://issues.apache.org/jira/browse/AXIS2-282

Ant, you can either attach your patch to the above issue or send the patch to Axis2 dev list. If you have problems let us know.

Chinthaka

Davanum Srinivas wrote: 
ant,

+1, please submit a patch against latest SVN for axis2.

thanks,
dims

On 10/14/05, ant elder <ant.elder@gmail.com> wrote:
  
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> 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






      
    


--
Davanum Srinivas : http://wso2.com/blogs/

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