On Sun, 2015-07-12 at 09:14 +0100, Fraser Adams wrote: > > As I say I think that ActiveMQ Apollo started out because of scaling > limitations of the original ActiveMQ and has evolved to a reactor > based > threading model built on hawt-dispatch (Java implementation of Grand > Central Dispatch https://en.wikipedia.org/wiki/Grand_Central_Dispatch > ) - > so a task parallel threading model rather than a shared state > threading > model. Given that the Proton reactor stuff seems to be, well, a > reaction > :-[ to this problem space it got me curious about the Qpid brokers.
The proton reactive APIs are an attempt to find an API that works well for servers AND clients. Procedural APIs are good for clients but problematic on brokers which must "react" to unpredictable client activity. This aspect is not really related to performance. The proton engine is a single-threaded event processing state machine. To scale across cores you need to use epoll or similar to dispatch from a large number of connections to to a small thread pool that serializes work to each proton engine. That is exactly what qpidd and dispatch do. The proton C reactor also has events that can hook directly into epoll or select, e.g. accepting incoming connections. This is useful for writing portable (i.e. epoll/select agnostic) *singe threaded* servers, but it doesn't help with multi-core. I'm not sure yet if the C reactor can/should be extended to multi-core or if concurrency support belongs in the language binding layer. This is especially true of languages like Go with built-in concurrency support. See http://qpid.apache.org/proton/go/ for more --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
