mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <trus...@gmail.com>
Subject Re: [1.0] Three questions concerning object serialization and MINA
Date Thu, 07 Dec 2006 02:05:21 GMT
Hello Sven,

On 12/7/06, Sven Panko <Sven.Panko@proximity.de> 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(

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.  :)

what we call human nature is actually human habit
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message