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

[Tony Garnock-Jones]

Hi Matthias,

Matthias Karlsson wrote:
> 1) Each thread has its own connection from which it creates one channel
> 2) One connection is shared for the whole application, multiple
> channels are created and given to threads
> 3) A hybrid variant where X channels is created from every connection,
> and depending on the number of threads, a number of connections are
> created

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.

The main differences are in terms of error handling: who is affected by 
a dropped connection. If multiple channels share a connection, a bug in 
a thread using one channel can disturb the clean operation of other 
channels. (Partly because AMQP 0-8's error design is not as clean as it 
could be, and accidentally specifies connection-level errors in some 
cases where a channel-level error was clearly a better idea.)

> The application needs to be fail-safe and be able to restablish
> connections to the broker in case of network problems, broker goes
> down etc.

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).

> I was also curious about performance. If a large amount of messages
> are sent, it seems like it would be more efficient to send those over
> a set of sockets ([1] or [3] above), instead of forcing them all
> through the only one available ([2] above).

Latency can suffer when multiplexing multiple channels over a socket, 
but generally not to more than epsilon above multiple sockets being 
multiplexed over an ethernet: after all, there's still just the one 
physical access medium! That said, 'one channel per connection' really 
should give slightly smoother operation -- at least in theory :)

Regards,
   Tony