Skip to content

Kryo Java serialization Notes

Jump to bottom
Oleg Zhurakousky edited this page Nov 28, 2017 · 1 revision

Currently (1.3.x and 2.0.x) we provide OOTB support for Java and Kryo serialization/deserialization. It is managed strictly by the presence of contentType header.

  • application/x-java-serialized-object - to select Java serialization mechanism
  • application/x-java-object - to select Kryo serialization

The above content types are treated as special case by the pair of InboundContentTypeConvertingInterceptor/OutboundContentTypeConvertingInterceptor (defined in MessageConverterConfigurer). This means that serialization will be attempted on each outgoing message and deserialization on each incoming message. This may result in unpredictable behavior especially if signature of the handler method suggests that deserialization is not needed (e.g., handle(byte[])). This is due to the fact that Kryo/JavaMessageConverter will attempt to convert incoming Message to a type and then the next conversion attempt will be made to convert the Message to the actual type of the handler method (e.g., byte[]) which may not be possible if there is no converter provided as part of the customization. To work around this the producer side may strip the contentType header or move its value under different name.

This behavior is deprecated as of v2.0 along with Java/Kryo serialization all together, since it proved to be very unreliable and error prone in the distributed environment (classpath, versions, JVM versions etc), thus increasingly difficult to support and maintain. We plan to discontinue it completely starting v3.0.

However the hooks will remain to introduce it as part of the application customization for those who still wish to rely on it.

Clone this wiki locally