Hmm I woudl have thought otherwise, since after
reading the protocol it seems specificly designed
to support keeping connection alive.
That a sender would keep a "pool" of available
connections and when a hit comes in "get" one
which is already connected, and push the request
out, and the destination looks up the servlet and
dispatches to it (until the request is complete),
and when complete, releases the still open
connection so the sender and can recycles it back
into its pool without "disconnecting" ie: socket
remains open. and there is some huristic for
culling excess connections after heavy traffic
may hve opened more than configured.
Anyway that is what I would do ;^>
If by "multiplexing" you thought interleaving
routed packets for simultaneous "hits" on one pipe I didn't mean that.
PK
At 02:41 3/8/2007, you wrote:
Peter Kennard wrote:
Doesn't AJP "multiplex" traffic, that is queued
up requests are "serialized" through one
connection that remains connected and it
switches between servlets on the receiving end?
and recycles the execution thread?
No multiplexing on connections.
Regards,
Rainer
At 19:19 3/7/2007, you wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rémy,
Rémy Maucherat wrote:
> The scalability improvement is twofold for AJP:
> - when running many Apache frontend servers (each with a sizeable
> number of workers), Tomcat would need a huge amount of AJP worker
> threads with the java.io connector
Makes sense. So, instead of a Java thread waiting in every single ajp
connection, you're using one native listener thread waiting on a
select(), right? It's sad that you can't do this in Java :(
> - threads will only be used for actually executing requests, thus
> making concurrency in business logic a bit more predictable (if you
> have 2000 threads, it's ok most of the time, as long as no lock gets
> contested by too many threads, in which case it's far better if you
> had only 200 threads)
Definitely. Unless I'm mistaken, Java threads on Linux are pthreads,
which are relatively heavy. Reducing them is certainly going to reduce
memory, thread counts (wrt system limits), and thread dump lengths.
> It also saves memory (no surprise). Socket polling will only be used
> for keepalive: during the processing of a request, the connector uses
> regular blocking IO.
Cool. So, it /does/ sound like something worth looking into. APR
installation looks like a snap, too, so it shouldn't be painful at all.
Thanks for the explanation, Rémy.
- -chris
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
