Problems with custom serializer using protostuff

[Roman Levenstein]

Hi,

I'm trying to create my own custom serializer using protostuff. So, I've written a ProtostuffSerializer class, as suggested in the docs. It inherits form akka.serialization.Serializer and implements required methods.

It also defines a unique identifier like this:
def identifier = 12454321

Everything compiles fine.
To be able to use my serializer I added only these lines to the config file:

    serializers {
        java = "akka.serialization.JavaSerializer"
        proto = "akka.serialization.ProtobufSerializer"
        protostuff = "acme.ProtostuffSerializer"
    }
 
    serialization-bindings {
        "java.io.Serializable" = java
        "com.google.protobuf.Message" = proto
        "acme.StringMessage" = protostuff
    }

With this description, StringMessage objects are supposed to be serialized using my protostuff serializer.

When I run the system, I get no exceptions on the sender side, but following exception on the receiving side:

[ERROR] [05/14/2012 11:39:43.517] [ApplicationRemote-7] [ActorSystem(Application
Remote)] REMOTE: RemoteServerError@akka://Applicat...@127.0.0.1:2554] Error[java.util.NoSuchElementException:key not found: 12454321
        at scala.collection.MapLike$class.default(MapLike.scala:224)
        at scala.collection.immutable.Map$Map3.default(Map.scala:143)
        at scala.collection.MapLike$class.apply(MapLike.scala:135)
        at scala.collection.immutable.Map$Map3.apply(Map.scala:143)
        at akka.serialization.Serialization.deserialize(Serialization.scala:73)
        at akka.remote.MessageSerializer$.deserialize(MessageSerializer.scala:21

I don't know how to interpret this message. Does it mean that my serializer is not registered/not known to the actor system? Or may be incoming message is expected to have a unique serializer ID with this value, but does not contain it?

Does anyone has an idea what's going wrong here?
Is there any way to see that my serializer is really used? E.g. some sort of debug/log output from Akka?
May be I need to configure something else in the config file to make my serializer visible by the system?

Another small question:
Is it possible to configure the system so that protobuf is used by default for all Akka-internal messages instead of Java serialization? Or is it the case already?

Any help is appreciated!

Thanks,
  Roman

[√iktor Ҡlang]

Have you've mapped the protostuff serializer on both nodes?

Cheers,

√

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/keSkpN2N1WMJ.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Roman Levenstein]

You are right, Viktor!

I've mapped the new serializer on both nodes, but my config file on the receiver's side was wrongly formatted. The serializer section was in the "akka" scope, but outside of "actor" scope.  I fixed it. Now I get some other exceptions, but they are protostuff specific, which means that my serialized is used.

Thanks,
  Roman

On Monday, May 14, 2012 12:05:03 PM UTC+2, √ wrote:

Have you've mapped the protostuff serializer on both nodes?

Cheers,

√

On Mon, May 14, 2012 at 12:00 PM, Roman Levenstein  wrote:

Hi,

I'm trying to create my own custom serializer using protostuff. So, I've written a ProtostuffSerializer class, as suggested in the docs. It inherits form akka.serialization.Serializer and implements required methods.

It also defines a unique identifier like this:
def identifier = 12454321

Everything compiles fine.
To be able to use my serializer I added only these lines to the config file:

    serializers {
        java = "akka.serialization.JavaSerializer"
        proto = "akka.serialization.ProtobufSerializer"
        protostuff = "acme.ProtostuffSerializer"
    }
 
    serialization-bindings {
        "java.io.Serializable" = java
        "com.google.protobuf.Message" = proto
        "acme.StringMessage" = protostuff
    }

With this description, StringMessage objects are supposed to be serialized using my protostuff serializer.

When I run the system, I get no exceptions on the sender side, but following exception on the receiving side:

[ERROR] [05/14/2012 11:39:43.517] [ApplicationRemote-7] [ActorSystem(Application

Remote)] REMOTE: RemoteServerError@akka://Application...@127.0.0.1:2554] Error[java.util.NoSuchElementException:key not found: 12454321

        at scala.collection.MapLike$class.default(MapLike.scala:224)
        at scala.collection.immutable.Map$Map3.default(Map.scala:143)
        at scala.collection.MapLike$class.apply(MapLike.scala:135)
        at scala.collection.immutable.Map$Map3.apply(Map.scala:143)
        at akka.serialization.Serialization.deserialize(Serialization.scala:73)
        at akka.remote.MessageSerializer$.deserialize(MessageSerializer.scala:21

I don't know how to interpret this message. Does it mean that my serializer is not registered/not known to the actor system? Or may be incoming message is expected to have a unique serializer ID with this value, but does not contain it?

Does anyone has an idea what's going wrong here?
Is there any way to see that my serializer is really used? E.g. some sort of debug/log output from Akka?
May be I need to configure something else in the config file to make my serializer visible by the system?

Another small question:
Is it possible to configure the system so that protobuf is used by default for all Akka-internal messages instead of Java serialization? Or is it the case already?

Any help is appreciated!

Thanks,
  Roman

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/keSkpN2N1WMJ.
To post to this group, send email to akka...@googlegroups.com.

To unsubscribe from this group, send email to akka-user+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[√iktor Ҡlang]

On Mon, May 14, 2012 at 2:33 PM, Roman Levenstein <romi...@gmail.com> wrote:

You are right, Viktor!

I've mapped the new serializer on both nodes, but my config file on the receiver's side was wrongly formatted. The serializer section was in the "akka" scope, but outside of "actor" scope.  I fixed it. Now I get some other exceptions, but they are protostuff specific, which means that my serialized is used.

Thanks,
  Roman

You're very welcome, hope you're enjoying yourself!

Please don't hesitate to give us feedback.

Happy hAkking!

Cheers,

√

 

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/reeFwhnIVyYJ.

To post to this group, send email to akka...@googlegroups.com.

To unsubscribe from this group, send email to akka-user+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Roman Levenstein]

On Monday, May 14, 2012 2:45:34 PM UTC+2, √ wrote:

On Mon, May 14, 2012 at 2:33 PM, Roman Levenstein  wrote:

You are right, Viktor!

I've mapped the new serializer on both nodes, but my config file on the receiver's side was wrongly formatted. The serializer section was in the "akka" scope, but outside of "actor" scope.  I fixed it. Now I get some other exceptions, but they are protostuff specific, which means that my serialized is used.

Thanks,
  Roman

You're very welcome, hope you're enjoying yourself!

Please don't hesitate to give us feedback.

Sure, I'll do! I'm going to contribute the protostuff-serializer once its implemented.

A few words about this serializer:
It uses protostuff-runtime and is able to serialize almost any Java POJO, even if it is not implementing Serializable. The nice thing about protostuff-runtime is that it is very fast and it does not need by default any kind of additional meta-info descriptions at design-time, e.g. it does not need any proto files. This makes it a good candidate for a drop-in replacement of Java serialization in many cases. And of course, if one wants to serialize a specific class more efficiently than it is done by default, there is an opportunity, but it requires some coding.

Currently, the basic initial version of this protostuff-serializer seems to work for me. But unfortunately, it uses the most inefficient modes supported by protostuff-runtime. This mode serializes FQCNs (fully-qualified class names) as strings, so that it is easy for a deserializer to know what to do. There are more efficient modes supported by protostuff-runtime, which are based on mapping FQCNs to integer ids. This makes serialized representation smaller and serialization/deserialization faster. But there is an issue with those modes:

- One of them requires that you define mapping for all FQCNs to integers in advance, i.e. via some sort of configuration. It also means that you are supposed to know all possible classes to be used for serialization in advance

- Another one allows for dynamic automatic registration of mappings, which means that you don't need to know all classes and their FQCN mappings in advance. But it has another problem: Assigned integer ids depend on the order of class serialization and hence it is non-deterministic when used on different nodes. It may happen then one node maps FQCN1 to 1, because it was first one to serialize on this node. But another node maps the same FQCN1 to a different integer id, because there it was not the first class to serialize.

At the moment, I'm looking into different alternatives of solving these problems.

But it would be interesting to hear opinions from Akka people about which alternative would be a preferred one from the usability point of view. Also ideas about how to provide configuration for FQCN->integer mappings for the first alternative or how to synchronize mappings for the second alternative are very welcome.

- Roman
 

[√iktor Ҡlang]

On Mon, May 14, 2012 at 4:06 PM, Roman Levenstein <romi...@gmail.com> wrote:

On Monday, May 14, 2012 2:45:34 PM UTC+2, √ wrote:

On Mon, May 14, 2012 at 2:33 PM, Roman Levenstein  wrote:

You are right, Viktor!

I've mapped the new serializer on both nodes, but my config file on the receiver's side was wrongly formatted. The serializer section was in the "akka" scope, but outside of "actor" scope.  I fixed it. Now I get some other exceptions, but they are protostuff specific, which means that my serialized is used.

Thanks,
  Roman

You're very welcome, hope you're enjoying yourself!

Please don't hesitate to give us feedback.

