Fixes #566: NotSerializableException: SessionRegistry$PublishedMessage

[hylkevds]

Fixes #566

Instances of implementations of the interface
SessionRegistry$EnqueuedMessage are put in the queue, which can be
backed by the H2 store. But since this class is not serializable, H2
can not store it. This commit makes the interface serializable, and
deals with the non-serializable ByteBuf that the PublishedMessage
subclass has as a field.

[andsel]

@hylkevds thanks to point out this problem. I'm thinking if Java serializaion could be avoided, maybe encoding the overall object as a byte array of (topic bytes, q0s byte, message bytes), or maybe a use Protobuf to serialize it; what do you think?

[hylkevds]

Long term that's probably a better solution. Is the Serializable a result of the H2 store, or is possible to specify on the H2 store how the serialisation has to happen?

[andsel]

I think that to use custom deserializer we should:

• implement https://github.com/h2database/h2database/blob/version-1.4.199/h2/src/main/org/h2/mvstore/type/DataType.java that a serializer method (for example Protobuf) and then use that data type in MVMap creation
• create a new MVMap.MapBuilder with a customized getValueType to return the previously create DataType https://github.com/h2database/h2database/blob/version-1.4.199/h2/src/main/org/h2/mvstore/MVMap.java#L1379
• use this new builder in map creation when invokes MVStore.openMap https://github.com/h2database/h2database/blob/version-1.4.199/h2/src/main/org/h2/mvstore/MVStore.java#L503

[hylkevds]

Yes, that should work. Probably also more efficient.
Using Protobuf isn't even really needed, since the read and write operations of DataType already pass ByteBuffers. The topic and message we need to store are already Bytes, and the qOs can also simply be stored as a byte. We can just write 4 (8?) length bytes for the topic, followed by the String bytes, 8 length bytes for the payload, followed by the payload and finally the qOs byte. That's essentially what I also did for the java serialization implementation.
That avoids pulling in more dependencies too.

[andsel]

I agree with your idea, I'll try to put down a draft for this; I would move the fixed length field (QoS) in front, so in case of debug the byte stream is more straight forward.