Problem sending large files as base64Binary from cxf client to cxf service

[xperjon]

Hi!
I'm having problem sending large files from a cxf client to a cxf service. I made a a sample application to reproduce: https://github.com/xperjon/Quarkus-CXF-FileUpload

Small files works just fine but when I try larger ones (about 100kB) the server throws:

Caused by: io.netty.handler.codec.http2.Http2Exception: Flow control window exceeded for stream: 0
at io.netty.handler.codec.http2.Http2Exception.connectionError(Http2Exception.java:109)

and the client throws:

Caused by: jakarta.xml.bind.MarshalException
 - with linked exception:
[java.io.IOException: Read end dead]
at org.glassfish.jaxb.runtime.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:268)

My wsdl looks like this (highly inspired by the example at https://docs.quarkiverse.io/quarkus-cxf/dev/user-guide/index.html):

<wsdl:definitions name = "FileService"
   targetNamespace = "http://server.it.cxf.quarkiverse.io/"
   xmlns:wsdl = "http://schemas.xmlsoap.org/wsdl/"
   xmlns:soap = "http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:tns = "http://server.it.cxf.quarkiverse.io/"
   xmlns:xsd = "http://www.w3.org/2001/XMLSchema">
   
   <wsdl:types>
   <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://server.it.cxf.quarkiverse.io/" attributeFormDefault="unqualified" elementFormDefault="unqualified" targetNamespace="http://server.it.cxf.quarkiverse.io/">

   <xsd:element name="upload" type="tns:upload"/>   
   <xsd:complexType name="upload">
       <xsd:sequence>
           <xsd:element minOccurs="0" name="filename" type="xsd:string"/>
           <xsd:element minOccurs="0" name="data" type="xsd:base64Binary"/>
        </xsd:sequence>
    </xsd:complexType>

    <xsd:element name="uploadResponse" type="tns:uploadResponse"/>
   <xsd:complexType name="uploadResponse">
     <xsd:sequence>
       <xsd:element minOccurs="0" name="size" type="xsd:int"/>
     </xsd:sequence>
   </xsd:complexType>
 </xsd:schema>
</wsdl:types>

   <wsdl:message name = "upload">
      <wsdl:part element="tns:upload" name = "parameters"></wsdl:part>
   </wsdl:message >

   <wsdl:message name = "uploadResponse">
    <wsdl:part element="tns:uploadResponse" name = "parameters"></wsdl:part>
 </wsdl:message >


   <wsdl:portType name = "FileService">
      <wsdl:operation name = "uploadFile">
         <wsdl:input message = "tns:upload" name="upload"/>
         <wsdl:output message = "tns:uploadResponse" name="uploadResponse"/>
      </wsdl:operation>
   </wsdl:portType>

   <wsdl:binding name = "FileServiceSoapBinding" type = "tns:FileService">
      <soap:binding style = "document"
         transport = "http://schemas.xmlsoap.org/soap/http"/>
      <wsdl:operation name = "uploadFile">
         <soap:operation soapAction = "" style="document"/>
         <wsdl:input name="upload">
            <soap:body use="literal"/>
         </wsdl:input>
		
         <wsdl:output name="uploadResponse">
            <soap:body use="literal"/>
         </wsdl:output>
      </wsdl:operation>
   </wsdl:binding>

   <wsdl:service name = "FileService">
      <wsdl:documentation>WSDL File for FileService</wsdl:documentation>
      <wsdl:port binding = "tns:FileServiceSoapBinding" name = "File">
         <soap:address
            location = "http://localhost:8080/FileService" />
      </wsdl:port>
   </wsdl:service>
</wsdl:definitions>

I'm using Java17 and Quarkus CXF 3.2.4.Final on both client and service.
Any ideas?

[shumonsharif]

Hi @xperjon It looks like HTTP/2 is getting used by the server, so the below may be one possible approach to resolving your issue.

Add the following dependency for client:

    <dependency>
      <groupId>io.quarkiverse.cxf</groupId>
      <artifactId>quarkus-cxf-rt-transports-http-hc5</artifactId>
    </dependency>

And then add the below to your client class:

    @PostConstruct
    public void configureHttp2() {
        Bus bus = ClientProxy.getClient(fileService).getBus();
        bus.setProperty(AsyncHTTPConduit.USE_ASYNC, Boolean.TRUE);
        bus.setProperty(AsyncHTTPConduit.ENABLE_HTTP2, Boolean.TRUE);
    }

You can read more about the above here: https://cxf.apache.org/docs/asynchronous-client-http-transport.html

[famod]

Quarkus server side can be ruled out in my case, it's quarkus-cxf client -> wiremock server (which is based on jetty) with upgrade from http 1.1 to 2. Also, it makes no difference whether I use Quarkus 3.3.2 or 3.4.0 (which contains that vert.x fix), unsurprisingly.

I would not say this proves that java.net.http.HttpClient was broken.

Yeah, could also be the conduit's fault.

[famod]

FWIW, problem persists with CXF 4.0.3 (using the CxfDefault conduit factory).

[ppalaga]

problem persists with CXF 4.0.3 (using the CxfDefault conduit factory).

Are you calling close() on the clients?

[famod]

@ppalaga no and TBH I don't see how that is related

[ppalaga]

TBH I don't see how that is related

No, it's not, sorry. I thought you might suffer from #992 but I see that you apparently don't (after reading your posts properly).

[shumonsharif]

Hmm, I just tried a simple test, I commented out the following in my patch.

+        bus.setProperty(AsyncHTTPConduit.ENABLE_HTTP2, Boolean.TRUE);

And your unit test cases still pass; so looks like it is indeed unrelated to HTTP/2, and likely the async client is doing something differently than the sync one. Look forward to what you come up with for this issue!

[famod]

You need to check what's happening on the wire - there could still be an upgrade to http/2 happening transparently.

[shumonsharif]

Very good point; never seem to have enough time these days to truly dig in :-) I think there's a good chance that is what's happening ...

[ppalaga]

That's very interesting, thanks for investigating @shumonsharif!

[xperjon]

Thanks a lot @ppalaga @shumonsharif! I will follow the created issues.

[dufoli]

Hello, I remember that a cxf vert request réponse I have written have a buffer management with size. Maybe it need some ajustement

[ppalaga]

The root cause is fixed in Vert.x 4.4.5 - see #973