axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nirmal Mukhi" <>
Subject Re: [WSIF] Improving performance of WSIF stub invocation
Date Tue, 08 Oct 2002 19:03:11 GMT


My comments below, prefixed with "NM>".


                      Slominski                To:         
                      <aslom@cs.indiana        cc:                                    
                      .edu>                    Subject:  Re: [WSIF] Improving performance
of WSIF stub invocation         
                      10/08/2002 02:48                                                   
                      Please respond to                                                  

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
approximately 5 - 9 times faster" and i would think that WSIF overhead
be _almost_ neglibable when comared with using SOAP direclty ...

NM> Yes, I think we need to set up performance tests to exercise all
providers and measure the
NM> numbers. I volunteer to do a first cut - the tests won't be NM> very
accurate but I think it will
NM> be good to have the infrastructure, we can improve on the perf testing
methodology later.

NM> Theoretically calling a SOAP service through WSIF should not be much
more expensive
NM>  than using the SOAP APIs directly, that is true (and ditto for other
providers, except
NM> perhaps local java, since there WSIF is bound to add a lot of overhead,
relatively speaking).
NM> So we'll make that the goal of the perf improvements.

> 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
> the following way:
> 1. Advise developers that the intent of the close() method on
> 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
> 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
be the contract between WSIF and provider - call to close() signals
implementaiton of WSIFOperation that it should release any transient state

NM> I agree, the stub would be the best place to call close() (at the end
NM> each invocation)

> 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
> 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
> a great independent verification of this.

this shows that it would be good to define/document what is exaclty
from WSIF provider (what is contract) ...

NM> Yes. Volunteers?

> 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
> 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
> 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 ...



View raw message