Sure, I'll do! I'm going to contribute the protostuff-serializer once its implemented.

A few words about this serializer:
It uses protostuff-runtime and is able to serialize almost any Java POJO, even if it is not implementing Serializable. The nice thing about protostuff-runtime is that it is very fast and it does not need by default any kind of additional meta-info descriptions at design-time, e.g. it does not need any proto files. This makes it a good candidate for a drop-in replacement of Java serialization in many cases. And of course, if one wants to serialize a specific class more efficiently than it is done by default, there is an opportunity, but it requires some coding.

Currently, the basic initial version of this protostuff-serializer seems to work for me. But unfortunately, it uses the most inefficient modes supported by protostuff-runtime. This mode serializes FQCNs (fully-qualified class names) as strings, so that it is easy for a deserializer to know what to do. There are more efficient modes supported by protostuff-runtime, which are based on mapping FQCNs to integer ids. This makes serialized representation smaller and serialization/deserialization faster. But there is an issue with those modes:

- One of them requires that you define mapping for all FQCNs to integers in advance, i.e. via some sort of configuration. It also means that you are supposed to know all possible classes to be used for serialization in advance

- Another one allows for dynamic automatic registration of mappings, which means that you don't need to know all classes and their FQCN mappings in advance. But it has another problem: Assigned integer ids depend on the order of class serialization and hence it is non-deterministic when used on different nodes. It may happen then one node maps FQCN1 to 1, because it was first one to serialize on this node. But another node maps the same FQCN1 to a different integer id, because there it was not the first class to serialize.

At the moment, I'm looking into different alternatives of solving these problems.

But it would be interesting to hear opinions from Akka people about which alternative would be a preferred one from the usability point of view. Also ideas about how to provide configuration for FQCN->integer mappings for the first alternative or how to synchronize mappings for the second alternative are very welcome.

You could very easily create your own ProtostuffExtension and have a config section to configure it, then you could load that extension in your ProtostuffSerializer to gain access to the integers.

Cheers,

√

 

- Roman
 

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/UYbBfkd-9JMJ.

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Roman Levenstein]

On Monday, May 14, 2012 4:47:44 PM UTC+2, √ wrote:

On Mon, May 14, 2012 at 4:06 PM, Roman Levenstein  wrote:

On Monday, May 14, 2012 2:45:34 PM UTC+2, √ wrote:

On Mon, May 14, 2012 at 2:33 PM, Roman Levenstein  wrote:

You are right, Viktor!

I've mapped the new serializer on both nodes, but my config file on the receiver's side was wrongly formatted. The serializer section was in the "akka" scope, but outside of "actor" scope.  I fixed it. Now I get some other exceptions, but they are protostuff specific, which means that my serialized is used.

Thanks,
  Roman

You're very welcome, hope you're enjoying yourself!

Please don't hesitate to give us feedback.

Sure, I'll do! I'm going to contribute the protostuff-serializer once its implemented.

A few words about this serializer:
It uses protostuff-runtime and is able to serialize almost any Java POJO, even if it is not implementing Serializable. The nice thing about protostuff-runtime is that it is very fast and it does not need by default any kind of additional meta-info descriptions at design-time, e.g. it does not need any proto files. This makes it a good candidate for a drop-in replacement of Java serialization in many cases. And of course, if one wants to serialize a specific class more efficiently than it is done by default, there is an opportunity, but it requires some coding.

Currently, the basic initial version of this protostuff-serializer seems to work for me. But unfortunately, it uses the most inefficient modes supported by protostuff-runtime. This mode serializes FQCNs (fully-qualified class names) as strings, so that it is easy for a deserializer to know what to do. There are more efficient modes supported by protostuff-runtime, which are based on mapping FQCNs to integer ids. This makes serialized representation smaller and serialization/deserialization faster. But there is an issue with those modes:

- One of them requires that you define mapping for all FQCNs to integers in advance, i.e. via some sort of configuration. It also means that you are supposed to know all possible classes to be used for serialization in advance

- Another one allows for dynamic automatic registration of mappings, which means that you don't need to know all classes and their FQCN mappings in advance. But it has another problem: Assigned integer ids depend on the order of class serialization and hence it is non-deterministic when used on different nodes. It may happen then one node maps FQCN1 to 1, because it was first one to serialize on this node. But another node maps the same FQCN1 to a different integer id, because there it was not the first class to serialize.

At the moment, I'm looking into different alternatives of solving these problems.

But it would be interesting to hear opinions from Akka people about which alternative would be a preferred one from the usability point of view. Also ideas about how to provide configuration for FQCN->integer mappings for the first alternative or how to synchronize mappings for the second alternative are very welcome.

