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
