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

java.io.EOFException continue occur when using health check with aws network load balancer

    Details

    • Similar Issues:

      Description

      Hi, we currently using AWS Network Load Balancer (http://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) for jenkins jnlp service port auto discovery.

      But we continues got this exceptions.

      Nov 20, 2017 10:55:50 AM FINE hudson.TcpSlaveAgentListener
      Accepted connection #41,949 from /10.240.0.4:24748
      Nov 20, 2017 10:55:50 AM WARNING hudson.TcpSlaveAgentListener$ConnectionHandler run
      Connection #41949 failed java.io.EOFException at java.io.DataInputStream.readFully(DataInputStream.java:197) at java.io.DataInputStream.readFully(DataInputStream.java:169) at hudson.TcpSlaveAgentListener$ConnectionHandler.run(TcpSlaveAgentListener.java:241)
      

      slaves although are still working normally.

        Attachments

          Activity

          Hide
          chrisvest chris vest added a comment -

          I am seeing the same issue as Aaron Trout

          Show
          chrisvest chris vest added a comment - I am seeing the same issue as Aaron Trout
          Hide
          aaron465 Aaron Trout added a comment -

          Sorry for posting three comments in a row, but to summarise; potentially not a jenkins bug. It doesn't break anything, just the log is super spammy in certain environments... Could raise the log level to work around that if it is a problem for you.

          Arguably though, the case where a TCP connection is established but no data is sent should be handled by the agent port listener so that we don't trigger this exception...

          Either way though, from jenkins point of view this is nothing to do with kubernetes or load balancers.

          Show
          aaron465 Aaron Trout added a comment - Sorry for posting three comments in a row, but to summarise; potentially not a jenkins bug. It doesn't break anything, just the log is super spammy in certain environments... Could raise the log level to work around that if it is a problem for you. Arguably though, the case where a TCP connection is established but no data is sent should be handled by the agent port listener so that we don't trigger this exception... Either way though, from jenkins point of view this is nothing to do with kubernetes or load balancers.
          Hide
          jthompson Jeff Thompson added a comment -

          Interesting. Thanks for the analysis, Aaron Trout. If we could figure out the appropriate behavior, we could do something about it. Maybe just lowering the level for that log message would be the right thing to do. I've done that for a number of messages lately that were overly aggressive when they were first implemented. I don't know if there are any situations in which that message might be useful, though. Perhaps, log it only if some specific condition is met. Maybe ignore the EOFException on the attempt to read the header but not if it comes later. I'm inclined to do that to clean up these spammy messages in these environments.

          Any thoughts?

          Show
          jthompson Jeff Thompson added a comment - Interesting. Thanks for the analysis, Aaron Trout . If we could figure out the appropriate behavior, we could do something about it. Maybe just lowering the level for that log message would be the right thing to do. I've done that for a number of messages lately that were overly aggressive when they were first implemented. I don't know if there are any situations in which that message might be useful, though. Perhaps, log it only if some specific condition is met. Maybe ignore the EOFException on the attempt to read the header but not if it comes later. I'm inclined to do that to clean up these spammy messages in these environments. Any thoughts?
          Hide
          jthompson Jeff Thompson added a comment -

          Looking at other reports, it's not clear that downgrading or ignoring this error is the correct thing to do in all environments. In some environments this message looks like it provides meaningful information.

          It sounds like Owen was correct initially, this is a duplicate of JENKINS-46893.

          Without further ideas I don't know what we could do here and sounds like there are some possibilities for addressing this in the system deployment configuration.

          Show
          jthompson Jeff Thompson added a comment - Looking at other reports, it's not clear that downgrading or ignoring this error is the correct thing to do in all environments. In some environments this message looks like it provides meaningful information. It sounds like Owen was correct initially, this is a duplicate of JENKINS-46893 . Without further ideas I don't know what we could do here and sounds like there are some possibilities for addressing this in the system deployment configuration.
          Hide
          jthompson Jeff Thompson added a comment -

          Closing this again as it appears to be Not a Defect, Duplicate, or Cannot Reproduce and no further information has been provided or explanation beyond the existing workarounds.

          Show
          jthompson Jeff Thompson added a comment - Closing this again as it appears to be Not a Defect, Duplicate, or Cannot Reproduce and no further information has been provided or explanation beyond the existing workarounds.

            People

            • Assignee:
              jthompson Jeff Thompson
              Reporter:
              protosschris Chris Lee
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: