Re: The fourth HBase 1.5.0 release candidate (RC3) is available

[Yu Li]

Sorry for the late response due to job priority.

This ConnectionRefused issue cannot be reproduced on my laptop (MacOS
10.14.4) but could on the linux env. And I've checked and confirmed it
could pass with 1.4.7/1.4.9 source package but stably failed with 1.5.0,
performing a git bisect now, will report back later.

Best Regards,
Yu


On Sat, 13 Apr 2019 at 00:38, Andrew Purtell 
wrote:

> I also see the occasional ConnectionRefused errors. They don’t reproduce
> if you run the test standalone. I also only see them on a Linux dev host.
> That may be enough to find by bisect the commit that introduced this
> behavior. Working on it. There is a JIRA filed for this one. Search for
> “TestBlocksRead” and label “branch-1”.
>
> Thanks for the investigations.
>
> > On Apr 12, 2019, at 6:36 AM, Yu Li  wrote:
> >
> > Quick updates:
> >
> > W/ patch of HBASE-22219 or say upgrading kerby version to 1.0.1, the
> > failures listed above in the 1st part of hbase-server disappeared.
> >
> > However, in the 2nd part of hbase-server UT there're still many
> > ConnectionRefused exceptions (17 errors in total) as shown below, which
> > could be reproduced easily with -Dtest=xxx command on my environments,
> > still checking the root cause.
> >
> > [INFO] Running org.apache.hadoop.hbase.regionserver.TestBlocksRead
> > [ERROR] Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed:
> > 0.853 s <<< FAILURE! - in
> > org.apache.hadoop.hbase.regionserver.TestBlocksRead
> > [ERROR]
> >
> testBlocksStoredWhenCachingDisabled(org.apache.hadoop.hbase.regionserver.TestBlocksRead)
> > Time elapsed: 0.17 s  <<< ERROR!
> > java.net.ConnectException: Call From
> > z05f06378.sqa.zth.tbsite.net/11.163.183.195 to localhost:35669 failed on
> > connection exception: java.net.ConnectException: Connection refused; For
> > more details see:
> > http://wiki.apache.org/hadoop/ConnectionRefused
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestBlocksRead.initHRegion(TestBlocksRead.java:112)
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestBlocksRead.testBlocksStoredWhenCachingDisabled(TestBlocksRead.java:389)
> > Caused by: java.net.ConnectException: Connection refused
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestBlocksRead.initHRegion(TestBlocksRead.java:112)
> >at
> >
> org.apache.hadoop.hbase.regionserver.TestBlocksRead.testBlocksStoredWhenCachingDisabled(TestBlocksRead.java:389)
> >
> > Best Regards,
> > Yu
> >
> >
> >> On Fri, 12 Apr 2019 at 13:11, Yu Li  wrote:
> >>
> >> I have no doubt that you've run the tests locally before announcing a
> >> release as you're always a great RM boss. And this shows one value of
> >> verifying release, that different voter has different environments.
> >>
> >> Now I think the failures may be kerberos related, since I possibly has
> >> changed some system configuration when doing Flink testing on this env
> >> weeks ago. Located one issue (HBASE-22219) which also observed in 1.4.7,
> >> will further investigate.
> >>
> >> Best Regards,
> >> Yu
> >>
> >>
> >> On Fri, 12 Apr 2019 at 12:38, Andrew Purtell 
> >> wrote:
> >>
> >>> “However it's good to find the issue earlier if there
> >>> really is any, before release announced.”
> >>>
> >>> I run the complete unit test suite before announcing a release
> candidate.
> >>> Just to be clear.
> >>>
> >>> Totally agree we should get these problems sorted before an actual
> >>> release. My policy is to cancel a RC if anyone vetoes for this
> reason...
> >>> want as much coverage and varying environments as we can manage.
> >>>
> >>> Thank you for your help so far and I hope the failures you see result
> in
> >>> analysis and fixes that lead to better test stability.
> >>>
>  On Apr 11, 2019, at 9:32 PM, Yu Li  wrote:
> 
>  Confirmed in 1.4.7 source the listed out cases passed (all in the 1st
> >>> part
>  of hbase-server so the result comes out quickly.)... Also confirmed
> the
>  test ran order are the same...
> 
>  Will try 1.5.0 again to prevent the environment difference caused by
> >>> time.
>  If 1.5.0 still fails, will start to do the git bisect to locate the
> >>> first
>  bad commit.
> 
>  Was also expecting an easy pass and +1 as always to save time and
> >>> efforts,
>  but obvious no luck. However it's good to find the issue earlier if
> >>> there
>  really is any, before release announced.
> 
>  Best Regards,
>  Yu
> 
> 
> > On Fri, 12 Apr 2019 at 12:16, Yu Li  wrote:
> >
> > Fine, let's focus on verifying whether it's a real problem rather
> than
> > arguing about wording, after all that's not my intention...
> >
> > As mentioned, I participated in the 1.4.7 release vote[1] and IIRC I
> >>> was
> > using the same env and all tests passed w/o issue, that's where my
> >>> concern
> > lies and the main reason I gave a -1 vote. I'm running against 1.4.7
> >>> source
> > on the same now and let's see 

[jira] [Created] (HBASE-22250) The same constants used in many places should be placed in constant classes

[lixiaobao (JIRA)]

lixiaobao created HBASE-22250:
-

 Summary: The same constants used in many places should be placed 
in constant classes
 Key: HBASE-22250
 URL: https://issues.apache.org/jira/browse/HBASE-22250
 Project: HBase
  Issue Type: Improvement
  Components: Client, conf, regionserver
Affects Versions: 2.1.4, 2.1.1, 2.0.0, 1.2.0
Reporter: lixiaobao
Assignee: lixiaobao
 Fix For: 3.0.0


I think we should put these configurations in the HConstants class to avoid the 
trouble of modifying a lot of places when we modify them later.
{code:java}
public static final String MASTER_KRB_PRINCIPAL = 
"hbase.master.kerberos.principal";
public static final String MASTER_KRB_KEYTAB_FILE = "hbase.master.keytab.file";
public static final String REGIONSERVER_KRB_PRINCIPAL = 
"hbase.regionserver.kerberos.principal";
public static final String REGIONSERVER_KRB_KEYTAB_FILE = 
"hbase.regionserver.keytab.file";{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-22207) Fix flakey TestAssignmentManager.testAssignSocketTimeout

[Guanghao Zhang (JIRA)]

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

Guanghao Zhang resolved HBASE-22207.

Resolution: Fixed

> Fix flakey TestAssignmentManager.testAssignSocketTimeout
> 
>
> Key: HBASE-22207
> URL: https://issues.apache.org/jira/browse/HBASE-22207
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
>
> The problem is that we may kill the RS which holds meta so the assertion of 
> the number of procedures maybe incorrect, as we may schedule another TRSP for 
> assigning meta...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-22249) HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)

[Sakthi (JIRA)]

Sakthi created HBASE-22249:
--

 Summary: HBase Rest Server throws NoClassDefFoundError with JAVA 
11 (run-time)
 Key: HBASE-22249
 URL: https://issues.apache.org/jira/browse/HBASE-22249
 Project: HBase
  Issue Type: Bug
Affects Versions: 2.1.5
Reporter: Sakthi
Assignee: Sakthi


While starting the rest server multiple instances of the following error can be 
seen:
{code:java}
java.lang.NoClassDefFoundError: javax/activation/DataSource
{code}
After start-up of the server, while serving requests, following errors can be 
seen:
{code:java}
Caused by: A MultiException has 3 exceptions.  They are:
1. java.lang.NoClassDefFoundError: Could not initialize class 
com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl
2. java.lang.IllegalStateException: Unable to perform operation: create on 
org.apache.hadoop.hbase.rest.provider.JAXBContextResolver
3. java.lang.IllegalStateException: Unable to perform operation: create on 
org.glassfish.jersey.internal.ContextResolverFactory
{code}

And the requests failed like this:
{code:java}



Error 500 


HTTP ERROR: 500
Problem accessing /. Reason:
Request failed.



{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] The first HBase 1.3.4 release candidate (RC0) is available

[Andrew Purtell]

+1

Checked sums and signatures: ok
RAT check passes: ok (7u80)
Built from source: ok (7u80)
Unit tests pass: ok (8u172)*
1M row LTT: ok (8u172)

* - TestReplicationAdmin failed when run in suite but passed standalone.


On Mon, Apr 15, 2019 at 2:10 AM Francis Liu  wrote:

> Hi Folks,
>
> The first HBase 1.3.4 release candidate (RC0) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.4RC0/ and Maven
> artifacts are available in the temporary repository
> *https://repository.apache.org/content/repositories/orgapachehbase-1302/
> *
>
> The git tag corresponding to the candidate is '1.3.4RC0' (5d44375).
>
> A detailed source and binary compatibility report for this release is
> available at
>
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.4RC0/compat-check-report.html
> .
> Please review and raise any concerns if you have them.
>
> A list of the 25 issues resolved in this release can be found at
>  https://s.apache.org/uyEI .
>
> Please try out the candidate and vote +1/0/-1.
>
> Prior to making this announcement I made the following checks:
>
> RAT check passes (7u211)
> Unit test suite passes (7u211)
> Loaded the UI in a browser, poked around (8u144)
> A few shell commands (8u144)
> ITBLL 25M rows (8u144)
>
> This vote will be open for one week and close April 22, 2018.
>
> Thanks,
> Francis
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

[jira] [Created] (HBASE-22248) Remove deprecated CollectionUtils

[Jan Hentschel (JIRA)]

Jan Hentschel created HBASE-22248:
-

 Summary: Remove deprecated CollectionUtils
 Key: HBASE-22248
 URL: https://issues.apache.org/jira/browse/HBASE-22248
 Project: HBase
  Issue Type: Task
Reporter: Jan Hentschel


The class CollectionUtils was deprecated and should be removed in 3.0.0.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Delete issues with NEW_VERSION_BEHAVIOR on HBase 2.0.5

[Kevin Ratnasekera]

Code for delete row issue in cases of qualifier = null, even after row is
deleted it will return non null value,

@Test
public void testing() throws IOException {

  Connection conn = ConnectionFactory.createConnection(conf);

  TableName test = TableName.valueOf("Test");
  TableDescriptorBuilder tableDescBuilder =
TableDescriptorBuilder.newBuilder(test);
  ColumnFamilyDescriptorBuilder columnDescBuilder =
ColumnFamilyDescriptorBuilder
  .newBuilder(Bytes.toBytes("test-family"));
  columnDescBuilder.setNewVersionBehavior(true);
  ColumnFamilyDescriptor columnDescriptor = columnDescBuilder.build();
  tableDescBuilder.addColumnFamily(columnDescriptor);
  TableDescriptor tableDescriptor = tableDescBuilder.build();

  conn.getAdmin().createTable(tableDescriptor);

  Table table = conn.getTable(test);

  Put put = new Put(Bytes.toBytes("com.example/http"));
  put.addColumn(Bytes.toBytes("test-family"), null,
Bytes.toBytes("test-value"));
  table.put(put);

  Delete del = new Delete(Bytes.toBytes("com.example/http"));
  table.delete(del);

  Get get = new Get(Bytes.toBytes("com.example/http"));
  //get.addColumn(Bytes.toBytes("test-family"), null);
  Result result = table.get(get);
  byte [] value = result.getValue(Bytes.toBytes("test-family"), null);

  if(value ==  null) {
 // Testing purposes
  }
}


On Mon, Apr 15, 2019 at 10:51 PM Kevin Ratnasekera 
wrote:

> Hi all,
>
> Here's test code I used for testing purposes and I would like to know the
> behavior,
>
>
> @Test
> public void testing() throws IOException {
>
>   Connection conn = ConnectionFactory.createConnection(conf);
>
>   TableName test = TableName.valueOf("Test");
>   TableDescriptorBuilder tableDescBuilder = 
> TableDescriptorBuilder.newBuilder(test);
>   ColumnFamilyDescriptorBuilder columnDescBuilder = 
> ColumnFamilyDescriptorBuilder
>   .newBuilder(Bytes.toBytes("test-family"));
>   columnDescBuilder.setNewVersionBehavior(true);
>   ColumnFamilyDescriptor columnDescriptor = columnDescBuilder.build();
>   tableDescBuilder.addColumnFamily(columnDescriptor);
>   TableDescriptor tableDescriptor = tableDescBuilder.build();
>
>   conn.getAdmin().createTable(tableDescriptor);
>
>   Table table = conn.getTable(test);
>   BufferedMutator bm =  conn.getBufferedMutator(test);
>
>   Delete del = new Delete(Bytes.toBytes("com.example/http"));
>   del.addColumn(Bytes.toBytes("test-family"), 
> Bytes.toBytes("test-qualifier"));
>   bm.mutate(del);
>
>   Put put = new Put(Bytes.toBytes("com.example/http"));
>   put.addColumn(Bytes.toBytes("test-family"), 
> Bytes.toBytes("test-qualifier"), Bytes.toBytes("test-value"));
>   bm.mutate(put);
>
>   put = new Put(Bytes.toBytes("com.example/http"));
>   put.addColumn(Bytes.toBytes("test-family"), 
> Bytes.toBytes("test-qualifier"), Bytes.toBytes("test-value-2"));
>   bm.mutate(put);
>
>   bm.flush();
>   bm.close();
>
>   Get get = new Get(Bytes.toBytes("com.example/http"));
>   get.addColumn(Bytes.toBytes("test-family"), 
> Bytes.toBytes("test-qualifier"));
>   Result result = table.get(get);
>   byte [] val = result.getValue(Bytes.toBytes("test-family"), 
> Bytes.toBytes("test-qualifier"));
>
>   if(val ==  null) {
>  // Testing purposes
>   }
> }
>
> I would like to know the exact behavior of value val variable here, when 
> NEW_VERSION_BEHAVIOR
> is true. Above code when it is executed returns null as value for val
> variable. As I can see, delete overshadows the subsequent puts.
>
> Regards
> Kevin
>
> On Mon, Apr 15, 2019 at 2:05 PM Kevin Ratnasekera 
> wrote:
>
>> Update:
>> Found out that above delete row works all columns which have non null
>> qualifier. Delete doesn't work for puts with column qualifier is null.
>>
>> On related note,
>>
>> Delete delete = new Delete(keyRaw);
>>
>> delete.addFamily(hcol.getFamily());
>>
>> Let's say I need to perform delete on all columns created inside a family
>> in a particular row, once I execute  above delete operation, I am not be
>> able to do put operation on the same row same column family.
>>
>> Is there something I am missing here?
>>
>> Regards
>>
>> Kevin
>>
>>
>> On Mon, Apr 15, 2019 at 12:20 AM Kevin Ratnasekera <
>> djkevincr1...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am from Apache Gora project. I currently in the process of upgrade our
>>> HBase dependencies to 2.0.5. We faced the issue described in [1] and had to
>>> put workarounds to get through it some time back. ( By timestamps ) Now I
>>> started to test NEW_VERSION_BEHAVIOR and I noticed even trivial row deletes
>>> fails when NEW_VERSION_BEHAVIOR is set to true.
>>>
>>> Delete del = new Delete(toBytes(key));
>>>
>>> table = connection.getTable(tableName);
>>>
>>> table.delete(del);
>>> Result result = table.get(new Get(toBytes(key)));
>>>
>>> Here Get returns some cells which are marked for delete. ( Some columns
>>> are deleted and some are not ) These deletes works fine when
>>> NEW_VERSION_BEHAVIOR is set to false. Please note I do this tests using 
>>> 

[jira] [Resolved] (HBASE-20586) SyncTable tool: Add support for cross-realm remote clusters

[Andrew Purtell (JIRA)]

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

Andrew Purtell resolved HBASE-20586.

   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 2.2.1
   2.1.5
   1.4.10

> SyncTable tool: Add support for cross-realm remote clusters
> ---
>
> Key: HBASE-20586
> URL: https://issues.apache.org/jira/browse/HBASE-20586
> Project: HBase
>  Issue Type: Improvement
>  Components: mapreduce, Operability, Replication
>Affects Versions: 1.2.0, 2.0.0
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 2.1.5, 2.2.1
>
> Attachments: HBASE-20586.master.001.patch
>
>
> One possible scenario for HashTable/SyncTable is for synchronize different 
> clusters, for instance, when replication has been enabled but data existed 
> already, or due replication issues that may had caused long lags in the 
> replication.
> For secured clusters under different kerberos realms (with cross-realm 
> properly set), though, current SyncTable version would fail to authenticate 
> with the remote cluster when trying to read HashTable outputs (when 
> *sourcehashdir* is remote) and also when trying to read table data on the 
> remote cluster (when *sourcezkcluster* is remote).
> The hdfs error would look like this:
> {noformat}
> INFO mapreduce.Job: Task Id : attempt_1524358175778_105392_m_00_0, Status 
> : FAILED
> Error: java.io.IOException: Failed on local exception: java.io.IOException: 
> org.apache.hadoop.security.AccessControlException: Client cannot authenticate 
> via:[TOKEN, KERBEROS]; Host Details : local host is: "local-host/1.1.1.1"; 
> destination host is: "remote-nn":8020;
>         at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:772)
>         at org.apache.hadoop.ipc.Client.call(Client.java:1506)
>         at org.apache.hadoop.ipc.Client.call(Client.java:1439)
>         at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:230)
>         at com.sun.proxy.$Proxy13.getBlockLocations(Unknown Source)
>         at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getBlockLocations(ClientNamenodeProtocolTranslatorPB.java:256)
> ...
>         at 
> org.apache.hadoop.hbase.mapreduce.HashTable$TableHash.readPropertiesFile(HashTable.java:144)
>         at 
> org.apache.hadoop.hbase.mapreduce.HashTable$TableHash.read(HashTable.java:105)
>         at 
> org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper.setup(SyncTable.java:188)
> at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:142)
> ...
> Caused by: java.io.IOException: 
> org.apache.hadoop.security.AccessControlException: Client cannot authenticate 
> via:[TOKEN, KERBEROS]{noformat}
> The above can be sorted if the SyncTable job acquires a DT for the remote NN. 
> Once hdfs related authentication is done, it's also necessary to authenticate 
> against remote HBase, as the below error would arise:
> {noformat}
> INFO mapreduce.Job: Task Id : attempt_1524358175778_172414_m_00_0, Status 
> : FAILED
> Error: org.apache.hadoop.hbase.client.RetriesExhaustedException: Can't get 
> the location
> at 
> org.apache.hadoop.hbase.client.RpcRetryingCallerWithReadReplicas.getRegionLocations(RpcRetryingCallerWithReadReplicas.java:326)
> ...
> at org.apache.hadoop.hbase.client.HTable.getScanner(HTable.java:867)
> at 
> org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper.syncRange(SyncTable.java:331)
> ...
> Caused by: java.io.IOException: Could not set up IO Streams to 
> remote-rs-host/1.1.1.2:60020
> at 
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:786)
> ...
> Caused by: java.lang.RuntimeException: SASL authentication failed. The most 
> likely cause is missing or invalid credentials. Consider 'kinit'.
> ...
> Caused by: GSSException: No valid credentials provided (Mechanism level: 
> Failed to find any Kerberos tgt)
> ...{noformat}
> The above would need additional authentication logic against the remote hbase 
> cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Delete issues with NEW_VERSION_BEHAVIOR on HBase 2.0.5

