[
https://issues.apache.org/jira/browse/IO-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732238#comment-17732238
]
Phil Steitz commented on IO-802:
--------------------------------
I agree that it would be best to just add back the protection, for the reasons
above. The jdk developers at least in the InflaterInputStream case seem to
think concurrent writes to a read buffer should not happen, so I would
recommend eliminating this risk. I would also evaluate the need for zero-ing
for the write only one. Is it needed?
> 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)
