From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 03, 2002 2:25 PM
To: [EMAIL PROTECTED]
Subject: RE: WSDL2Java: generated client stub and performance issues
- Thread T1 sets the endpoint to X
- Thread T2 sets the endpoint to Y
- T1 calls stub.a synchronously but setting the endpoint is outside any synchronization so it calls T2's endpoint.
Russell Butek
[EMAIL PROTECTED]
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
cc:
"'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
Subject: RE:
WSDL2Java: generated client stub and performance
issues
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
super.cachedProperties.get(key));
- }
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
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.
Thank you.
David Ostrovsky
