Commons Net
  1. Commons Net
  2. NET-35

[net] FTPClient.setDataTimeout() should contain a default timeout

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.2
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Operating System: Windows 2000
      Platform: PC

      Description

      The method FTPClient.setDataTimeout() appears not to have a default value, or
      better said, it appears that the default value is 0, meaning that if a socket
      hangs (which will happen with an ftp connection eventually) you may block
      indefinately waiting on the connection.

      If we omit a call to setDataTimeout() it's almost certain that we will face a
      bug in our code later on, and unfortunately it's relatively unlikely that this
      bug will be caught in development. I think it would be far safer to have a
      default timeout value of say, pick a number, maybe 60 seconds? Those that need
      this changes should specically call it to make the change. If you do want it to
      block indefinately (I doubt almost anyone actually wants this) then they should
      explicitly set this to 0, but I think 99.9% of your users will actually want a
      resonable timeout, thus it would be best to set this 'resonable' timeout value
      as the default to safeguard those that miss adding it to their code.

      Thanks,
      David Parks

        Activity

        Hide
        Daniel Savarese added a comment -

        As you observed, there already is a default timeout.
        By default, network I/O blocks within the default
        parameters of the underlying OS. The individual
        programmer using the library knows best what timeout
        is suitable for his/her application and should set it
        as appropriate. You are the first to request a
        different approach. Until there is evidence that a
        majority of users prefer a different approach, I'm
        marking this request as won't fix.

        I understand your desire, but I disagree with your reasoning.
        A default timeout other than the OS default that
        you feel is appropriate will not be appropriate for
        someone else. Therefore the need to set the timeout
        explicitly will not be minimized, and I'd argue it
        would increase because common practice is to rely
        on the OS default in the face of unreliable networks
        (e.g., you don't want a 2 GB file transfer to die just
        because there is a 10 minute loss of connectivity; and
        if you do, you can reset the timeout based on your needs).
        Regardless, if you want a different default, you can
        subclass FTPClient and set the timeout in the
        constructor.

        Show
        Daniel Savarese added a comment - As you observed, there already is a default timeout. By default, network I/O blocks within the default parameters of the underlying OS. The individual programmer using the library knows best what timeout is suitable for his/her application and should set it as appropriate. You are the first to request a different approach. Until there is evidence that a majority of users prefer a different approach, I'm marking this request as won't fix. I understand your desire, but I disagree with your reasoning. A default timeout other than the OS default that you feel is appropriate will not be appropriate for someone else. Therefore the need to set the timeout explicitly will not be minimized, and I'd argue it would increase because common practice is to rely on the OS default in the face of unreliable networks (e.g., you don't want a 2 GB file transfer to die just because there is a 10 minute loss of connectivity; and if you do, you can reset the timeout based on your needs). Regardless, if you want a different default, you can subclass FTPClient and set the timeout in the constructor.
        Hide
        Paul Stanton added a comment -

        this has just caused me a MAJOR headache. it's blocked a thread for over a week and effectively halted my serialisation procedure. the documentation does not make it obvious that NOT setting a timeout could eventuate in such a problem. I actually do set this timeout directly after I call the 'connect' method (along with setSoTimeout) however it's the connect method which is blocking.

        please re-open and resolve, default it to 5 days if necessary!!

        Show
        Paul Stanton added a comment - this has just caused me a MAJOR headache. it's blocked a thread for over a week and effectively halted my serialisation procedure. the documentation does not make it obvious that NOT setting a timeout could eventuate in such a problem. I actually do set this timeout directly after I call the 'connect' method (along with setSoTimeout) however it's the connect method which is blocking. please re-open and resolve, default it to 5 days if necessary!!
        Hide
        Paul Stanton added a comment -

        if this problem has occurred (which it has) would interrupting the thread have any effect? ie, is this "an I/O operation upon an interruptible channel"?

        http://java.sun.com/javase/6/docs/api/java/lang/Thread.html#interrupt%28%29
        "If this thread is blocked in an I/O operation upon an interruptible channel then the channel will be closed, the thread's interrupt status will be set, and the thread will receive a ClosedByInterruptException. "

        Show
        Paul Stanton added a comment - if this problem has occurred (which it has) would interrupting the thread have any effect? ie, is this "an I/O operation upon an interruptible channel"? http://java.sun.com/javase/6/docs/api/java/lang/Thread.html#interrupt%28%29 "If this thread is blocked in an I/O operation upon an interruptible channel then the channel will be closed, the thread's interrupt status will be set, and the thread will receive a ClosedByInterruptException. "

          People

          • Assignee:
            Unassigned
            Reporter:
            David Parks
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development