All,

  Since the refactoring to avoid threadlocal in skipFully, we are now
getting errors in one of our unit tests on Tika [0].  We're still on
commons-io 2.11.0, but we found this problem with 2.12.0 and 2.13.0.

   I was able to reproduce the problem outside of Tika [1].  To reproduce
the problem, the stream has to be wrapped in java's InflaterInputStream,
and it has to be run multithreaded.  The problem is easily reproducible
with only two threads, but there is variation on which iteration triggers
the problem even with the same seed (what you'd expect from a
multi-threading bug).

  I don't think this is a bug in commons-io, per se, but it is mildly
frightening from a data reliability perspective that the combination of
IOUtils.skipFully on top of Java's InflaterInputStream can lead to
different data.

  Is this a bug in Java, a bug in commons-io or something else?  What
should we do?  Thank you!

       Best,

           Tim




[0] https://issues.apache.org/jira/browse/TIKA-4065
[1]
https://github.com/tballison/commons-io/blob/TIKA-4065/src/test/java/org/apache/commons/io/IOUtilsMultithreadedTest.java

Reply via email to