Michael Stack created HBASE-24623:
-
Summary: SIGSEGV v ~StubRoutines::jbyte_disjoint_arraycopy
Key: HBASE-24623
URL: https://issues.apache.org/jira/browse/HBASE-24623
Project: HBase
Issue
I would like to make sure I am emphatically clear that "master" by itself
is not okay if the context is the same as what would normally be a
master/slave context. Furthermore our use of master is clearly such a
context.
It seems to me we have, broadly speaking, consensus around making *some*
+1 to "do it in javadoc" unless there's some magic for IDEs brought about
via the VFT annotation that I'm missing.
On Tue, Jun 23, 2020, 13:04 Andrew Purtell wrote:
> I don't find the VisibleForTesting annotation provides a lot of value. It
> became fashionable to use this annotation when a
Let's fix via approach #3. Get it done for next minor versions and then if
folks aren't sure about principle of least surprise we can talk about
wether it goes into maintenance releases.
On Tue, Jun 23, 2020, 13:07 Andrew Purtell wrote:
> > Current IncreasingToUpperBoundRegionSplitPolicy
Marc Parisi created HBASE-24622:
---
Summary: Download CyrusSasl and DoubleConversion
Key: HBASE-24622
URL: https://issues.apache.org/jira/browse/HBASE-24622
Project: HBase
Issue Type: Sub-task
Marc Parisi created HBASE-24621:
---
Summary: Update to c++17
Key: HBASE-24621
URL: https://issues.apache.org/jira/browse/HBASE-24621
Project: HBase
Issue Type: Sub-task
Reporter:
> Current IncreasingToUpperBoundRegionSplitPolicy implementation is
violating those configs.
Thank you for pointing this out. I feel even more strongly now this is a
bug.
I vote for #3.
On Tue, Jun 23, 2020 at 2:42 AM Wellington Chevreuil <
wellington.chevre...@gmail.com> wrote:
> >
> > The
I don't find the VisibleForTesting annotation provides a lot of value. It
became fashionable to use this annotation when a single line of Javadoc
would serve the same purpose and not make yet another dependency on Guava.
My advice is to remove them all and replace with Javadoc.
Even if in an
I think the intent behind VisibleForTesting is clear: the person using that
annotation does not intend for it to be used by downstreamers.
However, our stated API promises are in terms of the Interface Audience
annotations only. So I think a downsteamer who e.g. used automated tooling
to ensure
[
https://issues.apache.org/jira/browse/HBASE-24205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ramkrishna.s.vasudevan resolved HBASE-24205.
Resolution: Fixed
Pushed to 2.3 and 2.2 branches also. Thanks
My hope is that we can clarify our policy and update the book accordingly.
On Tue, Jun 23, 2020 at 9:01 AM Wellington Chevreuil <
wellington.chevre...@gmail.com> wrote:
> >
> > For the current problem, what is the class? I think changing a method
> > signature for a protected method will only
[
https://issues.apache.org/jira/browse/HBASE-24446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani resolved HBASE-24446.
--
Fix Version/s: (was: 2.4.0)
2.2.6
2.3.0
>
> For the current problem, what is the class? I think changing a method
> signature for a protected method will only break the compatibility when
> users extend the class.
>
This specific case is *LoadIncrementalHFiles.tryAtomicRegionLoad, *mostly
an end user tool, not likely to be extended.
[
https://issues.apache.org/jira/browse/HBASE-21773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wellington Chevreuil resolved HBASE-21773.
--
Resolution: Fixed
Pushed addendum PR to branch-2.3, branch-2 and master
[
https://issues.apache.org/jira/browse/HBASE-24446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani reopened HBASE-24446:
--
Reopening for further backports.
> Use EnvironmentEdgeManager to compute clock skew in Master
>
Technically, I do not think the developer who makes a field or method
public for an IA.Public class but marks it with @VisibleForTesting,
actually wants to expose this field or method to end users.
But this could be a problem for end users, so I think we should avoid doing
this on an IA.Public
[
https://issues.apache.org/jira/browse/HBASE-24217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk resolved HBASE-24217.
--
Fix Version/s: 2.2.5
2.3.0
3.0.0-alpha-1
Release
[
https://issues.apache.org/jira/browse/HBASE-24231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk resolved HBASE-24231.
--
Fix Version/s: 3.0.0-alpha-1
Resolution: Fixed
> Add hadoop 3.2.x in our support
My opinion expressed on the 2.3.0RC0 thread was that @VisibleForTesting
would flag class/method/variable as private. I believe the annotation label
is pretty suggestive and (I also believe) it's common sense that it should
be treated as private by developers. I don't think the fact it's
omitted
I also share the former opinion from two opinions provided by Nick. And I also
thought that Nick and Sean were of the same opinion that @VisibleForTesting is
only intended for our project and should not be treated as public API by
downstreamers.
After Bharath's reply, I again went through the
Lokesh Khurana created HBASE-24620:
--
Summary: Add a ClusterManager which submits command to ZooKeeper
and its Agent which picks and execute those Commands.
Key: HBASE-24620
URL:
>
> The config name was/is hbase.hregion.max.*filesize* and never *
> hbase.hregion.max.size*.
>
Description for hbase.hregion.max.filesize is very clear stating that it's
the sum of all hfiles in the region that should not exceed this property
value. And we not always use
[
https://issues.apache.org/jira/browse/HBASE-24579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wellington Chevreuil resolved HBASE-24579.
--
Resolution: Fixed
Thanks for the contribution, [~bszabolcs]! Had merged last
Guanghao Zhang created HBASE-24619:
--
Summary: Try compact the recovered hfiles firstly after region
online
Key: HBASE-24619
URL: https://issues.apache.org/jira/browse/HBASE-24619
Project: HBase
24 matches
Mail list logo
