Hello Sven, On 12/7/06, Sven Panko <[EMAIL PROTECTED]> wrote:
first of all I like to thank of all you guys - MINA is a really excellent piece of software! After using it for more than a year I am fascinated how easy it is to implement complex client-server applications without much effort! But now to my questions concerning the object serialization features.
Wow, I didn't know that you've been using MINA for that long time. I hope you enjoyed your time with MINA. I was wondering if the ObjectSerializationCodecFactory may be used safely
in production environments when the only data that is transferred between clients and the server are objects (i.e. a custom codec doesn't seem to be necessary to me)? The reason I am asking is because the JavaDoc description of the class states that the "codec is very useful when you have to prototype your application rapidly without any specific codec". This sounds as if it should only be used for testing purposes but not within a production environment.
It's saying that the codec is very useful in prototyping phase, but it's not saying that it's not usefule in other phases. So it can be useful in any phase, even in production phase. In general, object serialization is slower than customized codec in bandwidth consumption and performance. If you have enough bandwidth and your application performs enough with object serialization filter, it's absolutely fine to use it. Furthermore I was wondering why the decoder and ByteBuffer.getObject() use
a classloader to check, if the transferred class is available on the receiver's platform (deserialization will fail without the check in every case when the class to be deserialized isn't available to the receiver, won't it?). I am developing a client application using Eclipse RCP and class loading is a bit difficult here because the OSGi platform is used to control class loading in the Eclipse platform. I wasn't able to use the ObjectSerializationCodecFactory out of the box because of NoClassDefFound errors produced by the Eclipse class loaders (which are not present if one simply uses the ObjectInputStream without specifying a separate classloader). Object serialization works find without the additional class checks, so I created a mere copy of the decoder and the ObjectSerializationCodecFactory to prevent the usage of explicit classloaders - but are there any risks involved in doing so which I don't see and you are aware of?
We overrided read/writeClassDescriptor() of ObjectInput/OutputStream to save the bandwidth. When a Java object is serialized, the descriptor of the object's class is serialized together. The descriptor contains a lot of meta-information related with the class and it's huge comparing to the actual data we want to exchange because it contains long strings such as type name and field name. It's sometimes ten times bigger, and then we are wasting 90% of bandwidth. That's why we chose to override read/writeClassDescriptor() method. Calling getObject() with explicit class loader specified might help you: MyMessageToReceive m = buffer.getObject( MyMessageToReceive.class.getClassLoader()); Please let me know if this works for you. Otherwise, we need to find a better solution. My last question concerns the different default max object sizes in the
en- and decoder implementations - is there a reason why the encoder may encode objects up to Integer.MAX_VALUE, but the decoder refuses anything above 1MB? Are you aware of some known issues concerning memory consumption if I set the max object size of the decoder to Integer.MAX_VALUE as well?
I thought decoder should be more restrictive in receiving a big object because of the rick of DoS attack. That's all. If there's consensus on changing the default value, we can change it, too. :) HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
