I imagine the RA creates a pool of connections. There ARE various reasons why multiple connections might be required, such as possibly for use in transactions. But from pretty extensive experience building other high performance network stacks I'd say it isn't a matter of greater throughput can be had from 2 or 3 connections vs 1 say. What determines throughput is how much data can go back and forth in a unit time (or perhaps the latency of individual data, depending on your requirements). A 'connection' is just a software construct. Actual data flow is accomplished by CPUs moving data onto the network stack and the NIC driver forwarding it onto the network, or receiving it and forwarding it to the application layer. One connection can do that as efficiently as many in general. That being said if someone that designed the code says different, then believe them. There could be concurrency or thread contention, locality, or context switching effects that make the code work better one way or the other.
Of course benchmarking different configurations never hurts. In an SMP machine several connections MIGHT gain you some, but I doubt more connections than CPUs will add much. drvillo wrote: > > Hi > > ok, interesting, I didn't know this. My doubt about connections > originated by seeing that by default 12 connections are created, of > which only one per destination is used. > > > > Abdul Alhazred wrote: >> >> Do you actually NEED multiple connections? >> >> IIRC each Session is effectively a thread of execution. I'm not sure how >> exactly pulling messages off the >> connection is implemented without going through the code, but just from a >> basic understanding of how >> JCA and the J2EE container normally manage resources it wouldn't seem to >> me to be required to have >> several connections. As messages come in on the one connection they >> should get dispatched to the >> MDB container in parallel via different sessions (or at least the >> internal implementation aught to be the >> same effect). I guess the results could depend on J2EE container >> internals, but it seems to me any good >> implementation should give good performance with one connection in >> general. >> >> >> drvillo wrote: >>> >>> Hi all >>> >>> I have some problems understanding how connection/session >>> pooling with jencks works, I would apreciate if someone could give me >>> some help... >>> >>> >>> I understand the use of maxSessions on an activationspec, and also >>> what the threadpool attribute of a JCAContainer is for. >>> What I don't get, is why if I specify maxSessions=1 I still >>> see that messages are consumed by multiple threads (looking >>> at the logs). This is in principle fine with me, as threads are >>> retrieved >>> by a pool but reading this >>> http://www.nabble.com/-activemq-user--maxSessions-limits-messages-fetched--tf254599.html#a773237 >>> it seems that I should see always the same one consuming messages. >>> >>> Another thing about pooling: why I get always >>> a single subscription on a queue, even if pooling the listeners with a >>> TargetSourceMessageListener? What is the point of having a pool >>> of identical stateless listeners if they all share the same connection? >>> >>> My primary objective is to maximize throughput, thus I'd like to have >>> a pool of listeners which consume messages using multiple connections, >>> is it possible to do so using a single JCAConnector or I have to >>> statically declare more of them? >>> >>> Wrapping up, are these two arguments (tweaking maxSessions, threadPool >>> and such, and >>> having more parallelism) related? >>> >>> I hope someone can help me on this, it's pretty hard to tune a system >>> without understanding the effect of its parameters... >>> >>> Thanks a lot >>> Francesco >>> >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/Configuring-session-connection-pooling-to-maximize-throughput-tf2925304.html#a8236981 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
