Michael Burman
Michael Burman
Why don't you just do ByteBuffer.duplicate() ? It's the same backing array, but you have new pointers which allow you to read the underlying data - without disrupting the original...
You only need to call close() before reading unknown number of items with Decompressor. If you know how many items to read, then there's no need for close(). Given that...
@billoley Did the previous comment solve your issue? Or is there still something you would wish to be changed? I might consider bookkeeping "helpers" for next release if you wish...
Can you create a test that causes that ArrayIndexOutOfBoundsException? If you added n-items and can't read n-items back, then there's a bug somewhere.
I pushed 2.1.0 version which allows to get the underlying array with getLongArray() and it won't do a copy anymore.
Fixed in commit 32807f2f29b50a76ac67c1fbc5b5e1e1619b16ba
Using only ValueCompression is possible from commit 077ddc8fa5010fa1db4e4b0caa4c367bcfa94d47
Yes, the storedTimestamp could be changed to something else or a boolean instead to detect the initialization part. The other issues are a bit more tricky and more related to...
Once done, the maven version can be queried and returned in the getFeatureSet endpoint (#142) to get the management-api version
@emerkle826 This is indeed true still. I hit this bug today when trying to improve MTLS testing.. there's no drain lines for example, so I can't verify if the drain...