Mladen Turk wrote:
Filip Hanik - Dev Lists wrote:
Mladen Turk wrote:
The ultimate goal is to have 20k connections and still handle them
evenly.
The question is what will you do with those 20K connections.
The goal is that they will eventually get serviced, and that is the key.
in my test, with around 4k requests/second, each connection should get a
request in every 5 seconds. However, if fairness is not implemented,
some connections are very likely to never get serviced. If the
acceptor(new connections) is competing with the poller(keep alive
connections) there is a risk for new connections not getting a say in
the game.
The current servlet implementation as well as http protocol
is transactional (request/response), and presumes that there
is no thread context switches during that transaction.
So, you are limited by design to handle the keep-alive only
on the opened connection.
If there is no keep-alive you are just filling the queue
with incoming connections, that needs to be served by limited
number of worker threads. The worker thread can be reused only
when the transaction ends (request/response).
A very valid point, there should be a "limit" attribute for the max
number of keep alive connections, or connections period.
Otherwise, if you are on Linux for example, if you get too many
connections, and start taking up
too much memory (socket buffers take up a lot), Linux kills the java
process instead of letting it take up even more RAM. The linux kernel
has a harsh but effective way of dealing with outside Java heap OOM
errors. :)
True async behavior would need a true async servlet specification,
We're doing pretty well with Comet, the only thing comet is missing is a
non blocking write.
Ie, if I have 1 thread servicing 1000 comet connections, I cant afford
to get stuck on one.
If the Comet API will let me query the response to see if I can write
without block, I can achieve that pretty well.
with all the thread local data persisted to a socket key, but then again
the memory consumption would be as large as traditional one.
Of course one can always try to propose something like Restlet
and hope people will start programming concurrently :)
yeah, when folks like us barely program concurrently, it would be
wishful thinking :)
I'm planning
Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
