[jira] [Created] (HBASE-26880) Misspelling commands in hbase shell will crash the shell

[Evan Krettek (Jira)]

Evan Krettek created HBASE-26880:


 Summary: Misspelling commands in hbase shell will crash the shell
 Key: HBASE-26880
 URL: https://issues.apache.org/jira/browse/HBASE-26880
 Project: HBase
  Issue Type: Bug
  Components: shell
Affects Versions: 2.4.10
Reporter: Evan Krettek


Misspelling commands in hbase shell will crash the shell, e.g.

hbase:001:0> hlep

NameError: undefined local variable or method `hlep' for 
#

Did you mean?  help

                  evaluate at (hbase):1

                      eval at org/jruby/RubyKernel.java:1048

                  evaluate at 
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/workspace.rb:85

                  evaluate at 
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/context.rb:380

                eval_input at uri:classloader:/irb/hirb.rb:112

             signal_status at 
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb.rb:623

                eval_input at uri:classloader:/irb/hirb.rb:109

  each_top_level_statement at 
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:246

                      loop at org/jruby/RubyKernel.java:1442

  each_top_level_statement at 
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:232

                     catch at org/jruby/RubyKernel.java:1189

  each_top_level_statement at 
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb/ruby-lex.rb:231

                eval_input at uri:classloader:/irb/hirb.rb:108

                       run at 
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb.rb:428

                     catch at org/jruby/RubyKernel.java:1189

                       run at 
uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/irb.rb:427

                     at classpath:/jar-bootstrap.rb:221



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (HBASE-26879) Allow Accepting snapshot location also to mapreduce jobs to run over exported snapshot.

[Rajeshbabu Chintaguntla (Jira)]

Rajeshbabu Chintaguntla created HBASE-26879:
---

 Summary: Allow Accepting snapshot location also to mapreduce jobs 
to run over exported snapshot.
 Key: HBASE-26879
 URL: https://issues.apache.org/jira/browse/HBASE-26879
 Project: HBase
  Issue Type: Improvement
  Components: snapshots
Reporter: Rajeshbabu Chintaguntla
Assignee: Rajeshbabu Chintaguntla


Currently there is no way to provide the snapshot location to mapreduce jobs to 
run over the exported snapshot. It would be better to provide the option so 
that even we can scan snapshots available at exported location.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: Request to be added as a contributor

[Ray Mattingly]

Amazing, thank you!

Have a good one,
Ray

On Tue, Mar 22, 2022 at 11:53 AM Nick Dimiduk  wrote:

> I have added you as a contributor. You may need to log out and back in
> again for the permission change to take effect.
>
> Thanks,
> Nick
>
> On Tue, Mar 22, 2022 at 4:49 PM Ray Mattingly
>  wrote:
>
> > No sweat! :)
> >
> > On Tue, Mar 22, 2022 at 11:48 AM Nick Dimiduk 
> wrote:
> >
> > > Err. Ray. Sorry :(
> > >
> > > On Tue, Mar 22, 2022 at 4:45 PM Nick Dimiduk 
> > wrote:
> > >
> > > > Hi Matt,
> > > >
> > > > Thank you for your interest. Do you have an account on our Jira
> > instance?
> > > > What is your user ID?
> > > >
> > > > Thanks,
> > > > Nick
> > > >
> > > > On Tue, Mar 22, 2022 at 4:28 PM Ray Mattingly
> > > >  wrote:
> > > >
> > > >> Hello,
> > > >>
> > > >> I'm a SWE at HubSpot and would love to start contributing upstream —
> > > >> probably, first, with a solution for
> > > >> https://issues.apache.org/jira/browse/HBASE-26874
> 
> > >  
> >
> > > >>  
> > >  
> >
> > > >
> > > >> that
> > > >> we've been using at HubSpot for a few months now.
> > > >>
> > > >> Can I please be added as a contributor?
> > > >>
> > > >> Thanks,
> > > >> Ray Mattingly
> > > >>
> > > >
> > >
> >
>

Re: Request to be added as a contributor

[Nick Dimiduk]

I have added you as a contributor. You may need to log out and back in
again for the permission change to take effect.

Thanks,
Nick

On Tue, Mar 22, 2022 at 4:49 PM Ray Mattingly
 wrote:

> No sweat! :)
>
> On Tue, Mar 22, 2022 at 11:48 AM Nick Dimiduk  wrote:
>
> > Err. Ray. Sorry :(
> >
> > On Tue, Mar 22, 2022 at 4:45 PM Nick Dimiduk 
> wrote:
> >
> > > Hi Matt,
> > >
> > > Thank you for your interest. Do you have an account on our Jira
> instance?
> > > What is your user ID?
> > >
> > > Thanks,
> > > Nick
> > >
> > > On Tue, Mar 22, 2022 at 4:28 PM Ray Mattingly
> > >  wrote:
> > >
> > >> Hello,
> > >>
> > >> I'm a SWE at HubSpot and would love to start contributing upstream —
> > >> probably, first, with a solution for
> > >> https://issues.apache.org/jira/browse/HBASE-26874
> > 
> > >>  > 
> > >
> > >> that
> > >> we've been using at HubSpot for a few months now.
> > >>
> > >> Can I please be added as a contributor?
> > >>
> > >> Thanks,
> > >> Ray Mattingly
> > >>
> > >
> >
>

Re: Request to be added as a contributor

[Ray Mattingly]

No sweat! :)

On Tue, Mar 22, 2022 at 11:48 AM Nick Dimiduk  wrote:

> Err. Ray. Sorry :(
>
> On Tue, Mar 22, 2022 at 4:45 PM Nick Dimiduk  wrote:
>
> > Hi Matt,
> >
> > Thank you for your interest. Do you have an account on our Jira instance?
> > What is your user ID?
> >
> > Thanks,
> > Nick
> >
> > On Tue, Mar 22, 2022 at 4:28 PM Ray Mattingly
> >  wrote:
> >
> >> Hello,
> >>
> >> I'm a SWE at HubSpot and would love to start contributing upstream —
> >> probably, first, with a solution for
> >> https://issues.apache.org/jira/browse/HBASE-26874
> 
> >>  
> >
> >> that
> >> we've been using at HubSpot for a few months now.
> >>
> >> Can I please be added as a contributor?
> >>
> >> Thanks,
> >> Ray Mattingly
> >>
> >
>

Re: Request to be added as a contributor

[Ray Mattingly]

Yes I do — the user ID is rmdmattingly

Thanks!

On Tue, Mar 22, 2022 at 11:45 AM Nick Dimiduk  wrote:

> Hi Matt,
>
> Thank you for your interest. Do you have an account on our Jira instance?
> What is your user ID?
>
> Thanks,
> Nick
>
> On Tue, Mar 22, 2022 at 4:28 PM Ray Mattingly
>  wrote:
>
> > Hello,
> >
> > I'm a SWE at HubSpot and would love to start contributing upstream —
> > probably, first, with a solution for
> > https://issues.apache.org/jira/browse/HBASE-26874
> 
> >  
> >
> > that
> > we've been using at HubSpot for a few months now.
> >
> > Can I please be added as a contributor?
> >
> > Thanks,
> > Ray Mattingly
> >
>

Re: Request to be added as a contributor

[Nick Dimiduk]

Err. Ray. Sorry :(

On Tue, Mar 22, 2022 at 4:45 PM Nick Dimiduk  wrote:

> Hi Matt,
>
> Thank you for your interest. Do you have an account on our Jira instance?
> What is your user ID?
>
> Thanks,
> Nick
>
> On Tue, Mar 22, 2022 at 4:28 PM Ray Mattingly
>  wrote:
>
>> Hello,
>>
>> I'm a SWE at HubSpot and would love to start contributing upstream —
>> probably, first, with a solution for
>> https://issues.apache.org/jira/browse/HBASE-26874
>> 
>> that
>> we've been using at HubSpot for a few months now.
>>
>> Can I please be added as a contributor?
>>
>> Thanks,
>> Ray Mattingly
>>
>

Re: Request to be added as a contributor

[Nick Dimiduk]

Hi Matt,

Thank you for your interest. Do you have an account on our Jira instance?
What is your user ID?

Thanks,
Nick

On Tue, Mar 22, 2022 at 4:28 PM Ray Mattingly
 wrote:

> Hello,
>
> I'm a SWE at HubSpot and would love to start contributing upstream —
> probably, first, with a solution for
> https://issues.apache.org/jira/browse/HBASE-26874
> 
> that
> we've been using at HubSpot for a few months now.
>
> Can I please be added as a contributor?
>
> Thanks,
> Ray Mattingly
>

Request to be added as a contributor

[Ray Mattingly]

Hello,

I'm a SWE at HubSpot and would love to start contributing upstream —
probably, first, with a solution for
https://issues.apache.org/jira/browse/HBASE-26874

that
we've been using at HubSpot for a few months now.

Can I please be added as a contributor?

Thanks,
Ray Mattingly

[jira] [Reopened] (HBASE-21065) Try ROW_INDEX_V1 encoding on meta table (fix bloomfilters on meta while we are at it)

[Andrew Kyle Purtell (Jira)]

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

Andrew Kyle Purtell reopened HBASE-21065:
-
  Assignee: Andrew Kyle Purtell  (was: Michael Stack)

Reopening to consider for 2.5.0. Let me make the change and run some tests.

> Try ROW_INDEX_V1 encoding on meta table (fix bloomfilters on meta while we 
> are at it)
> -
>
> Key: HBASE-21065
> URL: https://issues.apache.org/jira/browse/HBASE-21065
> Project: HBase
>  Issue Type: Improvement
>  Components: meta, Performance
>Reporter: Michael Stack
>Assignee: Andrew Kyle Purtell
>Priority: Major
> Fix For: 3.0.0-alpha-1
>
>
> Some users end up hitting meta hard. Bulk is probably because our client goes 
> to meta too often, and the real 'fix' for a saturated meta is splitting it, 
> but the encoding that came in with HBASE-16213, ROW_INDEX_V1, could help in 
> the near term. It adds an index on hfile blocks and helped improve random 
> reads against user-space tables (less compares as we used index to go direct 
> to requested Cells rather than look at each Cell in turn until we found what 
> we wanted -- see RN on HBASE-16213 for citation).
> I also noticed code-reading that we don't enable blooms on hbase:meta tables; 
> that could save some CPU and speed things up a bit too:
> {code}
> // Disable blooms for meta.  Needs work.  Seems to mess w/ 
> getClosestOrBefore.
> .setBloomFilterType(BloomType.NONE)
> {code}
> This issue is about doing a bit of perf compare of encoding *on* vs current 
> default (and will check diff in size of indexed blocks).
> Meta access is mostly random-read I believe (A review of a user's access 
> showed this so at least for their workload). The nice addition, HBASE-19722 
> Meta query statistics metrics source, would help verify if it saw some usage 
> on a prod cluster.
> If all is good, I'd like to make a small patch, one that could be easily 
> backported, with minimal changes in it.
> As is, its all a little awkward as the meta table schema is hard-coded and 
> meta is immutable -- stuff we'll have to fix if we want to split meta -- so 
> in the meantime it requires a code change to enable (and a backport of 
> HBASE-16213 -- this patch is in 1.4.0 only currently, perhaps that is 
> enough). Code change to enable is small:
> {code}
> diff --git 
> a/hbase-server/src/main/java/org/apache/hadoop/hbase/util/FSTableDescriptors.java
>  
> b/hbase-server/src/main/java/org/apache/hadoop/hbase/util/FSTableDescriptors.java
> index 28c7ec3c2f..8f08f94dc1 100644
> --- 
> a/hbase-server/src/main/java/org/apache/hadoop/hbase/util/FSTableDescriptors.java
> +++ 
> b/hbase-server/src/main/java/org/apache/hadoop/hbase/util/FSTableDescriptors.java
> @@ -160,6 +160,7 @@ public class FSTableDescriptors implements 
> TableDescriptors {
>  .setScope(HConstants.REPLICATION_SCOPE_LOCAL)
>  // Disable blooms for meta.  Needs work.  Seems to mess w/ 
> getClosestOrBefore.
>  .setBloomFilterType(BloomType.NONE)
> +
> .setDataBlockEncoding(org.apache.hadoop.hbase.io.encoding.DataBlockEncoding.ROW_INDEX_V1)
>  .build())
>
> .setColumnFamily(ColumnFamilyDescriptorBuilder.newBuilder(HConstants.TABLE_FAMILY)
>  .setMaxVersions(conf.getInt(HConstants.HBASE_META_VERSIONS,
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (HBASE-26878) TableInputFormatBase should cache RegionSizeCalculator

[Bryan Beaudreault (Jira)]

Bryan Beaudreault created HBASE-26878:
-

 Summary: TableInputFormatBase should cache RegionSizeCalculator
 Key: HBASE-26878
 URL: https://issues.apache.org/jira/browse/HBASE-26878
 Project: HBase
  Issue Type: Improvement
Reporter: Bryan Beaudreault
Assignee: Bryan Beaudreault


TableInputFormatBase's getSplits() method instantiates a new 
RegionSizeCalculator every time. Instantiating a RegionSizeCalculator involves 
scanning for all regionlocations for a given table in meta. This can be costly 
for large tables, and we don't know how often a subclass will call getSplits().

When initializeTable is called, we already cache the RegionLocator and Admin 
that are used for passing into the RegionSizeCalculator. We should similarly 
cache the RegionSizeCalculator itself at that same time to avoid unnecessary 
meta scans on repeat getSplits() calls.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)