Non-blocking sockets

[bengali]

Hi,

i have a client application that connects to remote servers via tcp.
Connections are made in threads and i would like them to be
interruptible, i mean that client socket should not block and if they
receive an interrupt signal they should quit.
I have seen that java nio allows to create such non-blocking sockets.

SocketChannel sChannel = SocketChannel.open();
sChannel.configureBlocking(false);
Socket mySocket = sChannel.socket();


My problem is that sockets are created from third-party libraries (JNDI
and JMX) and i don't even manipulate sockets.

But the Socket class has a setSocketImplFactory(SocketImplFactory
factory) method which I could call at the beginning of my application
to set it a SocketImplFactory that would in turn return non-blocking
SocketImpl.

I have searched the Web and I haven't found anyone doing such things.
The SocketImpl class has a lot of abstract methods and i am reluctant
to extend it (lack of time).
Does anyone know if a non-blocking SocketImplFactory exists ?

Thanks,
Luc

 

[Robert Klemme]

Hi,

i have a client application that connects to remote servers via tcp.
Connections are made in threads and i would like them to be
interruptible, i mean that client socket should not block and if they
receive an interrupt signal they should quit.
I have seen that java nio allows to create such non-blocking sockets.

Are you sure you actually need nio? AFAIK classes in java.io honor
Thread.interrupt() and you get an InterruptedIOException which is a
subclass of IOException.

Kind regards

robert

 

[bengali]

For me, a thread that waits on a blocking IO can not be interrupted
because a thread can only be interrupted if it's in wait or sleep state.
That's why nio has been added to the JDK.

There's the InterruptibleChannel class which SocketChannel implements:
"A channel that implements this interface is also interruptible: If a
thread is blocked in an I/O operation on an interruptible channel then
another thread may invoke the blocked thread's interrupt method. This
will cause the channel to be closed, the blocked thread to receive a
ClosedByInterruptException, and the blocked thread's interrupt status to
be set."

But this doesn't solve my problem...

Luc

 

[Karl Uppiano]

For me, a thread that waits on a blocking IO can not be interrupted
because a thread can only be interrupted if it's in wait or sleep state.
That's why nio has been added to the JDK.

There's the InterruptibleChannel class which SocketChannel implements:
"A channel that implements this interface is also interruptible: If a
thread is blocked in an I/O operation on an interruptible channel then
another thread may invoke the blocked thread's interrupt method. This will
cause the channel to be closed, the blocked thread to receive a
ClosedByInterruptException, and the blocked thread's interrupt status to
be set."

But this doesn't solve my problem...

Luc

In my experience, a thread blocking in a classic Java socket will not
interrupt. Calling wakeup on a waiting NIO socket will bring a waiting
thread back to you.

 

[Christopher Benson-Manica]

Are you sure you actually need nio? AFAIK classes in java.io honor
Thread.interrupt() and you get an InterruptedIOException which is a
subclass of IOException.

I don't believe that's correct. java.io classes do not reliably honor
Thread.interrupt(), although the situation can be worked around by
closing the associated stream, causing an exception to be thrown. If
nio isn't an option for OP, that might be the poor man's workaround.

 

[EJP]

Hi,

i have a client application that connects to remote servers via tcp.
Connections are made in threads and i would like them to be
interruptible, i mean that client socket should not block and if they
receive an interrupt signal they should quit.
I have seen that java nio allows to create such non-blocking sockets.

Maybe what you really want is just a read timeout?

 

[bengali]

Maybe what you really want is just a read timeout?

It would be a good idea but as I said i don't have access to the code
that creates the client sockets (in third-party libraries) and don't
even manipulate Socket objects.

That's why I thought of changing Socket's class default
SocketImplFactory to a SocketImplFactory that would create NIO
SocketImpl at the beginning of my client application.

That's why I was asking if anyone had done such thing or if there would
be was a different way to do this (JVM parameter).

The target JVM is a 1.4.2.

Thanks,
bengali (a.k.a Luc)

 

[Thomas Hawtin]

I don't believe that's correct. java.io classes do not reliably honor
Thread.interrupt(), although the situation can be worked around by
closing the associated stream, causing an exception to be thrown. If
nio isn't an option for OP, that might be the poor man's workaround.

I thought interruptible I/O had been fixed for some time. So I checked
the bug database:

"As of today, the interruptable io has officially deprecated. We are not
going to fix this bug. However, we leave the current implementation as
it is for backward compatibility.

" xxxxx@xxxxx 1999-09-12"

-- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4103109

I haven't seen that anywhere else.

Tom Hawtin

 

[Mark Thornton]

I don't believe that's correct. java.io classes do not reliably honor
Thread.interrupt(), although the situation can be worked around by
closing the associated stream, causing an exception to be thrown. If
nio isn't an option for OP, that might be the poor man's workaround.

I think closing the associated stream only works on some operating systems.

 

[Chris Uppal]

I thought interruptible I/O had been fixed for some time. So I checked
the bug database:

"As of today, the interruptable io has officially deprecated. We are not
going to fix this bug. However, we leave the current implementation as
it is for backward compatibility.

" xxxxx@xxxxx 1999-09-12"

-- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4103109

I haven't seen that anywhere else.

The writeup of 4154947 (referenced from that bug) at:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4154947

also makes interesting (if sad, and salutary) reading.

-- chris