hi nirmal, i think that performance numbers both for CPU and memory utilizaton backed by a performance test would make the most convincing arguments - after all you have mentioned that in some situation "stu incocation became approximately 5 - 9 times faster" and i would think that WSIF overhead shoudl be _almost_ neglibable when comared with using SOAP direclty ...
Nirmal Mukhi wrote: > 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. actually couldnt WSIF be responsible to call close() in stub - so this would be the contract between WSIF and provider - call to close() signals provider implementaiton of WSIFOperation that it should release any transient state ... > 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. this shows that it would be good to define/document what is exaclty required from WSIF provider (what is contract) ... > 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? we are only now reaching a stable version so we should make chnages now and not wait until later when it would be almost impossible ... thanks, alek