You could very easily create your own ProtostuffExtension and have a config section to configure it, then you could load that extension in your ProtostuffSerializer to gain access to the integers.

Nice! This is a very good hint about ProtostuffExtension.

But another question is:
What would be more convenient for Akka users? Writing a special config section with mappings, which is more work, but makes things very explicit. Or to do implicit mapping as described in the second alternative? This would not require any additional configuration from a user, but would require from the implementation some sort of synchronization between mappings on different nodes or something similar.

Regards,
  Roman

[√iktor Ҡlang]

The problem is that you do not know who's receiving it. And the recipient doesn't know all things that might be deserialized.

 

Regards,
  Roman

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/yYH5BH9o3XkJ.

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Roman Levenstein]

On Monday, May 14, 2012 5:03:32 PM UTC+2, √ wrote:

On Mon, May 14, 2012 at 5:00 PM, Roman Levenstein wrote:

On Monday, May 14, 2012 4:47:44 PM UTC+2, √ wrote:

On Mon, May 14, 2012 at 4:06 PM, Roman Levenstein  wrote:

On Monday, May 14, 2012 2:45:34 PM UTC+2, √ wrote:

On Mon, May 14, 2012 at 2:33 PM, Roman Levenstein  wrote:

You are right, Viktor!

I've mapped the new serializer on both nodes, but my config file on the receiver's side was wrongly formatted. The serializer section was in the "akka" scope, but outside of "actor" scope.  I fixed it. Now I get some other exceptions, but they are protostuff specific, which means that my serialized is used.

Thanks,
  Roman

You're very welcome, hope you're enjoying yourself!

Please don't hesitate to give us feedback.

Sure, I'll do! I'm going to contribute the protostuff-serializer once its implemented.

A few words about this serializer:
It uses protostuff-runtime and is able to serialize almost any Java POJO, even if it is not implementing Serializable. The nice thing about protostuff-runtime is that it is very fast and it does not need by default any kind of additional meta-info descriptions at design-time, e.g. it does not need any proto files. This makes it a good candidate for a drop-in replacement of Java serialization in many cases. And of course, if one wants to serialize a specific class more efficiently than it is done by default, there is an opportunity, but it requires some coding.

Currently, the basic initial version of this protostuff-serializer seems to work for me. But unfortunately, it uses the most inefficient modes supported by protostuff-runtime. This mode serializes FQCNs (fully-qualified class names) as strings, so that it is easy for a deserializer to know what to do. There are more efficient modes supported by protostuff-runtime, which are based on mapping FQCNs to integer ids. This makes serialized representation smaller and serialization/deserialization faster. But there is an issue with those modes:

- One of them requires that you define mapping for all FQCNs to integers in advance, i.e. via some sort of configuration. It also means that you are supposed to know all possible classes to be used for serialization in advance

- Another one allows for dynamic automatic registration of mappings, which means that you don't need to know all classes and their FQCN mappings in advance. But it has another problem: Assigned integer ids depend on the order of class serialization and hence it is non-deterministic when used on different nodes. It may happen then one node maps FQCN1 to 1, because it was first one to serialize on this node. But another node maps the same FQCN1 to a different integer id, because there it was not the first class to serialize.

At the moment, I'm looking into different alternatives of solving these problems.

But it would be interesting to hear opinions from Akka people about which alternative would be a preferred one from the usability point of view. Also ideas about how to provide configuration for FQCN->integer mappings for the first alternative or how to synchronize mappings for the second alternative are very welcome.

You could very easily create your own ProtostuffExtension and have a config section to configure it, then you could load that extension in your ProtostuffSerializer to gain access to the integers.

Nice! This is a very good hint about ProtostuffExtension.

But another question is:
What would be more convenient for Akka users? Writing a special config section with mappings, which is more work, but makes things very explicit. Or to do implicit mapping as described in the second alternative? This would not require any additional configuration from a user, but would require from the implementation some sort of synchronization between mappings on different nodes or something similar.

The problem is that you do not know who's receiving it. And the recipient doesn't know all things that might be deserialized.

