When does a single JMS connection with multiple production sessions begin to become a bottleneck?

Question

I recently read a lot about best practices with JMS, Spring (and TIBCO EMS) around connections, sessions, consumers and manufacturers.

When working in the Spring world, prevailing wisdom seems

• for consuming / incoming streams - use AbstractMessageListenerContainer with multiple consumers / streams.
• To create / publish streams , use CachingConnectionFactory under the JmsTemplate to support a single connection to the broker, and then cache the sessions and producers.

To create / publish, this is what my (large) server application does, where previously it created a new connection / session / producer for every single message that it published (poorly!) JmsTemplate to the use of a raw factory connection under JmsTemplate . Old behavior sometimes led to the creation of 1,000,000,000,000,000,000,000,000,000 brokers in a short period of time during periods of high peak and even falling within the descriptor / file descriptors.

However, when switching to this model, it is difficult for me to understand what performance limitations / considerations are associated with using one TCP connection with a broker. I understand that the JMS provider must ensure that it can be used in a multi-threaded way, etc., but from a practical point of view

• this is just one TCP connection
• To some extent, the JMS provider must coordinate the records down the channel so that they do not mix up with each other, even if there are several fragments in its internal protocol
• Of course, this is due to some conflicts between threads / sessions using the same connection.
• with certain network semantics (high latency for unstable broker bandwidth?), of course, one connection will not be ideal?

Assuming I'm a little on the right track

• Am I really out of order here and don’t understand how basic connections work and which the JMS provider uses?
• Is any statement a problem mitigated by having more connections or is it just transferring competition to a broker?
• Does anyone have any practical experience of reaching such a limit that they could share? Either with a specific message or network bandwidth, or even caused by # threads / sessions sharing a connection
• Should I keep in mind a single connection scenario about sessions that write very large messages that block other sessions that write small messages?

I would read any thoughts or pointers for more reading on this issue or experience, even with other brokers.

Answer 1

When you think about a bottleneck, remember two facts:

• TCP is a streaming protocol, almost all JMS providers use a protocol based on TCP

• many actions from the TIBCO EMS client to the EMS server are in the form of a request / response. For example, when you publish a message / confirm receipt of a message / make a transactional session, what happens under the hood is that some TCP packets are sent from the client, and the server will also respond to some packets. Due to the nature of TCP streaming, these actions must be serialized if they are initiated from the same connection. Otherwise, let's say that if you publish a message from one thread and at the same time you are making a session from another thread, the packets will be mixed on the wire and the server will not be able to interpret the correct message from the packets. [Note: synchronization is performed at the EMS client library level, so the user can freely share one connection with several streams / sessions / consumers / producers]

My own experience is multiple connections that always output a single connection. In a situation with network loss, it is certainly necessary to use several connections. In the best condition of a network with multiple connections, one client can almost saturate the network bandwidth between the client and server.

However, it really depends on the performance requirements of your customers, a single connection in a good network can already provide good enough performance.

Answer 2

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

You are good until you reach the limits of the system resource