[rabbitmq-discuss] Multithreaded application, separation of connections and channels

Tue Jun 30 12:27:47 BST 2009

Hi Tony,

thanks for your input!

>
> Unless you have a very high number of threads and/or separate VMs, your
> option (1) seems easiest to work with. Suitably abstracted, it can always be
> switched out for one of the others later.
>

Implementation-wise, this seems to be the easier one to get right and
it'll most likely be the one I'll use when prototyping. There will be
many instances of the same application (so more VMs) though so I will
have to make some careful benchmarking I think.

> Many people have this need. It'd be great if you could share the design (or
> even the implementation!) of what you come up with for this; our java
> library is very much a thin layer atop the protocol, and could definitely
> stand to grow some affordances for the developer.
>
> As a complete aside, since it's not directly relevant to getting something
> working for solving the problem you have, we've been thinking a little bit
> about how best to do reconnection/HA/etc in a language-neutral way. Our
> current thinking is something along the lines of a small, standalone,
> light-weight *client-side* AMQP proxy, accessible from any AMQP-speaking
> language library. The proxy would deal with connection reestablishment and
> message redelivery, making use of the "fate-sharing" notion used in the
> design of TCP. The idea is that it'd be trustworthy because it'd be on the
> same machine as the client itself. Such a proxy could also help with various
> HA and sharding scenarios (by automating and abstracting-out communication
> patterns like N-of-M and deduplication etc).
>

When I get something up and running (I haven't planned the actual work
until late July however) I can definitely share any information I have
found (ideas, code etc.).

My planned implementation for the fail-safe is to basically take an
existing solution I wrote for when the application communicated over
pure TCP sockets. Basically, each socket (5-10) is associated with a
thread hidden behind a common "output"-interface. This thread is
responsible for delivering messages received, and to (re)establish the
connection when needed. Further more, if messages are recieved when in
disconnected state, messages are queued waiting for the socket to be
reestablished. When the number of queued messages reach a certain
threshold, they are flushed to local disk to avoid an ultimate
OutOfMemoryException (these messages are then of course read back when
the connection is up again).

In this regard, this seems to be along the same lines as your proxy,
though yours is more general and low-level. Have you given any thought
about how to handle messages received when not connected? With proper
callbacks to application code, a developer could himself decide how to
handle messages that couldn't be delivered due to communication
problems, e.g. discard, save to disk locally, queue in memory and so
on. That is, perhaps make the failhandling pluggable with perhaps at
least two obvious implementations available by default, one that
discards messages and one that queues in memory forever waiting for
reconnect.

// Matthias