Hi thanks for the confirmation - I'm on holidays for another few days hence the delays... I think Dan was also mentioning that the server might be able to affect this process by setting Content-Length to a specific value assuming the size of the message is known. I don't recall if it is supported in 2.2.11, but custom JAX-RS MessageBodyWriters can use getSize() method to achieve that...
Cheers, Sergey On Mon, Aug 1, 2011 at 8:28 PM, Andrew <[email protected]> wrote: > Update: this issue was resolved by setting the connection close header: > > WebClient.getConfig(client).getHttpConduit().getClient().setConnection(ConnectionType.CLOSE); > > which appears to force HTTP 1.0 > > On Sat, Jul 30, 2011 at 8:04 PM, Andrew <[email protected]> wrote: > >> I'm getting the following error with my CXF client: >> >> Caused by: java.io.IOException: Premature EOF >> at >> sun.net.www.http.ChunkedInputStream.readAheadBlocking(ChunkedInputStream.java:538) >> at >> sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:582) >> at sun.net.www.http.ChunkedInputStream.read(ChunkedInputStream.java:669) >> at java.io.FilterInputStream.read(FilterInputStream.java:116) >> at >> sun.net.www.protocol.http.HttpURLConnection$HttpInputStream.read(HttpURLConnection.java:2672) >> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264) >> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) >> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) >> at java.io.InputStreamReader.read(InputStreamReader.java:167) >> at org.apache.xerces.impl.XMLEntityScanner.load(Unknown Source) >> at org.apache.xerces.impl.XMLEntityScanner.skipString(Unknown Source) >> at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown >> Source) >> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) >> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) >> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) >> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) >> at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) >> at >> com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:211) >> >> This occurs while attempting to unmarshal the JAXB response. What's >> strange is this is only occurring in one environment, which unfortunately is >> production. And it is only occurring with responses around 8K, which >> appears to be the threshold where CXF starts chunking the response. >> >> The basic architecture is as follows: The client makes a REST request to >> server 1, which makes a similar REST request to server 2. Then, server 1 >> hands the Response object from server 2 back to the client, without >> unmarshalling/remarshalling. >> >> What I see when analyzing the http traffic is a correct chunked response >> from server 2, but the response from server 1 a bit malformed. It says it's >> chunked (in header) but it's not and contains the entire response. >> >> I've attempted to turn off chunking, with the following: >> >> >> WebClient.getConfig(t).getHttpConduit().getClient().setAllowChunking(false); >> >> but I've learned that pertains only to request chunking -- not where the >> problem is. >> >> So, my questions are, is there a method to tell CXF to not chunk the >> response? Or, is there an obvious problem here that can be resolved in >> another manner? I am using CXF 2.2.11 (old I know but stuck on it for >> now). Thanks, >> >> Andrew >> >> > -- Sergey Beryozkin http://sberyozkin.blogspot.com Talend - http://www.talend.com
