My concern is this: You have a bunch of open http requests. As far as I know, modern app servers handle requests more/less via a queue that is served by a queue of worker threads. The assumption is that each request is relatively short lived. So each request is given to the a thread in the pool and the other requests wait until a thread completes it's asigned request. Since the connections are staying open, you need a much larger pool of threads. Having large numbers of threads in Java is a killer (and ultimately limits scalability of a server far below what it is "really" capable of).
Killing idle connections doesn't really address this in the case where the majority of the users are active. Your mileage may vary. On the other hand, a client initiated socket can be handled by the server outside the direct context of a HttpServlet. We can use our own thread pool (e.g. java.util.concurrent.Executors is a great resource) which can handle more connections per thread because it understands how to avoid waiting on idle connections (without closing them) Can anyone provide any implementation details or point me to any articles which discuss these "seriously big financial and other applications that run mission critical systems"? My guess is that there are some key solutions to these problems with stock app servers and hardware. I'd like to stand on the shoulders of giants (rather than repeat their mistakes on the path to glory)! --- In flexcoders@yahoogroups.com, "Dave Wolf" <[EMAIL PROTECTED]> wrote: > > There are some things to keep in mind in terms of performance. > Realize that for every client event registration you effectively tie > up a HTTP connection on the server. This means you effectively tie up > a thread on the server. You will want to make sure you server has > enough HTTP threads and descriptors so it can still service normal > HTTP connects. You might also want to see where TCP_KEEPALIVE is set > to prevent the possibility of half dead sockets from dropped clients > getting in the way. > > You might also want to implement a timeout in the servlet. Just drop > idle sockets every N interval. Since the clients should be inside > loops, they will just reconnect if they are still alive. > > As I said, there are some seriously big financial and other > applications that run mission critical systems using just such a design. > > Dave Wolf > Cynergy Systems, Inc. > Macromedia Flex Alliance Partner > http://www.cynergysystems.com > > Email: [EMAIL PROTECTED] > Office: 866-CYNERGY x85 > > > > --- In flexcoders@yahoogroups.com, "Eric Raymond" > <[EMAIL PROTECTED]> wrote: > > > > Very clever. > > > > I'm curious if you'd care to share any experiences or gotcha's with > > this approach? > > > > In practice, can you rely upon the HtppService returning or generating > > an error? Or do you need some sort of setInterval function which > > occasionally resets things. > > > > Are there any timeouts accross the entire stack that one would need to > > be aware of. > > > > Are there any issues with the servlet thread poor that arise in > practice? > > > > > > > > > > > > > > > > --- In flexcoders@yahoogroups.com, "Dave Wolf" <[EMAIL PROTECTED]> wrote: > > > > > > No not quite. That would be polling. I am *not* suggesting polling. > > > What I am suggesting is using a "Blocking Registration" pattern to > > > handle this. > > > > > > Basically you get Flex to make an HTTP request to say a servlet in > > > your webserver. That http call will "hang". Since the player makes > > > an http request on its own thread, this hang has no impact on the > UI. > > > > > > Now when the event occurs the servlet releases the hung connection, > > > which returns data and the result handler on the client fires and > > > delivers the event to the UI. Viola. Effectively server-push but > > > without the major issues of server-push or true client-pull. > > > > > > This design has been tested in basically some of the biggest financial > > > services applications in the world. > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/nhFolB/TM --------------------------------------------------------------------~-> -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
