-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
None
The Gzip and Inflate encoding providers (GzipEncodingProvider and InflateEncodingProvider) have support for re-using Deflater and Inflater objects via ObjectPools; the simple object pool type, NewInstanceObjectPool, which these encoding providers default to, work fine - instances are properly created and then recycled.
However, attempting to use a SimpleObjectPool, which allows for reuse of the same Deflater/Inflater instances (by returning them to an internal pool which they can be pulled from again), fails and causes the consumer of the object pool - in this case, the encoding providers - to hang indefinitely.
The source of the problem is fortunately relatively easy - the main problem is that the Deflater/Inflater instances are not reset between usages, which causes undefined behavior when they are pulled from the pool again for attempted reuse. The fix for this involves just calling reset() on the instances either after they are returned to the internal pool of the SimpleObjectPool or before they are pulled from the pool.
I've attached a unit test which is a copy of another GzipEncodingHandler unit test, but which uses the SimpleObjectPool instead of the NewInstanceObjectPool; the unit test hangs on my machine, though it could have other strange behavior on other systems/JDK implementations. I'll also provide a pull request with the aforementioned test and a potential fix (by adding a "recycle" lambda to a SimpleObjectPool which is called every time an object is returned to the pool).
In the meanwhile, I've just created a custom implementation of an ObjectPool specialized to inflaters/deflaters which applies the above fix.
Sorry in advance if this was far too wordy, and thanks in advance for any help.