On Tue, Mar 31, 2015 at 11:02 AM, Alan Conway <acon...@redhat.com> wrote:
> On Mon, 2015-03-30 at 00:11 +0100, Adrian Preston wrote:
> > Hello all,
> >
> > I've been following the development of the reactor API and think that it
> looks really neat. Is anyone working on a pure Java version? I'd be
> interested in helping.
> >
> > Regards
> > - Adrian
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
> >
>
> I'm currently working on a Go version which is not directly relevant,
> but porting directly from the python handlers.py and it is pretty
> straightforward. That's where I would start. For Go I also had to wrap a
> bunch of lower-level proton details but the task should be easier for
> Java since all that stuff already exists in Java.
>
> In Go I am not using the proton reactor to establish or select over
> connections, so I'm not using any of the reactor or selectable events. I
> have a goroutine per connection pumping a proton transport with separate
> event handling per-connection so we have connection concurrency but each
> proton engine is only used in a single thread.
>
This sounds to me like it is based on a bit of a missunderstanding of how
the reactor works. The reactor doesn't actually establish or select over
connections in C/Python. It is actually just mediating the request for
connection creation between whatever piece of application code wants a new
connection, and whatever handler has been configured to deal with I/O
related events. This allows for a significant amount of flexiblity since
you can have multiple I/O implementations without having to hard code your
app to work against a specific one. This is just as important a requirement
in Go or Java or any other language.
> I'm not sure what the right approach is for Java. Having a C-based
> reactor is useful in C and for some bindings (e.g. the python binding
> uses it) but in languages that have their own version of event
> loops/polling/selecting it may be better to go with the native
> approach.
>
The reactor is pure code/data structure. I believe the correct approach for
Java would be a straightforward port, and the correct approach for Go would
be a simple binding, just like all the other pure code/data pieces
(connection, transport, etc). Tthinking of the reactor as part of the I/O
subsystem is to misunderstand how it works. The reactor proper has been
carefully designed to not directly incorporate any I/O dependencies at all.
In other words, don't think of the reactor as analogous to or a replacement
for the old Driver, think of the reactor as a (potentially)
multi-connection engine, or in UML terms:
Reactor <>---> Connection <>--> Session <>---> Link <>---> Delivery
Please excuse the ascii art UML. The diamonds are supposed to imply
containment by composition.
--Rafael