[Kevin Ratnasekera]

Hi all,

Here's test code I used for testing purposes and I would like to know the
behavior,


@Test
public void testing() throws IOException {

  Connection conn = ConnectionFactory.createConnection(conf);

  TableName test = TableName.valueOf("Test");
  TableDescriptorBuilder tableDescBuilder =
TableDescriptorBuilder.newBuilder(test);
  ColumnFamilyDescriptorBuilder columnDescBuilder =
ColumnFamilyDescriptorBuilder
  .newBuilder(Bytes.toBytes("test-family"));
  columnDescBuilder.setNewVersionBehavior(true);
  ColumnFamilyDescriptor columnDescriptor = columnDescBuilder.build();
  tableDescBuilder.addColumnFamily(columnDescriptor);
  TableDescriptor tableDescriptor = tableDescBuilder.build();

  conn.getAdmin().createTable(tableDescriptor);

  Table table = conn.getTable(test);
  BufferedMutator bm =  conn.getBufferedMutator(test);

  Delete del = new Delete(Bytes.toBytes("com.example/http"));
  del.addColumn(Bytes.toBytes("test-family"), Bytes.toBytes("test-qualifier"));
  bm.mutate(del);

  Put put = new Put(Bytes.toBytes("com.example/http"));
  put.addColumn(Bytes.toBytes("test-family"),
Bytes.toBytes("test-qualifier"), Bytes.toBytes("test-value"));
  bm.mutate(put);

  put = new Put(Bytes.toBytes("com.example/http"));
  put.addColumn(Bytes.toBytes("test-family"),
Bytes.toBytes("test-qualifier"), Bytes.toBytes("test-value-2"));
  bm.mutate(put);

  bm.flush();
  bm.close();

  Get get = new Get(Bytes.toBytes("com.example/http"));
  get.addColumn(Bytes.toBytes("test-family"), Bytes.toBytes("test-qualifier"));
  Result result = table.get(get);
  byte [] val = result.getValue(Bytes.toBytes("test-family"),
Bytes.toBytes("test-qualifier"));

  if(val ==  null) {
 // Testing purposes
  }
}

I would like to know the exact behavior of value val variable here,
when NEW_VERSION_BEHAVIOR
is true. Above code when it is executed returns null as value for val
variable. As I can see, delete overshadows the subsequent puts.

Regards
Kevin

On Mon, Apr 15, 2019 at 2:05 PM Kevin Ratnasekera 
wrote:

> Update:
> Found out that above delete row works all columns which have non null
> qualifier. Delete doesn't work for puts with column qualifier is null.
>
> On related note,
>
> Delete delete = new Delete(keyRaw);
>
> delete.addFamily(hcol.getFamily());
>
> Let's say I need to perform delete on all columns created inside a family
> in a particular row, once I execute  above delete operation, I am not be
> able to do put operation on the same row same column family.
>
> Is there something I am missing here?
>
> Regards
>
> Kevin
>
>
> On Mon, Apr 15, 2019 at 12:20 AM Kevin Ratnasekera <
> djkevincr1...@gmail.com> wrote:
>
>> Hi all,
>>
>> I am from Apache Gora project. I currently in the process of upgrade our
>> HBase dependencies to 2.0.5. We faced the issue described in [1] and had to
>> put workarounds to get through it some time back. ( By timestamps ) Now I
>> started to test NEW_VERSION_BEHAVIOR and I noticed even trivial row deletes
>> fails when NEW_VERSION_BEHAVIOR is set to true.
>>
>> Delete del = new Delete(toBytes(key));
>>
>> table = connection.getTable(tableName);
>>
>> table.delete(del);
>> Result result = table.get(new Get(toBytes(key)));
>>
>> Here Get returns some cells which are marked for delete. ( Some columns
>> are deleted and some are not ) These deletes works fine when
>> NEW_VERSION_BEHAVIOR is set to false. Please note I do this tests using 
>> HBaseTestingUtility
>> minicluster.
>>
>> Are there any known issues with NEW_VERSION_BEHAVIOR with deletes? It
>> would be really helpful if someone can give some pointers to debug the root
>> cause of this.
>>
>> [1] https://issues.apache.org/jira/browse/HBASE-2256
>>
>> Regards
>> Kevin
>>
>

