SOAPMappingRegistry and SOAP Performance

[Tom O'Connor <to...@surety.com>]

Does every instance of soap.rpc.Call *need* it own instance of
SOAPMappingRegistry?

On the server side, in the RPCRouterServlet, a new Call instance is created
for every incoming request.  For every new Call instance, a new
SOAPMappingRegistry is created.  The default SOAPMappingRegistry creates new
instances of Serializer/Deserializer classes, even though these
serialzer/deserializer classes carry no state, and even if a
serializer/deserializer for a given type is never used by the Call.  So if I
have 10 concurrent requests, I'll have 10 instances of
org.apache.soap.encoding.soapenc.DateSerializer in memory, even if they
never get used!

Object creation in Java is expensive.  Shouldn't there be one globally
reusable SOAPMappingRegistry that all Call instances get a reference to by
default?  If that's not possible, then at the very least, there should only
ever be one instance of each Serializer/Deserializer class in memory at one
time.  Why create new instances of classes that don't have any state?

Must each Call have its own SOAPMappingRegistry instance?

I can see why some people report 375 ms to create a Call object....

t

Re: SOAPMappingRegistry and SOAP Performance

[Sanjiva Weerawarana <sa...@watson.ibm.com>]

On the client side, each call does actually need its own SMR
(or someone has to give it one). The user can manage things
with exactly one SMR if you wish (after some changes mentioned
below).

On the server side, the current code creates an SMR auto for
each Call object (its an instance var) and then throws it away
immediately. This is silly .. if there are no custom mappings
it should use a "system" SMR and if there are it should use
a registry that hangs on to the custom mappings only and
delegates to the system reg for other stuff.

Cleaning this up should have a relatively large impact on
performance. I have written most of this code and am currently
testing it .. will try to commit it soon. I'll be very interested
in seeing whether it has any noticeable impact on performance.

Sanjiva.

----- Original Message -----
From: "Tom O'Connor" <to...@surety.com>
To: <so...@xml.apache.org>
Sent: Tuesday, June 12, 2001 5:23 PM
Subject: SOAPMappingRegistry and SOAP Performance


> Does every instance of soap.rpc.Call *need* it own instance of
> SOAPMappingRegistry?
>
> On the server side, in the RPCRouterServlet, a new Call instance is
created
> for every incoming request.  For every new Call instance, a new
> SOAPMappingRegistry is created.  The default SOAPMappingRegistry creates
new
> instances of Serializer/Deserializer classes, even though these
> serialzer/deserializer classes carry no state, and even if a
> serializer/deserializer for a given type is never used by the Call.  So if
I
> have 10 concurrent requests, I'll have 10 instances of
> org.apache.soap.encoding.soapenc.DateSerializer in memory, even if they
> never get used!
>
> Object creation in Java is expensive.  Shouldn't there be one globally
> reusable SOAPMappingRegistry that all Call instances get a reference to by
> default?  If that's not possible, then at the very least, there should
only
> ever be one instance of each Serializer/Deserializer class in memory at
one
> time.  Why create new instances of classes that don't have any state?
>
> Must each Call have its own SOAPMappingRegistry instance?
>
> I can see why some people report 375 ms to create a Call object....
>
> t