Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > How to kill thread which is blocked by Serversocket.accept()?

Reply
Thread Tools

How to kill thread which is blocked by Serversocket.accept()?

 
 
Jan Liße
Guest
Posts: n/a
 
      02-16-2004
Hi;
I have got a network-thread running in the background listening for
connection-attempts.
The thread uses an instance of Serversocket and its accept() method to
listen.
After a certain period of time i want to kill the thread if no connection is
established.
The problem is: the accept-method blocks until someone connects.
Therefore it is not possible for me to use the interrupted-flag and check it
within a loop in my
thread to signalize it to end (the recommended way to kill a thread). I dont
want to use the thread.stop
() method since it is deprecated, but even when i try to use it i can not
kill the thread.
Within my gui thread i tried to use a swing timer, but it doesnt kill the
thread:

timer = new Timer(TEN_SECONDS, new ActionListener() {
public void actionPerformed(ActionEvent evt) {
if (networkThread.isAlive) {
timer.stop();
networkThread.stop();
//...Update the GUI...
}
}

Anybody there who knows a proper way of killing such a blocked thread?

Thanks in advance,
Jan


 
Reply With Quote
 
 
 
 
Ryan Stewart
Guest
Posts: n/a
 
      02-16-2004
"Jan Liße" <(E-Mail Removed)> wrote in message
news:c0q37g$19jcpa$(E-Mail Removed)-berlin.de...
> Hi;
> I have got a network-thread running in the background listening for
> connection-attempts.
> The thread uses an instance of Serversocket and its accept() method to
> listen.
> After a certain period of time i want to kill the thread if no connection

is
> established.
> The problem is: the accept-method blocks until someone connects.
> Therefore it is not possible for me to use the interrupted-flag and check

it
> within a loop in my
> thread to signalize it to end (the recommended way to kill a thread). I

dont
> want to use the thread.stop
> () method since it is deprecated, but even when i try to use it i can not
> kill the thread.
> Within my gui thread i tried to use a swing timer, but it doesnt kill the
> thread:
>
> timer = new Timer(TEN_SECONDS, new ActionListener() {
> public void actionPerformed(ActionEvent evt) {
> if (networkThread.isAlive) {
> timer.stop();
> networkThread.stop();
> //...Update the GUI...
> }
> }
>
> Anybody there who knows a proper way of killing such a blocked thread?
>
> Thanks in advance,
> Jan
>

Close the socket.


 
Reply With Quote
 
 
 
 
John C. Bollinger
Guest
Posts: n/a
 
      02-16-2004
Jan Liße wrote:

> Hi;
> I have got a network-thread running in the background listening for
> connection-attempts.
> The thread uses an instance of Serversocket and its accept() method to
> listen.
> After a certain period of time i want to kill the thread if no connection is
> established.
> The problem is: the accept-method blocks until someone connects.
> Therefore it is not possible for me to use the interrupted-flag and check it
> within a loop in my
> thread to signalize it to end (the recommended way to kill a thread). I dont
> want to use the thread.stop
> () method since it is deprecated, but even when i try to use it i can not
> kill the thread.
> Within my gui thread i tried to use a swing timer, but it doesnt kill the
> thread:
>
> timer = new Timer(TEN_SECONDS, new ActionListener() {
> public void actionPerformed(ActionEvent evt) {
> if (networkThread.isAlive) {
> timer.stop();
> networkThread.stop();
> //...Update the GUI...
> }
> }
>
> Anybody there who knows a proper way of killing such a blocked thread?


I think you are going about it the hard way. If you read the API docs
for ServerSocket.accept(), you will see, among other things,

"Throws:
[...]
SocketTimeoutException - if a timeout was previously set with
setSoTimeout and the timeout has been reached."

That seems custom-made for precisely your problem. If you proceed to
read the docs for setSoTimeout then it seems even more so. Before
invoking accept(), then, set a timeout via setSoTimeout, and you
shouldn't need to worry about actively killing the accepting thread.
Moreover, you can trap the SocketTimeoutException and take appropriate
action in the thread that attempted to accept(), where you have
considerably more context with which to write log messages, retry, or
whatever else you might want to do.


John Bollinger
http://www.velocityreviews.com/forums/(E-Mail Removed)

 
Reply With Quote
 
Thomas G. Marshall
Guest
Posts: n/a
 
      02-18-2004
Jan Liße <(E-Mail Removed)> coughed up the following:

> Hi;
> I have got a network-thread running in the background listening for
> connection-attempts.
> The thread uses an instance of Serversocket and its accept() method to
> listen.
> After a certain period of time i want to kill the thread if no
> connection is established.
> The problem is: the accept-method blocks until someone connects.
> Therefore it is not possible for me to use the interrupted-flag and
> check it within a loop in my
> thread to signalize it to end (the recommended way to kill a thread).
> I dont want to use the thread.stop
> () method since it is deprecated, but even when i try to use it i can
> not kill the thread.
> Within my gui thread i tried to use a swing timer, but it doesnt kill
> the thread:
>
> timer = new Timer(TEN_SECONDS, new ActionListener() {
> public void actionPerformed(ActionEvent evt) {
> if (networkThread.isAlive) {
> timer.stop();
> networkThread.stop();
> //...Update the GUI...
> }
> }
>
> Anybody there who knows a proper way of killing such a blocked thread?
>
> Thanks in advance,
> Jan


Perhaps.....

ServerSocket.accept() can throw an IOException. Check to see if one of the
IOExceptions thrown is actually InterruptedIOException (a subclass of
IOException). It's likely that /that/ will be thrown when somewhere else
Thread.interrupt() is called on the thread running the
ServerSocket.accept(). Basically, call accept() while catching all
exceptions. Then externally call theThread.interrupt(), and see if the
accept() unblocks. Perhaps that'd work----it's been a while since I've used
it.

Sorry, I'd have tested this out for you before posting right now, but my
eclipse install just exploded, so I thought it'd help to think aloud.



 
Reply With Quote
 
Tony Morris
Guest
Posts: n/a
 
      02-18-2004
"Thomas G. Marshall" <(E-Mail Removed). com>
wrote in message news:u1CYb.32339$(E-Mail Removed)...
> Jan Liße <(E-Mail Removed)> coughed up the following:
>
> > Hi;
> > I have got a network-thread running in the background listening for
> > connection-attempts.
> > The thread uses an instance of Serversocket and its accept() method to
> > listen.
> > After a certain period of time i want to kill the thread if no
> > connection is established.
> > The problem is: the accept-method blocks until someone connects.
> > Therefore it is not possible for me to use the interrupted-flag and
> > check it within a loop in my
> > thread to signalize it to end (the recommended way to kill a thread).
> > I dont want to use the thread.stop
> > () method since it is deprecated, but even when i try to use it i can
> > not kill the thread.
> > Within my gui thread i tried to use a swing timer, but it doesnt kill
> > the thread:
> >
> > timer = new Timer(TEN_SECONDS, new ActionListener() {
> > public void actionPerformed(ActionEvent evt) {
> > if (networkThread.isAlive) {
> > timer.stop();
> > networkThread.stop();
> > //...Update the GUI...
> > }
> > }
> >
> > Anybody there who knows a proper way of killing such a blocked thread?
> >
> > Thanks in advance,
> > Jan

>
> Perhaps.....
>
> ServerSocket.accept() can throw an IOException. Check to see if one of

the
> IOExceptions thrown is actually InterruptedIOException (a subclass of
> IOException). It's likely that /that/ will be thrown when somewhere else
> Thread.interrupt() is called on the thread running the
> ServerSocket.accept(). Basically, call accept() while catching all
> exceptions. Then externally call theThread.interrupt(), and see if the
> accept() unblocks. Perhaps that'd work----it's been a while since I've

used
> it.
>
> Sorry, I'd have tested this out for you before posting right now, but my
> eclipse install just exploded, so I thought it'd help to think aloud.
>
>
>


InterruptedException is not a subclass of IOException, which blows your
whole theory.

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform


 
Reply With Quote
 
thoff
Guest
Posts: n/a
 
      02-18-2004
The way i've done it before is to:
1. set an is exit flag to true
2. check the exit flag after accept
3. have another thread make a connection so accept unblocks

Not sure if this is the most elegant java approach,
but it works.
 
Reply With Quote
 
Thomas Schodt
Guest
Posts: n/a
 
      02-18-2004
Tony Morris wrote:

> "Thomas G. Marshall" <(E-Mail Removed). com>
> wrote in message news:u1CYb.32339$(E-Mail Removed)...
>
>>
>>Perhaps.....
>>
>>ServerSocket.accept() can throw an IOException. Check to see if the
>>IOException thrown is actually InterruptedIOException (a subclass of
>>IOException). It's likely that /that/ will be thrown when somewhere else
>>Thread.interrupt() is called on the thread running the
>>ServerSocket.accept(). Basically, call accept() while catching all
>>exceptions. Then externally call theThread.interrupt(), and see if the
>>accept() unblocks. Perhaps that'd work----it's been a while since I've
>>used it.
>>
>>Sorry, I'd have tested this out for you before posting right now, but my
>>eclipse install just exploded, so I thought it'd help to think aloud.

>
> InterruptedException is not a subclass of IOException, which blows your
> whole theory.


I coded something like this recently, it took me a while to notice that
InterruptedException != InterruptedIOException

Anyhow, I found that Thread.interrupt() does not interrupt a socket
operation, so I had to use setSoTimeout() to interrupt the operation
periodically and then check Thread.currentThread().interrupted() to see
if another thread had called Thread.interrupt() on us.
 
Reply With Quote
 
Ryan Stewart
Guest
Posts: n/a
 
      02-18-2004
"Tony Morris" <(E-Mail Removed)> wrote in message
news:c0urnt$dha$(E-Mail Removed)...
> "Thomas G. Marshall"

<(E-Mail Removed). com>
> wrote in message news:u1CYb.32339$(E-Mail Removed)...
> > Jan Liße <(E-Mail Removed)> coughed up the following:
> >
> > > Hi;
> > > I have got a network-thread running in the background listening for
> > > connection-attempts.
> > > The thread uses an instance of Serversocket and its accept() method to
> > > listen.
> > > After a certain period of time i want to kill the thread if no
> > > connection is established.
> > > The problem is: the accept-method blocks until someone connects.
> > > Therefore it is not possible for me to use the interrupted-flag and
> > > check it within a loop in my
> > > thread to signalize it to end (the recommended way to kill a thread).
> > > I dont want to use the thread.stop
> > > () method since it is deprecated, but even when i try to use it i can
> > > not kill the thread.
> > > Within my gui thread i tried to use a swing timer, but it doesnt kill
> > > the thread:
> > >
> > > timer = new Timer(TEN_SECONDS, new ActionListener() {
> > > public void actionPerformed(ActionEvent evt) {
> > > if (networkThread.isAlive) {
> > > timer.stop();
> > > networkThread.stop();
> > > //...Update the GUI...
> > > }
> > > }
> > >
> > > Anybody there who knows a proper way of killing such a blocked thread?
> > >
> > > Thanks in advance,
> > > Jan

> >
> > Perhaps.....
> >
> > ServerSocket.accept() can throw an IOException. Check to see if one of

> the
> > IOExceptions thrown is actually InterruptedIOException (a subclass of
> > IOException). It's likely that /that/ will be thrown when somewhere

else
> > Thread.interrupt() is called on the thread running the
> > ServerSocket.accept(). Basically, call accept() while catching all
> > exceptions. Then externally call theThread.interrupt(), and see if the
> > accept() unblocks. Perhaps that'd work----it's been a while since I've

> used
> > it.
> >
> > Sorry, I'd have tested this out for you before posting right now, but my
> > eclipse install just exploded, so I thought it'd help to think aloud.
> >
> >
> >

>
> InterruptedException is not a subclass of IOException, which blows your
> whole theory.
>

Besides which, would Thread.interrupt() even work here? In the docs, it
seems to indicate that interrupt() will only work on I/O operations being
done by classes that implement java.nio.channels.InterruptibleChannel.


 
Reply With Quote
 
Thomas G. Marshall
Guest
Posts: n/a
 
      02-18-2004
Tony Morris <(E-Mail Removed)> coughed up the following:

> "Thomas G. Marshall"
> <(E-Mail Removed). com> wrote in
> message news:u1CYb.32339$(E-Mail Removed)...


....[thwack]...

>> Perhaps.....
>>
>> ServerSocket.accept() can throw an IOException. Check to see if one
>> of the IOExceptions thrown is actually InterruptedIOException (a
>> subclass of IOException). It's likely that /that/ will be thrown
>> when somewhere else Thread.interrupt() is called on the thread
>> running the ServerSocket.accept(). Basically, call accept() while
>> catching all exceptions. Then externally call
>> theThread.interrupt(), and see if the accept() unblocks. Perhaps
>> that'd work----it's been a while since I've used it.
>>
>> Sorry, I'd have tested this out for you before posting right now,
>> but my eclipse install just exploded, so I thought it'd help to
>> think aloud.
>>
>>
>>

>
> InterruptedException is not a subclass of IOException, which blows
> your whole theory.
>
> --
> Tony Morris


It turns out that the accept() is not interruptible from empirical evidence.

BUT regardless, you need to be more careful before you respond
contentiously. I *never* said anything about "InterruptedException". I
said "InterruptedIOException".

java.lang.Object
java.lang.Throwable
java.lang.Exception
java.io.IOException
java.io.InterruptedIOException



 
Reply With Quote
 
Thomas G. Marshall
Guest
Posts: n/a
 
      02-18-2004
Thomas Schodt" <"news04jan"@\"xenoc.demon.co.uk\
<"news04jan"@\"xenoc.demon.co.uk\"> coughed up the following:

> Tony Morris wrote:
>
>> "Thomas G. Marshall"
>> <(E-Mail Removed). com> wrote in
>> message news:u1CYb.32339$(E-Mail Removed)...
>>
>>>
>>> Perhaps.....
>>>
>>> ServerSocket.accept() can throw an IOException. Check to see if the
>>> IOException thrown is actually InterruptedIOException (a subclass of
>>> IOException). It's likely that /that/ will be thrown when
>>> somewhere else Thread.interrupt() is called on the thread running
>>> the ServerSocket.accept(). Basically, call accept() while catching
>>> all exceptions. Then externally call theThread.interrupt(), and
>>> see if the accept() unblocks. Perhaps that'd work----it's been a
>>> while since I've used it.
>>>
>>> Sorry, I'd have tested this out for you before posting right now,
>>> but my eclipse install just exploded, so I thought it'd help to
>>> think aloud.

>>
>> InterruptedException is not a subclass of IOException, which blows
>> your whole theory.

>
> I coded something like this recently, it took me a while to notice
> that InterruptedException != InterruptedIOException
>
> Anyhow, I found that Thread.interrupt() does not interrupt a socket
> operation, so I had to use setSoTimeout() to interrupt the operation
> periodically and then check Thread.currentThread().interrupted() to
> see
> if another thread had called Thread.interrupt() on us.


Yeah, and that seems like a shame.

Dusting off some of the gears in me noggin, I remember asking an interview
candidate something similar to this back in the ugly 1.0 days. I *thought*
that interrupts worked on it from 1.1 on though....to much dust I suppose







 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Site to open the blocked sites and blocked and encoded alagmy2030 Javascript 0 02-11-2011 11:54 PM
Thread#raise, Thread#kill, and timeout.rb are unsafe Charles Oliver Nutter Ruby 43 03-25-2008 02:31 PM
KILL BABY KILL widescreen drsd2kill DVD Video 3 11-29-2004 09:36 PM
Bava's KILL BABY KILL widescreen drsd2kill DVD Video 0 11-27-2004 12:04 AM
thread, threading; how to kill a thread? Jerry Sievers Python 12 11-19-2004 12:10 AM



Advertisments