Improvements of call-by-value and pluging jboss-serializatio
clebert.suconic Sep 6, 2005 6:11 PMI was going to send this message to jboss-development list at sourceforge but since the message takes forever to be delivered I decided to use this forum instead.
I have worked with Telrod on improve call-by-value operations. We have worked in another branch (derived from Branch_4_0) called Branch_4_0_call_by_value_optimizations
We have done basically two major modifications:
I - Avoiding serializing the entire Invocation in a call-by-value operation
If you look at InvokerInterceptor::invokeMarshalled, you will realize that the entire Invocation is being copied with container instances, when only the arguments to the method itself were necessary to guarantee the call-by-value operation.
We have created another method in our branch called invokeLocalmarshalled which is only serializing (by using MarshalledValue) the arguments used by the class.
After doing that change, the throughput for that operation was 3 or 4 times faster than before.
II ? Refactoring Invocation and Remoting to accept pluggable serializations
I have worked with JBossSerialization, and I have 95% of the features needed to JBossAS. The only feature missing now is ObjectFields which we have one usecase for that. It will be implemented soon.
I have then refactored org.jboss.invocation to accept pluggable serializations.
We are creating a factory called org.jboss.remoting.serialization.SerializationStreamFactory (which is exposed as a MBean) which will create implementation of Serializationmanager
For SerializationManager you can do these operations:
ObjectInputStream createInputStream (input,classloader)
ObjectOutputStream createOutputStream (output)
ObjectINputStreamcreatedMarshaledInputStream(input,classLoader):
ObjectOutputStream createOutputStream (output)
RemoteMarshalledValue createMarshalledValue(serializableObject)
Now, instead of simply do new ObjectInputStream when you want to create your ObjectStreaming, you need to ask the factory for the ObjectStreaming.
I refactored then org.jboss.invocation to support those changes.
One nice feature presented into JBossSerialization is the capability of reusing primitive values instead of byte-arrays. Using that feature I was able to create the Proxy 4 times faster than using JavaSerialization. (And I still have some bottlenecks with Proxy resolutions as I'm not chaching anything and always going to the classloader)
Design pending...:
- Having the serializationManager is easy on the server side, but I'm still looking for ways of sending the configured value to the client side. Right now, just for my tests I'm using a System Property, but I know this is not the best design. I have talked to Telrod and he told me he has some ideas about how to do it.
- Maybe someone already thought about this, but is there any way we could cache ClientProxy instead serializing it every home.create operation?
Maybe we could mix static variables with object.replace operations... I don't know...
Any idea here?
If you want to try these changes, you need to:
I - download jboss-4.0.x using Branch_4_0_call_by_value_optimizations
II - Download remoting from CVS (JBossRemoting) and substitute thirdlibrary/jboss/remoting manually
III - Do the same operation with jboss-serialization
IV - Build it.
V - You will need to define -DSERIALIZATION= org.jboss.invocation.JBossSerializationManager on any remote clients you are running against your JBoss instance
For II and III we will create a developer's release soon. We still have some pending changes before adding it to repository.jboss.com
Clebert