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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [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. > > > > > > > > >
