Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-44785

Add Built-in Request timeout support in Remoting

XMLWordPrintable

      Filing at oleg_nenashev's request.

      VirtualChannel.call has no timeout parameter, so it is assumed to block the calling thread until the call completes, fails, or the thread is interrupted externally. In practice the programmer often knows that it is unreasonable for a given call to take more than a certain amount of time, and would prefer to pass a timeout, akin to Future.get(long timeout, TimeUnit unit) throwing TimeoutException.

      Similarly, various calls in Jenkins core which are implemented using Remoting ought to have overloads which take a timeout, or even (arguably) ought to default to using a fixed timeout. For example, FilePath.isDirectory has been observed to hang indefinitely when an agent connection is broken. It is almost never desirable to just wait until it completes; if the agent cannot respond in a reasonable amount of time (a few minutes at most), it would be better to just fail.

          [JENKINS-44785] Add Built-in Request timeout support in Remoting

          Jesse Glick created issue -
          Jesse Glick made changes -
          Link New: This issue relates to JENKINS-32986 [ JENKINS-32986 ]

          Jesse Glick added a comment -

          A Timeout utility class was introduced into Pipeline to solve some issues associated with JENKINS-32986. Used in the context of Remoting (specifically isDirectory) in JENKINS-37719.

          Jesse Glick added a comment - A Timeout utility class was introduced into Pipeline to solve some issues associated with  JENKINS-32986 . Used in the context of Remoting (specifically isDirectory ) in  JENKINS-37719 .
          Jesse Glick made changes -
          Link New: This issue relates to JENKINS-37719 [ JENKINS-37719 ]
          Jesse Glick made changes -
          Link New: This issue relates to JENKINS-44784 [ JENKINS-44784 ]
          Oleg Nenashev made changes -
          Epic Link New: JENKINS-38833 [ 175240 ]
          Jesse Glick made changes -
          Link New: This issue relates to JENKINS-40613 [ JENKINS-40613 ]

          Jesse Glick added a comment -

          Some diagnostic improvements to Request.call, which already sets the Thread.name to the Channel.name:

          • make sure that Channel.name is easily aligned with a SlaveComputer.nodeName; currently it seems that we get things like JNLP4-connect connection from some.host.name/1.2.3.4:12345 which bears no obvious relationship to agent names used elsewhere in thread dumps etc.
          • while it waits in 30s increments, it does not indicate in the Thread.name how long it has been waiting so far, so it is hard to tell if a given thread dump excerpt is just a normal delay of a couple seconds on a busy machine, or something gone haywire which has been hanging for hours

          Jesse Glick added a comment - Some diagnostic improvements to Request.call , which already sets the Thread.name to the Channel.name : make sure that Channel.name is easily aligned with a SlaveComputer.nodeName ; currently it seems that we get things like JNLP4-connect connection from some.host.name/1.2.3.4:12345 which bears no obvious relationship to agent names used elsewhere in thread dumps etc. while it waits in 30s increments, it does not indicate in the Thread.name how long it has been waiting so far, so it is hard to tell if a given thread dump excerpt is just a normal delay of a couple seconds on a busy machine, or something gone haywire which has been hanging for hours
          Oleg Nenashev made changes -
          Assignee New: Oleg Nenashev [ oleg_nenashev ]
          Oleg Nenashev made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            4 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: