[
https://issues.apache.org/jira/browse/HBASE-22776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yi Mei resolved HBASE-22776.
Resolution: Fixed
> Rename config names in user scan snapshot feature
>
Balazs Meszaros created HBASE-22817:
---
Summary: Use hbase-shaded dependencies in hbase-spark
Key: HBASE-22817
URL: https://issues.apache.org/jira/browse/HBASE-22817
Project: HBase
Issue
[
https://issues.apache.org/jira/browse/HBASE-22821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey resolved HBASE-22821.
-
Resolution: Invalid
please bring these kinds of questions to the
This is great, but in the future please refrain from borderline marketing
of a commercial product on these lists. This is not the appropriate venue
for that.
It is especially poor form to dump on a fellow open source project, as you
claim to be. This I think is the tell behind the commercial
Viraj Jasani created HBASE-22822:
Summary: Re/Un-schedule balancer chore for balance_switch
Key: HBASE-22822
URL: https://issues.apache.org/jira/browse/HBASE-22822
Project: HBase
Issue Type:
Ok, in that spirit let me say I've always found Apache Trafodion to be
interesting and credible technology and worthy of anyone's consideration.
On Thu, Aug 8, 2019 at 1:34 PM Rohit Jain wrote:
> Andrew,
>
> I would never dump on Apache Phoenix. I have worked with James for years
> and have
Just want to chime in with my Phoenix PMC hat on and say that there are no
current plans endorsed by the PMC to "split" Phoenix away from HBase. I'm
not even aware of any JIRAs proposing such a thing, though if the anonymous
Phoenix committer at HBaseCon Asia wants to make one, he or she is of
Andrew Purtell created HBASE-22823:
--
Summary: Mark Canary as Public/Evolving
Key: HBASE-22823
URL: https://issues.apache.org/jira/browse/HBASE-22823
Project: HBase
Issue Type: Sub-task
Don't we first write to WAL and then memstore? Getting confused here, sorry.
JMS
Le mer. 7 août 2019 13 h 22, Udai Bhan Kashyap (BLOOMBERG/ PRINCETON) <
ukashy...@bloomberg.net> a écrit :
> memstore is written first and if write(s) to WAL fails, they are rolled
> back.
>
> From:
Please let me direct your attention to the tail of HBASE-22623 for a larger
discussion. I tried to sum it up as follows:
An opinion that we should have more and more coprocessor interfaces to
address new use cases is valid. An opinion that coprocessors are too
invasive and should be 'cleaned up'
Hi folks,
This is a nice write-up of the round-table meeting at HBaseConAsia. I would
like to address the points I have pulled out from write-up (at the bottom of
this message).
Many in the HBase community may not be aware that besides Apache Phoenix, there
has been a project called Apache
Andrew,
I would never dump on Apache Phoenix. I have worked with James for years and
have always wanted to see how we could collaborate on various aspects,
including common data type support and transaction management, to name a few.
I think the challenges we faced is the Java vs C++ nature
On Thu, Aug 8, 2019 at 11:49 AM Jean-Marc Spaggiari
wrote:
> Don't we first write to WAL and then memstore? Getting confused here,
> sorry.
>
>
You are right JMS. IIRC, Udai is correct for older versions of HBase; the
memstore update would get rolled back if the concurrent WAL write failed.
S
[
https://issues.apache.org/jira/browse/HBASE-22809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-22809.
---
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: HBASE-22514
Pushed to branch
Guanghao Zhang created HBASE-22824:
--
Summary: Show filesystem path for the orphans regions on filesystem
Key: HBASE-22824
URL: https://issues.apache.org/jira/browse/HBASE-22824
Project: HBase
When releasing 2.0.0 we faced a lot of problems because we exposes so many
internal classes to CPs. It is really hard to both consider the
compatibility and development on HBase. And then we have done lots of works
to abstract interfaces for CPs to use and hide the actual implementation
classes to
[
https://issues.apache.org/jira/browse/HBASE-22818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki resolved HBASE-22818.
--
Resolution: Duplicate
This issue was fixed by HBASE-20784. Resolving as Duplicate.
>
There are a bunch of issues raised here, some micro and some macro. I'll
tackle them in two separate messages so they're short(ish) enough for
people to bother reading. :-) For this one I wear my "HBase contributor"
hat.
First the micro, which is my patch on HBASE-22623 which sparked a lot of
Duo Zhang created HBASE-22820:
-
Summary: Do not need to persist default rs group now
Key: HBASE-22820
URL: https://issues.apache.org/jira/browse/HBASE-22820
Project: HBase
Issue Type: Sub-task
[
https://issues.apache.org/jira/browse/HBASE-15666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang reopened HBASE-15666:
The patch for branch-2 broken the maven build. Need to change the version from
jay created HBASE-22821:
---
Summary: The application get stuck when put data to hbase table
Key: HBASE-22821
URL: https://issues.apache.org/jira/browse/HBASE-22821
Project: HBase
Issue Type: Test
[
https://issues.apache.org/jira/browse/HBASE-22808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang reopened HBASE-22808:
Attached a addendum patch for branch-2.2.
> HBCK Report showed the offline regions which
Duo Zhang created HBASE-22819:
-
Summary: Automatically migrate the rs group config for table after
HBASE-22695
Key: HBASE-22819
URL: https://issues.apache.org/jira/browse/HBASE-22819
Project: HBase
Olivier Delhomme created HBASE-22818:
Summary: regionserver's version in master status page
Key: HBASE-22818
URL: https://issues.apache.org/jira/browse/HBASE-22818
Project: HBase
Issue
[
https://issues.apache.org/jira/browse/HBASE-22808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang resolved HBASE-22808.
Resolution: Fixed
Fix Version/s: 2.1.6
2.2.1
25 matches
Mail list logo
