Thanks for creating WSTX-260 ...
Does look rather like the underlying input stream is ending early (but
why does reading it all work?)
It does not appear to be a chunked encoding per se but I'm not sure
exactly what java.net is going to ask for: (I tried setting "TE:" -
either I got it wrong it I didn't get chunks back anyway).
Connection = [keep-alive]
Content-Length = [225983]
Date = [Wed, 09 Feb 2011 09:31:59 GMT]
Accept-Ranges = [bytes]
Content-Type = [application/sparql-results+xml; charset=UTF-8]
Server = [Virtuoso/06.02.3128 (Linux) x86_64-generic-linux-glibc25-64 VDB]
null = [HTTP/1.1 200 OK]
Hmm ... and that does not explain the reading all the stream part ...
need to poke the endpoint some more.
Andy
On 09/02/11 02:05, Benson Margulies wrote:
I've reproduced this. It looks to me like a cousin of a
never-entirely-resolved woodstox mystery. So I packaged it all up as
http://jira.codehaus.org/browse/WSTX-260
and we'll see what Tatu makes of it.
On Tue, Feb 8, 2011 at 5:48 PM, Andy Seaborne
<[email protected]> wrote:
The workaround is in
Package: com.hp.hpl.jena.sparql.engine.http
HttpQuery.execCommon()
Look for "WORKAROUND"
It does:
byte[] bytes = IO.readWholeFile(in) ;
in = new ByteArrayInputStream(bytes) ;
remove that.
The report code is in:
<src-dev>/reports.ReportDBPedia2
XMLInputStAX is the StAX based parser.
There is a separate SAX-based parser (non-streaming, but the workaround is
to stop streaming...) enabled by:
ARQ.getContext().setTrue(ARQ.useSAX) ;
Andy
On 08/02/11 22:11, Benson Margulies wrote:
What would I back out from trunk to get the failure so that I could
see if I could make any sense of it, possibly with help from Tatu?
On Tue, Feb 8, 2011 at 1:30 PM, Benson Margulies<[email protected]>
wrote:
On Tue, Feb 8, 2011 at 11:34 AM, Andy Seaborne
<[email protected]> wrote:
On 08/02/11 15:23, Benson Margulies wrote:
Hmm. This works fine in CXF. Do you all care enough to put more effort
into avoiding the extra buffer?
Is the STaX parser is CXF using?
I tried upgrading to woodstox 4.1.1 and (stil using the STaX API) get
the
same problem.
recoding (only in XMLInputStAX?) to use STaX2 might be an option.
I don't think that's relevant. The main CXF data path does just what's
giving you trouble, using the plain STaX API.
Andy
