Yup, you are dead on with your understanding. But remember in my descriptions I said that the server would be able to on schedule also force disconnects. This also frees worker threads as well. The clients would be coded in a loop looking for the disconnect and reconnecting. Again you need to weigh all of this. The impact on the nework in terms of the pusedo polling, the impact on the app server in terms of threads, acceptable latency, etc.
In terms of the reference, please feel free to give me a call. As I am sure you'd understand, we do much of our work under NDA. This is especiall true of a financial institution who doesnt want their server topology discussed, but I would be glad to discuss this anytime. The other thing to keep in mind though. Most of the alternaative architectures are just unworkable in a true distributed network (aka the web). Dave Wolf Cynergy Systems, Inc. Macromedia Flex Alliance Partner http://www.cynergysystems.com Email: [EMAIL PROTECTED] Office: 866-CYNERGY x85 --- In [email protected], "Eric Raymond" <[EMAIL PROTECTED]> wrote: > > 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 [email protected], "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 [email protected], "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 [email protected], "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 --------------------~--> Most low income households are not online. Help bridge the digital divide today! http://us.click.yahoo.com/cd_AJB/QnQLAA/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/
