[
https://issues.apache.org/jira/browse/IO-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732161#comment-17732161
]
Tim Allison commented on IO-802:
--------------------------------
My concern with that approach is that users would need to know when they have
to take matters into their own hands. {{InflaterInputStream}} is weird and
does not document what it is doing, but there could be other InputStreams that
behave similarly. If we didn't have multithreaded tests on Tika, we would
never have known that {{InflaterInputStream}} is, um, surprising.
> Restore threadlocal for skipfully() byte buffer
> -----------------------------------------------
>
> Key: IO-802
> URL: https://issues.apache.org/jira/browse/IO-802
> Project: Commons IO
> Issue Type: Bug
> Reporter: Tim Allison
> Priority: Major
>
> Over on TIKA-4065, we found that trying to upgrade to commons-io 2.12.0 or
> 2.13.0 caused one of our unit tests to fail. We found that dropping
> {{threadlocal}} on the buffer used in IOUtils.skipFully() in conjunction with
> Java's InflaterInputStream was the cause of the problem.
> Our unit test shows that running skipFully() on a stream and then reading
> gets different results on the same underlying stream when running
> multithreaded. This is really bad. It appears to be confined to
> InflaterInputStream...so not a very common case.
> On the [commons-io's user
> list|https://lists.apache.org/thread/rxfyxqochnj7bw75nr2v7hf5qtkogx7d]
> [~psteitz] observed that Java's InflaterInputStream expects read access to
> the byte array passed in...so having multiple threads writing to the same
> static (not-thread local) byte array is dangerous. The behavior of Java's
> InflaterInputStream is surprising and not documented.
> I have a demonstration of the problem here:
> https://github.com/tballison/commons-io/blob/TIKA-4065/src/test/java/org/apache/commons/io/IOUtilsMultithreadedTest.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
