wildfly 8.1 occasional servlet errors

[petercr4]

We have an JSF application with pages containing lots of images served with servlet. Servlet checks if user is logged in by injecting a session scoped bean. It works a few days, after that random images from page are not loaded, user has to do a manual refresh in the browser. In the console we get undertow errors like:

org.xnio.channels.FixedLengthUnderflowException: 961551 bytes remaining

2014-06-28 20:59:53,718 ERROR [stderr] (default task-27)        at io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.terminateWrites(AbstractFixedLengthStreamSinkConduit.java:228)

2014-06-28 20:59:53,719 ERROR [stderr] (default task-27)        at org.xnio.conduits.ConduitStreamSinkChannel.shutdownWrites(ConduitStreamSinkChannel.java:178)

2014-06-28 20:59:53,719 ERROR [stderr] (default task-27)        at io.undertow.channels.DetachableStreamSinkChannel.shutdownWrites(DetachableStreamSinkChannel.java:60)

2014-06-28 20:59:53,719 ERROR [stderr] (default task-27)        at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:624)

2014-06-28 20:59:53,719 ERROR [stderr] (default task-27)        at java.io.FilterOutputStream.close(FilterOutputStream.java:160)

and removed EJBs:

2014-06-28 22:22:40,666 SEVERE [si.efos.trapview.action.general.FullAjaxExceptionHandler] (default task-22) FullAjaxExceptionHandler: An exception occurred during processing JSF ajax request. Error

page '/error.jsf' will be shown.: javax.ejb.NoSuchEJBException: JBAS016055: EJB has been removed

        at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.getBusinessObject(StatefulSessionObjectReferenceImpl.java:123) [wildfly-weld-8.1.0.Final.jar:8.1.0.Final]

        at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:97) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]

        at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]

        at org.jboss.weld.bean.proxy.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:65) [weld-core-impl-2.1.2.Final.jar:2014

-01-09 09:23]

        at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]

        at si.efos.trapview.action.sm.SmCurrentSession$Proxy$_$$_Weld$EnterpriseProxy$.getCurrentIdUser(Unknown Source) [classes:]

        at si.efos.trapview.action.sm.SmCurrentSession$Proxy$_$$_WeldClientProxy.getCurrentIdUser(Unknown Source) [classes:]

        at si.efos.trapview.action.security.AuthorizationListener.afterPhase(AuthorizationListener.java:66) [classes:]

        at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:189) [jsf-impl-2.1.28.jar:2.1.28]

        at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:107) [jsf-impl-2.1.28.jar:2.1.28]

        at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) [jsf-impl-2.1.28.jar:2.1.28]

        at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.28.jar:2.1.28]

        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jsf-api-2.1.28.jar:2.1]

        at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:229) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:172) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:402) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:319) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:263) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]

        at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55]

Any idea where the problem would be?

[swd847]

The first one happens when you set a content-length header, and the close the response before you have written as much content as you said you were going to.

Not sure about the second one.

[petercr4]

Thanks for reply Stuart, well this is pretty much old servlet code, nothing special here.

File image = new File(imagePath, URLDecoder.decode(requestedImage, "UTF-8"));

	// Get content type by filename.
	String contentType = getServletContext().getMimeType(image.getName());

	// Init servlet response.
	response.reset();
	response.setBufferSize(DEFAULT_BUFFER_SIZE);
	response.setContentType(contentType);
	response.setHeader("Content-Length", String.valueOf(image.length()));
	response.setHeader("Content-Disposition", "inline; filename=\"" + image.getName() + "\"");

	// Prepare streams.
	BufferedInputStream input = null;
	BufferedOutputStream output = null;

	try {
	// Open streams.
	input = new BufferedInputStream(new FileInputStream(image), DEFAULT_BUFFER_SIZE);
	output = new BufferedOutputStream(response.getOutputStream(), DEFAULT_BUFFER_SIZE);

	// Write file contents to response.
	byte[] buffer = new byte[DEFAULT_BUFFER_SIZE];
	int length;
	while ((length = input.read(buffer)) > 0) {
	output.write(buffer, 0, length);
	}
	output.flush();
	} finally { // close streams
	close(output);
	close(input);
	}

Like said it works for a while, then it begins to throw errors

[swd847]

Hmm, its possible the client is disconnecting, and as a result this exception gets thrown when undertow tries to close the connection. I will need to investigate.

[ctomc]

Does it make any difference if you use proper api for setting content length?

instead of using response.setHeader(), can you try with response.setContentLength(image.length());

[petercr4]

Thanks Tomaz,

I tried to set that but it doesn't make difference.Still getting lots of errors on servlet close, at times refresh needs to be done manually, but the issue it's hard to reproduce. I'll see if I can get something more concrete.

[javacoryd]

I know a lot of time has past, but was there ever a resolution to this issue?  We get this exception periodically when loading css and javascript files with IE.  Here is an example:

18:20:23,550 ERROR [io.undertow.request.executeRootHandler:200] (default task-63) Blocking request failed HttpServerExchange{ GET /app/resources/some.css}: java.lang.RuntimeException: org.xnio.channels.FixedLengthUnderflowException: 23323 bytes remaining

        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:177)

        at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [rt.jar:1.8.0_25]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [rt.jar:1.8.0_25]

        at java.lang.Thread.run(Unknown Source) [rt.jar:1.8.0_25]

Caused by: org.xnio.channels.FixedLengthUnderflowException: 23323 bytes remaining

We are using WildFly 8.1.0 Final.

Thanks,

Cory.