The exception indicates that the HTTP client has shut down the connection without fully reading the response, which is actually quite normal.

In Jenkins, the code is written such that we simply swallow this exception, but if you are seeing it in console, it must be that someone is catching it and dumping it. I suspect the monitoring plugin is causing this.

I have been tormented by similar exceptions (usually java.net.SocketException: Connection reset, but sometimes also java.io.IOException: Broken pipe from Jetty in 1.457 IIRC), which pollute the log file with junk.

org.kohsuke.stapler.compression.CompressionFilter.reportException is what actually sends the log record. Not sure what “code is written such that we simply swallow this exception”.

Unfortunately I have not yet managed to reproduce the problem in a controlled environment. Have tried installing a plugin with

@Extension
public class XXX extends PageDecorator {
    public void sleep() throws InterruptedException, IOException {
        Stapler.getCurrentResponse().flushBuffer();
        Thread.sleep(5000);
    }
}

and a matching footer.jelly

<?xml version="1.0" encoding="UTF-8"?>
<?jelly escape-by-default='true'?>
<j:jelly xmlns:j="jelly:core" xmlns:st="jelly:stapler" xmlns:d="jelly:define" xmlns:i="jelly:fmt">
    <hr/>
    Sleeping…
    ${it.sleep()}
    done.
</j:jelly>

which makes a page take a long time to load, but halting it halfway prints nothing to the Jenkins console. Installing the Monitoring plugin changes nothing. Tried Jenkins trunk, 1.480.3, 1.466.2. Tried Stop button in Chrome, as well as running curl and interrupting the process before the page finishes loading.

So if I can ever figure out how to reproduce this, I will try to patch reportException to check for exceptions (incl. nested causes) that seem to indicate a broken socket, and if so not send them to LOGGER (or use FINE rather than WARNING).

Also java.net.SocketException: Broken pipe from Tomcat.

I've been trying to find a pattern as well for reproducing this (and JENKINS-14825) but have had no luck. The randomness is making it a really stickler.

I'll keep trying and hopefully we can come up with something. Thanks for looking into it Jesse!

@Kohsuke I also suspected the monitoring plugin, so I uninstalled it entirely and removed JENKINS_HOME/monitoring. Still no luck.

The odd thing about this is that it seems to result in HTTP 404 errors on the front end, sometimes for an entire page and other times just for certain ajax calls. I'd expect a 500ish error.

@hardwickj: this and the duplicate issue seem to be mixing up several things.

One is the issue reported in the summary, which is that a broken client connection results in a noisy stack trace in the Jenkins log file, which it should not, since this is a normal condition for an HTTP-based server application.

You report some 404s, which are probably some unrelated bug whose cause I cannot speculate on.

And others in JENKINS-14825 report extremely long delays in page loads under some circumstances. Such delays probably trigger this bug, but are caused by something unrelated—which may well be different in each case. Only a thread dump can diagnose why a page load is hanging.

Same here on Windows xp X86 SP2 with java version "1.7.0_11", Jenkins ver: 1.488 ,build-pipeline: 1.3.4-snapshot,run by java -jar jenkins.war

@Jesse: we discovered this was being caused when we accessed our Jenkins instance through a proxy. After some digging we stumbled across https://wiki.jenkins-ci.org/display/JENKINS/Running+Jenkins+behind+Apache which mentions setting the proxy-nokeepalive value in our apache config. After setting that value, all our issues went away. The 404's and stack trace in the jenkins log were related, albeit loosely. When the proxied connection broke down, apache would return a 404, and Jenkins would spit out the ClientSocketException.

We discovered this when one of our developers mentioned he always accessed Jenkins directly rather than through our proxy and he had never had issues. With a little wget magic we saw he was absolutely right, which set us on the right path.

Here's hoping this helps everyone else out...

@hardwickj: very interesting, thanks for noting this. Might help reproduce the stack trace, and is a good tip for people encountering odd errors. (I am wondering whether some incidences of JENKINS-16474 are related.)

Bizarre that Apache would produce the totally inappropriate 404 status code for this situation though; I would have expected a 504 here! If you can reproduce that, consider filing a bug for Apache.

I've worked around this by adding Keepalive=On to the ProxyPass line in my VHost configuration.
The above hasn't worked. Still seeing this issue.

It seems to happen more often in chrome where I've disabled the browser's cache than firefox where I haven't...

There seem to be a LOT of javascript files loaded on each page refresh, so this may have something to do with it?

Still no luck reproducing this with an Apache reverse proxy. Maybe browser-specific?

have the issue and we do not use a reverse proxy.

If it were a matter of too many javascript files being loaded than a lot more users would be having this problem.

If you guys are running Jenkins behind an apache proxy, try just hitting jenkins directly for a day and see what your results are. This might require typing a longer URL and appending :8080 at the end, but definitely worth it for debugging reasons.

All our problems went away once we figured out our apache proxying issue. We initially discovered the discrepancy by running the following curl command against jenkins, first through the apache proxy, and second against jenkins directly:

 
#!/bin/bash

for i in {1..100}
do
  # via proxy
  wget --quiet --spider http://build/api/json?pretty=true
  if [ $? -ne 0 ]; then
    echo "wget failed via proxy"
  fi
done

for i in {1..100}
do
  # bypassing the proxy
  wget --quiet --spider http://jenkins:8080/api/json?pretty=true
  if [ $? -ne 0 ]; then
    echo "wget failed directly"
  fi
done

If you run that and you only see "wget failed via proxy" but nothing directly, then it's your proxy configuration.

My point being, if you use a proxy at all and are having issues, give that a try first.

Same here on 2k8r2 x64 sp1 @ jdk 1.7 @ v1.514.

Same problem here. Using v1.516 with Windows Server 2008 R2, JDK 1.7 Update 21 64Bit.

We use a master and 10 slaves. All connected without any proxy.

If i request any of the master jenkins urls via VPN this exception occurs more often.

Experiencing this issue, while we are using a proxy we did not run into this until we configured matrix based security with the bitbucket oAuth plugin. With matrix based security in use, the error presented itself after logging out then back in. Once we switched aware from matrix based security the error went away.

Jenkins 1.521 included https://github.com/stapler/stapler/commit/ac0b5683c4a3a45c3b987baf264674934470b668 which installs a new pretty exception handler that may affect the symptoms of this bug somehow.

https://github.com/stapler/stapler/commit/a6307f473e44aa4fd6a26275304d738dba5201c9 (once integrated into Jenkins core) might work.

7e8bbea3336dc65a10c2fd69a20beac20bc6fca3 in 1.528 should have integrated the purported fix.

Code changed in jenkins
User: Jesse Glick
Path:
core/pom.xml
http://jenkins-ci.org/commit/jenkins/fdbcfda5acd430a8f8bfb90d7def4351f7bfce57
Log:
[FIXED JENKINS-10524][FIXED JENKINS-19168] Stapler 1.218.

(cherry picked from commit d814a6ff7f2e99c9ada722d17c33ca87b0bbea65)

Conflicts:
changelog.html
core/pom.xml