This discussion is just starting to stray into 'advanced-java' territory, indeed we had a discussion about large numbers of threads in a single VM a month or so ago. David Chase of Natural Bridge cited their product, as proof by example that it is possible to support large numbers of threads on a single VM, by multiplexing multiple java threads onto an OS thread. However Gosling's origional design for Java threads was explicitly that they could map 1-to-1 with the OS's threads, so for the while we'll have to live with OS threading limitations. As far as async servlets are concerned, I don't see a future in the 'async get()' pattern, where the current get() method is split into two methods, one that starts a thread to process the request, and a second 'call-back' method that is invoked when the thread completes in order to send the actual data. What this discussion has raised (for me) is the issue of background threads in the servlet engine. As I understand it, these are frowned upon, but there are cases where they are _very_ useful, for example use them to poll snmp variables, which ensures that we can always pop up a historical graph of (say) bandwidth whenever a browser request comes in. We'd like to see some support for this in the servlet container, with threads started at startup an (possibly) serialized at shutdown. Tim ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
