axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Fremantle" <...@hursley.ibm.com>
Subject Re: [WSIF] Improving performance of WSIF stub invocation
Date Wed, 09 Oct 2002 14:04:26 GMT
Nirmal

Erm... This design point came from the JCA team. Michael B in particular was
adamant we did it this way, and we (Sanjiva, Michael and I) went through a
number of iterations on this.

I don't believe we can change this without agreement from the JCA provider
team.

How about explicitly identifying which providers require stateful operations
and which dont. Those that dont could reuse operations from a cache, ignore
closes etc. I'm not sure this will help us either. At the moment our HTTP
support is not efficient because we don't reuse HTTP connections. If we
updated it to be much more closely bound to the real HTTP interactions then
maybe close() might be useful?? I havent really thought this through, but I
know that close() was designed to allow long running connections.

Paul


----- Original Message -----
From: "Nirmal Mukhi" <nmukhi@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Tuesday, October 08, 2002 7:30 PM
Subject: Re: [WSIF] Improving performance of WSIF stub invocation


>
>
>
>
>
> Hi,
>
> There might be some cases where some state is leftover at the end of the
> invocation which might interfere with the next one. So I suggest we do
this
> the following way:
> 1. Advise developers that the intent of the close() method on
WSIFOperation
> is to give them the opportunity to do any clean up that may be required
> before the next invocation using the same object.
> 2. Write a default close() method that does nothing.
>
> Even to accomodate such state cleanup, it shouldn't be necssary to discard
> the old object and create a new one for the next invocation, that is
> overkill - providers can implement close() however they like in their
> implementations of WSIFOperation and that should be sufficient.
>
> To fix our code to implement the above scheme, we just need to get rid of
> the "closed" flag in WSIFDefaultOperation (then we have full reuse enabled
> in the base implementation); next we test multiple invocations with each
> provider and make sure they work, adding a custom close() method if they
> don't. Ant, if you volunteer to make these changes (shouldn't take long,
> since I doubt you will need any custom close() implementations) it would
be
> a great independent verification of this.
>
> Nirmal.
>
>
>
>                       Anthony
>                       Elder/UK/IBM@IBMG        To:
axis-dev@xml.apache.org
>                       B                        cc:
>                                                Subject:  Re: [WSIF]
Improving performance of WSIF stub invocation
>                       10/08/2002 01:39
>                       PM
>                       Please respond to
>                       axis-dev
>
>
>
>
>
>
> I'd be a bit nervous about reusing WSIFOperations. I'd always been under
> the impression that we could assume a WSIFOperation would not be reused.
> Whether or not that's the correct design that's the way some of the
> providers may have been written. I'm out this week so don't have so much
> time to check, but things like JMS properties and the context could end up
> with residual data. There's also the providers that others have written
> that we don't have control over. Isn't it safer to let  the WSIFPort
decide
> if it wants to cache and reuse a WSIFOperation?
>
>        ...ant
>
> Anthony Elder
> ant.elder@uk.ibm.com
> Web Services Development
> IBM UK Laboratories,  Hursley Park
> (+44) 01962 818320, x248320, MP208.
>
>
> Nirmal Mukhi/Watson/IBM@IBMUS on 07/10/2002 15:21:15
>
> Please respond to axis-dev@xml.apache.org
>
> To:    axis-dev@xml.apache.org
> cc:
> Subject:    [WSIF] Improving performance of WSIF stub invocation
>
>
>
>
>
>
>
> Hello,
>
> I've been doing a bit of work on improving WSIF performance, right now I'm
> concentrating on improvements to the dynamic proxy (this is
> provider-independent code and thus affects all stub invocations).
>
> I noticed that in the code reuse of WSIFOperation objects for multiple
> invocations is prevented - providers call the close() method after an
> invocation is complete that tags the operation as having been used; this
> flag is checked prior to a use. I don't see why this should be done.
> WSIFOperation objects should not hold any state specific to a single
> invocation, so why is reuse bad? Reusing operations results in a big
> performance improvement, since creating them is somewhat expensive.  As a
> test, I disabled the "closed" flag and cached WSIF operation objects
> created by the dynamic proxy, and things worked great. Anybody have any
> reason I should not do that? The right way to fix this of course would be
> to eliminate the existence of the close method completely (but this would
> require minor changes in all providers).
>
> I also added caching of WSDL operations (so java method calls via the stub
> interface don't have to be mapped to the WSDL operation each time) and
> caching of messages used during invocations (it's safe to do this since we
> overwrite all message parts before invocation) in the dynamic proxy. These
> changes are fairly straightforward.
>
> Altogether the stub invocation became approximately 5 - 9 times faster
than
> before for a large number of invocations. I'll commit my changes in a
> couple of days if nobody has objections.
>
> Thanks,
> Nirmal.
>
>
>
>
>
>
>
>
>


Mime
View raw message