Simple Object passing on Event bus

[Alan Kash]

Hi All,

I started going through the tutorials for eventbus communication, when I am passing an serializable object instance it is throwing a runtime exception.
Exception

java.lang.IllegalArgumentException: Cannot send object of class class Server$HelloWorld on the event bus

Code:

public class Server extends Verticle {

    public void start() {

        EventBus eb = vertx.eventBus();

        Handler<Message<Object>> reqProcessor = new Handler<Message<Object>>() {
            public void handle(Message<Object> message) {
                System.out.println("I received a message :" + message.body());
            }
        };
        eb.registerHandler("test.address", reqProcessor);
        eb.send("test.address", new HelloWorld());
    }

    public class HelloWorld implements Serializable {
        private String name = "I AM SERIALIZABLE OBJECT";
    }
}

Whats wrong with the code ?

[Jordan Halterman]

The problem is: Vert.x does not support sending arbitrary Serializable objects on the event bus. The reason is that Serializable is a Java specific interface, and Vert.x is a polyglot framework. What happens if a Python verticle is listening on the other side?

You should manually serialize your object to a JsonObject or a Buffer and send that instead.

Note: Vert.x 3 supports codecs for custom serialization of event bus messages.

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alan Kash]

Thanks for the reply. This makes sense. However, if I share an interface definition between different language modules, I should be able to any serialize arbitrary object. Do we have any documentation on Vx3 serialization ?

Best, 

[Jordan Halterman]

No documentation that I know of right now, but you can look at the tests :-)

https://github.com/eclipse/vert.x/blob/master/src/test/java/io/vertx/test/core/LocalEventBusTest.java

Sent from my iPhone

[Alan Kash]

On the similar lines, currently, Sharable Objects have containers with simple object support. Is it possible to share arbitrary immutable objects with multiple verticles ?

e.g I just annotate a immutable class with Share, which can be shared across Vertx platform.

@Share
final public class HelloWorld implements Serializable {
    private final String name = "I AM SERIALIZABLE OBJECT";
}

[Nick Scavelli]

Are you asking if you can do the same in v3 ? The answer is yes but with the added bonus you can share across the cluster. It's not an annotation anymore, but just a marker interface your object would implement. See http://git.io/2JqrDw

[Alan Kash]

Thanks for sharing link, Shareable Interface covers a lot of ground. So, on the inter-module communication over event-bus, I can send Messages with Objects implementing Sharable interface across the cluster. Sweet ! Do we have an ETA for v3 yet ?

[Jordan Halterman]

No no, Shareable is for shared data, not the event bus AFAIK. Like I said, you can register a custom codec to serialize arbitrary messages on the event bus.

Sent from my iPhone

On Nov 20, 2014, at 11:35 AM, Alan Kash <cru...@gmail.com> wrote:

Thanks for sharing link, Shareable Interface covers a lot of ground. So, on the inter-module communication over event-bus, I can send Messages with Objects implementing Sharable interface across the cluster. Sweet ! Do we have an ETA for v3 yet ?

--

[Alan Kash]

Then what is the difference between sharing Objects using Shareable interface vs. Serializing Custom Object via Eventbus in a cluster. As sharing is happening in a cluster, how are objects are shared between the nodes (Custom persistence protocol?). For e.g. Hazelcast's only restriction is that Objects should be serializable. If I understand correctly, in Vertx v3 collections are shared across the cluster (no other types : Maps/Set/List?/Queue?) and the member Objects should implement Shareable. Semantically, the same Shareable Object should be allowed on the eventbus as well.

May be this will help everybody understand the difference between the two types of sharing Vx3 allows.

[Jordan Halterman]

I wouldn't equate the two with one another. The concepts are fundamentally different. The event bus is a messaging system and shared data - whether across threads or across the cluster - is essentially an in memory database. One is event driven and one is not (though it could be).

Coincidentally, both the event bus codecs and ClusterSerializable use a similar interface, serializing objects to/from Buffer, but the MessageCodec does require some additional methods that really are specific to the event bus. You should go check out those respective interfaces. Also, messages serialized by custom codecs can be associated with the appropriate codec for deserialization when they're sent across the wire. Of course, the same thing could be accomplished with fully qualified class names, but it's less efficient than a 1 byte identifier. I suspect the message codecs are more performant than ClusterSerializable objects, which they should be.

I'm sure one of the guys that worked on the event bus and cluster APIs can speak more to the reasoning behind separating the two. It obviously would be simpler to merge the two concepts of possible, so maybe there's some room for refactoring. Perhaps ClusterSerializable or Serializable objects could be sent on the event bus while still allowing codecs for event bus specific handling of serialization/deserialization. But I tend to get a little uncomfortable when too many types serve the same purpose.

BTW I believe cluster-wide shared data for many (all?) of the other data structures you mentioned is on the TODO list.

[Alan Kash]

Thanks for the detailed explanation. I will go throw the interfaces and try to understand the rationale behind it. I see the hazelcast cluster management code has been moved to a module, will the Shared data structure implementation use Hazelcast initially ?

[Nick Scavelli]

On Friday, November 21, 2014 3:40:47 AM UTC-5, Alan Kash wrote:

Thanks for the detailed explanation. I will go throw the interfaces and try to understand the rationale behind it. I see the hazelcast cluster management code has been moved to a module, will the Shared data structure implementation use Hazelcast initially ?

SharedData#getClusterWideMap will always ask the cluster manager for the AsyncMap. So yes, it will use Hazelcast initially as that's the default cluster implementation.