[jira] [Commented] (HBASE-28482) Reverse scan with tags throws ArrayIndexOutOfBoundsException with DBE
[
https://issues.apache.org/jira/browse/HBASE-28482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833392#comment-17833392
]
Pankaj Kumar commented on HBASE-28482:
--
Thank you [~vineet.4008] for raising this issue. Added you as a contributor,
please raise a PR.
> Reverse scan with tags throws ArrayIndexOutOfBoundsException with DBE
> -
>
> Key: HBASE-28482
> URL: https://issues.apache.org/jira/browse/HBASE-28482
> Project: HBase
> Issue Type: Bug
> Components: HFile
>Reporter: Vineet Kumar Maheshwari
>Assignee: Vineet Kumar Maheshwari
>Priority: Major
>
> Facing ArrayIndexOutOfBoundsException when performing reverse scan on a table
> with 30K+ records in single hfile.
> Exception is happening when block changes during seekBefore call.
> {code:java}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.hadoop.hbase.util.ByteBufferUtils.copyFromBufferToArray(ByteBufferUtils.java:1326)
> at org.apache.hadoop.hbase.nio.SingleByteBuff.get(SingleByteBuff.java:213)
> at
> org.apache.hadoop.hbase.io.encoding.DiffKeyDeltaEncoder$DiffSeekerStateBufferedEncodedSeeker.decode(DiffKeyDeltaEncoder.java:431)
> at
> org.apache.hadoop.hbase.io.encoding.DiffKeyDeltaEncoder$DiffSeekerStateBufferedEncodedSeeker.decodeNext(DiffKeyDeltaEncoder.java:502)
> at
> org.apache.hadoop.hbase.io.encoding.BufferedDataBlockEncoder$BufferedEncodedSeeker.seekToKeyInBlock(BufferedDataBlockEncoder.java:1012)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderImpl$EncodedScanner.loadBlockAndSeekToKey(HFileReaderImpl.java:1605)
> at
> org.apache.hadoop.hbase.io.hfile.HFileReaderImpl$HFileScannerImpl.seekBefore(HFileReaderImpl.java:719)
> at
> org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekBeforeAndSaveKeyToPreviousRow(StoreFileScanner.java:645)
> at
> org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekToPreviousRowWithoutHint(StoreFileScanner.java:570)
> at
> org.apache.hadoop.hbase.regionserver.StoreFileScanner.seekToPreviousRow(StoreFileScanner.java:506)
> at
> org.apache.hadoop.hbase.regionserver.ReversedKeyValueHeap.next(ReversedKeyValueHeap.java:126)
> at
> org.apache.hadoop.hbase.regionserver.StoreScanner.next(StoreScanner.java:693)
> at
> org.apache.hadoop.hbase.regionserver.KeyValueHeap.next(KeyValueHeap.java:151){code}
>
> Steps to reproduce:
> Create a table with DataBlockEncoding.DIFF and block size as 1024, write some
> 30K+ puts with setTTL, then do a reverse scan.
> {code:java}
> @Test
> public void testReverseScanWithDBEWhenCurrentBlockUpdates() throws
> IOException {
> byte[] family = Bytes.toBytes("0");
> Configuration conf = new Configuration(TEST_UTIL.getConfiguration());
> conf.setInt(HConstants.HBASE_CLIENT_RETRIES_NUMBER, 1);
> try (Connection connection = ConnectionFactory.createConnection(conf)) {
> testReverseScanWithDBE(connection, DataBlockEncoding.DIFF, family, 1024,
> 3);
> for (DataBlockEncoding encoding : DataBlockEncoding.values()) {
> testReverseScanWithDBE(connection, encoding, family, 1024, 3);
> }
> }
> }
> private void testReverseScanWithDBE(Connection conn, DataBlockEncoding
> encoding, byte[] family, int blockSize, int maxRows)
> throws IOException {
> LOG.info("Running test with DBE={}", encoding);
> TableName tableName = TableName.valueOf(TEST_NAME.getMethodName() + "-" +
> encoding);
> TEST_UTIL.createTable(TableDescriptorBuilder.newBuilder(tableName)
> .setColumnFamily(
> ColumnFamilyDescriptorBuilder.newBuilder(family).setDataBlockEncoding(encoding).setBlocksize(blockSize).build())
> .build(), null);
> Table table = conn.getTable(tableName);
> byte[] val1 = new byte[10];
> byte[] val2 = new byte[10];
> Bytes.random(val1);
> Bytes.random(val2);
> for (int i = 0; i < maxRows; i++) {
> table.put(new Put(Bytes.toBytes(i)).addColumn(family, Bytes.toBytes(1), val1)
> .addColumn(family, Bytes.toBytes(2), val2).setTTL(600_000));
> }
> TEST_UTIL.flush(table.getName());
> Scan scan = new Scan();
> scan.setReversed(true);
> try (ResultScanner scanner = table.getScanner(scan)) {
> for (int i = maxRows - 1; i >= 0; i--) {
> Result row = scanner.next();
> assertEquals(2, row.size());
> Cell cell1 = row.getColumnLatestCell(family, Bytes.toBytes(1));
> assertTrue(CellUtil.matchingRows(cell1, Bytes.toBytes(i)));
> assertTrue(CellUtil.matchingValue(cell1, val1));
> Cell cell2 = row.getColumnLatestCell(family, Bytes.toBytes(2));
> assertTrue(CellUtil.matchingRows(cell2, Bytes.toBytes(i)));
> assertTrue(CellUtil.matchingValue(cell2, val2));
> }
> }
> }
> {code}
>
> HBASE-27580 has fixed the issue for seekBefore in rewind function flow, but
> similar change is required in setCurrentBlock function flow also.
--
This message was sent by Atlassian Jira
[jira] [Commented] (HBASE-28060) Region server getting crashed during write - A fatal error has been detected by the Java Runtime Environment
[
https://issues.apache.org/jira/browse/HBASE-28060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763650#comment-17763650
]
Pankaj Kumar commented on HBASE-28060:
--
Checked ByteBuffAllocator code, couldn't find any issue there. Observed ZStd
compression algorithm is set in production environment tables.
> Region server getting crashed during write - A fatal error has been detected
> by the Java Runtime Environment
>
>
> Key: HBASE-28060
> URL: https://issues.apache.org/jira/browse/HBASE-28060
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.4.14
>Reporter: Pankaj Kumar
>Priority: Critical
>
> In our production environment, Region server JVM is getting crashed randomly
> with the following error logs.
> {code:java}
> Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
> space=2040k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> v ~StubRoutines::jshort_disjoint_arraycopy
> J 98497 C2
> org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
> (53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
> C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
> [error occurred during error reporting (printing native stack), id 0xb]
> {code}
>
> We are using HBase 2.4.14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (HBASE-28060) Region server getting crashed during write - A fatal error has been detected by the Java Runtime Environment
[
https://issues.apache.org/jira/browse/HBASE-28060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17762118#comment-17762118
]
Pankaj Kumar commented on HBASE-28060:
--
HBASE-26024 also have similar error.
> Region server getting crashed during write - A fatal error has been detected
> by the Java Runtime Environment
>
>
> Key: HBASE-28060
> URL: https://issues.apache.org/jira/browse/HBASE-28060
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.4.14
>Reporter: Pankaj Kumar
>Priority: Critical
>
> In our production environment, Region server JVM is getting crashed randomly
> with the following error logs.
> {code:java}
> Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
> space=2040k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> v ~StubRoutines::jshort_disjoint_arraycopy
> J 98497 C2
> org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
> (53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
> C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
> [error occurred during error reporting (printing native stack), id 0xb]
> {code}
>
> We are using HBase 2.4.14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (HBASE-28060) Region server getting crashed during write - A fatal error has been detected by the Java Runtime Environment
[
https://issues.apache.org/jira/browse/HBASE-28060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761955#comment-17761955
]
Pankaj Kumar edited comment on HBASE-28060 at 9/5/23 6:31 AM:
--
Some RegionServer in a cluster have this issue which is happening randomly,
There is no special operation and memory usage is also normal.
Are we releasing the DBB memory in advance? And because of that memory address
is not accessible .
was (Author: pankajkumar):
Some RegionServer in a cluster have this issue which is happening randomly,
There is no special operation and memory usage is also normal.
> Region server getting crashed during write - A fatal error has been detected
> by the Java Runtime Environment
>
>
> Key: HBASE-28060
> URL: https://issues.apache.org/jira/browse/HBASE-28060
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.4.14
>Reporter: Pankaj Kumar
>Priority: Critical
>
> In our production environment, Region server JVM is getting crashed randomly
> with the following error logs.
> {code:java}
> Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
> space=2040k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> v ~StubRoutines::jshort_disjoint_arraycopy
> J 98497 C2
> org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
> (53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
> C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
> [error occurred during error reporting (printing native stack), id 0xb]
> {code}
>
> We are using HBase 2.4.14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (HBASE-28060) Region server getting crashed during write - A fatal error has been detected by the Java Runtime Environment
[
https://issues.apache.org/jira/browse/HBASE-28060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761955#comment-17761955
]
Pankaj Kumar edited comment on HBASE-28060 at 9/5/23 6:03 AM:
--
Some RegionServer in a cluster have this issue which is happening randomly,
There is no special operation and memory usage is also normal.
was (Author: pankajkumar):
Some RegionServer in a cluster have this this issue which is happening
randomly, There is no special operation and memory usage is also normal.
> Region server getting crashed during write - A fatal error has been detected
> by the Java Runtime Environment
>
>
> Key: HBASE-28060
> URL: https://issues.apache.org/jira/browse/HBASE-28060
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.4.14
>Reporter: Pankaj Kumar
>Priority: Critical
>
> In our production environment, Region server JVM is getting crashed randomly
> with the following error logs.
> {code:java}
> Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
> space=2040k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> v ~StubRoutines::jshort_disjoint_arraycopy
> J 98497 C2
> org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
> (53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
> C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
> [error occurred during error reporting (printing native stack), id 0xb]
> {code}
>
> We are using HBase 2.4.14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (HBASE-28060) Region server getting crashed during write - A fatal error has been detected by the Java Runtime Environment
[
https://issues.apache.org/jira/browse/HBASE-28060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761955#comment-17761955
]
Pankaj Kumar commented on HBASE-28060:
--
Some RegionServer in a cluster have this this issue which is happening
randomly, There is no special operation and memory usage is also normal.
> Region server getting crashed during write - A fatal error has been detected
> by the Java Runtime Environment
>
>
> Key: HBASE-28060
> URL: https://issues.apache.org/jira/browse/HBASE-28060
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.4.14
>Reporter: Pankaj Kumar
>Priority: Critical
>
> In our production environment, Region server JVM is getting crashed randomly
> with the following error logs.
> {code:java}
> Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
> space=2040k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> v ~StubRoutines::jshort_disjoint_arraycopy
> J 98497 C2
> org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
> (53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
> C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
> [error occurred during error reporting (printing native stack), id 0xb]
> {code}
>
> We are using HBase 2.4.14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (HBASE-28060) Region server getting crashed during write - A fatal error has been detected by the Java Runtime Environment
[
https://issues.apache.org/jira/browse/HBASE-28060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761933#comment-17761933
]
Pankaj Kumar commented on HBASE-28060:
--
We are using 1.8.0_332..
> Region server getting crashed during write - A fatal error has been detected
> by the Java Runtime Environment
>
>
> Key: HBASE-28060
> URL: https://issues.apache.org/jira/browse/HBASE-28060
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.4.14
>Reporter: Pankaj Kumar
>Priority: Critical
>
> In our production environment, Region server JVM is getting crashed randomly
> with the following error logs.
> {code:java}
> Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
> space=2040k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> v ~StubRoutines::jshort_disjoint_arraycopy
> J 98497 C2
> org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
> (53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
> C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
> [error occurred during error reporting (printing native stack), id 0xb]
> {code}
>
> We are using HBase 2.4.14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (HBASE-28060) Region server getting crashed during write - A fatal error has been detected by the Java Runtime Environment
[
https://issues.apache.org/jira/browse/HBASE-28060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761827#comment-17761827
]
Pankaj Kumar edited comment on HBASE-28060 at 9/4/23 2:00 PM:
--
[~zhangduo] [~anoop.hbase] any suggestion?
was (Author: pankajkumar):
[~zhangduo] [~anoopsamjohn] any suggestion?
> Region server getting crashed during write - A fatal error has been detected
> by the Java Runtime Environment
>
>
> Key: HBASE-28060
> URL: https://issues.apache.org/jira/browse/HBASE-28060
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.4.14
>Reporter: Pankaj Kumar
>Priority: Critical
>
> In our production environment, Region server JVM is getting crashed randomly
> with the following error logs.
> {code:java}
> Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
> space=2040k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> v ~StubRoutines::jshort_disjoint_arraycopy
> J 98497 C2
> org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
> (53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
> C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
> [error occurred during error reporting (printing native stack), id 0xb]
> {code}
>
> We are using HBase 2.4.14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (HBASE-28060) Region server getting crashed during write - A fatal error has been detected by the Java Runtime Environment
[
https://issues.apache.org/jira/browse/HBASE-28060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17761827#comment-17761827
]
Pankaj Kumar commented on HBASE-28060:
--
[~zhangduo] [~anoopsamjohn] any suggestion?
> Region server getting crashed during write - A fatal error has been detected
> by the Java Runtime Environment
>
>
> Key: HBASE-28060
> URL: https://issues.apache.org/jira/browse/HBASE-28060
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.4.14
>Reporter: Pankaj Kumar
>Priority: Critical
>
> In our production environment, Region server JVM is getting crashed randomly
> with the following error logs.
> {code:java}
> Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
> space=2040k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> v ~StubRoutines::jshort_disjoint_arraycopy
> J 98497 C2
> org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
> (53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
> C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
> [error occurred during error reporting (printing native stack), id 0xb]
> {code}
>
> We are using HBase 2.4.14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (HBASE-28060) Region server getting crashed during write - A fatal error has been detected by the Java Runtime Environment
[
https://issues.apache.org/jira/browse/HBASE-28060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pankaj Kumar updated HBASE-28060:
-
Description:
In our production environment, Region server JVM is getting crashed randomly
with the following error logs.
{code:java}
Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
space=2040k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v ~StubRoutines::jshort_disjoint_arraycopy
J 98497 C2
org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
(53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
[error occurred during error reporting (printing native stack), id 0xb]
{code}
We are using HBase 2.4.14.
was:
In our production environment, Region server JVM is getting crashed randomly
with the following error logs.
{code:java}
Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
space=2040k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v ~StubRoutines::jshort_disjoint_arraycopy
J 98497 C2
org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
(53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
[error occurred during error reporting (printing native stack), id 0xb]
{code}
We are using HBase 2.4.14.
> Region server getting crashed during write - A fatal error has been detected
> by the Java Runtime Environment
>
>
> Key: HBASE-28060
> URL: https://issues.apache.org/jira/browse/HBASE-28060
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.4.14
>Reporter: Pankaj Kumar
>Priority: Critical
>
> In our production environment, Region server JVM is getting crashed randomly
> with the following error logs.
> {code:java}
> Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
> space=2040k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> v ~StubRoutines::jshort_disjoint_arraycopy
> J 98497 C2
> org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
> (53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
> C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
> [error occurred during error reporting (printing native stack), id 0xb]
> {code}
>
> We are using HBase 2.4.14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (HBASE-28060) Region server getting crashed during write - A fatal error has been detected by the Java Runtime Environment
[
https://issues.apache.org/jira/browse/HBASE-28060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pankaj Kumar updated HBASE-28060:
-
Description:
In our production environment, Region server JVM is getting crashed randomly
with the following error logs.
{code:java}
Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
space=2040k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v ~StubRoutines::jshort_disjoint_arraycopy
J 98497 C2
org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
(53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
[error occurred during error reporting (printing native stack), id 0xb]
{code}
We are using HBase 2.4.14.
was:
In our production environment, Region server's JVM is getting crashed randomly
with the following error logs.
{code:java}
Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
space=2040k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v ~StubRoutines::jshort_disjoint_arraycopy
J 98497 C2
org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
(53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
[error occurred during error reporting (printing native stack), id 0xb]
{code}
We are using HBase 2.4.14.
> Region server getting crashed during write - A fatal error has been detected
> by the Java Runtime Environment
>
>
> Key: HBASE-28060
> URL: https://issues.apache.org/jira/browse/HBASE-28060
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.4.14
>Reporter: Pankaj Kumar
>Priority: Critical
>
> In our production environment, Region server JVM is getting crashed randomly
> with the following error logs.
>
> {code:java}
> Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
> space=2040k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> v ~StubRoutines::jshort_disjoint_arraycopy
> J 98497 C2
> org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
> (53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
> C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
> [error occurred during error reporting (printing native stack), id 0xb]
> {code}
>
> We are using HBase 2.4.14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (HBASE-28060) Region server getting crashed during write - A fatal error has been detected by the Java Runtime Environment
[
https://issues.apache.org/jira/browse/HBASE-28060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pankaj Kumar updated HBASE-28060:
-
Description:
In our production environment, Region server's JVM is getting crashed randomly
with the following error logs.
{code:java}
Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
space=2040k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v ~StubRoutines::jshort_disjoint_arraycopy
J 98497 C2
org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
(53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
[error occurred during error reporting (printing native stack), id 0xb]
{code}
We are using HBase 2.4.14.
was:
In our production environment, Region server's JVM is getting crashed randomly
with the following error logs.
{code:java}
Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
space=2040k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v ~StubRoutines::jshort_disjoint_arraycopy
J 98497 C2
org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
(53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
[error occurred during error reporting (printing native stack), id 0xb]
{code}
We are using HBase 2.4.14.
> Region server getting crashed during write - A fatal error has been detected
> by the Java Runtime Environment
>
>
> Key: HBASE-28060
> URL: https://issues.apache.org/jira/browse/HBASE-28060
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 2.4.14
>Reporter: Pankaj Kumar
>Priority: Critical
>
> In our production environment, Region server's JVM is getting crashed
> randomly with the following error logs.
>
> {code:java}
> Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
> space=2040k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> v ~StubRoutines::jshort_disjoint_arraycopy
> J 98497 C2
> org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
> (53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
> C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
> [error occurred during error reporting (printing native stack), id 0xb]
> {code}
>
> We are using HBase 2.4.14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (HBASE-28060) Region server getting crashed during write - A fatal error has been detected by the Java Runtime Environment
Pankaj Kumar created HBASE-28060:
Summary: Region server getting crashed during write - A fatal
error has been detected by the Java Runtime Environment
Key: HBASE-28060
URL: https://issues.apache.org/jira/browse/HBASE-28060
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 2.4.14
Reporter: Pankaj Kumar
In our production environment, Region server's JVM is getting crashed randomly
with the following error logs.
{code:java}
Stack: [0xfffdd32d8000,0xfffdd34d8000], sp=0xfffdd34d6000, free
space=2040k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
v ~StubRoutines::jshort_disjoint_arraycopy
J 98497 C2
org.apache.hadoop.hbase.io.ByteBufferListOutputStream.write(Ljava/nio/ByteBuffer;II)V
(53 bytes) @ 0x8cc9a154 [0x8cc9a040+0x114]
C [ld-linux-aarch64.so.1+0x40018] _rtld_global+0x0
[error occurred during error reporting (printing native stack), id 0xb]
{code}
We are using HBase 2.4.14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (HBASE-23340) hmaster /hbase/replication/rs session expired (hbase replication default value is true, we don't use ) causes logcleaner can not clean oldWALs, which resulits in old
[ https://issues.apache.org/jira/browse/HBASE-23340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17655093#comment-17655093 ] Pankaj Kumar commented on HBASE-23340: -- [~psomogyi] We resolved this jira long time ago, it's better we create a new sub-task Jira to backport to branch-2.4. > hmaster /hbase/replication/rs session expired (hbase replication default > value is true, we don't use ) causes logcleaner can not clean oldWALs, which > resulits in oldWALs too large (more than 2TB) > - > > Key: HBASE-23340 > URL: https://issues.apache.org/jira/browse/HBASE-23340 > Project: HBase > Issue Type: Improvement > Components: master >Affects Versions: 3.0.0-alpha-1, 2.2.3 >Reporter: jackylau >Assignee: Bo Cui >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0 > > Attachments: Snipaste_2019-11-21_10-39-25.png, > Snipaste_2019-11-21_14-10-36.png > > > hmaster /hbase/replication/rs session expired (hbase replication default > value is true, we don't use ) causes logcleaner can not clean oldWALs, which > resulits in oldWALs too large (more than 2TB). > !Snipaste_2019-11-21_10-39-25.png! > > !Snipaste_2019-11-21_14-10-36.png! > > we can solve it by following : > 1) increase the session timeout(but i think it is not a good idea. because we > do not know how long to set is suitable) > 2) close the hbase replication. It is not a good idea too, when our user uses > this feature > 3) we need add retry times, for example when it has already happened three > times, we set the ReplicationLogCleaner and SnapShotCleaner stop > that is all my ideas, i do not konw it is suitable, If it is suitable, could > i commit a PR? > Does anynode have a good idea. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (HBASE-27158) Add namespace column family to UNDELETABLE_META_COLUMNFAMILIES
[ https://issues.apache.org/jira/browse/HBASE-27158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-27158: - Affects Version/s: 3.0.0-alpha-2 3.0.0-alpha-1 (was: 2.4.12) > Add namespace column family to UNDELETABLE_META_COLUMNFAMILIES > -- > > Key: HBASE-27158 > URL: https://issues.apache.org/jira/browse/HBASE-27158 > Project: HBase > Issue Type: Improvement > Components: proc-v2 >Affects Versions: 3.0.0-alpha-1, 3.0.0-alpha-2 >Reporter: ruanhui >Assignee: ruanhui >Priority: Minor > Fix For: 3.0.0-alpha-4 > > > If we delete the namespace family from hbase:meta, clusters can also be > problematic. So I think we should also add the namespace family to the family > list which can not be deleted. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (HBASE-26856) BufferedDataBlockEncoder.OnheapDecodedCell value can get corrupted
[
https://issues.apache.org/jira/browse/HBASE-26856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558469#comment-17558469
]
Pankaj Kumar commented on HBASE-26856:
--
Earlier OnheapDecodedCell was containing the underlying array of
valAndTagsBuffer as value array, which is being considered while adding to the
responseBlockSize
https://github.com/apache/hbase/blob/c0e7e98ec71e77a9bfccf8f59e0c7c59aa70c828/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L1328
While processing next action the if condition will be true
(responseBlockSize=124 & hbase.server.scanner.max.result.size=100)
https://github.com/apache/hbase/blob/c0e7e98ec71e77a9bfccf8f59e0c7c59aa70c828/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L724
So exception will be set.
After the PR changes, we are extracting the value array from valAndTagsBuffer
and setting the same in Cell. In TestMultiRespectsLimits#testBlockMultiLimits
PUT are done with empty values,
https://github.com/apache/hbase/blob/c0e7e98ec71e77a9bfccf8f59e0c7c59aa70c828/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestMultiRespectsLimits.java#L156
So during multi get, Cell#getValueArray() will return empty array in
RSRpcServices#addSize() and responseBlockSize will be 0. While processing next
action exception won't be set which is causing UT failure.
> BufferedDataBlockEncoder.OnheapDecodedCell value can get corrupted
> --
>
> Key: HBASE-26856
> URL: https://issues.apache.org/jira/browse/HBASE-26856
> Project: HBase
> Issue Type: Bug
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Major
> Fix For: 2.5.0, 3.0.0-alpha-3
>
>
> In our production cluster we observed the cell value is modified after
> successful scanner read. After analyzing we observed OnheapDecodedCell is not
> created properly.
> We create OnheapDecodedCell with complete valAndTagsBuffer underlying array.
> {code:java}
> return new OnheapDecodedCell(Bytes.copy(keyBuffer, 0, this.keyLength),
> currentKey.getRowLength(), currentKey.getFamilyOffset(),
> currentKey.getFamilyLength(),
> currentKey.getQualifierOffset(), currentKey.getQualifierLength(),
> currentKey.getTimestamp(), currentKey.getTypeByte(),
> valAndTagsBuffer.array(),
> valAndTagsBuffer.arrayOffset() + vOffset, this.valueLength,
> memstoreTS, tagsArray,
> tOffset, this.tagsLength);
> {code}
> Here we are passing valAndTagsBuffer.array() for value extraction.
> The underlying array will be modified if it is altered anywhere.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (HBASE-25423) Support dynamic update configurations about tracing, e.g. OpenTelemetry
[
https://issues.apache.org/jira/browse/HBASE-25423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558175#comment-17558175
]
Pankaj Kumar edited comment on HBASE-25423 at 6/23/22 5:36 PM:
---
Intially I thought enable/disable/reset opentelemetry can be done using below
APIs,
{code}
GlobalOpenTelemetry#resetForTest()
GlobalOpenTelemetry.set(OpenTelemetry.noop());
{code}
But it seems, with opentelemetry javaagent it wont be the case. Currently we
uses the OpenTelemetry javaagent where AutoConfiguredOpenTelemetrySdk &
AgentListeners are initialized during agent initialization. Since
GlobalOpenTelemetry is a singleton volatile instance, so runtime configuration
change & re-initialization will not be effective.
Also created discussion threads in OpenTelemetry,
https://github.com/open-telemetry/opentelemetry-java-instrumentation/discussions/5972
https://github.com/open-telemetry/community/discussions/1048
was (Author: pankajkumar):
Intially I thought enable/disable/reset opentelemetry can be done using below
APIs,
{code}
GlobalOpenTelemetry#resetForTest()
GlobalOpenTelemetry.set(OpenTelemetry.noop());
{code}
But it seems, with opentelemetry javaagent it wont be the case. Currently we
uses the OpenTelemetry javaagent where AutoConfiguredOpenTelemetrySdk &
AgentListeners are initialized at the beginning. Since GlobalOpenTelemetry is a
singleton volatile instance, so runtime configuration change &
re-initialization will not be effective.
Also created discussion threads in OpenTelemetry,
https://github.com/open-telemetry/opentelemetry-java-instrumentation/discussions/5972
https://github.com/open-telemetry/community/discussions/1048
> Support dynamic update configurations about tracing, e.g. OpenTelemetry
> ---
>
> Key: HBASE-25423
> URL: https://issues.apache.org/jira/browse/HBASE-25423
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiaolin Ha
>Assignee: Xiaolin Ha
>Priority: Major
>
> It is necessary to update configurations which are relevant to HTrace without
> restart the RS, such as the sampler of HTrace.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (HBASE-25423) Support dynamic update configurations about tracing, e.g. OpenTelemetry
[
https://issues.apache.org/jira/browse/HBASE-25423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17558175#comment-17558175
]
Pankaj Kumar commented on HBASE-25423:
--
Intially I thought enable/disable/reset opentelemetry can be done using below
APIs,
{code}
GlobalOpenTelemetry#resetForTest()
GlobalOpenTelemetry.set(OpenTelemetry.noop());
{code}
But it seems, with opentelemetry javaagent it wont be the case. Currently we
uses the OpenTelemetry javaagent where AutoConfiguredOpenTelemetrySdk &
AgentListeners are initialized at the beginning. Since GlobalOpenTelemetry is a
singleton volatile instance, so runtime configuration change &
re-initialization will not be effective.
Also created discussion threads in OpenTelemetry,
https://github.com/open-telemetry/opentelemetry-java-instrumentation/discussions/5972
https://github.com/open-telemetry/community/discussions/1048
> Support dynamic update configurations about tracing, e.g. OpenTelemetry
> ---
>
> Key: HBASE-25423
> URL: https://issues.apache.org/jira/browse/HBASE-25423
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiaolin Ha
>Assignee: Xiaolin Ha
>Priority: Major
>
> It is necessary to update configurations which are relevant to HTrace without
> restart the RS, such as the sampler of HTrace.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (HBASE-27001) The deleted variable cannot be printed out
[
https://issues.apache.org/jira/browse/HBASE-27001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pankaj Kumar resolved HBASE-27001.
--
Fix Version/s: 2.5.0
2.6.0
3.0.0-alpha-3
Resolution: Fixed
Thanks [~selina.yan] for the contribution.
> The deleted variable cannot be printed out
> --
>
> Key: HBASE-27001
> URL: https://issues.apache.org/jira/browse/HBASE-27001
> Project: HBase
> Issue Type: Bug
>Reporter: selina.yan
>Assignee: selina.yan
>Priority: Minor
> Fix For: 2.5.0, 2.6.0, 3.0.0-alpha-3
>
>
> In the deleteAction method of CleanerChore class, the delete variable cannot
> be printed out
> {code:java}
> LOG.trace("Finish deleting {} under {}, deleted=", type, dir, deleted); {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (HBASE-27105) HBaseInterClusterReplicationEndpoint should honor replication adaptive timeout
[ https://issues.apache.org/jira/browse/HBASE-27105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-27105: - Fix Version/s: 2.5.0 2.6.0 Resolution: Fixed Status: Resolved (was: Patch Available) Pushed to branch-2.5+. Thanks [~wchevreuil] for the review. > HBaseInterClusterReplicationEndpoint should honor replication adaptive timeout > -- > > Key: HBASE-27105 > URL: https://issues.apache.org/jira/browse/HBASE-27105 > Project: HBase > Issue Type: Bug > Components: Replication >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 2.5.0, 2.6.0, 3.0.0-alpha-4 > > > HBASE-23293 introduced replication.source.shipedits.timeout which is > adaptive, ReplicationSourceShipper#shipEdits() set the adaptive timeout based > on retries. But on CallTimeoutException in > HBaseInterClusterReplicationEndpoint#replicate(), it keep retrying the > replication after sleep with same timeout value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (HBASE-27105) HBaseInterClusterReplicationEndpoint should honor replication adaptive timeout
[ https://issues.apache.org/jira/browse/HBASE-27105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17557867#comment-17557867 ] Pankaj Kumar commented on HBASE-27105: -- Pushed to master branch. Can't cherry-pick the changes, raised PR for branch-2. > HBaseInterClusterReplicationEndpoint should honor replication adaptive timeout > -- > > Key: HBASE-27105 > URL: https://issues.apache.org/jira/browse/HBASE-27105 > Project: HBase > Issue Type: Bug > Components: Replication >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 3.0.0-alpha-4 > > > HBASE-23293 introduced replication.source.shipedits.timeout which is > adaptive, ReplicationSourceShipper#shipEdits() set the adaptive timeout based > on retries. But on CallTimeoutException in > HBaseInterClusterReplicationEndpoint#replicate(), it keep retrying the > replication after sleep with same timeout value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (HBASE-26125) Backport HBASE-25401 "Add trace support for async call in rpc client" to branch-2
[
https://issues.apache.org/jira/browse/HBASE-26125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553529#comment-17553529
]
Pankaj Kumar commented on HBASE-26125:
--
We shouldn't have removed below API in branch-2, WDYT [~taklwu] [~zhangduo] ?
{code:java}
/**
* Keep for backward compatibility.
* @deprecated As of release 2.0, this will be removed in HBase 3.0
*/
@Deprecated
public ServerCall getCall() {
return (ServerCall) call;
}
{code}
> Backport HBASE-25401 "Add trace support for async call in rpc client" to
> branch-2
> -
>
> Key: HBASE-26125
> URL: https://issues.apache.org/jira/browse/HBASE-26125
> Project: HBase
> Issue Type: Sub-task
> Components: tracing
>Affects Versions: 2.5.0
>Reporter: Tak-Lon (Stephen) Wu
>Assignee: Tak-Lon (Stephen) Wu
>Priority: Major
> Fix For: 2.5.0
>
>
> [2/17 commits of
> HBASE-22120|https://github.com/apache/hbase/pull/2901/commits], original
> commit of HBASE-25401 was
> [https://github.com/apache/hbase/commit/242028671535dfed67ec13d9ed0d6067f3ccfd04]
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (HBASE-26856) BufferedDataBlockEncoder.OnheapDecodedCell value can get corrupted
[
https://issues.apache.org/jira/browse/HBASE-26856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553475#comment-17553475
]
Pankaj Kumar commented on HBASE-26856:
--
Sorry [~ndimiduk], missed spotless:apply. [~arshad.mohammad] please raise the
PR again.
> BufferedDataBlockEncoder.OnheapDecodedCell value can get corrupted
> --
>
> Key: HBASE-26856
> URL: https://issues.apache.org/jira/browse/HBASE-26856
> Project: HBase
> Issue Type: Bug
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Major
> Fix For: 2.6.0, 3.0.0-alpha-3, 2.4.13, 2.5.1
>
>
> In our production cluster we observed the cell value is modified after
> successful scanner read. After analyzing we observed OnheapDecodedCell is not
> created properly.
> We create OnheapDecodedCell with complete valAndTagsBuffer underlying array.
> {code:java}
> return new OnheapDecodedCell(Bytes.copy(keyBuffer, 0, this.keyLength),
> currentKey.getRowLength(), currentKey.getFamilyOffset(),
> currentKey.getFamilyLength(),
> currentKey.getQualifierOffset(), currentKey.getQualifierLength(),
> currentKey.getTimestamp(), currentKey.getTypeByte(),
> valAndTagsBuffer.array(),
> valAndTagsBuffer.arrayOffset() + vOffset, this.valueLength,
> memstoreTS, tagsArray,
> tOffset, this.tagsLength);
> {code}
> Here we are passing valAndTagsBuffer.array() for value extraction.
> The underlying array will be modified if it is altered anywhere.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (HBASE-27105) HBaseInterClusterReplicationEndpoint should honor replication adaptive timeout
[ https://issues.apache.org/jira/browse/HBASE-27105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-27105: - Fix Version/s: 3.0.0-alpha-3 Status: Patch Available (was: In Progress) > HBaseInterClusterReplicationEndpoint should honor replication adaptive timeout > -- > > Key: HBASE-27105 > URL: https://issues.apache.org/jira/browse/HBASE-27105 > Project: HBase > Issue Type: Bug > Components: Replication >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 3.0.0-alpha-3 > > > HBASE-23293 introduced replication.source.shipedits.timeout which is > adaptive, ReplicationSourceShipper#shipEdits() set the adaptive timeout based > on retries. But on CallTimeoutException in > HBaseInterClusterReplicationEndpoint#replicate(), it keep retrying the > replication after sleep with same timeout value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Work started] (HBASE-27105) HBaseInterClusterReplicationEndpoint should honor replication adaptive timeout
[ https://issues.apache.org/jira/browse/HBASE-27105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-27105 started by Pankaj Kumar. > HBaseInterClusterReplicationEndpoint should honor replication adaptive timeout > -- > > Key: HBASE-27105 > URL: https://issues.apache.org/jira/browse/HBASE-27105 > Project: HBase > Issue Type: Bug > Components: Replication >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > > HBASE-23293 introduced replication.source.shipedits.timeout which is > adaptive, ReplicationSourceShipper#shipEdits() set the adaptive timeout based > on retries. But on CallTimeoutException in > HBaseInterClusterReplicationEndpoint#replicate(), it keep retrying the > replication after sleep with same timeout value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (HBASE-27105) HBaseInterClusterReplicationEndpoint should honor replication adaptive timeout
Pankaj Kumar created HBASE-27105: Summary: HBaseInterClusterReplicationEndpoint should honor replication adaptive timeout Key: HBASE-27105 URL: https://issues.apache.org/jira/browse/HBASE-27105 Project: HBase Issue Type: Bug Components: Replication Reporter: Pankaj Kumar Assignee: Pankaj Kumar HBASE-23293 introduced replication.source.shipedits.timeout which is adaptive, ReplicationSourceShipper#shipEdits() set the adaptive timeout based on retries. But on CallTimeoutException in HBaseInterClusterReplicationEndpoint#replicate(), it keep retrying the replication after sleep with same timeout value. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (HBASE-24337) Backport HBASE-23968 to branch-2
[ https://issues.apache.org/jira/browse/HBASE-24337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar reassigned HBASE-24337: Assignee: Minwoo Kang (was: Pankaj Kumar) > Backport HBASE-23968 to branch-2 > > > Key: HBASE-24337 > URL: https://issues.apache.org/jira/browse/HBASE-24337 > Project: HBase > Issue Type: Sub-task >Reporter: Minwoo Kang >Assignee: Minwoo Kang >Priority: Minor > Fix For: 2.5.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (HBASE-24337) Backport HBASE-23968 to branch-2
[ https://issues.apache.org/jira/browse/HBASE-24337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar reassigned HBASE-24337: Assignee: Pankaj Kumar (was: Minwoo Kang) > Backport HBASE-23968 to branch-2 > > > Key: HBASE-24337 > URL: https://issues.apache.org/jira/browse/HBASE-24337 > Project: HBase > Issue Type: Sub-task >Reporter: Minwoo Kang >Assignee: Pankaj Kumar >Priority: Minor > Fix For: 2.5.0 > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (HBASE-27047) Fix typo for metric drainingRegionServers
[ https://issues.apache.org/jira/browse/HBASE-27047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17540817#comment-17540817 ] Pankaj Kumar commented on HBASE-27047: -- [~tomscut] Please update release notes for this incompatible change. > Fix typo for metric drainingRegionServers > - > > Key: HBASE-27047 > URL: https://issues.apache.org/jira/browse/HBASE-27047 > Project: HBase > Issue Type: Bug > Components: metrics >Reporter: Tao Li >Assignee: Tao Li >Priority: Minor > Fix For: 2.5.0, 3.0.0-alpha-3, 2.4.13 > > > Fix typo for metric drainingRegionServers. `draininigRegionServers` -> > `drainingRegionServers`. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (HBASE-27001) The deleted variable cannot be printed out
[
https://issues.apache.org/jira/browse/HBASE-27001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17540061#comment-17540061
]
Pankaj Kumar commented on HBASE-27001:
--
Thanks for reporting this issue, please raise a PR.
> The deleted variable cannot be printed out
> --
>
> Key: HBASE-27001
> URL: https://issues.apache.org/jira/browse/HBASE-27001
> Project: HBase
> Issue Type: Bug
>Reporter: selina.yan
>Assignee: selina.yan
>Priority: Minor
>
> In the deleteAction method of CleanerChore class, the delete variable cannot
> be printed out
> {code:java}
> LOG.trace("Finish deleting {} under {}, deleted=", type, dir, deleted); {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (HBASE-26856) BufferedDataBlockEncoder.OnheapDecodedCell value can get corrupted
[
https://issues.apache.org/jira/browse/HBASE-26856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pankaj Kumar resolved HBASE-26856.
--
Fix Version/s: 2.5.0
2.6.0
3.0.0-alpha-3
2.4.13
Resolution: Fixed
Pushed to branch-2.4+.
Thanks [~arshad.mohammad] for the contribution & [~apurtell] for reviewing.
> BufferedDataBlockEncoder.OnheapDecodedCell value can get corrupted
> --
>
> Key: HBASE-26856
> URL: https://issues.apache.org/jira/browse/HBASE-26856
> Project: HBase
> Issue Type: Bug
>Reporter: Mohammad Arshad
>Assignee: Mohammad Arshad
>Priority: Major
> Fix For: 2.5.0, 2.6.0, 3.0.0-alpha-3, 2.4.13
>
>
> In our production cluster we observed the cell value is modified after
> successful scanner read. After analyzing we observed OnheapDecodedCell is not
> created properly.
> We create OnheapDecodedCell with complete valAndTagsBuffer underlying array.
> {code:java}
> return new OnheapDecodedCell(Bytes.copy(keyBuffer, 0, this.keyLength),
> currentKey.getRowLength(), currentKey.getFamilyOffset(),
> currentKey.getFamilyLength(),
> currentKey.getQualifierOffset(), currentKey.getQualifierLength(),
> currentKey.getTimestamp(), currentKey.getTypeByte(),
> valAndTagsBuffer.array(),
> valAndTagsBuffer.arrayOffset() + vOffset, this.valueLength,
> memstoreTS, tagsArray,
> tOffset, this.tagsLength);
> {code}
> Here we are passing valAndTagsBuffer.array() for value extraction.
> The underlying array will be modified if it is altered anywhere.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (HBASE-27032) The draining region servers metric description is incorrect
[ https://issues.apache.org/jira/browse/HBASE-27032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537949#comment-17537949 ] Pankaj Kumar commented on HBASE-27032: -- [~tomscut] You can raise another JIRA for correcting the typo mistake in metric name. > The draining region servers metric description is incorrect > --- > > Key: HBASE-27032 > URL: https://issues.apache.org/jira/browse/HBASE-27032 > Project: HBase > Issue Type: Bug >Reporter: Tao Li >Assignee: Tao Li >Priority: Minor > Fix For: 2.5.0, 2.6.0, 3.0.0-alpha-3, 2.4.13 > > > The draining region servers metric description is incorrect. > Fixed the description and added unit test. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (HBASE-27032) The draining region servers metric description is incorrect
[ https://issues.apache.org/jira/browse/HBASE-27032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar resolved HBASE-27032. -- Fix Version/s: 2.5.0 2.6.0 3.0.0-alpha-3 2.4.13 Resolution: Fixed Pushed to branch-2.4+. Thanks [~tomscut] for the contribution and [~Xiaolin Ha] for reviewing. > The draining region servers metric description is incorrect > --- > > Key: HBASE-27032 > URL: https://issues.apache.org/jira/browse/HBASE-27032 > Project: HBase > Issue Type: Bug >Reporter: Tao Li >Assignee: Tao Li >Priority: Minor > Fix For: 2.5.0, 2.6.0, 3.0.0-alpha-3, 2.4.13 > > > The draining region servers metric description is incorrect. > Fixed the description and added unit test. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (HBASE-25423) Support dynamic update configurations about tracing, e.g. OpenTelemetry
[ https://issues.apache.org/jira/browse/HBASE-25423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528126#comment-17528126 ] Pankaj Kumar commented on HBASE-25423: -- [~Xiaolin Ha] Are you working on this? If not, I can take this. > Support dynamic update configurations about tracing, e.g. OpenTelemetry > --- > > Key: HBASE-25423 > URL: https://issues.apache.org/jira/browse/HBASE-25423 > Project: HBase > Issue Type: Improvement >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > > It is necessary to update configurations which are relevant to HTrace without > restart the RS, such as the sampler of HTrace. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (HBASE-26964) Fix java import in admin.rb
[
https://issues.apache.org/jira/browse/HBASE-26964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pankaj Kumar resolved HBASE-26964.
--
Fix Version/s: 3.0.0-alpha-3
Resolution: Fixed
Thanks [~liangxs] for the contribution.
> Fix java import in admin.rb
> ---
>
> Key: HBASE-26964
> URL: https://issues.apache.org/jira/browse/HBASE-26964
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Xuesen Liang
>Assignee: Xuesen Liang
>Priority: Minor
> Fix For: 3.0.0-alpha-3
>
>
> The java_import for MobCompactPartitionPolicy in admin.rb is missed, which
> cause an error message for creating table.
> {code:bash}
> hbase:006:0> create 't2', {NAME => 'f', IS_MOB => true, MOB_THRESHOLD =>
> 100, MOB_COMPACT_PARTITION_POLICY => 'weekly'}
> ERROR: uninitialized constant Hbase::Admin::MobCompactPartitionPolicy
> Did you mean? Hbase::Admin::MOB_COMPACT_PARTITION_POLICY
> For usage try 'help "create"'
> Took 0.6897 seconds
> hbase:007:0> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (HBASE-26944) Possible resource leak while creating new region scanner
[ https://issues.apache.org/jira/browse/HBASE-26944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-26944: - Fix Version/s: 2.5.0 2.6.0 2.4.12 Resolution: Fixed Status: Resolved (was: Patch Available) Pushed to branch-2.4+. Thank [~zhangduo] for the review. > Possible resource leak while creating new region scanner > > > Key: HBASE-26944 > URL: https://issues.apache.org/jira/browse/HBASE-26944 > Project: HBase > Issue Type: Bug >Affects Versions: 2.5.0, 3.0.0-alpha-2, 2.6.0, 2.4.11 >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 2.5.0, 2.6.0, 3.0.0-alpha-3, 2.4.12 > > > We will miss to close the region scanner when RegionObserver#postScannerOpen > impl throws exception. > https://github.com/apache/hbase/blob/1d8a5bf0e3246a1df11f0aa9215f29e6fbc4ecb1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L3203 > https://github.com/apache/hbase/blob/1d8a5bf0e3246a1df11f0aa9215f29e6fbc4ecb1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L3207 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (HBASE-26944) Possible resource leak while creating new region scanner
[ https://issues.apache.org/jira/browse/HBASE-26944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-26944: - Fix Version/s: 3.0.0-alpha-3 Status: Patch Available (was: In Progress) > Possible resource leak while creating new region scanner > > > Key: HBASE-26944 > URL: https://issues.apache.org/jira/browse/HBASE-26944 > Project: HBase > Issue Type: Bug >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 3.0.0-alpha-3 > > > We will miss to close the region scanner when RegionObserver#postScannerOpen > impl throws exception. > https://github.com/apache/hbase/blob/1d8a5bf0e3246a1df11f0aa9215f29e6fbc4ecb1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L3203 > https://github.com/apache/hbase/blob/1d8a5bf0e3246a1df11f0aa9215f29e6fbc4ecb1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L3207 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (HBASE-26944) Possible resource leak while creating new region scanner
[ https://issues.apache.org/jira/browse/HBASE-26944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-26944: - Affects Version/s: 2.4.11 3.0.0-alpha-2 2.5.0 2.6.0 > Possible resource leak while creating new region scanner > > > Key: HBASE-26944 > URL: https://issues.apache.org/jira/browse/HBASE-26944 > Project: HBase > Issue Type: Bug >Affects Versions: 2.5.0, 3.0.0-alpha-2, 2.6.0, 2.4.11 >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 3.0.0-alpha-3 > > > We will miss to close the region scanner when RegionObserver#postScannerOpen > impl throws exception. > https://github.com/apache/hbase/blob/1d8a5bf0e3246a1df11f0aa9215f29e6fbc4ecb1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L3203 > https://github.com/apache/hbase/blob/1d8a5bf0e3246a1df11f0aa9215f29e6fbc4ecb1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L3207 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work started] (HBASE-26944) Possible resource leak while creating new region scanner
[ https://issues.apache.org/jira/browse/HBASE-26944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-26944 started by Pankaj Kumar. > Possible resource leak while creating new region scanner > > > Key: HBASE-26944 > URL: https://issues.apache.org/jira/browse/HBASE-26944 > Project: HBase > Issue Type: Bug >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > > We will miss to close the region scanner when RegionObserver#postScannerOpen > impl throws exception. > https://github.com/apache/hbase/blob/1d8a5bf0e3246a1df11f0aa9215f29e6fbc4ecb1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L3203 > https://github.com/apache/hbase/blob/1d8a5bf0e3246a1df11f0aa9215f29e6fbc4ecb1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L3207 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (HBASE-26944) Possible resource leak while creating new region scanner
Pankaj Kumar created HBASE-26944: Summary: Possible resource leak while creating new region scanner Key: HBASE-26944 URL: https://issues.apache.org/jira/browse/HBASE-26944 Project: HBase Issue Type: Bug Reporter: Pankaj Kumar Assignee: Pankaj Kumar We will miss to close the region scanner when RegionObserver#postScannerOpen impl throws exception. https://github.com/apache/hbase/blob/1d8a5bf0e3246a1df11f0aa9215f29e6fbc4ecb1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L3203 https://github.com/apache/hbase/blob/1d8a5bf0e3246a1df11f0aa9215f29e6fbc4ecb1/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L3207 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (HBASE-26885) The TRSP should not go on when it get a bogus server name from AM
[
https://issues.apache.org/jira/browse/HBASE-26885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17513429#comment-17513429
]
Pankaj Kumar commented on HBASE-26885:
--
Nice finding [~filtertip], better to avoid OpenRegionProcedure when no server
available.
> The TRSP should not go on when it get a bogus server name from AM
> -
>
> Key: HBASE-26885
> URL: https://issues.apache.org/jira/browse/HBASE-26885
> Project: HBase
> Issue Type: Improvement
> Components: proc-v2
>Reporter: Zheng Wang
>Assignee: Zheng Wang
>Priority: Major
>
> Currently it will submit lots of unnecessary OpenRegionProcedure by retry.
> Related log looks like below, 'localhost,1,1' is the bogus server:
> {code:java}
> 2022-03-22 10:17:48,301 WARN [PEWorker-8]
> assignment.RegionRemoteProcedureBase: Can not add remote operation pid=17952,
> ppid=17951, state=RUNNABLE, locked=true;
> org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure for region
> {ENCODED => 490391c232c7aa13f7e0d50bfe1f7235, NAME =>
> 'TestTable1,002497747,1647568640784.490391c232c7aa13f7e0d50bfe1f7235.',
> STARTKEY => '002497747', ENDKEY => ''} to server
> localhost,1,1, this usually because the server is alread dead, give up and
> mark the procedure as complete, the parent procedure will take care of this.
> org.apache.hadoop.hbase.procedure2.NoServerDispatchException: localhost,1,1;
> pid=17952, ppid=17951, state=RUNNABLE, locked=true;
> org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure
> at
> org.apache.hadoop.hbase.procedure2.RemoteProcedureDispatcher.addOperationToNode(RemoteProcedureDispatcher.java:168)
> at
> org.apache.hadoop.hbase.master.assignment.RegionRemoteProcedureBase.execute(RegionRemoteProcedureBase.java:285)
> at
> org.apache.hadoop.hbase.master.assignment.RegionRemoteProcedureBase.execute(RegionRemoteProcedureBase.java:58)
> at
> org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:962)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1648)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1395)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.access$1100(ProcedureExecutor.java:78)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor$WorkerThread.run(ProcedureExecutor.java:1965)
> 2022-03-22 10:17:48,301 DEBUG [PEWorker-8] procedure2.RootProcedureState: Add
> procedure pid=17952, ppid=17951, state=SUCCESS, locked=true;
> org.apache.hadoop.hbase.master.assignment.OpenRegionProcedure as the 8th
> rollback step {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (HBASE-26746) Update protobuf-java to 3.19.4
[ https://issues.apache.org/jira/browse/HBASE-26746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489717#comment-17489717 ] Pankaj Kumar commented on HBASE-26746: -- Got it.. > Update protobuf-java to 3.19.4 > -- > > Key: HBASE-26746 > URL: https://issues.apache.org/jira/browse/HBASE-26746 > Project: HBase > Issue Type: Bug > Components: Protobufs, thirdparty >Reporter: Pankaj Kumar >Assignee: Sean Busbey >Priority: Minor > > Refer, > https://nvd.nist.gov/vuln/detail/CVE-2021-22569 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (HBASE-26746) Update protobuf-java to 3.19.4
[ https://issues.apache.org/jira/browse/HBASE-26746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489237#comment-17489237 ] Pankaj Kumar edited comment on HBASE-26746 at 2/9/22, 4:43 AM: --- Thanks [~busbey] for taking this up. This issue is applicable for branch-2 as well where we have depependecy, see . was (Author: pankajkumar): This issue is applicable for branch-2 as well where we have depependecy, see . > Update protobuf-java to 3.19.4 > -- > > Key: HBASE-26746 > URL: https://issues.apache.org/jira/browse/HBASE-26746 > Project: HBase > Issue Type: Bug > Components: Protobufs, thirdparty >Reporter: Pankaj Kumar >Assignee: Sean Busbey >Priority: Minor > > Refer, > https://nvd.nist.gov/vuln/detail/CVE-2021-22569 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (HBASE-26746) Update protobuf-java to 3.19.4
[ https://issues.apache.org/jira/browse/HBASE-26746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489237#comment-17489237 ] Pankaj Kumar commented on HBASE-26746: -- This issue is applicable for branch-2 as well where we have depependecy, see . > Update protobuf-java to 3.19.4 > -- > > Key: HBASE-26746 > URL: https://issues.apache.org/jira/browse/HBASE-26746 > Project: HBase > Issue Type: Bug > Components: Protobufs, thirdparty >Reporter: Pankaj Kumar >Assignee: Sean Busbey >Priority: Minor > > Refer, > https://nvd.nist.gov/vuln/detail/CVE-2021-22569 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (HBASE-26746) Protobuf jar is vulnerable with CVE-2021-22569
Pankaj Kumar created HBASE-26746: Summary: Protobuf jar is vulnerable with CVE-2021-22569 Key: HBASE-26746 URL: https://issues.apache.org/jira/browse/HBASE-26746 Project: HBase Issue Type: Bug Components: Protobufs Reporter: Pankaj Kumar Refer, https://nvd.nist.gov/vuln/detail/CVE-2021-22569 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (HBASE-26591) [hbase-thirdparty] Make a 4.0.1 release for hbase-thirdparty
[
https://issues.apache.org/jira/browse/HBASE-26591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461184#comment-17461184
]
Pankaj Kumar commented on HBASE-26591:
--
Yes it is causing compilation issue. Thanks [~zhangduo]
> [hbase-thirdparty] Make a 4.0.1 release for hbase-thirdparty
>
>
> Key: HBASE-26591
> URL: https://issues.apache.org/jira/browse/HBASE-26591
> Project: HBase
> Issue Type: Umbrella
> Components: community, hbase-thirdparty
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
>
> Copy the content in mailing list here
> {noformat}
> Oh, when backporting to branch-2, I found that there is a serious problem
> with this release.
> We do not include the proto files in protobuf-java jar, I think this is a
> side effect of HBASE-26496.
> And on the master branch, hbase-shaded-protobuf also pulls in protobuf-java
> 3.19.1 dependency so everything is fine. But for branch-2, we will need to
> depend on protobuf 2.5.0 then the compilation is broken.
> Anyway, we should include the proto files in hbase-shaded-protobuf, and also
> we should not pull in the original protobuf-java dependency.
> Let me fix this and do a 4.0.1 release.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (HBASE-26320) Separate Log Cleaner DirScanPool to prevent the OLDWALs from filling up the disk when archive is large
[ https://issues.apache.org/jira/browse/HBASE-26320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17440955#comment-17440955 ] Pankaj Kumar commented on HBASE-26320: -- Thanks [~zyork] for merging this in master branch, are you planning to port it to branch-2/1? > Separate Log Cleaner DirScanPool to prevent the OLDWALs from filling up the > disk when archive is large > -- > > Key: HBASE-26320 > URL: https://issues.apache.org/jira/browse/HBASE-26320 > Project: HBase > Issue Type: Improvement > Components: Operability >Affects Versions: 1.7.1, 2.4.6 >Reporter: Zach York >Assignee: Zach York >Priority: Major > > We currently share the DirScanPool (threadpool for scanning for files to > delete in the OldLogs and archive directories) between the LogCleaner and > HFileCleaner. This means that if the archive directory is large/has lots of > files/directories, the threads can get stuck scanning through the archive > directory, starving the LogCleaner. This is especially apparent on S3 where > list can be slower than on HDFS. > This JIRA creates separate DirScanPools for the LogCleaner and HFileCleaner -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (HBASE-26320) Separate Log Cleaner DirScanPool to prevent the OLDWALs from filling up the disk when archive is large
[ https://issues.apache.org/jira/browse/HBASE-26320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424087#comment-17424087 ] Pankaj Kumar commented on HBASE-26320: -- Thanks [~zyork] for bringing this, recently we faced this problem in one of our production environment where archived and old WAL files size reaches to several TBs due to slow directory scan, we had to modify multiple configs to speed up the cleaning. > Separate Log Cleaner DirScanPool to prevent the OLDWALs from filling up the > disk when archive is large > -- > > Key: HBASE-26320 > URL: https://issues.apache.org/jira/browse/HBASE-26320 > Project: HBase > Issue Type: Improvement > Components: Operability >Affects Versions: 1.7.1, 2.4.6 >Reporter: Zach York >Assignee: Zach York >Priority: Major > > We currently share the DirScanPool (threadpool for scanning for files to > delete in the OldLogs and archive directories) between the LogCleaner and > HFileCleaner. This means that if the archive directory is large/has lots of > files/directories, the threads can get stuck scanning through the archive > directory, starving the LogCleaner. This is especially apparent on S3 where > list can be slower than on HDFS. > This JIRA creates separate DirScanPools for the LogCleaner and HFileCleaner -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-26292) Update jetty version to fix CVE-2021-34429
Pankaj Kumar created HBASE-26292: Summary: Update jetty version to fix CVE-2021-34429 Key: HBASE-26292 URL: https://issues.apache.org/jira/browse/HBASE-26292 Project: HBase Issue Type: Bug Components: dependencies, thirdparty Reporter: Pankaj Kumar Assignee: Pankaj Kumar CVE-2021-34429 issue is fixed in Jetty 9.4.43.v20210629 and we are using jetty 9.4.41.v20210516. https://github.com/apache/hbase-thirdparty/blob/c28a235236b9f63ec1d36431e5d1b6c8d4b66d90/pom.xml#L139 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26228) updateRSGroupConfig operation should be authorized by AccessController
[ https://issues.apache.org/jira/browse/HBASE-26228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412005#comment-17412005 ] Pankaj Kumar commented on HBASE-26228: -- Thank you so much [~zhangduo] & [~zhaobaiqiang] for reviewing and merging the PR. > updateRSGroupConfig operation should be authorized by AccessController > --- > > Key: HBASE-26228 > URL: https://issues.apache.org/jira/browse/HBASE-26228 > Project: HBase > Issue Type: Bug > Components: acl, rsgroup >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 3.0.0-alpha-2 > > > Currently there is no ACL check for Admin#updateRSGroupConfig() operation. > AccessController should implement MasterObserver#preUpdateRSGroupConfig(). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26227) Forward port HBASE-26223 test code to branch-2.4+
[ https://issues.apache.org/jira/browse/HBASE-26227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405862#comment-17405862 ] Pankaj Kumar commented on HBASE-26227: -- Thanks [~zhangduo] for the review and merge. > Forward port HBASE-26223 test code to branch-2.4+ > - > > Key: HBASE-26227 > URL: https://issues.apache.org/jira/browse/HBASE-26227 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 2.5.0, 3.0.0-alpha-2, 2.4.6 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-26227) Forward port HBASE-26223 test code to branch-2.4+
[ https://issues.apache.org/jira/browse/HBASE-26227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-26227: - Fix Version/s: 3.0.0-alpha-2 Status: Patch Available (was: In Progress) > Forward port HBASE-26223 test code to branch-2.4+ > - > > Key: HBASE-26227 > URL: https://issues.apache.org/jira/browse/HBASE-26227 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 3.0.0-alpha-2 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26228) updateRSGroupConfig operation should be authorized by AccessController
[ https://issues.apache.org/jira/browse/HBASE-26228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405438#comment-17405438 ] Pankaj Kumar commented on HBASE-26228: -- PR Link: https://github.com/apache/hbase/pull/3633 > updateRSGroupConfig operation should be authorized by AccessController > --- > > Key: HBASE-26228 > URL: https://issues.apache.org/jira/browse/HBASE-26228 > Project: HBase > Issue Type: Bug > Components: acl, rsgroup >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 3.0.0-alpha-2 > > > Currently there is no ACL check for Admin#updateRSGroupConfig() operation. > AccessController should implement MasterObserver#preUpdateRSGroupConfig(). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-26228) updateRSGroupConfig operation should be authorized by AccessController
[ https://issues.apache.org/jira/browse/HBASE-26228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-26228: - Fix Version/s: 3.0.0-alpha-2 Status: Patch Available (was: In Progress) > updateRSGroupConfig operation should be authorized by AccessController > --- > > Key: HBASE-26228 > URL: https://issues.apache.org/jira/browse/HBASE-26228 > Project: HBase > Issue Type: Bug > Components: acl, rsgroup >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > Fix For: 3.0.0-alpha-2 > > > Currently there is no ACL check for Admin#updateRSGroupConfig() operation. > AccessController should implement MasterObserver#preUpdateRSGroupConfig(). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HBASE-26228) updateRSGroupConfig operation should be authorized by AccessController
[ https://issues.apache.org/jira/browse/HBASE-26228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-26228 started by Pankaj Kumar. > updateRSGroupConfig operation should be authorized by AccessController > --- > > Key: HBASE-26228 > URL: https://issues.apache.org/jira/browse/HBASE-26228 > Project: HBase > Issue Type: Bug > Components: acl, rsgroup >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > > Currently there is no ACL check for Admin#updateRSGroupConfig() operation. > AccessController should implement MasterObserver#preUpdateRSGroupConfig(). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-26228) updateRSGroupConfig operation should be authorized by AccessController
[ https://issues.apache.org/jira/browse/HBASE-26228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-26228: - Description: Currently there is no ACL check for Admin#updateRSGroupConfig() operation. AccessController should implement MasterObserver#preUpdateRSGroupConfig(). (was: Currently there is no ACL check Admin#updateRSGroupConfig() operation. AccessController should implement MasterObserver#preUpdateRSGroupConfig()) > updateRSGroupConfig operation should be authorized by AccessController > --- > > Key: HBASE-26228 > URL: https://issues.apache.org/jira/browse/HBASE-26228 > Project: HBase > Issue Type: Bug > Components: acl, rsgroup >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > > Currently there is no ACL check for Admin#updateRSGroupConfig() operation. > AccessController should implement MasterObserver#preUpdateRSGroupConfig(). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-26228) updateRSGroupConfig operation should be authorized by AccessController
Pankaj Kumar created HBASE-26228: Summary: updateRSGroupConfig operation should be authorized by AccessController Key: HBASE-26228 URL: https://issues.apache.org/jira/browse/HBASE-26228 Project: HBase Issue Type: Bug Components: acl, rsgroup Reporter: Pankaj Kumar Assignee: Pankaj Kumar Currently there is no ACL check Admin#updateRSGroupConfig() operation. AccessController should implement MasterObserver#preUpdateRSGroupConfig() -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26227) Forward port HBASE-26223 test code to branch-2.4+
[ https://issues.apache.org/jira/browse/HBASE-26227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405427#comment-17405427 ] Pankaj Kumar commented on HBASE-26227: -- PR link: https://github.com/apache/hbase/pull/3632 > Forward port HBASE-26223 test code to branch-2.4+ > - > > Key: HBASE-26227 > URL: https://issues.apache.org/jira/browse/HBASE-26227 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HBASE-26227) Forward port HBASE-26223 test code to branch-2.4+
[ https://issues.apache.org/jira/browse/HBASE-26227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-26227 started by Pankaj Kumar. > Forward port HBASE-26223 test code to branch-2.4+ > - > > Key: HBASE-26227 > URL: https://issues.apache.org/jira/browse/HBASE-26227 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-26227) Forward port HBASE-26223 test code to branch-2.4+
[ https://issues.apache.org/jira/browse/HBASE-26227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-26227: - Component/s: test > Forward port HBASE-26223 test code to branch-2.4+ > - > > Key: HBASE-26227 > URL: https://issues.apache.org/jira/browse/HBASE-26227 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-26227) Forward port HBASE-26223 test code to branch-2.4+
Pankaj Kumar created HBASE-26227: Summary: Forward port HBASE-26223 test code to branch-2.4+ Key: HBASE-26227 URL: https://issues.apache.org/jira/browse/HBASE-26227 Project: HBase Issue Type: Sub-task Reporter: Pankaj Kumar Assignee: Pankaj Kumar -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-26223) Splitted WAL files are deleted rather than archiving
[ https://issues.apache.org/jira/browse/HBASE-26223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar resolved HBASE-26223. -- Fix Version/s: 2.3.7 Resolution: Fixed > Splitted WAL files are deleted rather than archiving > > > Key: HBASE-26223 > URL: https://issues.apache.org/jira/browse/HBASE-26223 > Project: HBase > Issue Type: Bug > Components: wal >Affects Versions: 2.2.7, 2.3.6 >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Critical > Fix For: 2.3.7 > > > When procedure based WAL split is enabled, we are deleting splitted WAL files > immediately rather than moving to archive path. > > https://github.com/apache/hbase/blob/67e9c6422d6d5b39586ffe529f55b76d8b8939ff/hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/SplitWALRemoteProcedure.java#L99 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26223) Splitted WAL files are deleted rather than archiving
[ https://issues.apache.org/jira/browse/HBASE-26223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17405417#comment-17405417 ] Pankaj Kumar commented on HBASE-26223: -- Pushed to branch-2.3. Thanks [~zhangduo] & [~apurt...@yahoo.com] for the review. > Splitted WAL files are deleted rather than archiving > > > Key: HBASE-26223 > URL: https://issues.apache.org/jira/browse/HBASE-26223 > Project: HBase > Issue Type: Bug > Components: wal >Affects Versions: 2.2.7, 2.3.6 >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Critical > > When procedure based WAL split is enabled, we are deleting splitted WAL files > immediately rather than moving to archive path. > > https://github.com/apache/hbase/blob/67e9c6422d6d5b39586ffe529f55b76d8b8939ff/hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/SplitWALRemoteProcedure.java#L99 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-26223) Splitted WAL files are deleted rather than archiving
[ https://issues.apache.org/jira/browse/HBASE-26223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-26223: - Summary: Splitted WAL files are deleted rather than archiving (was: Splitted WAL files are deleted rather than archiving them) > Splitted WAL files are deleted rather than archiving > > > Key: HBASE-26223 > URL: https://issues.apache.org/jira/browse/HBASE-26223 > Project: HBase > Issue Type: Bug > Components: wal >Affects Versions: 2.2.7, 2.3.6 >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Critical > > When procedure based WAL split is enabled, we are deleting splitted WAL files > immediately rather than moving to archive path. > > https://github.com/apache/hbase/blob/67e9c6422d6d5b39586ffe529f55b76d8b8939ff/hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/SplitWALRemoteProcedure.java#L99 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26223) Splitted WAL files are deleted rather than archiving them
[ https://issues.apache.org/jira/browse/HBASE-26223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404496#comment-17404496 ] Pankaj Kumar commented on HBASE-26223: -- Not complete backport, HBASE-24632 enables procedure-based WAL split by default which we shouldn't do for patch releases. I will raise PR with the required changes only. > Splitted WAL files are deleted rather than archiving them > - > > Key: HBASE-26223 > URL: https://issues.apache.org/jira/browse/HBASE-26223 > Project: HBase > Issue Type: Bug > Components: wal >Affects Versions: 2.2.7, 2.3.6 >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Critical > > When procedure based WAL split is enabled, we are deleting splitted WAL files > immediately rather than moving to archive path. > > https://github.com/apache/hbase/blob/67e9c6422d6d5b39586ffe529f55b76d8b8939ff/hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/SplitWALRemoteProcedure.java#L99 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26223) Splitted WAL files are deleted rather than archiving them
[ https://issues.apache.org/jira/browse/HBASE-26223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404472#comment-17404472 ] Pankaj Kumar commented on HBASE-26223: -- HBASE-24632 already fixed this issue in branch-2.4+. > Splitted WAL files are deleted rather than archiving them > - > > Key: HBASE-26223 > URL: https://issues.apache.org/jira/browse/HBASE-26223 > Project: HBase > Issue Type: Bug > Components: wal >Affects Versions: 2.2.7, 2.3.6 >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Critical > > When procedure based WAL split is enabled, we are deleting splitted WAL files > immediately rather than moving to archive path. > > https://github.com/apache/hbase/blob/67e9c6422d6d5b39586ffe529f55b76d8b8939ff/hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/SplitWALRemoteProcedure.java#L99 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-26223) Splitted WAL files are deleted rather than archiving them
[ https://issues.apache.org/jira/browse/HBASE-26223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-26223: - Summary: Splitted WAL files are deleted rather than archiving them (was: Splitted WAL files are deleted immediately rather than archiving them) > Splitted WAL files are deleted rather than archiving them > - > > Key: HBASE-26223 > URL: https://issues.apache.org/jira/browse/HBASE-26223 > Project: HBase > Issue Type: Bug > Components: wal >Affects Versions: 2.2.7, 2.3.6 >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Critical > > When procedure based WAL split is enabled, we are deleting splitted WAL files > immediately rather than moving to archive path. > > https://github.com/apache/hbase/blob/67e9c6422d6d5b39586ffe529f55b76d8b8939ff/hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/SplitWALRemoteProcedure.java#L99 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-26223) Splitted WAL files are deleted immediately rather than archiving them
Pankaj Kumar created HBASE-26223: Summary: Splitted WAL files are deleted immediately rather than archiving them Key: HBASE-26223 URL: https://issues.apache.org/jira/browse/HBASE-26223 Project: HBase Issue Type: Bug Components: wal Affects Versions: 2.3.6, 2.2.7 Reporter: Pankaj Kumar Assignee: Pankaj Kumar When procedure based WAL split is enabled, we are deleting splitted WAL files immediately rather than moving to archive path. https://github.com/apache/hbase/blob/67e9c6422d6d5b39586ffe529f55b76d8b8939ff/hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/SplitWALRemoteProcedure.java#L99 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26175) MetricsHBaseServer should record all kinds of Exceptions
[
https://issues.apache.org/jira/browse/HBASE-26175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17397834#comment-17397834
]
Pankaj Kumar commented on HBASE-26175:
--
But OtherExcpetions category metric will provide only quantitve information not
the exact execption, we should debug log as well.
> MetricsHBaseServer should record all kinds of Exceptions
>
>
> Key: HBASE-26175
> URL: https://issues.apache.org/jira/browse/HBASE-26175
> Project: HBase
> Issue Type: Improvement
> Components: metrics
>Reporter: Xiaolin Ha
>Priority: Major
> Attachments: RequestTooBigException.png
>
>
> We can define a kind of Exception such as OtherExcpetions to record
> exceptions doesn't in the following kinds of exceptions. Only debug those
> exceptions by LOG.debug("Unknown exception type", throwable); is not helpful
> to find errors.
> {code:java}
> if (throwable != null) {
> if (throwable instanceof OutOfOrderScannerNextException) {
> source.outOfOrderException();
> } else if (throwable instanceof RegionTooBusyException) {
> source.tooBusyException();
> } else if (throwable instanceof UnknownScannerException) {
> source.unknownScannerException();
> } else if (throwable instanceof ScannerResetException) {
> source.scannerResetException();
> } else if (throwable instanceof RegionMovedException) {
> source.movedRegionException();
> } else if (throwable instanceof NotServingRegionException) {
> source.notServingRegionException();
> } else if (throwable instanceof FailedSanityCheckException) {
> source.failedSanityException();
> } else if (throwable instanceof MultiActionResultTooLarge) {
> source.multiActionTooLargeException();
> } else if (throwable instanceof CallQueueTooBigException) {
> source.callQueueTooBigException();
> } else if (throwable instanceof QuotaExceededException) {
> source.quotaExceededException();
> } else if (throwable instanceof RpcThrottlingException) {
> source.rpcThrottlingException();
> } else if (LOG.isDebugEnabled()) {
> LOG.debug("Unknown exception type", throwable);
> }
> }
> {code}
> !RequestTooBigException.png|width=787,height=336!
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-26175) MetricsHBaseServer should record all kinds of Exceptions
[
https://issues.apache.org/jira/browse/HBASE-26175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17397833#comment-17397833
]
Pankaj Kumar commented on HBASE-26175:
--
I think, it make sense to park the exceptions (which are not listed above) to
OtherExcpetions category instead of just debug log.
> MetricsHBaseServer should record all kinds of Exceptions
>
>
> Key: HBASE-26175
> URL: https://issues.apache.org/jira/browse/HBASE-26175
> Project: HBase
> Issue Type: Improvement
> Components: metrics
>Reporter: Xiaolin Ha
>Priority: Major
> Attachments: RequestTooBigException.png
>
>
> We can define a kind of Exception such as OtherExcpetions to record
> exceptions doesn't in the following kinds of exceptions. Only debug those
> exceptions by LOG.debug("Unknown exception type", throwable); is not helpful
> to find errors.
> {code:java}
> if (throwable != null) {
> if (throwable instanceof OutOfOrderScannerNextException) {
> source.outOfOrderException();
> } else if (throwable instanceof RegionTooBusyException) {
> source.tooBusyException();
> } else if (throwable instanceof UnknownScannerException) {
> source.unknownScannerException();
> } else if (throwable instanceof ScannerResetException) {
> source.scannerResetException();
> } else if (throwable instanceof RegionMovedException) {
> source.movedRegionException();
> } else if (throwable instanceof NotServingRegionException) {
> source.notServingRegionException();
> } else if (throwable instanceof FailedSanityCheckException) {
> source.failedSanityException();
> } else if (throwable instanceof MultiActionResultTooLarge) {
> source.multiActionTooLargeException();
> } else if (throwable instanceof CallQueueTooBigException) {
> source.callQueueTooBigException();
> } else if (throwable instanceof QuotaExceededException) {
> source.quotaExceededException();
> } else if (throwable instanceof RpcThrottlingException) {
> source.rpcThrottlingException();
> } else if (LOG.isDebugEnabled()) {
> LOG.debug("Unknown exception type", throwable);
> }
> }
> {code}
> !RequestTooBigException.png|width=787,height=336!
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-26154) Provide exception metric for quota exceeded and throttling
[ https://issues.apache.org/jira/browse/HBASE-26154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17391958#comment-17391958 ] Pankaj Kumar commented on HBASE-26154: -- That looks like flaky and not relevant to this change. > Provide exception metric for quota exceeded and throttling > -- > > Key: HBASE-26154 > URL: https://issues.apache.org/jira/browse/HBASE-26154 > Project: HBase > Issue Type: Improvement >Reporter: Bryan Beaudreault >Assignee: Bryan Beaudreault >Priority: Minor > Fix For: 2.5.0, 3.0.0-alpha-2, 2.4.6 > > > We should add metrics for QuotaExceededException and RpcThrottlingException. > This is something we've found very useful to track as it helps us identify > bad access patterns in clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-26154) Provide exception metric for quota exceeded and throttling
[ https://issues.apache.org/jira/browse/HBASE-26154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar resolved HBASE-26154. -- Resolution: Fixed > Provide exception metric for quota exceeded and throttling > -- > > Key: HBASE-26154 > URL: https://issues.apache.org/jira/browse/HBASE-26154 > Project: HBase > Issue Type: Improvement >Reporter: Bryan Beaudreault >Assignee: Bryan Beaudreault >Priority: Minor > Fix For: 2.5.0, 3.0.0-alpha-2, 2.4.6 > > > We should add metrics for QuotaExceededException and RpcThrottlingException. > This is something we've found very useful to track as it helps us identify > bad access patterns in clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26154) Provide exception metric for quota exceeded and throttling
[ https://issues.apache.org/jira/browse/HBASE-26154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17391475#comment-17391475 ] Pankaj Kumar commented on HBASE-26154: -- Pushed to branch-2.4+. Thanks [~bbeaudreault] for the contribution and [~haxiaolin] for reviewing. > Provide exception metric for quota exceeded and throttling > -- > > Key: HBASE-26154 > URL: https://issues.apache.org/jira/browse/HBASE-26154 > Project: HBase > Issue Type: Improvement >Reporter: Bryan Beaudreault >Assignee: Bryan Beaudreault >Priority: Minor > Fix For: 2.5.0, 3.0.0-alpha-2, 2.4.6 > > > We should add metrics for QuotaExceededException and RpcThrottlingException. > This is something we've found very useful to track as it helps us identify > bad access patterns in clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25853) Backport HBASE-22120 (Replace HTrace with OpenTelemetry) to branch-2
[
https://issues.apache.org/jira/browse/HBASE-25853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pankaj Kumar updated HBASE-25853:
-
Summary: Backport HBASE-22120 (Replace HTrace with OpenTelemetry) to
branch-2 (was: Backport HBASE-22120 to branch-2)
> Backport HBASE-22120 (Replace HTrace with OpenTelemetry) to branch-2
>
>
> Key: HBASE-25853
> URL: https://issues.apache.org/jira/browse/HBASE-25853
> Project: HBase
> Issue Type: Task
> Components: tracing
>Affects Versions: 2.5.0
>Reporter: Duo Zhang
>Assignee: Tak-Lon (Stephen) Wu
>Priority: Major
> Fix For: 2.5.0
>
>
> list of commits from upstream/master need to be backported
> {code}
> HBASE-25373
> https://github.com/apache/hbase/commit/302d9ea8b888762a5a20a5ba5c2be7bc239afaef
>
> HBASE-25401
> https://github.com/apache/hbase/commit/242028671535dfed67ec13d9ed0d6067f3ccfd04
>
> HBASE-25424
> https://github.com/apache/hbase/commit/57960fa8fa7228d65b1a4adc8e9b5b1a8158824d
>
> HBASE-23898
> https://github.com/apache/hbase/commit/805b2ae2ad0f6325515d46043ff01e4e2c7a9f59
>
> HBASE-25454
> https://github.com/apache/hbase/commit/dcb78bd4bda4a4ae13d863df8aec266031e5bc93
> HBASE-25481
> https://github.com/apache/hbase/commit/ae2c62ffaad5ba4c976b0a79c10a365edf2844fd
> HBASE-25455
> https://github.com/apache/hbase/commit/03e12bfa4ad62ecc6eee6a2c68d431bea2d5c473
> HBASE-25484
> https://github.com/apache/hbase/commit/2be2c63f0d3917a243b74af9754cbfc805b858d1
> HBASE-25535
> https://github.com/apache/hbase/commit/bb8c4967f8ce2c89ebaf1ddc5d8a1bf55f1e20d3
> HBASE-25591
> https://github.com/apache/hbase/commit/f6ff519dd0c7fe0e3ae3c175eefee27a26a065a4
> HBASE-25617
> https://github.com/apache/hbase/commit/8d68f8cd1c8613be1b499eaa99f46806b2743294
> HBASE-25616
> https://github.com/apache/hbase/commit/8399293e21127df3ffdcb757242e4cb5964c7e99
> HBASE-25723
> https://github.com/apache/hbase/commit/7f90c2201f6a17d2e2d031505c35ae7c2b1ed7ea
> HBASE-25732
> https://github.com/apache/hbase/commit/8df9bebdd367d52a32b08c18a7cf4f9c2d712071
> HBASE-25733
> https://github.com/apache/hbase/commit/b71488998970a3353086a34736ed1edab527f673
> HBASE-23762
> https://github.com/apache/hbase/commit/be4503d9f82f044fbfce21c8a42d0b1684607238
> HBASE-25778
> https://github.com/apache/hbase/commit/f36e1539648bbaee84c626fd54d1605baebf3c5a
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-26116) Parallel scheduling of getClusterstatus interface will lead to linear growth of HMaster memory
[ https://issues.apache.org/jira/browse/HBASE-26116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17386173#comment-17386173 ] Pankaj Kumar commented on HBASE-26116: -- Added [~idol] in the contributor list and assigned this JIRA to you. > Parallel scheduling of getClusterstatus interface will lead to linear growth > of HMaster memory > --- > > Key: HBASE-26116 > URL: https://issues.apache.org/jira/browse/HBASE-26116 > Project: HBase > Issue Type: Bug > Components: mapreduce, master >Affects Versions: 1.3.1, 2.2.3 >Reporter: ShuangQi Xia >Assignee: ShuangQi Xia >Priority: Major > > when Mapreduce job and Spark job use TableInputFormat.getSplits will call > getclusterstatus ,and when running more ten job, HMaster memory is very > high，Of course, the region quantity itself is a reason > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (HBASE-26116) Parallel scheduling of getClusterstatus interface will lead to linear growth of HMaster memory
[ https://issues.apache.org/jira/browse/HBASE-26116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar reassigned HBASE-26116: Assignee: ShuangQi Xia > Parallel scheduling of getClusterstatus interface will lead to linear growth > of HMaster memory > --- > > Key: HBASE-26116 > URL: https://issues.apache.org/jira/browse/HBASE-26116 > Project: HBase > Issue Type: Bug > Components: mapreduce, master >Affects Versions: 1.3.1, 2.2.3 >Reporter: ShuangQi Xia >Assignee: ShuangQi Xia >Priority: Major > > when Mapreduce job and Spark job use TableInputFormat.getSplits will call > getclusterstatus ,and when running more ten job, HMaster memory is very > high，Of course, the region quantity itself is a reason > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26113) Hmaster dead after a few second when i run hbase
[ https://issues.apache.org/jira/browse/HBASE-26113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17385614#comment-17385614 ] Pankaj Kumar commented on HBASE-26113: -- Which JDK version are you using? please refer https://hbase.apache.org/book.html#java > Hmaster dead after a few second when i run hbase > > > Key: HBASE-26113 > URL: https://issues.apache.org/jira/browse/HBASE-26113 > Project: HBase > Issue Type: Test > Components: build, Client, master >Affects Versions: 3.0.0-alpha-1 >Reporter: Yose Simamora >Priority: Major > Fix For: 3.0.0-alpha-1 > > Attachments: Screenshot from 2021-07-22 16-39-47.png > > > first hmaster runs but after a few seconds hmaster shuts down -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-26113) Hmaster dead after a few second when i run hbase
[ https://issues.apache.org/jira/browse/HBASE-26113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar resolved HBASE-26113. -- Resolution: Not A Problem JIRA is for bug tracking. For discussion or queries, please feel free to send mail to u...@hbase.apache.org or d...@hbase.apache.org. Closing it for now, please reopen if required, > Hmaster dead after a few second when i run hbase > > > Key: HBASE-26113 > URL: https://issues.apache.org/jira/browse/HBASE-26113 > Project: HBase > Issue Type: Test > Components: build, Client, master >Affects Versions: 3.0.0-alpha-1 >Reporter: Yose Simamora >Priority: Major > Fix For: 3.0.0-alpha-1 > > Attachments: Screenshot from 2021-07-22 16-39-47.png > > > first hmaster runs but after a few seconds hmaster shuts down -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-26113) Hmaster dead after a few second when i run hbase
[ https://issues.apache.org/jira/browse/HBASE-26113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17385420#comment-17385420 ] Pankaj Kumar commented on HBASE-26113: -- Please check the HMaster log for more details, any exceptions there? > Hmaster dead after a few second when i run hbase > > > Key: HBASE-26113 > URL: https://issues.apache.org/jira/browse/HBASE-26113 > Project: HBase > Issue Type: Test > Components: build, Client, master >Affects Versions: 3.0.0-alpha-1 >Reporter: Yose Simamora >Priority: Major > Fix For: 3.0.0-alpha-1 > > Attachments: Screenshot from 2021-07-22 16-39-47.png > > > first hmaster runs but after a few seconds hmaster shuts down -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25700) Enhance znode parent validation when add_peer
[
https://issues.apache.org/jira/browse/HBASE-25700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pankaj Kumar updated HBASE-25700:
-
Fix Version/s: 2.5.0
3.0.0-alpha-1
> Enhance znode parent validation when add_peer
> -
>
> Key: HBASE-25700
> URL: https://issues.apache.org/jira/browse/HBASE-25700
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Affects Versions: 2.2.3, 2.4.2
>Reporter: mokai
>Assignee: mokai
>Priority: Minor
> Fix For: 3.0.0-alpha-1, 2.5.0
>
>
> If the znode parent end with empty string, add_peer command has no
> validation. It should be enhanced.
> Command example: add_peer '1', CLUSTER_KEY => "10.244.225.186:2181:/hbase ",
> STATE => "ENABLED"
> It causes enable_table_replication execute failed with folloing error.
> {quote}2021-03-27 09:59:47,738 DEBUG
> [ReadOnlyZKClient-10.244.225.186:2181@0x5817f1ca-SendThread(10.244.225.186:2181)]
> zookeeper.ClientCnxn: Reading reply sessionid:0x106fe808733000a, packet::
> clientPath:/hbase /hbaseid serverPath:/hbase /hbaseid finished:false header::
> 1,4 replyHeader:: 1,44,-101 request:: '/hbase /hbaseid,F
> response::2021-03-27 09:59:47,738 DEBUG
> [ReadOnlyZKClient-10.244.225.186:2181@0x5817f1ca-SendThread(10.244.225.186:2181)]
> zookeeper.ClientCnxn: Reading reply sessionid:0x106fe808733000a, packet::
> clientPath:/hbase /hbaseid serverPath:/hbase /hbaseid finished:false header::
> 1,4 replyHeader:: 1,44,-101 request:: '/hbase /hbaseid,F
> response::2021-03-27 09:59:47,755 WARN [main]
> client.ConnectionImplementation: Retrieve cluster id
> failedjava.util.concurrent.ExecutionException:
> org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for /hbase /hbaseid at
> java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
> at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1908) at
> org.apache.hadoop.hbase.client.ConnectionImplementation.retrieveClusterId(ConnectionImplementation.java:603)
> at
> org.apache.hadoop.hbase.client.ConnectionImplementation.(ConnectionImplementation.java:313)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at
> org.apache.hadoop.hbase.client.ConnectionFactory.lambda$createConnection$0(ConnectionFactory.java:230)
> at java.security.AccessController.doPrivileged(Native Method) at
> javax.security.auth.Subject.doAs(Subject.java:422)
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-20503) [AsyncFSWAL] Failed to get sync result after 300000 ms for txid=160912, WAL system stuck?
[
https://issues.apache.org/jira/browse/HBASE-20503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361122#comment-17361122
]
Pankaj Kumar commented on HBASE-20503:
--
We also met this issue in one of our production env, where slow sync cost is
even more than 5 min and so flush and compaction are getting timedout. We are
using HBase-2.2.3 version + some JIRA backport.
> [AsyncFSWAL] Failed to get sync result after 30 ms for txid=160912, WAL
> system stuck?
> -
>
> Key: HBASE-20503
> URL: https://issues.apache.org/jira/browse/HBASE-20503
> Project: HBase
> Issue Type: Bug
> Components: wal
>Reporter: Michael Stack
>Priority: Major
> Attachments:
> 0001-HBASE-20503-AsyncFSWAL-Failed-to-get-sync-result-aft.patch,
> 0001-HBASE-20503-AsyncFSWAL-Failed-to-get-sync-result-aft.patch
>
>
> Scale test. Startup w/ 30k regions over ~250nodes. This RS is trying to
> furiously open regions assigned by Master. It is importantly carrying
> hbase:meta. Twenty minutes in, meta goes dead after an exception up out
> AsyncFSWAL. Process had been restarted so I couldn't get a thread dump.
> Suspicious is we archive a WAL and we get a FNFE because we got to access WAL
> in old location. [~Apache9] mind taking a look? Does this FNFE rolling kill
> the WAL sub-system? Thanks.
> DFS complaining on file open for a few files getting blocks from remote dead
> DNs: e.g. {{2018-04-25 10:05:21,506 WARN
> org.apache.hadoop.hdfs.client.impl.BlockReaderFactory: I/O error constructing
> remote block reader.
> java.net.ConnectException: Connection refused}}
> AsyncFSWAL complaining: "AbstractFSWAL: Slow sync cost: 103 ms" .
> About ten minutes in, we get this:
> {code}
> 2018-04-25 10:15:16,532 WARN
> org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL: sync failed
> java.io.IOException: stream already broken
> at
> org.apache.hadoop.hbase.io.asyncfs.FanOutOneBlockAsyncDFSOutput.flush0(FanOutOneBlockAsyncDFSOutput.java:424)
> at
> org.apache.hadoop.hbase.io.asyncfs.FanOutOneBlockAsyncDFSOutput.flush(FanOutOneBlockAsyncDFSOutput.java:513)
>
>
>
> at
> org.apache.hadoop.hbase.regionserver.wal.AsyncProtobufLogWriter.sync(AsyncProtobufLogWriter.java:134)
> at
> org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.sync(AsyncFSWAL.java:364)
> at
> org.apache.hadoop.hbase.regionserver.wal.AsyncFSWAL.consume(AsyncFSWAL.java:547)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2018-04-25 10:15:16,680 INFO
> org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL: Rolled WAL
> /hbase/WALs/vc0205.halxg.cloudera.com,22101,1524675808073/vc0205.halxg.cloudera.com%2C22101%2C1524675808073.meta.1524676253923.meta
> with entries=10819, filesize=7.57 MB; new WAL
> /hbase/WALs/vc0205.halxg.cloudera.com,22101,1524675808073/vc0205.halxg.cloudera.com%2C22101%2C1524675808073.meta.1524676516535.meta
> 2018-04-25 10:15:16,680 INFO
> org.apache.hadoop.hbase.regionserver.wal.AbstractFSWAL: Archiving
> hdfs://ns1/hbase/WALs/vc0205.halxg.cloudera.com,22101,1524675808073/vc0205.halxg.cloudera.com%2C22101%2C1524675808073.meta.1524675848653.meta
> to
> hdfs://ns1/hbase/oldWALs/vc0205.halxg.cloudera.com%2C22101%2C1524675808073.meta.1524675848653.meta
> 2018-04-25 10:15:16,686 WARN
> org.apache.hadoop.hbase.regionserver.wal.AbstractProtobufLogWriter: Failed to
> write trailer, non-fatal, continuing...
> java.io.IOException: stream already broken
> at
> org.apache.hadoop.hbase.io.asyncfs.FanOutOneBlockAsyncDFSOutput.flush0(FanOutOneBlockAsyncDFSOutput.java:424)
> at
> org.apache.hadoop.hbase.io.asyncfs.FanOutOneBlockAsyncDFSOutput.flush(FanOutOneBlockAsyncDFSOutput.java:513)
> at
> org.apache.hadoop.hbase.regionserver.wal.AsyncProtobufLogWriter.lambda$writeWALTrailerAndMagic$3(AsyncProtobufLogWriter.java:210)
> at
> org.apache.hadoop.hbase.regionserver.wal.AsyncProtobufLogWriter.write(AsyncProtobufLogWriter.java:166)
> at
> org.apache.hadoop.hbase.regionserver.wal.AsyncProtobufLogWriter.writeWALTrailerAndMagic(AsyncProtobufLogWriter.java:201)
> at
> org.apache.hadoop.hbase.regionserver.wal.AbstractProtobufLogWriter.writeWALTrailer(AbstractProtobufLogWriter.java:233)
> at
> org.apache.hadoop.hbase.regionserver.wal.AsyncProtobufLogWriter.close(AsyncProtobufLogWriter.java:143)
> at
>
[jira] [Commented] (HBASE-25729) Upgrade to latest hbase-thirdparty
[
https://issues.apache.org/jira/browse/HBASE-25729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17360312#comment-17360312
]
Pankaj Kumar commented on HBASE-25729:
--
I too feel it is little risky to upgrade thirdparty-3.5.1 in 2.3 & 2.4 release
line, but pb & guava are upgraded to minor versions, so IMO we can go for 3.5.1.
{quote} I now think a 3.4.2, just to leave out the pb and guava bumps, not
worth the effort.
{quote}
Not much worth until there is strong reason.
> Upgrade to latest hbase-thirdparty
> --
>
> Key: HBASE-25729
> URL: https://issues.apache.org/jira/browse/HBASE-25729
> Project: HBase
> Issue Type: Sub-task
> Components: build, thirdparty
>Affects Versions: 2.4.2
>Reporter: Andrew Kyle Purtell
>Priority: Major
> Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.5
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (HBASE-25918) Upgrade hbase-thirdparty dependency to 3.5.1
[ https://issues.apache.org/jira/browse/HBASE-25918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17359057#comment-17359057 ] Pankaj Kumar commented on HBASE-25918: -- There is some discussion in HBASE-25729 for upgrading hbase-thirdparty in 2.3 & 2.4 branch, We may need to revert this from 2.4 or cherry-pick to 2.3 after [~stack] & [~apurtell] confirmation. > Upgrade hbase-thirdparty dependency to 3.5.1 > > > Key: HBASE-25918 > URL: https://issues.apache.org/jira/browse/HBASE-25918 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Critical > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.5 > > > Recently we have fixed multiple CVEs from jetty & netty as part of > HBASE-25728 & HBASE-25746. This Jira is to upgrade hbase-thirdparty jar > version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (HBASE-25729) Upgrade to latest hbase-thirdparty
[ https://issues.apache.org/jira/browse/HBASE-25729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar reopened HBASE-25729: -- > Upgrade to latest hbase-thirdparty > -- > > Key: HBASE-25729 > URL: https://issues.apache.org/jira/browse/HBASE-25729 > Project: HBase > Issue Type: Sub-task > Components: build, thirdparty >Affects Versions: 2.4.2 >Reporter: Andrew Kyle Purtell >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.5 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25729) Upgrade to latest hbase-thirdparty
[ https://issues.apache.org/jira/browse/HBASE-25729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17359053#comment-17359053 ] Pankaj Kumar commented on HBASE-25729: -- Pardon me, I wasn't aware of above conversation. Shall I revert back HBASE-25918 from branch-2.4? > Upgrade to latest hbase-thirdparty > -- > > Key: HBASE-25729 > URL: https://issues.apache.org/jira/browse/HBASE-25729 > Project: HBase > Issue Type: Sub-task > Components: build, thirdparty >Affects Versions: 2.4.2 >Reporter: Andrew Kyle Purtell >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.5 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25729) Upgrade to latest hbase-thirdparty
[ https://issues.apache.org/jira/browse/HBASE-25729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar resolved HBASE-25729. -- Fix Version/s: 2.4.5 Resolution: Fixed > Upgrade to latest hbase-thirdparty > -- > > Key: HBASE-25729 > URL: https://issues.apache.org/jira/browse/HBASE-25729 > Project: HBase > Issue Type: Sub-task > Components: build, thirdparty >Affects Versions: 2.4.2 >Reporter: Andrew Kyle Purtell >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.5 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25918) Upgrade hbase-thirdparty dependency to 3.5.1
[ https://issues.apache.org/jira/browse/HBASE-25918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar resolved HBASE-25918. -- Fix Version/s: 2.4.5 2.5.0 Resolution: Fixed Thanks [~zhangduo] for the review and merge. > Upgrade hbase-thirdparty dependency to 3.5.1 > > > Key: HBASE-25918 > URL: https://issues.apache.org/jira/browse/HBASE-25918 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Critical > Fix For: 3.0.0-alpha-1, 2.5.0, 2.4.5 > > > Recently we have fixed multiple CVEs from jetty & netty as part of > HBASE-25728 & HBASE-25746. This Jira is to upgrade hbase-thirdparty jar > version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25918) Upgrade hbase-thirdparty dependency to 3.5.1
[ https://issues.apache.org/jira/browse/HBASE-25918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-25918: - Fix Version/s: 3.0.0-alpha-1 > Upgrade hbase-thirdparty dependency to 3.5.1 > > > Key: HBASE-25918 > URL: https://issues.apache.org/jira/browse/HBASE-25918 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Critical > Fix For: 3.0.0-alpha-1 > > > Recently we have fixed multiple CVEs from jetty & netty as part of > HBASE-25728 & HBASE-25746. This Jira is to upgrade hbase-thirdparty jar > version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25777) Fix wrong initialization value in StressAssignmentManagerMonkeyFactory
[ https://issues.apache.org/jira/browse/HBASE-25777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-25777: - Fix Version/s: 2.5.0 3.0.0-alpha-1 > Fix wrong initialization value in StressAssignmentManagerMonkeyFactory > -- > > Key: HBASE-25777 > URL: https://issues.apache.org/jira/browse/HBASE-25777 > Project: HBase > Issue Type: Bug > Components: integration tests >Reporter: Yulin Niu >Assignee: Yulin Niu >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0 > > > the initialization of BatchRestartRsAction and RollingBatchRestartRsAction in > StressAssignmentManagerMonkeyFactory use wrong default value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25902) 1.x to 2.3.x upgrade does not work; you must install an hbase2 that is earlier than hbase-2.3.0 first
[ https://issues.apache.org/jira/browse/HBASE-25902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354289#comment-17354289 ] Pankaj Kumar commented on HBASE-25902: -- We had backported HBASE-23055 to our 2.2.x version, that is why we added the hack to read the default meta descriptor (at 2.x RS side) until HMaster update it. > 1.x to 2.3.x upgrade does not work; you must install an hbase2 that is > earlier than hbase-2.3.0 first > - > > Key: HBASE-25902 > URL: https://issues.apache.org/jira/browse/HBASE-25902 > Project: HBase > Issue Type: Bug > Components: meta, Operability >Affects Versions: 2.3.0, 2.4.0 >Reporter: Michael Stack >Priority: Critical > Attachments: NoSuchColumnFamilyException.png > > > Making note of this issue in case others run into it. At my place of employ, > we tried to upgrade a cluster that was an hbase-1.2.x version to an > hbase-2.3.5 but it failed because meta didn't have the 'table' column family. > Up to 2.3.0, hbase:meta was hardcoded. HBASE-12035 added the 'table' CF for > hbase-2.0.0. HBASE-23782 (2.3.0) undid hardcoding of the hbase:meta schema; > i.e. reading hbase:meta schema from the filesystem. The hbase:meta schema is > only created on initial install. If an upgrade over existing data, the > hbase-1 hbase:meta will not be suitable for hbase-2.3.x context as it will be > missing columnfamilies needed to run (HBASE-23055 made it so hbase:meta could > be altered (2.3.0) but probably of no use since Master won't come up). > It would be a nice-to-have if a user could go from hbase1 to hbase.2.3.0 w/o > having to first install an hbase2 that is earlier than 2.3.0 but needs to be > demand before we would work on it; meantime, install an intermediate hbase2 > version before going to hbase-2.3.0+ if coming from hbase-1.x -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25902) 1.x to 2.3.x upgrade does not work; you must install an hbase2 that is earlier than hbase-2.3.0 first
[ https://issues.apache.org/jira/browse/HBASE-25902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354252#comment-17354252 ] Pankaj Kumar commented on HBASE-25902: -- RS can't update the table descriptor, it is read-only at RS side. HMaster check and update meta during HRegionServer#initializeFileSystem in branch-2.3, https://github.com/apache/hbase/blob/328d57119047629de929fbe802ca59e51475daca/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java#L737 > 1.x to 2.3.x upgrade does not work; you must install an hbase2 that is > earlier than hbase-2.3.0 first > - > > Key: HBASE-25902 > URL: https://issues.apache.org/jira/browse/HBASE-25902 > Project: HBase > Issue Type: Bug > Components: meta, Operability >Affects Versions: 2.3.0, 2.4.0 >Reporter: Michael Stack >Priority: Critical > Attachments: NoSuchColumnFamilyException.png > > > Making note of this issue in case others run into it. At my place of employ, > we tried to upgrade a cluster that was an hbase-1.2.x version to an > hbase-2.3.5 but it failed because meta didn't have the 'table' column family. > Up to 2.3.0, hbase:meta was hardcoded. HBASE-12035 added the 'table' CF for > hbase-2.0.0. HBASE-23782 (2.3.0) undid hardcoding of the hbase:meta schema; > i.e. reading hbase:meta schema from the filesystem. The hbase:meta schema is > only created on initial install. If an upgrade over existing data, the > hbase-1 hbase:meta will not be suitable for hbase-2.3.x context as it will be > missing columnfamilies needed to run (HBASE-23055 made it so hbase:meta could > be altered (2.3.0) but probably of no use since Master won't come up). > It would be a nice-to-have if a user could go from hbase1 to hbase.2.3.0 w/o > having to first install an hbase2 that is earlier than 2.3.0 but needs to be > demand before we would work on it; meantime, install an intermediate hbase2 > version before going to hbase-2.3.0+ if coming from hbase-1.x -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25902) 1.x to 2.3.x upgrade does not work; you must install an hbase2 that is earlier than hbase-2.3.0 first
[ https://issues.apache.org/jira/browse/HBASE-25902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354242#comment-17354242 ] Pankaj Kumar commented on HBASE-25902: -- Thanks [~zhangduo] & [~vjasani] for the background and suggestions. Agree we should submit ModifyTableProcedure to modify the meta descriptor and so RegionServers will read the updated meta desc. > 1.x to 2.3.x upgrade does not work; you must install an hbase2 that is > earlier than hbase-2.3.0 first > - > > Key: HBASE-25902 > URL: https://issues.apache.org/jira/browse/HBASE-25902 > Project: HBase > Issue Type: Bug > Components: meta, Operability >Affects Versions: 2.3.0, 2.4.0 >Reporter: Michael Stack >Priority: Critical > Attachments: NoSuchColumnFamilyException.png > > > Making note of this issue in case others run into it. At my place of employ, > we tried to upgrade a cluster that was an hbase-1.2.x version to an > hbase-2.3.5 but it failed because meta didn't have the 'table' column family. > Up to 2.3.0, hbase:meta was hardcoded. HBASE-12035 added the 'table' CF for > hbase-2.0.0. HBASE-23782 (2.3.0) undid hardcoding of the hbase:meta schema; > i.e. reading hbase:meta schema from the filesystem. The hbase:meta schema is > only created on initial install. If an upgrade over existing data, the > hbase-1 hbase:meta will not be suitable for hbase-2.3.x context as it will be > missing columnfamilies needed to run (HBASE-23055 made it so hbase:meta could > be altered (2.3.0) but probably of no use since Master won't come up). > It would be a nice-to-have if a user could go from hbase1 to hbase.2.3.0 w/o > having to first install an hbase2 that is earlier than 2.3.0 but needs to be > demand before we would work on it; meantime, install an intermediate hbase2 > version before going to hbase-2.3.0+ if coming from hbase-1.x -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (HBASE-25902) 1.x to 2.3.x upgrade does not work; you must install an hbase2 that is earlier than hbase-2.3.0 first
[ https://issues.apache.org/jira/browse/HBASE-25902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354241#comment-17354241 ] Pankaj Kumar commented on HBASE-25902: -- We faced NoSuchColumnFamilyException while upgrading 1.3.x cluster to HBase 2.2.x. Steps: 1. Install HBase 2.2.x cluster 2. Stop old HBase 1.3.x cluster 3. Start HBase 2.2.x cluster with existing HDFS & ZK data Default value of _hbase.migrate.table.state.from.zookeeper_ is true, so during HMaster startup TableStateManager will try to mirror the table state from ZK to meta table which will fail because meta table don't have table CF during in old 1.3.x cluster. So HMaster startup will fail always untill we set _hbase.migrate.table.state.from.zookeeper_ to false, I have attached snapshot of the exception trace, kindly refer there. > 1.x to 2.3.x upgrade does not work; you must install an hbase2 that is > earlier than hbase-2.3.0 first > - > > Key: HBASE-25902 > URL: https://issues.apache.org/jira/browse/HBASE-25902 > Project: HBase > Issue Type: Bug > Components: meta, Operability >Affects Versions: 2.3.0, 2.4.0 >Reporter: Michael Stack >Priority: Critical > Attachments: NoSuchColumnFamilyException.png > > > Making note of this issue in case others run into it. At my place of employ, > we tried to upgrade a cluster that was an hbase-1.2.x version to an > hbase-2.3.5 but it failed because meta didn't have the 'table' column family. > Up to 2.3.0, hbase:meta was hardcoded. HBASE-12035 added the 'table' CF for > hbase-2.0.0. HBASE-23782 (2.3.0) undid hardcoding of the hbase:meta schema; > i.e. reading hbase:meta schema from the filesystem. The hbase:meta schema is > only created on initial install. If an upgrade over existing data, the > hbase-1 hbase:meta will not be suitable for hbase-2.3.x context as it will be > missing columnfamilies needed to run (HBASE-23055 made it so hbase:meta could > be altered (2.3.0) but probably of no use since Master won't come up). > It would be a nice-to-have if a user could go from hbase1 to hbase.2.3.0 w/o > having to first install an hbase2 that is earlier than 2.3.0 but needs to be > demand before we would work on it; meantime, install an intermediate hbase2 > version before going to hbase-2.3.0+ if coming from hbase-1.x -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25902) 1.x to 2.3.x upgrade does not work; you must install an hbase2 that is earlier than hbase-2.3.0 first
[ https://issues.apache.org/jira/browse/HBASE-25902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-25902: - Attachment: NoSuchColumnFamilyException.png > 1.x to 2.3.x upgrade does not work; you must install an hbase2 that is > earlier than hbase-2.3.0 first > - > > Key: HBASE-25902 > URL: https://issues.apache.org/jira/browse/HBASE-25902 > Project: HBase > Issue Type: Bug > Components: meta, Operability >Affects Versions: 2.3.0, 2.4.0 >Reporter: Michael Stack >Priority: Critical > Attachments: NoSuchColumnFamilyException.png > > > Making note of this issue in case others run into it. At my place of employ, > we tried to upgrade a cluster that was an hbase-1.2.x version to an > hbase-2.3.5 but it failed because meta didn't have the 'table' column family. > Up to 2.3.0, hbase:meta was hardcoded. HBASE-12035 added the 'table' CF for > hbase-2.0.0. HBASE-23782 (2.3.0) undid hardcoding of the hbase:meta schema; > i.e. reading hbase:meta schema from the filesystem. The hbase:meta schema is > only created on initial install. If an upgrade over existing data, the > hbase-1 hbase:meta will not be suitable for hbase-2.3.x context as it will be > missing columnfamilies needed to run (HBASE-23055 made it so hbase:meta could > be altered (2.3.0) but probably of no use since Master won't come up). > It would be a nice-to-have if a user could go from hbase1 to hbase.2.3.0 w/o > having to first install an hbase2 that is earlier than 2.3.0 but needs to be > demand before we would work on it; meantime, install an intermediate hbase2 > version before going to hbase-2.3.0+ if coming from hbase-1.x -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (HBASE-25948) Remove deprecated ZK command 'rmr' in hbase-cleanup.sh
[ https://issues.apache.org/jira/browse/HBASE-25948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar resolved HBASE-25948. -- Resolution: Fixed Pushed to master & branch-2, thanks [~mokai87] for the contribution. > Remove deprecated ZK command 'rmr' in hbase-cleanup.sh > -- > > Key: HBASE-25948 > URL: https://issues.apache.org/jira/browse/HBASE-25948 > Project: HBase > Issue Type: Task > Components: scripts >Affects Versions: 3.0.0-alpha-1, 2.5.0 >Reporter: mokai >Assignee: mokai >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0 > > > Deprecated command 'rmr' was removed from ZooKeeper since 3.6.0(see: > ZOOKEEPER-3411). > It's better to use 'deleteall' instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25948) Remove deprecated ZK command 'rmr' in hbase-cleanup.sh
[ https://issues.apache.org/jira/browse/HBASE-25948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-25948: - Fix Version/s: 2.5.0 3.0.0-alpha-1 > Remove deprecated ZK command 'rmr' in hbase-cleanup.sh > -- > > Key: HBASE-25948 > URL: https://issues.apache.org/jira/browse/HBASE-25948 > Project: HBase > Issue Type: Task > Components: scripts >Affects Versions: 3.0.0-alpha-1, 2.5.0 >Reporter: mokai >Assignee: mokai >Priority: Major > Fix For: 3.0.0-alpha-1, 2.5.0 > > > Deprecated command 'rmr' was removed from ZooKeeper since 3.6.0(see: > ZOOKEEPER-3411). > It's better to use 'deleteall' instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work started] (HBASE-25918) Upgrade hbase-thirdparty dependency to 3.5.0
[ https://issues.apache.org/jira/browse/HBASE-25918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-25918 started by Pankaj Kumar. > Upgrade hbase-thirdparty dependency to 3.5.0 > > > Key: HBASE-25918 > URL: https://issues.apache.org/jira/browse/HBASE-25918 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Critical > > Recently we have fixed multiple CVEs from jetty & netty as part of > HBASE-25728 & HBASE-25746. This Jira is to upgrade hbase-thirdparty jar > version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25918) Upgrade hbase-thirdparty dependency to 3.5.0
[ https://issues.apache.org/jira/browse/HBASE-25918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-25918: - Issue Type: Task (was: Bug) > Upgrade hbase-thirdparty dependency to 3.5.0 > > > Key: HBASE-25918 > URL: https://issues.apache.org/jira/browse/HBASE-25918 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Critical > > Recently we have fixed multiple CVEs from jetty & netty as part of > HBASE-25728 & HBASE-25746. This Jira is to upgrade hbase-thirdparty jar > version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (HBASE-25918) Upgrade hbase-thirdparty dependency to 3.5.0
[ https://issues.apache.org/jira/browse/HBASE-25918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-25918: - Description: Recently we have fixed multiple CVEs from jetty & netty as part of HBASE-25728 & HBASE-25746. This Jira is to upgrade hbase-thirdparty jar version. (was: Recently we have fixed multiple CVEs from jetty & netty as part of HBASE-25728 & HBASE-25746. This Jira is to upgrade hbase-thirdpaty jar version.) > Upgrade hbase-thirdparty dependency to 3.5.0 > > > Key: HBASE-25918 > URL: https://issues.apache.org/jira/browse/HBASE-25918 > Project: HBase > Issue Type: Bug > Components: dependencies >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Critical > > Recently we have fixed multiple CVEs from jetty & netty as part of > HBASE-25728 & HBASE-25746. This Jira is to upgrade hbase-thirdparty jar > version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (HBASE-25918) Upgrade hbase-thirdparty dependency to 3.5.0
Pankaj Kumar created HBASE-25918: Summary: Upgrade hbase-thirdparty dependency to 3.5.0 Key: HBASE-25918 URL: https://issues.apache.org/jira/browse/HBASE-25918 Project: HBase Issue Type: Bug Components: dependencies Reporter: Pankaj Kumar Assignee: Pankaj Kumar Recently we have fixed multiple CVEs from jetty & netty as part of HBASE-25728 & HBASE-25746. This Jira is to upgrade hbase-thirdpaty jar version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
