Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
None
-
None
Description
As reported by Andrea Di Menna [1] the current StreamSource implementation my cause
java.io.IOException: Stream closed
at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:308)
at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:169)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1025)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:999)
at org.apache.commons.io.IOUtils.toByteArray(IOUtils.java:218)
at org.apache.stanbol.enhancer.servicesapi.impl.StreamSource.getData(StreamSource.java:136)
at org.apache.stanbol.enhancer.contentitem.inmemory.InMemoryContentItemFactory.createBlob(InMemoryContentItemFactory.java:80)
at org.apache.stanbol.enhancer.servicesapi.impl.AbstractContentItemFactory.createContentItem(AbstractContentItemFactory.java:121)
at org.apache.stanbol.enhancer.servicesapi.impl.AbstractContentItemFactory.createContentItem(AbstractContentItemFactory.java:90)
at org.apache.stanbol.enhancer.jersey.reader.ContentItemReader.readFrom(ContentItemReader.java:261)
at org.apache.stanbol.enhancer.jersey.reader.ContentItemReader.readFrom(ContentItemReader.java:69)
in cases where the Servlet Container reuses parsed InputStreams - what seams to be the case with Tomcat 7.
The reason for that is that the finalize() method of the StreamSource does call close() on the initially parsed InputStream. This might results in Situations where close() is called on an InputStream that is currently used by an other connection.
To Solve this the following two adaptions are planed:
1. The StreamSource MUST NOT close parsed Streams.
2. Add the Requirement that the ContentItemFactory needs to consume all data from parsed ContentSource implementation before returning from create** methods.
While (1) solves the reported issue and also allows for reusing streams by the container (2) is required to allow users outside a container to know when they can safely close streams.