[jira] [Created] (HBASE-22247) Remove deprecated field from MetricsReplicationSourceSourceImpl

[Jan Hentschel (JIRA)]

Jan Hentschel created HBASE-22247:
-

 Summary: Remove deprecated field from 
MetricsReplicationSourceSourceImpl
 Key: HBASE-22247
 URL: https://issues.apache.org/jira/browse/HBASE-22247
 Project: HBase
  Issue Type: Task
Reporter: Jan Hentschel


The field shippedKBsKey of the class MetricsReplicationSourceSourceImpl was 
deprecated in 1.3.0 and should be removed for 3.0.0.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-22246) Remove deprecated field from MetricsReplicationSourceSource

[Jan Hentschel (JIRA)]

Jan Hentschel created HBASE-22246:
-

 Summary: Remove deprecated field from 
MetricsReplicationSourceSource
 Key: HBASE-22246
 URL: https://issues.apache.org/jira/browse/HBASE-22246
 Project: HBase
  Issue Type: Task
Reporter: Jan Hentschel


The field SOURCE_SHIPPED_KBS in the class MetricsReplicationSourceSource is 
deprecated and should be removed in 3.0.0.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Assign new users to Jira issues

[Jan Hentschel]

Works like a charm. Thanks Sean.

From: Sean Busbey 
Reply-To: "dev@hbase.apache.org" 
Date: Monday, April 15, 2019 at 6:31 PM
To: dev 
Subject: Re: Assign new users to Jira issues

Should be all set now. If you go to this page:

https://issues.apache.org/jira/plugins/servlet/project-config/HBASE/roles

There's a link for "Add users to a role" and you can search for any
jira user and add them to the role "Contributors 1"

On Mon, Apr 15, 2019 at 11:01 AM Jan Hentschel
mailto:jan.hentsc...@ultratendency.com>> wrote:

Hi Sean,

I’m fine with it. Thanks for your help.

Best, Jan

From: Sean Busbey mailto:bus...@apache.org>>
Reply-To: "dev@hbase.apache.org" 
mailto:dev@hbase.apache.org>>
Date: Monday, April 15, 2019 at 5:37 PM
To: dev mailto:dev@hbase.apache.org>>
Subject: Re: Assign new users to Jira issues

Hi Jan!

They need to be added to the "contributors 1" role in the jira
project. Anyone with the administrator role in the project can do it.
By default we add PMC members to that group, but it's open to
basically anyone who wants to do the work.

You fine with being added to the admin group? If so please make sure
you have a good password  (complexity, not reused, etc).

On Mon, Apr 15, 2019 at 9:53 AM Jan Hentschel
mailto:jan.hentsc...@ultratendency.com>>
 wrote:

Hi,

one of my colleagues wants to start contributing to HBase. How can I assign him 
to an issue (or how can he do it)? I was looking for his Jira handle, but 
wasn’t able to find it. I can see his handle when commenting on an issue, but 
I’m not able to assign an issue to him.

Best, Jan

Re: Assign new users to Jira issues

[Sean Busbey]

Should be all set now. If you go to this page:

https://issues.apache.org/jira/plugins/servlet/project-config/HBASE/roles

There's a link for "Add users to a role" and you can search for any
jira user and add them to the role "Contributors 1"

On Mon, Apr 15, 2019 at 11:01 AM Jan Hentschel
 wrote:
>
> Hi Sean,
>
> I’m fine with it. Thanks for your help.
>
> Best, Jan
>
> From: Sean Busbey 
> Reply-To: "dev@hbase.apache.org" 
> Date: Monday, April 15, 2019 at 5:37 PM
> To: dev 
> Subject: Re: Assign new users to Jira issues
>
> Hi Jan!
>
> They need to be added to the "contributors 1" role in the jira
> project. Anyone with the administrator role in the project can do it.
> By default we add PMC members to that group, but it's open to
> basically anyone who wants to do the work.
>
> You fine with being added to the admin group? If so please make sure
> you have a good password  (complexity, not reused, etc).
>
> On Mon, Apr 15, 2019 at 9:53 AM Jan Hentschel
> mailto:jan.hentsc...@ultratendency.com>> 
> wrote:
>
> Hi,
>
> one of my colleagues wants to start contributing to HBase. How can I assign 
> him to an issue (or how can he do it)? I was looking for his Jira handle, but 
> wasn’t able to find it. I can see his handle when commenting on an issue, but 
> I’m not able to assign an issue to him.
>
> Best, Jan
>

[jira] [Created] (HBASE-22245) Please add my public key to committer keys

[Balazs Meszaros (JIRA)]

Balazs Meszaros created HBASE-22245:
---

 Summary: Please add my public key to committer keys
 Key: HBASE-22245
 URL: https://issues.apache.org/jira/browse/HBASE-22245
 Project: HBase
  Issue Type: Task
Reporter: Balazs Meszaros
Assignee: Sean Busbey
 Attachments: meszibalu.asc





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Assign new users to Jira issues

[Jan Hentschel]

Hi Sean,

I’m fine with it. Thanks for your help.

Best, Jan

From: Sean Busbey 
Reply-To: "dev@hbase.apache.org" 
Date: Monday, April 15, 2019 at 5:37 PM
To: dev 
Subject: Re: Assign new users to Jira issues

Hi Jan!

They need to be added to the "contributors 1" role in the jira
project. Anyone with the administrator role in the project can do it.
By default we add PMC members to that group, but it's open to
basically anyone who wants to do the work.

You fine with being added to the admin group? If so please make sure
you have a good password  (complexity, not reused, etc).

On Mon, Apr 15, 2019 at 9:53 AM Jan Hentschel
mailto:jan.hentsc...@ultratendency.com>> wrote:

Hi,

one of my colleagues wants to start contributing to HBase. How can I assign him 
to an issue (or how can he do it)? I was looking for his Jira handle, but 
wasn’t able to find it. I can see his handle when commenting on an issue, but 
I’m not able to assign an issue to him.

Best, Jan

Re: Assign new users to Jira issues

[Sean Busbey]

Hi Jan!

They need to be added to the "contributors 1" role in the jira
project. Anyone with the administrator role in the project can do it.
By default we add PMC members to that group, but it's open to
basically anyone who wants to do the work.

You fine with being added to the admin group? If so please make sure
you have a good password  (complexity, not reused, etc).

On Mon, Apr 15, 2019 at 9:53 AM Jan Hentschel
 wrote:
>
> Hi,
>
> one of my colleagues wants to start contributing to HBase. How can I assign 
> him to an issue (or how can he do it)? I was looking for his Jira handle, but 
> wasn’t able to find it. I can see his handle when commenting on an issue, but 
> I’m not able to assign an issue to him.
>
> Best, Jan

Assign new users to Jira issues

[Jan Hentschel]

Hi,

one of my colleagues wants to start contributing to HBase. How can I assign him 
to an issue (or how can he do it)? I was looking for his Jira handle, but 
wasn’t able to find it. I can see his handle when commenting on an issue, but 
I’m not able to assign an issue to him.

Best, Jan

Still Failing: HBase Generate Website

[Apache Jenkins Server]

Build status: Still Failing

The HBase website has not been updated to incorporate HBase commit 
${CURRENT_HBASE_COMMIT}.

See https://builds.apache.org/job/hbase_generate_website/1646/console

[jira] [Resolved] (HBASE-22243) Remove deprecated methods in Result

[Jan Hentschel (JIRA)]

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

Jan Hentschel resolved HBASE-22243.
---
   Resolution: Fixed
 Hadoop Flags: Incompatible change
Fix Version/s: 3.0.0
 Release Note: Removed the deprecated isPartial() method from the Result 
class.

> Remove deprecated methods in Result
> ---
>
> Key: HBASE-22243
> URL: https://issues.apache.org/jira/browse/HBASE-22243
> Project: HBase
>  Issue Type: Task
>  Components: Client
>Reporter: Jan Hentschel
>Priority: Trivial
> Fix For: 3.0.0
>
>
> The Result class defines the deprecated isPartial() method, which should be 
> removed. For now it should be for 3.0.0 only.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-22244) Make use of MetricsConnection in async client

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-22244:
-

 Summary: Make use of MetricsConnection in async client
 Key: HBASE-22244
 URL: https://issues.apache.org/jira/browse/HBASE-22244
 Project: HBase
  Issue Type: Sub-task
Reporter: Duo Zhang






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-22243) Remove deprecated methods in Result

[Jan Hentschel (JIRA)]

Jan Hentschel created HBASE-22243:
-

 Summary: Remove deprecated methods in Result
 Key: HBASE-22243
 URL: https://issues.apache.org/jira/browse/HBASE-22243
 Project: HBase
  Issue Type: Task
  Components: Client
Reporter: Jan Hentschel


The Result class defines the deprecated isPartial() method, which should be 
removed. For now it should be for 3.0.0 only.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[VOTE] The first HBase 1.3.4 release candidate (RC0) is available

[Francis Liu]

Hi Folks,

The first HBase 1.3.4 release candidate (RC0) is available for download at
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.4RC0/ and Maven
artifacts are available in the temporary repository
*https://repository.apache.org/content/repositories/orgapachehbase-1302/
*

The git tag corresponding to the candidate is '1.3.4RC0' (5d44375).

A detailed source and binary compatibility report for this release is
available at
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.4RC0/compat-check-report.html
.
Please review and raise any concerns if you have them.

A list of the 25 issues resolved in this release can be found at
 https://s.apache.org/uyEI .

Please try out the candidate and vote +1/0/-1.

Prior to making this announcement I made the following checks:

RAT check passes (7u211)
Unit test suite passes (7u211)
Loaded the UI in a browser, poked around (8u144)
A few shell commands (8u144)
ITBLL 25M rows (8u144)

This vote will be open for one week and close April 22, 2018.

Thanks,
Francis

Re: Delete issues with NEW_VERSION_BEHAVIOR on HBase 2.0.5

[Kevin Ratnasekera]

Update:
Found out that above delete row works all columns which have non null
qualifier. Delete doesn't work for puts with column qualifier is null.

On related note,

Delete delete = new Delete(keyRaw);

delete.addFamily(hcol.getFamily());

Let's say I need to perform delete on all columns created inside a family
in a particular row, once I execute  above delete operation, I am not be
able to do put operation on the same row same column family.

Is there something I am missing here?

Regards

Kevin


On Mon, Apr 15, 2019 at 12:20 AM Kevin Ratnasekera 
wrote:

> Hi all,
>
> I am from Apache Gora project. I currently in the process of upgrade our
> HBase dependencies to 2.0.5. We faced the issue described in [1] and had to
> put workarounds to get through it some time back. ( By timestamps ) Now I
> started to test NEW_VERSION_BEHAVIOR and I noticed even trivial row deletes
> fails when NEW_VERSION_BEHAVIOR is set to true.
>
> Delete del = new Delete(toBytes(key));
>
> table = connection.getTable(tableName);
>
> table.delete(del);
> Result result = table.get(new Get(toBytes(key)));
>
> Here Get returns some cells which are marked for delete. ( Some columns
> are deleted and some are not ) These deletes works fine when
> NEW_VERSION_BEHAVIOR is set to false. Please note I do this tests using 
> HBaseTestingUtility
> minicluster.
>
> Are there any known issues with NEW_VERSION_BEHAVIOR with deletes? It
> would be really helpful if someone can give some pointers to debug the root
> cause of this.
>
> [1] https://issues.apache.org/jira/browse/HBASE-2256
>
> Regards
> Kevin
>

[jira] [Resolved] (HBASE-22241) Fix TestRegionServerCoprocessorEndpoint

[Duo Zhang (JIRA)]

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

Duo Zhang resolved HBASE-22241.
---
   Resolution: Fixed
 Assignee: Duo Zhang
 Hadoop Flags: Reviewed
Fix Version/s: HBASE-21512

Merged to branch HBASE-21512.

Thanks [~carp84] for reviewing.

> Fix TestRegionServerCoprocessorEndpoint
> ---
>
> Key: HBASE-22241
> URL: https://issues.apache.org/jira/browse/HBASE-22241
> Project: HBase
>  Issue Type: Sub-task
>  Components: test
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: HBASE-21512
>
>
> In AsyncAdmin we will unwrap the RemoteException so the assertion should be 
> changed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-22239) Should translate the exception before returning it in AsyncRegionServerAdmin

[Duo Zhang (JIRA)]

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

Duo Zhang resolved HBASE-22239.
---
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: HBASE-21512

Merged to branch HBASE-21512.

> Should translate the exception before returning it in AsyncRegionServerAdmin
> 
>
> Key: HBASE-22239
> URL: https://issues.apache.org/jira/browse/HBASE-22239
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: HBASE-21512
>
>
> This breaks TestSyncReplicationActive.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-22242) Remove deprecated method in RegionLoadStats

[Jan Hentschel (JIRA)]

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

Jan Hentschel resolved HBASE-22242.
---
   Resolution: Fixed
Fix Version/s: 3.0.0

> Remove deprecated method in RegionLoadStats
> ---
>
> Key: HBASE-22242
> URL: https://issues.apache.org/jira/browse/HBASE-22242
> Project: HBase
>  Issue Type: Task
>  Components: Client
>Reporter: Jan Hentschel
>Assignee: Jan Hentschel
>Priority: Trivial
> Fix For: 3.0.0
>
>
> getMemstoreLoad() in RegionLoadStats was deprecated back in 2.0.0 and should 
> be removed for 3.0.0.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)