• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • p4-plugin
    • None
    • Windows 7 SP1 x64 master
      Windows 7 SP1 x64 slave
      connection over JNLP agent

      Project on slave builders with perforce SCM are hanging after several hours. Perforces workspaces configered as permanent with only one checkbox
      "Don't update client workspace".

      Main log:
      Sep 26, 2012 1:16:28 PM hudson.plugins.perforce.PerforceSCM getEffectiveClientName
      WARNING: Could not get hostname for slave <SlaveName>

      Polling log:
      Started on Sep 26, 2012 1:19:27 PM
      Looking for changes...
      Using node: Builder
      Using remote perforce client: <ws_name>
      terminate here

          [JENKINS-15315] Slave polling hungup

          Oleg Nenashev added a comment -

          InputStream.available() returns null by default. Several child classes like BufferedInputStream override this method.

          What about usage of Future wrapper? StackOverflow has several samples: http://stackoverflow.com/questions/804951/is-it-possible-to-read-from-a-inputstream-with-a-timeout

          P.S: I suppose that usage of newest P4Java versions could be the best solution for this issue (not for workaround), but it almost means rewriting from scratch.

          Oleg Nenashev added a comment - InputStream.available() returns null by default. Several child classes like BufferedInputStream override this method. What about usage of Future wrapper? StackOverflow has several samples: http://stackoverflow.com/questions/804951/is-it-possible-to-read-from-a-inputstream-with-a-timeout P.S: I suppose that usage of newest P4Java versions could be the best solution for this issue (not for workaround), but it almost means rewriting from scratch.

          Rob Petti added a comment -

          Look at the comments for the answer the suggests Futures. If we used this, we'd leak threads every time Perforce hangs until Jenkins is restarted, since there's absolutely no way to interrupt a read operation in Java apart from killing the JVM entirely... I don't think this is an option here.

          Rob Petti added a comment - Look at the comments for the answer the suggests Futures. If we used this, we'd leak threads every time Perforce hangs until Jenkins is restarted, since there's absolutely no way to interrupt a read operation in Java apart from killing the JVM entirely... I don't think this is an option here.

          Rob Petti added a comment -

          I rewrote the timeout functionality to spawn a thread that waits, then closes the underlying InputStream if no lines have been received for a while. This seems to work fine, at least on my system.

          Also, there's still no timeout on several of the perforce response methods being used by the plugin. Only one of them currently has a timeout.

          Rob Petti added a comment - I rewrote the timeout functionality to spawn a thread that waits, then closes the underlying InputStream if no lines have been received for a while. This seems to work fine, at least on my system. Also, there's still no timeout on several of the perforce response methods being used by the plugin. Only one of them currently has a timeout.

          James Howe added a comment -

          I'm still having problems.
          Slave polling p4 command hangs (on OSX slave), perforce plugin timeout feature isn't killing it.
          Eventually every fork on the slave failed with EAGAIN.
          dtruss shows nothing happening, netstat shows p4's sockets in SYN_SENT

          Jenkins 1.569, plugin 1.3.27, p4 2013.3
          Will update to 2014.1 and see if anything changes.

          James Howe added a comment - I'm still having problems. Slave polling p4 command hangs (on OSX slave), perforce plugin timeout feature isn't killing it. Eventually every fork on the slave failed with EAGAIN. dtruss shows nothing happening, netstat shows p4's sockets in SYN_SENT Jenkins 1.569, plugin 1.3.27, p4 2013.3 Will update to 2014.1 and see if anything changes.

          Oleg Nenashev added a comment - - edited

          The issue has not been solved yet, timeouts are not reliable.
          BTW, an update to the new client version may workaround the issue

          Oleg Nenashev added a comment - - edited The issue has not been solved yet, timeouts are not reliable. BTW, an update to the new client version may workaround the issue

          James Howe added a comment -

          >Will update to 2014.1 and see if anything changes.
          It didn't.

          James Howe added a comment - >Will update to 2014.1 and see if anything changes. It didn't.

          James Howe added a comment -

          Running the same commands manually that are hanging, with the same credentials, shows no issues.

          James Howe added a comment - Running the same commands manually that are hanging, with the same credentials, shows no issues.

          Brantone added a comment -

          In my case, after leaving it for a week on polling, netstat shows several thousand entires sitting in FIN_WAIT_2

          Brantone added a comment - In my case, after leaving it for a week on polling, netstat shows several thousand entires sitting in FIN_WAIT_2

          Alexey Larsky added a comment -

          Version 1.31 is most stable. 1.33 and 1,34 hungs on slaves periodically.

          Alexey Larsky added a comment - Version 1.31 is most stable. 1.33 and 1,34 hungs on slaves periodically.

          Oleg Nenashev added a comment -

          I do not longer work on the plugin. Unassigned

          Oleg Nenashev added a comment - I do not longer work on the plugin. Unassigned

            Unassigned Unassigned
            alexey_larsky Alexey Larsky
            Votes:
            2 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated: