I'd just like to point out that the solution with one call object has some
disadvantages:
- You have still create objects and rerun the same code for each function
call:
QName param = new QName(...);
call.addParameter(param, ...);
QName returnType = new QName(...);
call.setReturnType(returnType );
QName operationName = new QName(...);
call.setOperationName(operationName);
etc.
- If I understand it right, there is no reason to prevent a multithreaded
client from simultaneously
calling of different methods. With only one call object you have to
syncronise for each method call.
In this way you have an avoidable bottleneck on the client side.
>From my point of view is one call objet for each method is more
efficiently.
Another consideration: you pointed out, that uncontested locks are *very*
fast in the JVM.
Is it an option to set up a new command line parameter, to generate a
single threaded or multithreaded code?
If my client is single threaded, why that performance penalty during every
method call?
David Ostrovsky
Tom Jordahl
<tomj@macrome An: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
dia.com> Kopie: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
Thema: RE: WSDL2Java: generated client stub
and performance issues
03.07.02
20:18
Bitte
antworten an
axis-user
I believe the code is the way that it is to allow the use of a Stub object
from multiple threads, each having its own Call object. It is on my TODO
list to revisit the way this all works because:
- I believe that synchronizing the methods of the Stub would provide for
the thread safety that we need with little performance penalty (uncontested
locks are *very* fast in the JVM).
- The way that it is now is complicated and, as you pointed out,
inefficient.
The way I envision the stub is to have a single Call object, initialized at
Stub creation with the type mappings, used throughout the class. I haven't
prototyped this yet however, although this is the way the code used to work
a long time ago. Russell made the changes back then. The big issue with
this is the reuse of the Call object - what problems will that cause (if
any).
Russell, I know we had a discussion about revamping the way we allocate the
Call objects in the stub. Do you remember when that was (or have that
thread archived)?
--
Tom Jordahl
Macromedia
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 02, 2002 8:50 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: WSDL2Java: generated client stub and performance issues
Hello.
Two performance issues:
1. I just wonder why in generated stub code the call objects aren't cached?
I.e. the follow code take place during every (even subsequently)
function call:
// In function private org.apache.axis.client.Call createCall() throws
java.rmi.RemoteException {
org.apache.axis.client.Call call =
(org.apache.axis.client.Call) super.service.createCall
();
if (super.maintainSessionSet) {
call.setMaintainSession(super.maintainSession);
}
if (super.cachedUsername != null) {
call.setUsername(super.cachedUsername);
}
if (super.cachedPassword != null) {
call.setPassword(super.cachedPassword);
}
if (super.cachedEndpoint != null) {
call.setTargetEndpointAddress(super.cachedEndpoint);
}
if (super.cachedTimeout != null) {
call.setTimeout(super.cachedTimeout);
}
java.util.Enumeration keys = super.cachedProperties.keys();
while (keys.hasMoreElements()) {
String key = (String) keys.nextElement();
if(call.isPropertySupported(key))
call.setProperty(key, super.cachedProperties.get(key));
else
call.setScopedProperty(key,
super.cachedProperties.get(key));
}
// In function public Hugo foo(...)
javax.xml.namespace.QName p0QName = new javax.xml.namespace.QName
("", "bar");
call.addParameter(p0QName, new javax.xml.namespace.QName
("http://schemas.xmlsoap.org/soap/encoding/";, "string"),
java.lang.String.class, javax.xml.rpc.ParameterMode.IN);
call.setReturnType(new javax.xml.namespace.QName
("urn:HugoNameSpace", "Hugo"));
call.setUseSOAPAction(true);
call.setSOAPActionURI("");
call.setOperationStyle("rpc");
call.setOperationName(new javax.xml.namespace.QName
("urn:FooNamespace", "foo"));
One could simple cache the call object(s) (in the same way as
serializer/deserializer) in Hashtable or
in Array (if for each method an unique index in the array is assigned).
2. Type registration take place not untill the first call is made. That's
why the performance of first call isn't ideal.
(In my case first call= 5 second, second call 2.5 second)
I would like to initialize all the needed stuf in the startup phase of
the client.
To achive it now, I have define a dummy method and call it, because
the function createCall is
private and cannot be called directly from the client.
Any comments?
Thank you.
David Ostrovsky
