By the way Neil, If you want high performance invocations, you can also have a look at CommonsHTTPSender. It uses a pool of http persistent connections (keep-alive).
http://wiki.apache.org/ws/FrontPage/Axis/AxisCommonsHTTP Cyrille PS : my first name is Cyrille, not Cedric :-) -- Cyrille Le Clerc [EMAIL PROTECTED] [EMAIL PROTECTED] On 1/24/06, Ferguson, Neil, VF-NZ <[EMAIL PROTECTED]> wrote: > 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
