[
https://issues.apache.org/jira/browse/IO-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732185#comment-17732185
]
Tilman Hausherr commented on IO-802:
------------------------------------
I agree. Simple stuff like that {{IOUtils.skipFully(input, toSkip)}} should
"just work". Also there may be other code out there and people won't know that
they need to use this very special new method if they update from 2.11.0 (and
they will many, if dependabot some day fixes the bug that it didn't detect that
there is a new version of commons-io).
> 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)
