eclipse-ee4j / mojarra

Mojarra, a Jakarta Faces implementation
Other
158 stars 107 forks source link

Frequent java.nio.channels.ClosedChannelException in Undertow with HTTP2 and JSF Applications #5391

Closed rabiter closed 4 months ago

rabiter commented 4 months ago

Description

When using Undertow (Wildfly or JBoss) with HTTP2 in conjunction with JSF applications, numerous instances of java.nio.channels.ClosedChannelException are logged. This issue appears to be related to how HTTP2 handles resource loading, particularly when interacting with different web browsers such as Chrome and Firefox.

Reproducer (vary slightly between Chrome and Firefox)

Chrome:

  1. Open any JSF application page
  2. Before the page fully loads, refresh (F5) or close the page.
  3. Observe that java.nio.channels.ClosedChannelException is logged on the server.

Firefox:

  1. Open any JSF application page, refresh the page (ensuring that the Firefox cached resources)
  2. Note that each request for resource loading results in java.nio.channels.ClosedChannelException.
  3. The issue disappears when Firefox's cache is disabled, indicating a potential link with Firefox's caching mechanism.

Environment

The issue seems to be more pronounced in Firefox, where every resource load request triggers the exception, potentially pointing towards a handling problem in the interaction between HTTP2, browser caching mechanisms, and resource loading in JSF applications.

Regarding Firefox (my assumptions): The exception occurs if Firefox sends a request to the server to load a resource, then finds out that it can retrieve the resource from the cache and interrupts the request, leading to a ClosedChannelException in Undertow.

Possible solution (?): The class ResourceHandlerImpl skips ClientAbortException (Tomcat) and EofException (Jetty) in method isConnectionAbort: https://github.com/eclipse-ee4j/mojarra/blob/350fbbea7fe3b2c02eb416934cdebb2c0f9830da/impl/src/main/java/com/sun/faces/application/resource/ResourceHandlerImpl.java#L346 Maybe ClosedChannelException (undertow) should be handled the same way?

the stacktrace is attached stacktrace.log

rabiter commented 4 months ago

there's another issue, probably related (I created it for undertow project, but not 100% sure on which side the problem is though): https://issues.redhat.com/browse/UNDERTOW-2343