Closing as Won't Fix as there are no ICEfaces classes in the stack trace. Likely IE9 bug and/or overzealous Wildfly server logging.

Re-opened after further investigation indicates that we might be able to trap this to avoid the annoying excess logging.

Deryk says:

Perhaps a Jack and/or Mircea thing. In the BlockingConnectionServer, the IOException (Connection rest by peer) bubbles up and is caught and rethrown as a RuntimeException. Doesn’t appear to be any closing done on the response from what I can tell:

 
   private boolean respondIfPendingRequest(ResponseHandler handler) {
        Request previousRequest = (Request) pendingRequest.poll();
        if (previousRequest != null) {
            if (log.isLoggable(Level.FINE)) {
                log.log(Level.FINE, "Pending request for PushIDs '" + participatingPushIDs + "', trying to respond.");
            }
            try {
                recordResponseTime();
                previousRequest.respondWith(handler);
                return true;
            } catch (Exception e) {
                throw new RuntimeException(e);  //<- Line 180
            }
        }
        return false;
    }

 
In the Undertow code, it still thinks that there are chunks left:

http://grepcode.com/file/repo1.maven.org/maven2/io.undertow/undertow-core/1.0.0.Final/io/undertow/conduits/ChunkedStreamSinkConduit.java?av=f#276

 
 @Override
278    public void terminateWrites() throws IOException {
279        if(anyAreSet(state, FLAG_WRITES_SHUTDOWN)) {
280            return;
281        }
282        if (this.chunkleft != 0) {
283            throw UndertowMessages.MESSAGES.chunkedChannelClosedMidChunk();
284        }
285        if (!anyAreSet(state, FLAG_FIRST_DATA_WRITTEN)) {
286            //if no data was actually sent we just remove the transfer encoding header, and set content length 0
287            //TODO: is this the best way to do it?
288            //todo: should we make this behaviour configurable?
289            responseHeaders.put(Headers.CONTENT_LENGTH, "0"); //according to the spec we don't actually need this, but better to be safe
290            responseHeaders.remove(Headers.TRANSFER_ENCODING);
291            state |= FLAG_NEXT_SHUTDOWN | FLAG_WRITES_SHUTDOWN;
292            if(anyAreSet(state, CONF_FLAG_PASS_CLOSE)) {
293                next.terminateWrites();
294            }
295        } else {
296            createLastChunk(false);
297            state |= FLAG_WRITES_SHUTDOWN;
298        }
299    }

Modified respondIfPendingRequest method to avoid re-throwing the caught exceptions. Instead the IOException is captured and just a debug level message is logged. Any other exception is still caught and an error level message is logged instead.

Not able to reproduce. Wildfly 8.0.0 Final, Chrome, FF, IE 9 (2 versions), IE 10. EE-3.3.0 maintenance branch build 440.

This same server error issue occurs on Icefaces 4 trunk when tested using Wildfly 8.1.0 and IE 11.
Error seen when interacting with the following Showcase demos:
Accordion, gMap, qrCode, radioButton, richTextEntry, simpleSelectOneMenu, sliderEntry, submitMonitor, tabSet, textEntry as well as the auction test application.
Server error seen:
11:23:12,500 ERROR [io.undertow.request] (default task-5) Blocking request failed HttpServerExchange

: java.lang.RuntimeException: java.io.IOException: UT000029: Channel was closed mid chunk, if you have attempted to write chunked data you cannot shutdown the channel until after it has all been written......

Modified ContentTypeContentHandler to not flush the content of the servlet's output stream since the server can choose to stream the content after the flush method is called. Anyway calling flush on the servlet output stream was never necessary.

Applied fix to maintenance branch.

Verified Icefaces 4 trunk Jenkins Build 532 r41846 with Wildfly 8.1.0, Icefaces EE -3.3.0, r41846 maintenance branch Wildfly 8.0.0, using IE11