🚀 go-pugleaf

In a related problem (not being able to detect the other end dying), in my
experience (in Explorer) even using setSoTimeout isn't enough to break out.
Let's say you set it to 30 seconds.  So, you block at the READ and no data
comes in for 30 seconds (and the other end is dead), you get an
InterruptedIOException which you catch.  If you go back to READing it will
just block again indefinitely EVEN THOUGH THE OTHER END IS DEAD.  I've
waited 10 minutes just to be sure and it stayed blocked (other than the
timeouts occuring every 30 seconds).  However, if when you get the timeout
exception you WRITE to the socket before going back to reading, the TCP
stack WILL detect that the other end died a mysterious death after about 40
seconds (while blocked in the READ).  Hope this doesn't confuse things more.
This sounds similar to your problem except the socket closing is the remote
one is my example - actually the machine disappeared without the socket
closing.  Of course your protocol has to support an "empty" message or you
could try a zero-byte write (just thought of it - don't know if you can).

Tom

"Evil Doona Bandit" <evildoonabandit@my-deja.com> wrote in message
news:920l3f$4j$1@nnrp1.deja.com...
> Yep, I had tried the interrupt() call, no luck there either
> unfortunately. Without knowing how the Netscape sockets are implemented
> (when blocking for input), it's difficult to say what state the thread
> is in. I guess there's always stop()...
>
> However there seems to be another solution - using a setSoTimeout() on
> the socket seems to make it aware of socket closure during reads. The
> timeout can be set to anything nonzero, and the socket reading thread
> will suddenly be able to detect when another thread has closed the
> socket. Weird huh? Why is this so? The downside of course is having to
> deal with the timeout, unless you really do want to have one..
>
>
> In article <5wc06.162440$3u1.40967621@news3.rdc1.on.home.com>,
>   "Tom Hall" <t.hall@home.com> wrote:
> > Have you tried calling "interrupt" on the thread after closing the
> socket -
> > maybe it will take the hint.
> >
> > Tom
> >
> > "Evil Doona Bandit" <evildoonabandit@my-deja.com> wrote in message
> > news:91ngv3$jep$1@nnrp1.deja.com...
> > > Hi Paul, thanks for your response.
> > >
> > > Unfortunately I'm still having no luck with the first thread
> snapping
> > > out of it and realising that the socket has actually been closed.
> The
> > > notify() call was worth a try but Netscape didn't want to cooperate.
> > > The thing is, there are no locks being held on the socket object,
> and
> > > no opportunity for deadlock of any kind - thread 2 closes the socket
> > > and returns to being a GUI event handler thread, which leaves the
> > > socket reading (blocking) thread as the last remaining user thread.
> It
> > > is apparently still twiddling its thumbs, waiting for that next
> input
> > > from the stream. It's pretty weird..
> > >
> > > Anyway, I thought that this would be a fairly common operation in a
> > > client/server situation, so surely others would have encountered
> this
> > > same issue with Netscape..?
> > >
> > > Thanks again for the suggestion Paul, I'll keep fiddling around
> with it
> > > to see what can be done. If you have any more ideas, please let me
> know!
> > >
> > > Thanks,
> > >
> > > EDB
> > >
> > > In article <WW1%5.160574$e5.123342@newsfeeds.bigpond.com>,
> > >   "Paul Murray" <pmurray@nospam.bigpond.com> wrote:
> > > > Try doing a notify() on the socket - may or may not work,
> depending
> > > on how
> > > > blocking is implemented.
> > > >
> > > > --
> > > > --------------------------------------------------------------
> > > > Repent! Quit your job! Slack off!
> > > > http://www.users.bigpond.com/pmurray
> > > > ICQ: 26066755
> > > > "Evil Doona Bandit" <evildoonabandit@my-deja.com> wrote in message
> > > > news:91hkvn$5t2$1@nnrp1.deja.com...
> > > > > Hi,
> > > > >
> > > > > A small problem that I've encountered with testing an applet in
> > > > > Netscape:
> > > > >
> > > > > Thread 1 blocks on the readObject() call to a (client) Socket's
> > > input
> > > > > stream.
> > > > >
> > > > > Thread 2 closes the socket, which should hopefully force Thread
> 2 to
> > > > > throw an IOException, but doesn't. The socket has been closed,
> but
> > > > > Thread 1 keeps blocking in Netscape v4.70, even though in Sun's
> > > > > appletviewer and IE v5.5 it is well behaved and throws the
> > > exception.
> > > > >
> > > > > Has anyone else had the same problem with Netscape? Any ideas? I
> > > would
> > > > > rather not change the code to put in a Socket timeout, and then
> > > have to
> > > > > regularly check a flag to see if the socket is due to be closed,
> > > etc.
> > > > >
> > > > > Thanks in advance!
> > > > >
> > > > > EDB
> > > > >
> > > > >
> > > > > Sent via Deja.com
> > > > > http://www.deja.com/
> > > >
> > > >
> > >
> > >
> > > Sent via Deja.com
> > > http://www.deja.com/
> >
> >
>
>
> Sent via Deja.com
> http://www.deja.com/