Well, there is probably a possibility. Every time a new mapping is automatically added when a new class is seen, this information is put (only once) into a serialized representation together with the usual stuff.  Then it can be sent to any receiver. You don't need to know it in advance. The receiver tries to deserialize a message, detects a new mapping and registers it locally. But here is a catch here, that needs to be solved: The receiver node may receive messages from different senders, and they may use different automatic mappings for the same FQCN. Which means that receiver should keep mapping table per sender (or per "session"). This is rather easily done with protostuff-runtime, if it would be possible to understand in which context an Akka Serializer is executed, i.e. in scope of which "session", who is the sender of the message, etc. (sender info does not need to be a real IP and port. It should be just something unique enough to distinguish between different senders using different mappings)
But at the moment, akka Serializer interface does not provide this information, AFAIK. Do you see any possibility to provide such an information about serializer's invocation context?

Regards,
 Roman

[Viktor Klang]

How would such a context be identified?

Cheers,

√

 

Regards,
 Roman

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/TAZ04xCjRXoJ.

[Roman Levenstein]

On Monday, May 14, 2012 5:27:11 PM UTC+2, √ wrote:

Well, I don't know yet, otherwise I would have done it already :-)

But an idea could be to provide to a Serializer together with a message (i.e. a byte array with payload) a parameter containing some information about the originator of a message, e.g. the actor instance that sent it.  Or may be a reference to a connection that was used to receive it for the case that two actor systems use a persistent connection/session when they communicate by means of message-passign between actors. (BTW, how it is done currently in Akka? Does it use persistent connections/sessions or creates new ones for each message?). May be there are some other ways? I don't know Akka that well to propose anything else, but may be you see something that is available currently only internally inside remoting, but unique enough to be used for context identification?

 

[Roman Levenstein]

Hi Viktor,

On Monday, May 14, 2012 6:59:45 PM UTC+2, Roman Levenstein wrote:

Well, there is probably a possibility. Every time a new mapping is automatically added when a new class is seen, this information is put (only once) into a serialized representation together with the usual stuff.  Then it can be sent to any receiver. You don't need to know it in advance. The receiver tries to deserialize a message, detects a new mapping and registers it locally. But here is a catch here, that needs to be solved: The receiver node may receive messages from different senders, and they may use different automatic mappings for the same FQCN. Which means that receiver should keep mapping table per sender (or per "session"). This is rather easily done with protostuff-runtime, if it would be possible to understand in which context an Akka Serializer is executed, i.e. in scope of which "session", who is the sender of the message, etc. (sender info does not need to be a real IP and port. It should be just something unique enough to distinguish between different senders using different mappings)
But at the moment, akka Serializer interface does not provide this information, AFAIK. Do you see any possibility to provide such an information about serializer's invocation context?

How would such a context be identified?

Well, I don't know yet, otherwise I would have done it already :-)

But an idea could be to provide to a Serializer together with a message (i.e. a byte array with payload) a parameter containing some information about the originator of a message, e.g. the actor instance that sent it.  Or may be a reference to a connection that was used to receive it for the case that two actor systems use a persistent connection/session when they communicate by means of message-passign between actors. (BTW, how it is done currently in Akka? Does it use persistent connections/sessions or creates new ones for each message?). May be there are some other ways? I don't know Akka that well to propose anything else, but may be you see something that is available currently only internally inside remoting, but unique enough to be used for context identification?

To conclude on this, could you explain if it would be in principle possible to provide such a context to a custom serializer form the akka-actor runtime or is it totally out of question?

Thanks,
  Roman

[√iktor Ҡlang]

I don't see how that would be possible.

Cheers,

√

 

Thanks,
  Roman

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/ZnV8rOWBDm0J.

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Roman Levenstein]

Hi,

You're very welcome, hope you're enjoying yourself!

Please don't hesitate to give us feedback.

Sure, I'll do! I'm going to contribute the protostuff-serializer once its implemented.

I have now a first working version of a protostuff-based serializer library for Akka.
You can find a project and description of how to use it here: https://github.com/romix/akka-protostuff-serialization

Any comments and feedback are welcome!

Thanks,
  -Roman

[Roman Levenstein]

On Friday, May 18, 2012 12:42:48 PM UTC+2, Roman Levenstein wrote:

I have now a first working version of a protostuff-based serializer library for Akka.
You can find a project and description of how to use it here: https://github.com/romix/akka-protostuff-serialization

Any comments and feedback are welcome!

Viktor, thanks a lot for your code-review and help! All suggested changes and improvements are incorporated.

In addition to this serialization back-end, please find another one that I quickly hacked together:
https://github.com/romix/akka-quickser-serialization

akka-quickser-serialization uses my quickser serialization library (https://github.com/romix/quickser), which is not very known yet. It seems to outperform Kryo and protostuff in many cases. The new back-end does not need any specific configuration and slightly outperforms akka-protostuff-serialization back-end on my tests.

As usual, any comments and feedback are welcome!

Regards,
  Roman