Issues with using Kryo for needed speed in serialization/deserialization

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Issues with using Kryo for needed speed in serialization/deserialization

CL Kim
This post has NOT been accepted by the mailing list yet.
Our enterprise application needs to batch very large numbers of log lines into a large (1G) mule message, which is taking too long to serialize/deserialize in a persisted vm:connector queue.

So we wanted to try Kryo instead of the Java serializer/deserializer. But Kryo needs a serializable class to have a zero-arg constructor and fails on DefaultMuleEvent because of that.

Is it possible to subclass and use our own DefaultMuleEvent (and probably also DefaultMuleMessage) class?

We could then add a zero-argument constructor in our subclass. We are aware of the registry-bootstrap.properties file, but don't believe we can register the new subclass so that mule uses our subclass instead.
Reply | Threaded
Open this post in threaded view
|

Re: Issues with using Kryo for needed speed in serialization/deserialization

mgonzalez
This post has NOT been accepted by the mailing list yet.
Hello,

Kryo provide a way to overcome the default constructor limitation by using Objenesis. You can enable that feature by setting the instantiation strategy like this:

kryo.setInstantiatorStrategy(new StdInstantiatorStrategy());

It's nice to see that you talk about batching and kryo in the same note since we're adding a Batch Module and Kryo support in Mule 3.5.0 EE.

If you're a CloudHub user, you already have access to the Batch Module since the December 2013 release and Kryo support will be available in the February 2014 release.

If you're an on-premise user, you can access both features by joining the beta-program next February or when 3.5.0-EE is released next April.

Regards,