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.
