When does a single JMS connection with multiple producing sessions start becoming a bottleneck?

When thinking about the bottleneck, keep in mind two facts:

1. TCP is a streaming protocol, almost all JMS providers use a TCP based protocol

2. lots of the actions from TIBCO EMS client to EMS server are in the form of request/reply. For example, when you publish a message / acknowledge a receive message / commit a transactional session, what's happening under the hood is that some TCP packets are sent out from client and the server will respond with some packets as well. Because of the nature of TCP streaming, those actions have to be serialised if they are initiated from the same connection -- otherwise say if from one thread you publish a message and in the exact same time from another thread you commit a session, the packets will be mixed on the wire and there is no way server can interpret the right message from the packets. [ Note: the synchronisation is done from the EMS client library level, hence user can feel free to share one connection with multiple threads/sessions/consumers/producers ]

My own experience is multiple connections always output perform single connection. In a lossy network situation, it is definitely a must to use multiple connections. Under best network condition, with multiple connections, a single client can nearly saturate the network bandwidth between client and server.

That said, it really depends on what is your clients' performance requirement, a single connection under good network can already provides good enough performance.

Even if you use one connection and 100 sessions it means finally you are using 100threads, it is same as using 10connections* 10 sessions = 100threads.

You are good until you reach your system resource limits