[
https://issues.apache.org/jira/browse/HBASE-27534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Beaudreault reopened HBASE-27534:
---------------------------------------
Assignee: Bryan Beaudreault
Reopening to fix this crash.
Actually, the problem is a core dump in jbyte_disjoint_arraycopy, which comes
from parsing a SlowLogParams. Taking a look at the surefire-reports output txt
and core dump, it seems to occur directly after a "responseTooLarge" log line
stemming from the TEST_UTIL.loadTable (which does a giant mutate to load data).
Unfortunately I can't seem to reproduce this locally. You'd think it was a jvm
issue, but according to the above has affected both jdk8 and 11 builds.
I'm going to push an addendum which tries to avoid triggering a slow log for
the loadTable request. We'll see if that improves it.
> Determine too large requests by response block size rather than cell size
> -------------------------------------------------------------------------
>
> Key: HBASE-27534
> URL: https://issues.apache.org/jira/browse/HBASE-27534
> Project: HBase
> Issue Type: Improvement
> Reporter: Bryan Beaudreault
> Assignee: Bryan Beaudreault
> Priority: Major
> Labels: slowlog
> Fix For: 2.6.0, 3.0.0-alpha-4
>
>
> We send responses that are too slow or too large to the slow log. The too
> large is currently based on the response cell size, but the response block
> size is actually more important for performance. We should enhance the
> threshold check to use the response block size (or maybe check both sizes).
> As part of this, we should also add the response block size to the slow log
> entries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
