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