I still think it may be better to leave this decision to the WSIFPort. When
calling createOperation on the WSIFPort then the WSIFPort is free to decide
whether to create a new WSIFOperation or to use an existing cached
WSIFOperation. Actually I thought this was already the way the providers
did it - looks like the WSIFPort_Java does do this now. Which provider were
you testing to get the performance increases?
Be great if some of the others could comment on this, I know Owen has done
some performance work on caching of various things...
...ant
Anthony Elder
[EMAIL PROTECTED]
Web Services Development
IBM UK Laboratories, Hursley Park
(+44) 01962 818320, x248320, MP208.
Nirmal Mukhi/Watson/IBM@IBMUS on 08/10/2002 19:30:50
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
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:
[EMAIL PROTECTED]
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
[EMAIL PROTECTED]
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 [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
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.
