zhangduo created HBASE-13164:
Summary: Update TestUsersOperationsWithSecureHadoop to use MiniKdc
Key: HBASE-13164
URL: https://issues.apache.org/jira/browse/HBASE-13164
Project: HBase
Issue Type:
Misty Stanley-Jones created HBASE-13163:
---
Summary: Add HBase version to header and footer of HTML and PDF
docs
Key: HBASE-13163
URL: https://issues.apache.org/jira/browse/HBASE-13163
Project: HB
The way some of the RPC's are done today is kind of negotiation
after-the-fact. So the client does an RPC, it can fail with
NoSuchMethodException, in which case the client should fallback if the
operation is supported in the old version (like create table). In some
cases where we add a new field in
> We want a 3.0 client able to talk to a 2.0 cluster?
Not necessarily. But a 2.0 client to talk to a 3.0? You bet :)If pb is good
enough to have us never break the protocol between an old client and new server
even across major version, I (with my work hat on) am happy.
-- Lars
From: Stack
+1 doing patch releases more frequently, and doing minor releases on a
per-need basis and if an RM volunteers to drive a minor version.
Every minor release we do will come up with its own branch, and we might
end up with a lot of active branches to accept bug fixes which might put
some burden on t
On Thu, Mar 5, 2015 at 4:23 PM, lars hofhansl wrote:
> Thanks Nick, yep, that's exactly how we should phrase it (IMHO, anyway).
> Does this need clarification in the book?
>
> So... Should we think about client-server protocol version negotiation,
> maybe in 2.0? We'd need the negotiation itself,
Yeah. Would need to define a set of features first. A version would simply
stand for a distinct set of supported features... I agree that'd be less
flexible.
From: Todd Lipcon
To: dev
Cc: lars hofhansl
Sent: Thursday, March 5, 2015 4:17 PM
Subject: Re: Client-Server wire compatibil
Thanks Nick, yep, that's exactly how we should phrase it (IMHO, anyway). Does
this need clarification in the book?
So... Should we think about client-server protocol version negotiation, maybe
in 2.0? We'd need the negotiation itself, as well as some refactoring to pass
that version information
If you add a negotiation phase, I'd recommend doing it in terms of a
list rather than a version number. That makes it much
easier to backport new features across branches without being forced to
backport all other features that might have been introduced between the two.
-Todd
Srikanth Srungarapu created HBASE-13162:
---
Summary: Add capability for cleaning hbase acls to hbase cleanup
script.
Key: HBASE-13162
URL: https://issues.apache.org/jira/browse/HBASE-13162
Project
Search google "how to run jobs in parallel in Hadoop"
Your mapreduce configuration allows you to run one job at a time. This
usually happens
when number of job's tasks exceeds capacity of a cluster.
-Vlad
On Thu, Mar 5, 2015 at 3:03 PM, Siva wrote:
> Hi All,
>
>
>
> I’m loading data to Hbase
stack created HBASE-13161:
-
Summary: ITBLL needs love; verify spins w/o end at 10B rows
Key: HBASE-13161
URL: https://issues.apache.org/jira/browse/HBASE-13161
Project: HBase
Issue Type: Bug
[
https://issues.apache.org/jira/browse/HBASE-13128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliott Clark resolved HBASE-13128.
---
Resolution: Fixed
Fix Version/s: 1.1.0
2.0.0
Hadoop Flags: Revi
Then to answer Matteo's original question, I guess the answer is "it
depends". If the client embedded in servers is never used to call your
modified RPC, we're fine with new clients not working with old servers.
However, if it's a server that's using the modified RPC (new RS using new
client to sca
+1 client-server negotation
I filed several JIRAs regarding connection setup negotiation around the
0.98.0 timeframe. I wanted to negotiate what cell codecs should be used on
the connection, somehow compatible with 0.96. Unfortunately this didn't
bear fruit. We should definitely have client-server
Hi All,
I’m loading data to Hbase by using Hbase ImportTsv utility. When I kick off
this process simultaneously for different tables in different sessions,
both the process starts in parallel till it reaches the map reduce program.
Once one of the process kicks off map reduce job for one table,
Enis Soztutar created HBASE-13160:
-
Summary: SplitLogWorker does not pick up the task immediately
Key: HBASE-13160
URL: https://issues.apache.org/jira/browse/HBASE-13160
Project: HBase
Issue
Everything should be back to normal! Thanks for your patience.
On Fri, Mar 6, 2015 at 7:35 AM, Nick Dimiduk wrote:
> Maybe break it into smaller commits?
>
> On Thu, Mar 5, 2015 at 12:58 PM, Misty Stanley-Jones <
> mstanleyjo...@cloudera.com> wrote:
>
> > The transfer of the apidocs, devapidocs,
Maybe break it into smaller commits?
On Thu, Mar 5, 2015 at 12:58 PM, Misty Stanley-Jones <
mstanleyjo...@cloudera.com> wrote:
> The transfer of the apidocs, devapidocs, xref, and xref-test is STILL in
> progress. :/ Hopefully soon.
>
> On Fri, Mar 6, 2015 at 3:39 AM, Andrew Purtell
> wrote:
>
>
To take a step... The discussion was around whether we can generally break a
new client talking an old cluster.From a client-server perspective that should
be OK (IMHO), and that is how we stated it in the compatibility doc.
If the client-server protocol is broken in such a way that (f.e.) an new
I'd say as long as there are folks who contribute patches we can do patch
releases for older minor releases. It's open source :)
Keeping *all* minor releases alive seem onerous (there could be dozens - unless
we significantly drive down the time between major releases).Could do the Linux
model
The transfer of the apidocs, devapidocs, xref, and xref-test is STILL in
progress. :/ Hopefully soon.
On Fri, Mar 6, 2015 at 3:39 AM, Andrew Purtell wrote:
> Yay! Thanks
>
> On Thu, Mar 5, 2015 at 5:23 AM, Misty Stanley-Jones <
> mstanleyjo...@cloudera.com> wrote:
>
> > Website is back (includin
It sounds to me like we have consensus around monthly for patch releases
and minor releases on demand, provided we can find RMs.
Would it be reasonable to keep all the minor release lines active until we
have a newer major release? At that point we could keep just the most
recent minor release goi
On Thu, Mar 5, 2015 at 12:24 PM, Stack wrote:
> On Thu, Mar 5, 2015 at 12:18 PM, lars hofhansl wrote:
>
> > Then we have broken server-server compatibility, which the doc state we
> > won't break for patch and minor versions.
>
> What is broke? A 1.1 client can't scan a 1.0 meta?
>
My thinking
Lars Hofhansl created HBASE-13159:
-
Summary: Consider RangeReferences with transformations
Key: HBASE-13159
URL: https://issues.apache.org/jira/browse/HBASE-13159
Project: HBase
Issue Type: B
Any further comments on this?
Seems important to get agreement at least generally.
-- Lars
From: lars hofhansl
To: "dev@hbase.apache.org"
Sent: Monday, March 2, 2015 10:26 PM
Subject: Re: Minor release cadence for branch-1
Hmmm...
I had only expect a monthly patch cadence for minor
On Thu, Mar 5, 2015 at 12:18 PM, lars hofhansl wrote:
> Then we have broken server-server compatibility, which the doc state we
> won't break for patch and minor versions.
>
What is broke? A 1.1 client can't scan a 1.0 meta?
St.Ack
> -- Lars
> From: Andrey Stepachev
> To: dev@hbase.
Then we have broken server-server compatibility, which the doc state we won't
break for patch and minor versions.
-- Lars
From: Andrey Stepachev
To: dev@hbase.apache.org
Sent: Thursday, March 5, 2015 9:48 AM
Subject: Re: Client-Server wire compatibility?
Hi Nick,
> I suppose it's p
[
https://issues.apache.org/jira/browse/HBASE-13151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh resolved HBASE-13151.
Resolution: Fixed
Hadoop Flags: Reviewed
> IllegalArgumentException in compaction whe
[
https://issues.apache.org/jira/browse/HBASE-13107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh resolved HBASE-13107.
Resolution: Fixed
Hadoop Flags: Reviewed
lgtm. thanks jingcheng! committed to hbase
Thanks for confirming Andrey.
In this case, I think the appropriate approach would be for the new client
to first attempt the new RPC, look for a NoSuchMethod kind of exception,
and fall back to the old RPC. This transparent fallback would be required
as long as online compatibility is required.
[
https://issues.apache.org/jira/browse/HBASE-12332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh resolved HBASE-12332.
Resolution: Fixed
Hadoop Flags: Reviewed
Thanks for the patience Jiajia, I've committ
Hi Nick,
> I suppose it's possible the client in the master is never used outside of
localhost, I haven't checked that bit.
Client is definitely used to access meta, which can be hosted anywhere,
so basically we can face with situation when master is upgraded and
hits old region server.
On Thu,
Nice to hear from Heinrich. You should be able to edit the page now.
yours,
St.Ack
On Thu, Mar 5, 2015 at 8:16 AM, Heinrich von Keler <
heinrich.von.ke...@axibase.com> wrote:
> Dear Sirs,
>
>
>
> Our company Axibase has created a product based on HBase, called the
> Axibase
> Time Series Database
On Thu, Mar 5, 2015 at 12:10 AM, Matteo Bertozzi
wrote:
> On Thu, Mar 5, 2015 at 4:20 AM, lars hofhansl wrote:
>
> > The idea actually was that a new client can never be 100% supported,
> since
> > a user could use it accessing new features that the server does not
> > understand.
>
>
> I think
Yay! Thanks
On Thu, Mar 5, 2015 at 5:23 AM, Misty Stanley-Jones <
mstanleyjo...@cloudera.com> wrote:
> Website is back (including PDF of the Ref Guide, accessible from the
> Documentation menu on the site). apidocs, devapidocs, xref, and xref-test
> will hopefully be done soon.
>
> On Thu, Mar 5,
Dear Sirs,
Our company Axibase has created a product based on HBase, called the Axibase
Time Series Database.
http://axibase.com/products/axibase-time-series-database/
We have would like to add our company to powered by HBase page:
https://wiki.apache.org/hadoop/Hbase/PoweredBy
ATS
[
https://issues.apache.org/jira/browse/HBASE-9066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-9066.
--
Resolution: Cannot Reproduce
Resolving as cannot reproduce
> TestReplicationTrackerZKImpl fails
> -
Website is back (including PDF of the Ref Guide, accessible from the
Documentation menu on the site). apidocs, devapidocs, xref, and xref-test
will hopefully be done soon.
On Thu, Mar 5, 2015 at 7:17 PM, Misty Stanley-Jones <
mstanleyjo...@cloudera.com> wrote:
> Still working on it. The SVN commi
Still working on it. The SVN commit of 18,000 files takes a long time. :(
On Thu, Mar 5, 2015 at 11:48 AM, Misty Stanley-Jones <
mstanleyjo...@cloudera.com> wrote:
> Working on it.
>
> On Thu, Mar 5, 2015 at 10:51 AM, Andrew Purtell
> wrote:
>
>> <
>> /eom>
>>
>
>
Anoop Sam John created HBASE-13158:
--
Summary: When client supports CellBlock, return the result Cells
as controller payload for get(Get) API also
Key: HBASE-13158
URL: https://issues.apache.org/jira/browse/HBASE-
On Thu, Mar 5, 2015 at 4:20 AM, lars hofhansl wrote:
> The idea actually was that a new client can never be 100% supported, since
> a user could use it accessing new features that the server does not
> understand.
I think that it is fine if we have exceptions not handled when a client
tries to
[
https://issues.apache.org/jira/browse/HBASE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Hsieh resolved HBASE-13012.
Resolution: Fixed
Hadoop Flags: Reviewed
> Add shell commands to trigger the mob file
43 matches
Mail list logo