In the DayTime Server example I have, there appears to be a call
to Thread.stop() ( on page 301 in Hunter/Crawford)to stop the
daemon thread. Is this accepted procedure or is there a more recent
edition?
Do you guys have any comments on using Thread.stop()
in general, not just in servlets? I do this, optionally, in
applets when everything goes bad and the only apparent alternative
is hanging a browser. How do you kill a thread stuck waiting to get
into a synchronized block? Is this improved in 1.4?
It doesn't look like there is really anything more dangerous about
launching a thread
from a servlet than from anything else(especially compared to an applet
inside
of an undetermined browser!).
Thanks.
->-----Original Message-----
->From: Christopher K. St. John [mailto:[EMAIL PROTECTED]]
->Sent: Sunday, August 05, 2001 11:52 PM
->To: [EMAIL PROTECTED]
->Subject: Re: is there support for raw tcp sockets ?
->
->
->Mark Galbreath wrote:
->>
->> Import the com.oreilly.servlet.DaemonHttpServlet class
->> and extend it in your main class.
->>
->
-> The DaemonHttpServlet code looks a little iffy.
->
-> DaemonHttpServlet.destroy() doesn't do the magic
->'close the socket out from underneath the waiting
->thread' trick, which means run() may not get knocked
->out of waiting for accept() and the accept'ed Socket
->isn't tracked at all, which means that handleClient
->could block forever waiting for client input.
->
-> Things get even more complicated when handleClient
->needs to do any significant work, since then you have
->to override destroy() to make sure it not only shuts
->down the socket, but also anything else handleClient
->might be waiting for. Plus, of course, the myriad of
->possible race conditions if the servlet container
->brings the servlet back to life while the old thread
->is still shutting down.
->
-> The whole point of defining a servlet lifecycle is
->that it means the servlet container can worry about
->all of that stuff for you. Clever tricks to get
->around the 'problem' mean that _you_ are now
->responsible for implementing all the tricky bits.
->
-> Classes like DaemonHttpServlet are evil, because
->they give newbies the false impression that they
->don't need to worry, and get in the way of knowledgable
->developers trying to do the right thing.
->
-> Just say no :-)
->
->
-> [1] See java.nio.channels.Channel javadoc referenced
->in previous message (and assuming I'm looking at the
->right version of the DaemonHttpServlet code)
->
->
->
->--
->Christopher St. John [EMAIL PROTECTED]
->DistribuTopia http://www.distributopia.com
->
->______________________________________________________________
->_____________
->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
->
->
___________________________________________________________________________
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
