On Wed, 2015-06-10 at 09:34 +0000, Kritikos, Alex wrote:
> [Resending as it ended up in the wrong thread]
> Hi all,
> is the proton-j engine meant to be thread safe?
The C engine is definitely NOT meant to be thread safe. Unless you have
found an explicit written declaration that the java engine is supposed
to be AND a bunch of code to back that up I wouldn't rely on it.
The way we use proton in the C++ broker and in the upcoming Go binding
is to create an engine per connection and serialize the action on each
connection. In principle you can read and write from the OS connection
concurrently but it's debatable how much you gain, you are likely just
moving OS buffers into app buffers which is not a big win.
The inbound and outbound protocol state *for a single connection* is
pretty closely tied together. Proton is probably taking the right
approach by assuming both are handled in a single concurrency context.
The engine state for separate connections is *completely independent*
so it's safe to run engines for separate connections in separte
The recent reactor extensions to proton are interesting but not thread
friendly. They force the protocol handling for multiple connections
into a single thread context, which is great for single threaded apps
but IMO the wrong way to go for concurrent apps.
The go binding uses channels to pump data from connection read/write
goroutines to a proton engine event loop goroutine per connection. The
C++ broker predates the reactor and does it's own polling with
read/write activity on an FD handled dispatched sequentially to worker
threads so the proton engine for a connection is never used
There may be something interesting we can do at the proton layer to
help with this pattern or it may be better to leave concurrency above
the binding to be handled by the languages own concurrency tools, I am
not sure yet.
> We have been experiencing some sporadic issues where under load, the
> engine sends callbacks to registered handlers with null as the event.
> We do not have a standalone repro case yet but just wondered what
> other people’s experience is as well as what are the recommendations
> around thread safety.
> Alex Kritikos
> Software AG
> This communication contains information which is confidential and may
> also be privileged. It is for the exclusive use of the intended
> recipient(s). If you are not the intended recipient(s), please note
> that any distribution, copying, or use of this communication or the
> information in it, is strictly prohibited. If you have received this
> communication in error please notify us by e-mail and then delete the
> e-mail and any copies of it.
> Software AG (UK) Limited Registered in England & Wales 1310740 -