Best practices using proton-j Reactor

[Garlapati Sreeram Kumar <sr...@live.com>]

Hello Folks!

Couple of Questions on Proton-j Reactor usage-pattern:

1. In the current version of proton-j: 1 Reactor instance is tied to 1 connection – is there any way to associate 1 Reactor per Link.
Or in other words, If there are multiple links attached to one Connection, which is handled by one Reactor instance - What is the recommendation to use reactor in such a way that One link will not impact others – the unhandled exceptions and the time it takes to process.
Here’s the Problem: When one of the links perform I/O upon any event dispatched (ex: onDelivery) by the Reactor pump – all other links are starving for messages as that I/O is blocking the thread in which reactor.run() – which absolutely makes sense from Reactor pump (the reactor.run()) perspective. 

2. What is the Best way to gracefully Stop the Reactor.
In our Tests – where we  are Starting a Reactor per testclass and calling reactor.free as part of class cleanup – throws exception: reactor:org.apache.qpid.proton.engine.HandlerException: java.nio.channels.ClosedSelectorException
Do we need to handle this by try-catch’ing the reactor.run() block ?

Thanks a lot for such a Wonderful Collaboration!
Sree

Re: Best practices using proton-j Reactor

[Robbie Gemmell <ro...@gmail.com>]

Hi Sree,

I'm not too familiar with the Reactor bits, I've never used them
beyong the send/recv examples, but I'll try to answer what I can.
Perhaps other folks can chime in if they know more (even if based on
knowledge of the proton-c reactor). Responses inline.

On 3 February 2016 at 20:05, Garlapati Sreeram Kumar <sr...@live.com> wrote:
> Hello Folks!
>
> Couple of Questions on Proton-j Reactor usage-pattern:
>
> 1. In the current version of proton-j: 1 Reactor instance is tied to 1 connection – is there any way to associate 1 Reactor per Link.

I think its actually each Connection (and related bits) is tied to a
single Reactor rather than the reverse, but no I wouldnt expect you
can associate a different reactor (though you could perhaps associate
a different Handler) with each link since that would presumably
involve multiple threads.

The proton engine can only be used by a single thread at a time. This
essentially encompasses everything relating to a given Transport as a
group except for the Message objects (which themselves still need to
be accessed by 1 thread at a time) since they are formed seperately
either from scratch or from bytes taken from a Delivery. The reactor
bits are one implementation of achieving that single-threaded access.

> Or in other words, If there are multiple links attached to one Connection, which is handled by one Reactor instance - What is the recommendation to use reactor in such a way that One link will not impact others – the unhandled exceptions and the time it takes to process.
> Here’s the Problem: When one of the links perform I/O upon any event dispatched (ex: onDelivery) by the Reactor pump – all other links are starving for messages as that I/O is blocking the thread in which reactor.run() – which absolutely makes sense from Reactor pump (the reactor.run()) perspective.
>

Do you mean for example taking a long time to process a particular
delivery before accepting/etc? I think the reactor is built around
assumption that events will be handled quickly. There does seem to be
support for scheduling tasks and inserting your own selectables, so
one approach might be to offload any long running processing of
deliveries to another thread and construct a way to monitor their
progress and then have the reactor take any subsequent action. In
terms of IO I would expect that to be non-blocking? I'm not sure what
exceptions you are referring to.

> 2. What is the Best way to gracefully Stop the Reactor.
> In our Tests – where we  are Starting a Reactor per testclass and calling reactor.free as part of class cleanup – throws exception: reactor:org.apache.qpid.proton.engine.HandlerException: java.nio.channels.ClosedSelectorException
> Do we need to handle this by try-catch’ing the reactor.run() block ?
>

I'm not entirely sure about this. The examples mostly look to take
advantage of the reactor exiting once there is no outstanding work (no
scheduled tasks, and no other selectables to process (e.g for outgoing
connections, or an acceptor for incoming ones)). Anything that calls
free() does it from the thread running the reactor, right after run()
returns. The wakeup() method is noted in the javadoc as the only
method that can be safely called while another thread is still
processing the reactor.

> Thanks a lot for such a Wonderful Collaboration!
> Sree
>