Establishing a different *default* java.net.Socket read timeoutvalue...

[joe.no_junk]

Hi all.

I would like to figure out a way to get every socket created by any
code
in the JVM time out if a socket read is not responded to in X seconds.
I
made the cheap hack to java.net.Socket to internally call
self.setSoTimeout()
just before returning in every constructor, and that does the trick,
but
is there a non-bootclasspath-hacking way of doing it?
thanks,
Joe

 

[Lew]

Hi all.

I would like to figure out a way to get every socket created by any
code
in the JVM time out if a socket read is not responded to in X seconds.
I
made the cheap hack to java.net.Socket to internally call
self.setSoTimeout()
just before returning in every constructor, and that does the trick,
but
is there a non-bootclasspath-hacking way of doing it?
thanks,

DO NOT rewrite java.* or javax.* classes.

Just subclass or delegate the functionality.

 

[joe.no_junk]

DO NOT rewrite java.* or javax.* classes.

Just subclass or delegate the functionality.

No can do. The idea is that *any* socket that *any*
code running in the JVM (third-party JDBC drivers
for instance) operate sockets with a timeout. We
have no access to the code that is making most
of the sockets.

 

[Gordon Beaton]

No can do. The idea is that *any* socket that *any*
code running in the JVM (third-party JDBC drivers
for instance) operate sockets with a timeout. We
have no access to the code that is making most
of the sockets.

How can you be certain that they will handle the potentially
unexpected (and certainly undocumented) timeout properly?

I would never recommend actually doing what you are asking, but
perhaps Socket.setSocketImplFactory() is what you are looking for.

/gordon

--

 

[joe.no_junk]

How can you be certain that they will handle the potentially
unexpected (and certainly undocumented) timeout properly?

I would never recommend actually doing what you are asking, but
perhaps Socket.setSocketImplFactory() is what you are looking for.

/gordon

--

Drivers already have code to handle unexpected disconnects,
which manifest themselves in failed reads. The issue I'm trying
to deal with are people who test product failure capabilities
by pulling the network cable from the DBMS box. This causes socket
reads to hang for *ten minutes* until the local OS's TCPTIMEOUT
aborts the read. For drivers and other third-party code there is
no direct access to their sockets to either initialize them with
a timeout, or to free up the threads that hang. I did look into
setSocketImplFactory(), but I didn't find any public SocketImpl
to subclass. I can recommend the customer tweak their OS to have
a shorter TCP TIMEOUT values, but that affects every process. My
hack at least limited the change to the single JVM...
thanks,
Joe

 

[Gordon Beaton]

I did look into setSocketImplFactory(), but I didn't find any public
SocketImpl to subclass.

I think that's what java.net.SocketImpl is for.

http://java.sun.com/javase/6/docs/technotes/guides/net/extendingSocks.html

/gordon

--