 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2007Establishing a different *default* java.net.Socket read timeout value...
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 > Hi all. > [quoted text clipped - 8 lines] > is there a non-bootclasspath-hacking way of doing it? > thanks, DO NOT rewrite java.* or javax.* classes. Just subclass or delegate the functionality.  SignatureLew > joe.no_j...@gmail.com wrote: > > Hi all. [quoted text clipped - 16 lines] > -- > Lew 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. > 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 -- > > No can do. The idea is that *any* socket that *any* > > code running in the JVM (third-party JDBC drivers [quoted text clipped - 11 lines] > > -- 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 > 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 -- Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.