Woodstox

Apparently invalid EOF exception when calling getElementText over a URL

Details

  • Type: Bug Bug
  • Status: In Progress In Progress
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 4.1
  • Fix Version/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

Under your chair you will find:

git://github.com/bimargulies/get-element-text-test-case-ARQ.git

(clone and build with mvn install)

Then you want:

git://github.com/bimargulies/get-element-text-test-case-BOOM.git

(clone this, run mvn install, and expect to see the backtrace below).

This is thought to be invalid because reading the entire URL input stream into a byte array, and then putting the woodstox stream on top of that, works perfectly fine.

Unexpected EOF; was expecting a close tag for element <uri>
[INFO] at [row,col

{unknown-source}]: [70,55]
[INFO] at com.hp.hpl.jena.sparql.resultset.XMLInputStAX$ResultSetStAX.staxError(XMLInputStAX.java:513)
[INFO] at com.hp.hpl.jena.sparql.resultset.XMLInputStAX$ResultSetStAX.hasNext(XMLInputStAX.java:223)
[INFO] at boom.Boom.main(Boom.java:28)
[INFO] Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF; was expecting a close tag for element <uri>
[INFO] at [row,col {unknown-source}

]: [70,55]
[INFO] at com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOF(StreamScanner.java:676)
[INFO] at com.ctc.wstx.sr.BasicStreamReader.throwUnexpectedEOF(BasicStreamReader.java:5439)
[INFO] at com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2673)
[INFO] at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1050)
[INFO] at com.ctc.wstx.sr.BasicStreamReader.getElementText(BasicStreamReader.java:687)
[INFO] at com.hp.hpl.jena.sparql.resultset.XMLInputStAX$ResultSetStAX.getOneSolution(XMLInputStAX.java:483)
[INFO] at com.hp.hpl.jena.sparql.resultset.XMLInputStAX$ResultSetStAX.hasNext(XMLInputStAX.java:219)
[INFO] ... 1 more

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Tatu Saloranta added a comment -

Ok, I can see the failure, which is a good first step.
Now it would be good to actually figure out what kind of input there is... it seems like this occurs with sizable data?

Show
Tatu Saloranta added a comment - Ok, I can see the failure, which is a good first step. Now it would be good to actually figure out what kind of input there is... it seems like this occurs with sizable data?
Hide
Permalink
Tatu Saloranta added a comment -

It actually looks like the underlying InputStream only serves first chunk and truncates content: I can only see this via UTF8Reader that wraps it but I think that is the place to check next.

Show
Tatu Saloranta added a comment - It actually looks like the underlying InputStream only serves first chunk and truncates content: I can only see this via UTF8Reader that wraps it but I think that is the place to check next.
Hide
Permalink
Benson Margulies added a comment -

The data content is moderate but not gigantic.

Do you see the underlying stream as other than the URL connection itself?

I can point you at the workaround code that is commented out that buffers and succeeds.

Show
Benson Margulies added a comment - The data content is moderate but not gigantic. Do you see the underlying stream as other than the URL connection itself? I can point you at the workaround code that is commented out that buffers and succeeds.
Hide
Permalink
Benson Margulies added a comment -

In com.hp.hpl.jena.sparql.engine.http.HttpQuery, look for WORKAROUND. It could be that the other end actually does close in some violent fashion if this all takes too long.

Show
Benson Margulies added a comment - In com.hp.hpl.jena.sparql.engine.http.HttpQuery, look for WORKAROUND. It could be that the other end actually does close in some violent fashion if this all takes too long.
Hide
Permalink
Tatu Saloranta added a comment -

Ok: so, initial read gets bit less than 3k of data, second read fails. Failure occurs so quickly that about the only explanation I can think of is that someone mixed up millisecond timeout with second-based timeout. grin
(which actually happens kind of often; I always name my properties with time unit prefix for that reason)

Show
Tatu Saloranta added a comment - Ok: so, initial read gets bit less than 3k of data, second read fails. Failure occurs so quickly that about the only explanation I can think of is that someone mixed up millisecond timeout with second-based timeout. grin (which actually happens kind of often; I always name my properties with time unit prefix for that reason)

People

  • Assignee:
    Tatu Saloranta
    Reporter:
    Benson Margulies
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: