[jira] [Resolved] (HBASE-28174) DELETE endpoint in REST API does not support deleting binary row keys/columns

2023-11-17 Thread Wellington Chevreuil (Jira)


 [ 
https://issues.apache.org/jira/browse/HBASE-28174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wellington Chevreuil resolved HBASE-28174.
--
Resolution: Fixed

Thanks for the contribution, [~james_udiljak_bhp]. I had now merged the PR on 
master branch and cherry-picked it to branch-3 and branch-2.

> DELETE endpoint in REST API does not support deleting binary row keys/columns
> -
>
> Key: HBASE-28174
> URL: https://issues.apache.org/jira/browse/HBASE-28174
> Project: HBase
>  Issue Type: Bug
>  Components: REST
>Affects Versions: 2.6.0, 3.0.0-alpha-4, 2.4.17, 2.5.6, 4.0.0-alpha-1
>Reporter: James Udiljak
>Assignee: James Udiljak
>Priority: Blocker
> Fix For: 2.6.0, 3.0.0-beta-1, 4.0.0-alpha-1
>
> Attachments: delete_base64_1.png
>
>
> h2. Notes
> This is the first time I have raised an issue in the ASF Jira. Please let me 
> know if there's anything I need to adjust on the issue to fit in with your 
> development flow.
> I have marked the priority as "blocker" because this issue blocks me as a 
> user of the HBase REST API from deploying an effective solution for our 
> setup. Please feel free to change this if the Priority field has another 
> meaning to you.
> I have also chosen 2.4.17 as the affected version because this is the version 
> I am running, however looking at the source code on GitHub in the default 
> branch, I think many other versions would be affected.
> h2. Description of Issue
> The DELETE operation in the [HBase REST 
> API|https://hbase.apache.org/1.2/apidocs/org/apache/hadoop/hbase/rest/package-summary.html#operation_delete]
>  requires specifying row keys and column families/offsets in the URI (i.e. as 
> UTF-8 text). This makes it impossible to specify a delete operation via the 
> REST API for a binary row key or column family/offset, as single bytes with a 
> decimal value greater than 127 are not valid in UTF-8.
> Percent-encoding these "high" values does not work around the issue, as the 
> HBase REST API uses Java's {{URLDecoder.Decode(percentEncodedString, 
> "UTF-8")}} function, which replaces any percent-encoded byte in the range 
> {{%80}} to {{%FF}} with the [replacement 
> character|https://en.wikipedia.org/wiki/Specials_(Unicode_block)#Replacement_character].
>  Even if this were not the case, the row-key is ultimately [converted to a 
> byte 
> array|https://github.com/apache/hbase/blob/rel/2.4.17/hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/RowSpec.java#L60-L100]
>  using UTF-8 encoding, wherein code points >127 are encoded across multiple 
> bytes, corrupting the user-supplied row key.
> h2. Proposed Solution
> I do not believe it is possible to allow encoding of arbitrary bytes in the 
> URL for the DELETE endpoint without breaking compatibility for any users who 
> may have been unknowingly UTF-8 encoding their binary row keys. Even if it 
> were possible, the syntax would likely be terse.
> Instead, I propose a new version of the DELETE endpoint that would accept row 
> keys and column families/offsets in the request _body_ (using Base64 encoding 
> for the JSON and XML formats, and bare binary for protobuf). This new 
> endpoint would follow the same conventions as the PUT operations, except that 
> cell values would not need to be specified (unless the user is performing a 
> check-and-delete operation).
> As an additional benefit, using the request body could potentially allow for 
> deleting multiple rows in a single request, which would drastically improve 
> the efficiency of my use case.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Heads up on HBASE-28210

2023-11-17 Thread Duo Zhang
Found this problem when implementing HBASE-28199.

The reason why the code change in HBASE-28199 can expose the problem
is that, we add the crash code between adding the procedure to root
procedure state and updating store, so we can reproduce the problem
that later procedure can be persistent earlier reliably, and then
cause trouble while loading procedure.

It is not very easy to reproduce in the normal world but if it
happens, it will be a very big problem and can only be recovered
manually.

I think this is a critical problem which we should fix ASAP.

Thanks.


[jira] [Created] (HBASE-28210) Should not add procedure to rollback step when it is suspended

2023-11-17 Thread Duo Zhang (Jira)
Duo Zhang created HBASE-28210:
-

 Summary: Should not add procedure to rollback step when it is 
suspended
 Key: HBASE-28210
 URL: https://issues.apache.org/jira/browse/HBASE-28210
 Project: HBase
  Issue Type: Bug
  Components: master, proc-v2
Reporter: Duo Zhang


Found this when implementing HBASE-28199, as after HBASE-28199 we will suspend 
procedures a lot, so a missed scenario has been covered.

I think this issue should be fixed separately as it affects all active branches.

Let me try to implement a UT first.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (HBASE-28209) Create a jmx metrics to expose the oldWALs directory size

2023-11-17 Thread Vinayak Hegde (Jira)
Vinayak Hegde created HBASE-28209:
-

 Summary: Create a jmx metrics to expose the oldWALs directory size
 Key: HBASE-28209
 URL: https://issues.apache.org/jira/browse/HBASE-28209
 Project: HBase
  Issue Type: Improvement
  Components: metrics
Reporter: Vinayak Hegde


Create a jmx metrics that can return the size of the old WALs in bytes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)