10

My case is:

  • single JVM
  • Java only (i don't need to be polyglot)
  • I don't want to pay serialization costs to publish an immutable event on the bus (publishing the reference to the java object would work).

I understand the scope of the vert.x event bus is much broader than my use case.

I had in mind a behaviour similar to akka: when you go distributed you have to provide serialization for your messages, if you stay local references get passed.

Is there anything that would allow me to do that in Vert.x?

white-surf-style-five
  • 423
  • 2
  • 14
  • send objects' ids instead of the objects themselves over the eventbus – injecteer Jul 17 '18 at 14:45
  • that could work. However i would avoid it as it would mean that i have shared state between publisher and consumer... which would mean why have a bus in the first place? – white-surf-style-five Jul 17 '18 at 14:49
  • with your case I also see no actual benefit of using event bus. You could easily use some java in-process messaging – injecteer Jul 17 '18 at 14:50
  • btw, in that `shared state` you mentioned, you would still have to use serialization – injecteer Jul 17 '18 at 14:52
  • In fact what i want to do is use some "in-process messaging" but also leverage the event loop dispatching semantics of Vert.X. Regarding serialization and shared state: i don't see the connection: how come sharing a java reference relates to serialization? – white-surf-style-five Jul 17 '18 at 16:56

1 Answers1

11

Vert.x already has such an optimization. When sending to the same JVM, objects won't get serialized or deserialized.

You can see the actual code here: https://github.com/eclipse/vert.x/blob/master/src/main/java/io/vertx/core/eventbus/impl/EventBusImpl.java#L372

When you implement your MessageCodec, you actually have two methods: decodeFromWire() and transform(). You can implement only transform with the most naive approach:

@Override
public Object transform(Object o) {
   return o;
}
Alexey Soshin
  • 16,718
  • 2
  • 31
  • 40