title: Wildfly: org.xnio.channels.FixedLengthOverflowException
body: <p>Until now we used JBoss AS 7.1 which has a tomcat as front-server. We now upgraded to Wildfly (JBoss 8.0) which ships with undertow as a tomcat replacement.</p>
  
  <p>For our filedownloads, we are reading the input stream of the file, and writing this to the external context's response output stream. This worked well in JBoss AS 7.1 - even for large files. In Undertow WE receive the following exception even for pretty "small" files:</p>
  
  <pre><code>13:04:43,292 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /project/getFile.xhtml}: java.lang.RuntimeException: org.xnio.channels.FixedLengthOverflowException
      at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527)
      at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:287)
      at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
      at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
      at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
      at io.undertow.server.Connectors.executeRootHandler(Connectors.java:168)
      at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
      at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
  Caused by: org.xnio.channels.FixedLengthOverflowException
      at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:97)
      at org.xnio.conduits.Conduits.writeFinalBasic(Conduits.java:132) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
      at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.writeFinal(AbstractFixedLengthStreamSinkConduit.java:137)
      at org.xnio.conduits.ConduitStreamSinkChannel.writeFinal(ConduitStreamSinkChannel.java:104) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
      at io.undertow.channels.DetachableStreamSinkChannel.writeFinal(DetachableStreamSinkChannel.java:172)
      at io.undertow.servlet.spec.ServletOutputStreamImpl.writeBufferBlocking(ServletOutputStreamImpl.java:580)
      at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:614)
      at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
      at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
      ... 9 more
  </code></pre>
  
  <p>The <code>getFile.xhtml</code> is invoking the download and the following code is used to copy the stream:</p>
  
  <p>(Try, catch, logs and error handling removed to save some space)</p>
  
  <pre><code>public void downloadFile(FileEntity fileEntity) {
          FacesContext fc = FacesContext.getCurrentInstance();
          ExternalContext ec = fc.getExternalContext();
  
          ec.responseReset();
          ec.setResponseContentType(getMimeType(fileEntity.getFile()));
          ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue());
          ec.setResponseHeader("Content-Disposition", "attachment; filename=\"" + ConversionHelper.validateFilename(fileEntity.getDisplayFileName()) + "\"");
  
          OutputStream output = ec.getResponseOutputStream();
          FileInputStream fis = new FileInputStream(fileEntity.getFile());
  
          IOUtils.copy(fis, output);
  
          fc.responseComplete();
      }
  </code></pre>
  
  <p>I noticed that removing the line</p>
  
  <pre><code>ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue());
  </code></pre>
  
  <p>makes it work again. However the ResponseConentLength is "correct". Using</p>
  
  <pre><code>ec.setResponseContentLength(new Long(fileEntity.getFile().length()).intValue() + 9);
  </code></pre>
  
  <p>(note the <code>+9</code>) solves this. Using <code>+8</code> -> <code>FixedLengthOverflow</code>, using <code>+10</code> -> <code>FixedLengthUnderflow</code></p>
  
  <p>The <code>+9</code> is independent of the filesize. Any idea? Looks strange to me...</p>