[
https://issues.apache.org/jira/browse/HBASE-27073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689306#comment-17689306
]
Andrew Kyle Purtell commented on HBASE-27073:
---------------------------------------------
bq. Why they all failed at position 65536...
Yes it is suspicious and possibly a buffering issue leading to a short read
when a buffer becomes full. My comment above may be relevant:
{quote}
When working on WAL value compression a while back I remember *the first
version used a temporary growable buffer (a ByteArrayOutputStream if I recall
correctly) to collect all encrypted bytes of the value before submitting the
payload to the codec*. Later in code review Bharath and I went back and forth a
bit on a trick with input streams to reduce the number of copies. To fix this I
would go back to the earlier approach.
{quote}
> TestReplicationValueCompressedWAL.testMultiplePuts is flaky
> -----------------------------------------------------------
>
> Key: HBASE-27073
> URL: https://issues.apache.org/jira/browse/HBASE-27073
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.5.0
> Environment: Java version: 1.8.0_322
> OS name: "linux", version: "5.10.0-13-arm64", arch: "aarch64", family: "unix"
> Reporter: Andrew Kyle Purtell
> Priority: Minor
> Fix For: 2.6.0, 3.0.0-alpha-4, 2.5.4
>
>
> org.apache.hadoop.hbase.replication.regionserver.TestReplicationValueCompressedWAL.testMultiplePuts
> 
Run 1: TestReplicationValueCompressedWAL.testMultiplePuts:56 Waited too
> much time for replication
> Run 2: PASS
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
