jena-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <andy.seabo...@epimorphics.com>
Subject Re: Unexpected end of input errors on reading from dbpedia
Date Wed, 09 Feb 2011 09:38:52 GMT
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
> <andy.seaborne@epimorphics.com>  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<bimargulies@gmail.com>
>>>   wrote:
>>>>
>>>> On Tue, Feb 8, 2011 at 11:34 AM, Andy Seaborne
>>>> <andy.seaborne@epimorphics.com>    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
>>>>>
>>>>
>>

Mime
View raw message