Hi Cedric. I've done some tests with both pooled stubs and non-pooled stubs (instantiating the stub object on every call), and as you say there's absolutely no difference (I did a test run of 1000 calls on each). This surprises me, but just goes to show that you should always test before optimising.
Thanks for your help. Neil. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cyrille Le Clerc Sent: Tuesday, 24 January 2006 2:01 a.m. To: [email protected] Subject: Re: Generated Stub Thread-safe? Hello Neil, I agree with you on the point that if stubs are caching ser/deser classes, it implies that these stubs were intended to be reused. However, I have re-run my micro benchmark with a "real life" stub (13 types in the WSDL) and the cost of instantiating stubs still seems negligible. With jdk-1.5.0_06, instantiation of 1 serviceLocator + 10 000 complex stubs took 220 ms against 70 ms with simple helloWorld stubs. I conclude that, thanks to JVM optimizations, complex Stubs remain lightweight objects to instantiate. The gain of pooling stubs would be in micro seconds. I expect it to be negligible in front of the cost of a soap over http call. Moreover, if you decide to pool the stubs, there is an additional complexity of cleaning stubs when they are returned to the pool (calling Stub.clearHeaders() and Stub.clearAttachments() ). I expect that in most cases, the end-to-end gain of performances will not justify this increase of complexity. On the other side, I would be interested in contributing to a modification of the Axis stubs architecture to optimize their instantiation (turning the cachedSerXXX variables into statics). If this can take place in the Axis 1.X roadmap (remembering that Axis 2.0 is the major focus nowadays) ... Hope this helps, Cyrille -- Cyrille Le Clerc [EMAIL PROTECTED] [EMAIL PROTECTED] 06.61.33.69.86 On 1/22/06, Ferguson, Neil, VF-NZ <[EMAIL PROTECTED]> wrote: > Hi guys. > > This is very useful, thanks. > > This definitely shows that I should cache the service locator. From > looking at the tests there doesn't seem to be any doubt about that. > > As for the stub, I haven't performed any performance tests, but from a > brief look at the source code it doesn't look like a particularly > lightweight object to me. It caches all of the type information for > the service on instantiation. Of course, the cost of instantiating the > stub will be very dependent on the complexity of the service it's > generated against. That could be one reason why Cyrille's tests showed > instantiating the stub to be relatively inexpensive (The stub is > called HelloWorldBindingStub and I'm guessing it has one method with > no params that returns a String -- correct me if I'm wrong!). > > Also, since the stub is doing all this caching it kind of implies that > a stub instance is meant to be reused (for purposes other than > maintaining a client-side session I would think). > > Perhaps the best method is for me to cache a reference to the service > locator, and pool my stub instances. Each thread will get a unique > stub instance from the pool (or create one if it's not available). > > Regards. > > Neil. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Cyrille Le Clerc > Sent: Saturday, 21 January 2006 12:27 a.m. > To: [email protected] > Subject: Re: Generated Stub Thread-safe? > > > Hello Chris, > > I didn't see such a cost of instantiating stubs with Axis 1.3. > > > I played a very simple microbenchmark against Axis 1.3 that showed > : > - instantiation of stub is really fast > - instantiation of the ServiceLocator is really slow > > The benchmark was to instantiate 10 000 stubs either reusing the > same service locator or instantiating a new service locator each time. > The first scenario was only took 70 ms when the second took 53 000 ms > (700 times slower). > > I know the limitations of micro benchmarks but it makes me feel > confident. > > More over, I re-checked the 1.3 source code and I didn't see any > jar scanning activities. > > Cyrille > > -- > Cyrille Le Clerc > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > MICRO BENCHMARK RESULT > ======================= > instantiate 10 000 stubs > reuse servicelocator, duration in millis : 2473 => initialization > instantiate service locator every time, duration in millis : 55110 > reuse servicelocator, duration in millis : 70 instantiate service > locator every time, duration in millis : 53727 reuse servicelocator, > duration in millis : 60 instantiate service locator every time, > duration in millis : 52766 reuse servicelocator, duration in millis : > 70 instantiate service locator every time, duration in millis : 53267 > reuse servicelocator, duration in millis : 70 instantiate service > locator every time, duration in millis : 50132 reuse servicelocator, > duration in millis : 50 > > MICRO BENCHMARK CODE > ===================== > for (int testCounter = 0; testCounter < 10; testCounter++) { > { > // reuse service locator > long timeBefore = System.currentTimeMillis(); > HelloWorldServiceLocator helloWorldServiceLocator = new > HelloWorldServiceLocator(); > for (int invocationCounter = 0; invocationCounter < 10000; > invocationCounter++) { > HelloWorldBindingStub bindingUserTic = > (HelloWorldBindingStub) helloWorldServiceLocator > .gethelloWorldBinding(); > } > long timeAfter = System.currentTimeMillis(); > System.out.println("reuse servicelocator, duration in millis : " > + (timeAfter - timeBefore)); > } > { > // instantiate service locator every time > long timeBefore = System.currentTimeMillis(); > for (int invocationCounter = 0; invocationCounter < 10000; > invocationCounter++) { > HelloWorldServiceLocator helloWorldServiceLocator = new > HelloWorldServiceLocator(); > HelloWorldBindingStub bindingUserTic = > (HelloWorldBindingStub) helloWorldServiceLocator > .gethelloWorldBinding(); > } > long timeAfter = System.currentTimeMillis(); > System.out.println("instantiate service locator every time, > duration in millis : " > + (timeAfter - timeBefore)); > } > } > > > On 1/20/06, Ebert, Chris <[EMAIL PROTECTED]> wrote: > > Maybe this changed in 1.3, but I found instantiating stubs to be > > heavyweight -- it triggered a scan of all jar files on the classpath > > in 1.1... Chris > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > On Behalf Of Cyrille Le Clerc > > Sent: Thursday, January 19, 2006 15:50 > > To: [email protected] > > Subject: Re: Generated Stub Thread-safe? > > > > Hello Neil, > > > > Axis 1.3 stubs are NOT thread safe. You will face problems if > > your calls involve soap headers or attachments for example. > > > > Note that can can reuse a stub. By the way, reusing a stub is the > > pattern to maintain a client side session (you then also have to > > call > > stub.setMaintainSession(true) ). > > > > If you use stateless soap calls, the simplest pattern is to use : > > - a single instance of the serviceLocator (acts as the stub factory) > > - to instantiate one new instance of the stub for each call and then > > throw this instance away > > > > If you use stateful soap calls, the simplest pattern is to use : > > - a single instance of the serviceLocator (acts as the stub factory) > > - to instantiate one new instance of the stub per session, perform > > the > > > calls and then throw this instance away > > > > > > Note that the cost of instantiating new stubs is small because > > the stubs are lightweight objects. > > An optimization to lower this cost could be to : > > - reduce the initial size of the vectors variables of > > org.apache.axis.client.Stub : "headers" and "attachments" > > - change to static the instance variables of the generated stubs > > (com.mycompany.MyServiceBindingStub) and initialize them in a static > > block : "cachedSerClasses", "cachedSerQNames", "cachedSerFactories", > > "cachedDeserFactories" > > > > Not that is is very important to reuse the same instance of the > > serviceLocator to instantiate all the stubs because : > > - serviceLocator is a heavyweight object (it holds its own > > AxisEngine) > > - if you use the CommonsHTTPSender, the serviceLocator holds this > > Sender (via the AxisEngine) and this CommonsHTTPSender MUST be shared > > among Stubs to benefit of the pooled http connections > > > > > > I have deduced these points analyzing Axis source code. If > > somebody > > > can confirm or contradict ? > > > > Hope this help, > > > > Cyrille > > > > -- > > Cyrille Le Clerc > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > On 1/19/06, Ferguson, Neil, VF-NZ <[EMAIL PROTECTED]> > > wrote: > > > > > > > > > Hi. > > > > > > I was wondering if anybody could give me a definitive answer on > > > whether the stub generated by WSDL2Java (Axis 1.3) is thread-safe > > > (i.e. it can safely be used by multiple concurrent threads without > > external synchronization)? > > > Unfortunately "I've tried it and it works" probably won't be > > > enough for me, I'll probably need some documentation to back it > > > up. > > > > > > Also, if it is thread-safe are there any performance implications > > > of > > > > multiple threads using it (i.e. it does lots of synchronization > > internally)? > > > > > > Perhaps I should just pool my stubs to be on the safe side. Any > > thoughts? > > > > > > Thanks. > > > > > > Neil. > > > ________________________________ > > > > > > > > > Have you seen our website? .... www.vodafone.co.nz > > > > > > Manage Your Account, check your Vodafone Mail and send web2TXT > > > online: www.vodafone.co.nz/myvodafone > > > ________________________________ > > > > > > CAUTION: This correspondence is confidential and intended for the > > > named > > > recipient(s) only. If you are not the named recipient and receive > > > this correspondence in error, you must not copy, distribute or > > > take any action in reliance on it and you should delete it from > > > your system > > > > > and notify the sender immediately. Thank you. > > > > > > Unless otherwise stated, any views or opinions expressed are > > > solely those of the author and do not represent those of Vodafone > > > New Zealand > > Limited. > > > > > > 20 Viaduct Harbour Avenue, Private Bag 92161, Auckland 1030 > > > Telephone > > > + 64 9 355 2000 Facsimile + 64 9 355 2001 > > > ________________________________ > > > > > > ---------------------------------------------------------------------- > ------------------------- > > Have you seen our website?.... http://www.vodafone.co.nz > > Manage Your Account, check your Vodafone Mail and send web2TXT online: > http://www.vodafone.co.nz/myvodafone > > CAUTION: This correspondence is confidential and intended for the > named recipient(s) only. If you are not the named recipient and > receive this correspondence in error, you must not copy, distribute or > take any action in reliance on it and you should delete it from your > system and notify the sender immediately. Thank you. > > Unless otherwise stated, any views or opinions expressed are solely > those of the author and do not represent those of Vodafone New Zealand > Limited. > > Vodafone New Zealand Limited > 20 Viaduct Harbour Avenue, Private Bag 92161, Auckland 1030 Telephone > + 64 9 355 2000 Facsimile + 64 9 355 2001 > ----------------------------------------------------------------------------------------------- Have you seen our website?.... http://www.vodafone.co.nz Manage Your Account, check your Vodafone Mail and send web2TXT online: http://www.vodafone.co.nz/myvodafone CAUTION: This correspondence is confidential and intended for the named recipient(s) only. If you are not the named recipient and receive this correspondence in error, you must not copy, distribute or take any action in reliance on it and you should delete it from your system and notify the sender immediately. Thank you. Unless otherwise stated, any views or opinions expressed are solely those of the author and do not represent those of Vodafone New Zealand Limited. Vodafone New Zealand Limited 20 Viaduct Harbour Avenue, Private Bag 92161, Auckland 1030 Telephone + 64 9 355 2000 Facsimile + 64 9 355 2001
