axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: [WSIF] Improving performance of WSIF stub invocation
Date Tue, 08 Oct 2002 18:48:54 GMT
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



Mime
View raw message