EJB over HTTP/2 doesn't work with huge objects

EJB calls with huge result objects (i.e. String >= 64 Kbytes) doesn't work with Wildfly 25 or 26 because the remote protocol doesn't work work anymore and I have to use now the HTTP protocol. Specifically the HTTP/2 implemenattion seems to have issues on transporting huge objects to the client, but the HTTP/1 seems to work.

Explanation: I have checked / debugged the Wildfly client code and in my opinion there are 2 different bugs. One in the server and one in the client code of the HTTP/2 protocol implementation.

First bug: The server sends without any obvious reason (only on bigger objects) in the middle of the data stream a FRAME_TYPE_RST_STREAM in the header position 3. (see io.undertow.protocols.http2.Http2FrameHeaderParser:191 --> type = header[3] & 0xff )  which marks the stream as broken (see io.undertow.server.protocol.framed.AbstractFramedStreamSourceChannel:684 --> state |= STATE_STREAM_BROKEN ) and afterwards causes "ClosedChannelExceptions" on all stream reads inside the client (see org.wildfly.httpclient.common.WildflyClientInputStream:58 --> int res = streamSourceChannel.read(pooled.getBuffer()) I didn't debug the server side code, so I can't tell why the server sends suddenly a "reset stream" on some huge objects. Sometimes the same huge object is transferred to the client without issues. On using HTTP/1 this neever happens so it can't be a network issue.

Second bug (in my case initiated by the reset sent from the server) : The client can't handle correctly a "ClosedChannelException", because it freezes the whole communication channel. The client just keeps reading from the channel and after each read it invokes the wait(0) on its lock Object (see org.wildfly.httpclient.common.WildflyClientInputStream:147 --> lock.wait() ) Normally this wait(0) is continued by invoking the notifyAll() of same lock Object (in case of ClosedChannelExceptions it is the org.wildfly.httpclient.common.WildflyClientInputStream:94 --> lock.notifyAll(); Unluckily after the last read and therefore last invoked wait(0), there is no notifyAll() invoked anymore, so the EJB client call freezes for ever.

In my opinion the client shall not freeze under any circumstances.

The solution I found is, but I'm not happy with that, to disable the HTTP/2 protocol on the server and use HTTP/1 instead. standalone-full.xml --> <https-listener name="https" socket-binding="https" enable-http2="false" />

Making the same EJB calls through the HTTP/1 protocol works fine for huge Objects as well.

The mentioned classes with line numbers are all taken from Wildlfy 26.0.0 Client jar: