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 >>>> >>> >
