@harry:
Q1. Yes. In the case of message burst nothing changes in the architecture - we don’t have special burst handling buffers or anything like that, because the architecture was designed to deal with just such a scenario. Each event is separately handled - we don’t resort to batch handling or anything like that. In fact, we can’t - each event can have a completely different topic so they have to be treated individually. A further detail is that the architecture is designed to support fan-out: a single message in may be destined for many subscribers. That means the key resource is actually the egress buffers rather than the ingress buffers. What almost always happens is that message consumers end up being the bottleneck, and we start intelligently dropping messages or connections if consumers can’t keep up and we start running out of buffer space.
Q2. In general I’d say you’re right - if you have a long running stateful process, such as a JVM, have that open the connection and the short lived jobs running in that JVM use the same connection. There are some performance considerations, but let’s cross that bridge when we come to it.