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

Discussion in 'Java' started by joe.no_junk@gmail.com, Dec 11, 2007.

  1. Guest

    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
    , Dec 11, 2007
    #1
    1. Advertising

  2. Lew Guest

    wrote:
    > 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.

    --
    Lew
    Lew, Dec 12, 2007
    #2
    1. Advertising

  3. Guest

    On Dec 11, 6:33 pm, Lew <> wrote:
    > wrote:
    > > 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.
    >
    > --
    > 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.
    , Dec 12, 2007
    #3
  4. Re: Establishing a different *default* java.net.Socket read timeout value...

    On Tue, 11 Dec 2007 20:56:15 -0800 (PST), wrote:
    > 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

    --
    Gordon Beaton, Dec 12, 2007
    #4
  5. Guest

    On Dec 11, 10:56 pm, Gordon Beaton <> wrote:
    > On Tue, 11 Dec 2007 20:56:15 -0800 (PST), wrote:
    > > 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
    >
    > --


    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
    , Dec 12, 2007
    #5
  6. Gordon Beaton, Dec 12, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Baran

    TOMCAT PROBLEM: Establishing a session

    Michael Baran, Jan 22, 2004, in forum: Java
    Replies:
    6
    Views:
    547
    John C. Bollinger
    Jan 27, 2004
  2. Chad W. Taylor
    Replies:
    1
    Views:
    2,970
    iksrazal
    Jun 26, 2004
  3. prabhu
    Replies:
    5
    Views:
    574
    Roedy Green
    Mar 25, 2006
  4. Mangabasi
    Replies:
    0
    Views:
    354
    Mangabasi
    Apr 23, 2007
  5. Joe Van Dyk
    Replies:
    3
    Views:
    135
    Adam P. Jenkins
    Jul 6, 2005
Loading...

Share This Page