Since we don't have direct UDP support in Reactor yet, your abstractions to publish events into Reactor are very sensible. But you do note in your "bonus question" that there are issues with publisher/consumer throughput that have to be managed in some domain-specific way; there's no silver bullet there.
In your use-case, I'd actually be tempted to say the Processor
[1] might be a better fit. It provides much higher overall throughput for data processing because it circumvents the dynamic Selector-based dispatching that happens in a plain Reactor
. Unless you're dispatching the incoming events to different handlers based on some topic criteria, I'd suggest you look at that instead. With higher throughput, you'll have to worry a little less about Consumers keeping up (unless your Consumer
is doing something really slow, which nothing can automagically speed up).
But if you really, really need to manage the backlog, I'd suggest decoupling your producers and consumers via a Queue
. Reactor has a PersistentQueue
[2] abstraction you can use to publish objects into and persist to disk using JavaChronicle [3], which can then be drained into a Consumer
using a Poller
(javadoc is coming on Poller
sometime this week as we get ready for 1.0...it was previously called Pipe
[4]).