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

[Jan Liße]

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

 

[Ryan Stewart]

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.

 

[John C. Bollinger]

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
(e-mail address removed)

 

[Thomas G. Marshall]

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.

 

[Tony Morris]

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

 

[thoff]

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.

 

[Thomas Schodt]

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.

 

[Ryan Stewart]

"Thomas G. Marshall"

wrote in message news:[email protected]...

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.

 

[Thomas G. Marshall]

"Thomas G. Marshall"
message
....[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.

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

 

[Thomas G. Marshall]

Thomas Schodt" <"news04jan"@\"xenoc.demon.co.uk\

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

 

[Thomas G. Marshall]

Thomas Schodt" <"news04jan"@\"xenoc.demon.co.uk\
<"news04jan"@\"xenoc.demon.co.uk\"> coughed up the following:

....[rip]...

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.

Apparently there *might* be a resolution to this. Perhaps this is what I
remember.

In any case read this:
http://developer.java.sun.com/developer/bugParade/bugs/4107086.html

If you haven't registered, then the contents are here:
----------------[paste]----------------

Bug Id 4107086

Votes 1

Synopsis Thread.interrupt doesn't work on ServerSocket.accept

Category java:classes_net

Reported Against 1.2beta3

Release Fixed 1.2fcs

State Closed, fixed

Related Bugs

Submit Date Jan 27, 1998

Description: With Solaris green threads, Thread.interrupt on a thread that's
waiting in
ServerSocket.accept has no effect. With native threads, the wrong exception
is
thrown: a plain SocketException instead of InterruptedIOException.


With Solaris green threads, Thread.interrupt on a thread that's waiting in
ServerSocket.accept has no effect. With native threads, the wrong exception
is
thrown: a plain SocketException instead of InterruptedIOException. See the
attached test program.



Workaround None.

Evaluation: This was fixed with the thread interrupt changes that went in
for other bugs,
such as 4152799, 4159884, 4160579.
xxxxx@xxxxx 1998-10-22


Your Comments & Work-arounds

Include a link with my name & email

THU AUG 19 03:59 P.M. 1999
mgriffin2

This still seems to be a problem with
JDK-1.2.2-W, native threads, nojit

 

[Tony Morris]

"Thomas G. Marshall"
message
...[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.

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

There was never any contention intended.
My apologies for the oversight.

--
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

 

[Thomas G. Marshall]

"Thomas G. Marshall"

"Thomas G. Marshall"
message
...[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.

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

There was never any contention intended.
My apologies for the oversight.

--
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

Nice bike. Is the 2003 red? I have a white 1993 VFR-750F. A distant
cousin twice removed to the vtr.

When deciding which bike to buy in '93, it was between that and a zx-11, the
/then/ bad boy. I bought the VFR for its technology. A single-sided swing
arm that neatly comes down and grabs the wheel from one side. A 90 degree
V4. Gear driven cams that sound spectacular.

 

[Tony Morris]

Nice bike. Is the 2003 red? I have a white 1993 VFR-750F. A distant

cousin twice removed to the vtr.

When deciding which bike to buy in '93, it was between that and a zx-11, the
/then/ bad boy. I bought the VFR for its technology. A single-sided swing
arm that neatly comes down and grabs the wheel from one side. A 90 degree
V4. Gear driven cams that sound spectacular.

Yep, it's red.
http://www.xdweb.net/~dibblego/vtr1000/

My girlfriend loves the look of the VFR800, however, she doesn't hold a
licence or the ability to ride a machine of that calibre (1.5 hours riding
experience) - perhaps another day in the future, we will own one.

--
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

 

[Thomas G. Marshall]

Yep, it's red.
http://www.xdweb.net/~dibblego/vtr1000/

My girlfriend loves the look of the VFR800, however, she doesn't hold
a licence or the ability to ride a machine of that calibre (1.5 hours
riding experience) - perhaps another day in the future, we will own
one.

I've never been a believer in the big-bikes-need-experience thing. /Any/
bike will put you in the ground. A larger bike has a distinct advantage:
You are less likely to get that rut-rut-rut engine complaint by not suppling
enough gas in the wrong gear. But you're right in one respect: I was able
to semi-smoothly go from a standstill to riding speed entirely in 5th gear
on the zx-11, without feathering the crap out of the clutch. (!) It's one
of my tests. I can't imagine what would happen if my hand twitched in
5th...

Sorry guys for the OT. I'll stop.

 

[Tony Morris]

I've never been a believer in the big-bikes-need-experience thing. /Any/
bike will put you in the ground. A larger bike has a distinct advantage:
You are less likely to get that rut-rut-rut engine complaint by not suppling
enough gas in the wrong gear. But you're right in one respect: I was able
to semi-smoothly go from a standstill to riding speed entirely in 5th gear
on the zx-11, without feathering the crap out of the clutch. (!) It's one
of my tests. I can't imagine what would happen if my hand twitched in
5th...

Sorry guys for the OT. I'll stop.

I feel the same way - but the thought of my girlfriend on a 200kg+ bike
tends to put me off a bit.
I grew up on dirt bikes, and I reckon it's the best way to learn, though I
try to be open-minded about alternatives.
In contrast, the thought of my girlfriend getting on a YZ125 brings less
confidence than a VFR800 - too many times, I've seen a learner drop the
clutch at high engine speed only to land on their butt !

It's going to be a slow process, but if she wants a VFR800, I want to be
confident that she's capable, and right now, I'm not.

--
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