[jira] [Commented] (IO-802) Restore threadlocal for skipfully() byte buffer

["Gary D. Gregory (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IO-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17732129#comment-17732129 ] 

Gary D. Gregory commented on IO-802:
------------------------------------

This feels to me like such an unusual case that we should offer a new API where the call site can provide its own buffer:

{{IOUtils.skipFully(InputStream, long, byte[])}}

> 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)