Interesting... So that may help to explain why my application which sends persistent messages and also receives works better if I use one connection on the sending and one on the receiving side. I haven't delved into why, but it seems like sending was bogging down receiving with only one connection, so your observation may answer that.
James.Strachan wrote: > > The session is the unit of transaction and threading, so a single > connection should do for most folks. > > For concurrency of consumers you should have lots of sessions on a > connection. (Its against the spirit of the spec but sending in a > non-transacted way on ActiveMQ you can get away with a single session > & produce as multiple threads can send on the same session > concurrently since the transport layer is completely async) > > However one area to be careful of is currently each connection's > commands are processed by a single thread on the broker side; so for > relatively slow operations like durable producers you won't get much > concurrency on the broker side (Guillaume hit this recently AFAIK on > ServiceMix). So you might want to have many connections too so that > you can have completely async broker side processing of separate > producers. Though we should allow a thread pool to be used for > different logical sessions on the broker side to avoid the client > having to worry about that. > > > On 1/9/07, Abdul Alhazred <[EMAIL PROTECTED]> wrote: >> >> 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. >> >> > > > -- > > James > ------- > http://radio.weblogs.com/0112098/ > > -- View this message in context: http://www.nabble.com/Configuring-session-connection-pooling-to-maximize-throughput-tf2925304.html#a8285243 Sent from the ActiveMQ - User mailing list archive at Nabble.com.
