[jira] [Commented] (HBASE-14960) Fallback to using default RPCControllerFactory if class cannot be loaded
[ https://issues.apache.org/jira/browse/HBASE-14960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058363#comment-15058363 ] Hudson commented on HBASE-14960: FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #1145 (See [https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/1145/]) HBASE-14960 Fallback to using default RPCControllerFactory if class (apurtell: rev ee1e453609e7838d8e447bea34b07fa27f11b336) * hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestRpcControllerFactory.java * hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcControllerFactory.java > Fallback to using default RPCControllerFactory if class cannot be loaded > > > Key: HBASE-14960 > URL: https://issues.apache.org/jira/browse/HBASE-14960 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.2.0, 1.3.0, 0.98.17 > > Attachments: HBASE-14960-0.98.patch, hbase-14960_v1.patch, > hbase-14960_v2.patch, hbase-14960_v3.patch, hbase-14960_v4.patch > > > In Phoenix + HBase clusters, the hbase-site.xml configuration will point to a > custom rpc controller factory which is a Phoenix-specific one to configure > the priorities for index and system catalog table. > However, sometimes these Phoenix-enabled clusters are used from pure-HBase > client applications resulting in ClassNotFoundExceptions in application code > or MapReduce jobs. Since hbase configuration is shared between > Phoenix-clients and HBase clients, having different configurations at the > client side is hard. > We can instead try to load up the RPCControllerFactory from conf, and if not > found, fallback to the default one (in case this is a pure HBase client). In > case Phoenix is already in the classpath, it will work as usual. > This does not affect the rpc scheduler factory since it is only used at the > server side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14967) Remove max-width constraint from website skin
[ https://issues.apache.org/jira/browse/HBASE-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-14967: Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to master. > Remove max-width constraint from website skin > - > > Key: HBASE-14967 > URL: https://issues.apache.org/jira/browse/HBASE-14967 > Project: HBase > Issue Type: Bug > Components: website >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-14967.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14804) HBase shell's create table command ignores 'NORMALIZATION_ENABLED' attribute
[
https://issues.apache.org/jira/browse/HBASE-14804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058361#comment-15058361
]
Hudson commented on HBASE-14804:
FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #1145 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/1145/])
HBASE-14804 HBase shell's create table command ignores (apurtell: rev
40d7fa2eccc881f0ebec5c001e9ddd6e27b75b09)
* hbase-shell/src/main/ruby/hbase/admin.rb
> HBase shell's create table command ignores 'NORMALIZATION_ENABLED' attribute
>
>
> Key: HBASE-14804
> URL: https://issues.apache.org/jira/browse/HBASE-14804
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.2.0, 1.1.2
>Reporter: Romil Choksi
>Assignee: Jean-Marc Spaggiari
>Priority: Minor
> Labels: beginner
> Fix For: 2.0.0, 1.2.0, 1.3.0, 0.98.17
>
> Attachments: HBASE-14804.v0-trunk.patch, HBASE-14804.v1-trunk.patch
>
>
> I am trying to create a new table and set the NORMALIZATION_ENABLED as true,
> but seems like the argument NORMALIZATION_ENABLED is being ignored. And the
> attribute NORMALIZATION_ENABLED is not displayed on doing a desc command on
> that table
> {code}
> hbase(main):020:0> create 'test-table-4', 'cf', {NORMALIZATION_ENABLED =>
> 'true'}
> An argument ignored (unknown or overridden): NORMALIZATION_ENABLED
> 0 row(s) in 4.2670 seconds
> => Hbase::Table - test-table-4
> hbase(main):021:0> desc 'test-table-4'
> Table test-table-4 is ENABLED
>
>
> test-table-4
>
>
> COLUMN FAMILIES DESCRIPTION
>
>
> {NAME => 'cf', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY => 'false',
> KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL =>
> 'FOREVER', COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOC
> KCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE => '0'}
>
>
> 1 row(s) in 0.0430 seconds
> {code}
> However, on doing an alter command on that table we can set the
> NORMALIZATION_ENABLED attribute for that table
> {code}
> hbase(main):022:0> alter 'test-table-4', {NORMALIZATION_ENABLED => 'true'}
> Unknown argument ignored: NORMALIZATION_ENABLED
> Updating all regions with the new schema...
> 1/1 regions updated.
> Done.
> 0 row(s) in 2.3640 seconds
> hbase(main):023:0> desc 'test-table-4'
> Table test-table-4 is ENABLED
>
>
> test-table-4, {TABLE_ATTRIBUTES => {NORMALIZATION_ENABLED => 'true'}
>
>
> COLUMN FAMILIES DESCRIPTION
>
>
> {NAME => 'cf', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY => 'false',
> KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL =>
> 'FOREVER', COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOC
> KCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE => '0'}
>
>
> 1 row(s) in 0.0190 seconds
> {code}
> I think it would be better to have a single step process to enable
> normalization while creating the table itself, rather than a two step process
> to alter the table later on to enable normalization
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14866) VerifyReplication should use peer configuration in peer connection
[
https://issues.apache.org/jira/browse/HBASE-14866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058362#comment-15058362
]
Hudson commented on HBASE-14866:
FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #1145 (See
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/1145/])
HBASE-14866 VerifyReplication and ReplicationAdmin should use full peer
(apurtell: rev 229c430fa144f1fc7a418a56e1ab180f5b4e3ff5)
* hbase-server/src/test/java/org/apache/hadoop/hbase/TestZooKeeper.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKConfig.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationStateZKImpl.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/SyncTable.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/TableOutputFormat.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationPeersZKImpl.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationStateBasic.java
* hbase-common/src/test/java/org/apache/hadoop/hbase/TestHBaseConfiguration.java
* hbase-server/src/test/java/org/apache/hadoop/hbase/zookeeper/TestZKConfig.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/replication/VerifyReplication.java
* hbase-client/src/test/java/org/apache/hadoop/hbase/zookeeper/TestZKUtil.java
* hbase-common/src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/replication/ReplicationAdmin.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/client/replication/TestReplicationAdmin.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/TableMapReduceUtil.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationEndpoint.java
* hbase-common/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKConfig.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationStateZKBase.java
* hbase-common/src/test/java/org/apache/hadoop/hbase/zookeeper/TestZKConfig.java
> VerifyReplication should use peer configuration in peer connection
> --
>
> Key: HBASE-14866
> URL: https://issues.apache.org/jira/browse/HBASE-14866
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Reporter: Gary Helmling
>Assignee: Gary Helmling
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: HBASE-14866-0.98.patch, HBASE-14866.patch,
> HBASE-14866_v1.patch, hbase-14866-branch-1-v1.patch, hbase-14866-v4.patch,
> hbase-14866-v5.patch, hbase-14866-v6.patch, hbase-14866_v2.patch,
> hbase-14866_v3.patch
>
>
> VerifyReplication uses the replication peer's configuration to construct the
> ZooKeeper quorum address for the peer connection. However, other
> configuration properties in the peer's configuration are dropped. It should
> merge all configuration properties from the {{ReplicationPeerConfig}} when
> creating the peer connection and obtaining a credentials for the peer cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14460) [Perf Regression] Merge of MVCC and SequenceId (HBASE-HBASE-8763) slowed Increments, CheckAndPuts, batch operations
[
https://issues.apache.org/jira/browse/HBASE-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058443#comment-15058443
]
stack commented on HBASE-14460:
---
[~jingcheng...@intel.com] Thanks. The explanation helps.
I think I understand now where the speedup comes from now (pardon my being so
dense).
Here is basic Increment flow:
1. get row lock
2. wait on ALL outstanding transactions to complete so can do a read and know
it will have the latest data
3. do get, then append...
4. call sync
4. let go of lock
5. wait on sync to complete
6. wait on read point to catch up with the write for the above added increment
so for sure the client and read what they wrote (this latter is probably not
needed given we start an increment by waiting on read to catch up with write --
TODO).
Your speed up comes of the following:
1. get row lock AND look to see if we have any write context for this row
already
2. if we don't have an existing write op on this row, proceed as per above but
if we do find an existing contextthen all we have to do is wait on the
write number for this existing transaction to clean, NOT for all existing
writes to clear...
3. as per above, etc.
Do I have it right? If so, sweet (again)... and, yeah, could we skip out on the
wait in step #6 above in the first list.
Now to the patch some more questions (smile).
In begin, we do this:
{code}
long lastWriterNumber = -1;
for (RowOperationContext context : rowOperationContexts) {
if (context != null) {
if (lastWriterNumber < context.getNextWriteNumber()) {
lastWriterNumber = context.getNextWriteNumber();
}
context.setNextWriteNumber(nextWriteNumber);
}
}
{code}
Is the intent that all passed in rowOperationContexts all get the highest found
nextWrite Number? If so, this loop does not seem like it will achieve this (if
rowOperationContexts have write numbers 1 to 3 say, then after the loop is
done, all rowOperationContexts will have the same 1 to 3 write numbers... but
if write numbers are 3 to 1, then they will have a write number of 3..)
Let me look more... will be back.
> [Perf Regression] Merge of MVCC and SequenceId (HBASE-HBASE-8763) slowed
> Increments, CheckAndPuts, batch operations
> ---
>
> Key: HBASE-14460
> URL: https://issues.apache.org/jira/browse/HBASE-14460
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Attachments: 0.94.test.patch, 0.98.test.patch, 14460.txt,
> HBASE-14460-discussion.patch, flamegraph-13120.svg.master.singlecell.svg,
> flamegraph-26636.094.100.svg, flamegraph-28066.098.singlecell.svg,
> flamegraph-28767.098.100.svg, flamegraph-31647.master.100.svg,
> flamegraph-9466.094.singlecell.svg, m.test.patch, region_lock.png,
> testincrement.094.patch, testincrement.098.patch, testincrement.master.patch
>
>
> As reported by 鈴木俊裕 up on the mailing list -- see "Performance degradation
> between CDH5.3.1(HBase0.98.6) and CDH5.4.5(HBase1.0.0)" -- our unification of
> sequenceid and MVCC slows Increments (and other ops) as the mvcc needs to
> 'catch up' to our current point before we can read the last Increment value
> that we need to update.
> We can say that our Increment is just done wrong, we should just be writing
> Increments and summing on read, but checkAndPut as well as batching
> operations have the same issue. Fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-6721) RegionServer Group based Assignment
[
https://issues.apache.org/jira/browse/HBASE-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058465#comment-15058465
]
Francis Liu commented on HBASE-6721:
{quote}
Took a quick look at GroupShellTest which misses master coprocessor setup
similar to the following:
{quote}
Precisely, I created a separate ShellTest subclass as I needed to configure a
different balancer and coprocessor which would not work with the existing shell
unit tests. I think there's a bigger problem, that there is no proper way to
run shell unit tests in trunk. I've filed HBASE-14981 to address that. I'm
going to address the non-shell unit test failures for now.
> RegionServer Group based Assignment
> ---
>
> Key: HBASE-6721
> URL: https://issues.apache.org/jira/browse/HBASE-6721
> Project: HBase
> Issue Type: New Feature
>Reporter: Francis Liu
>Assignee: Francis Liu
> Labels: hbase-6721
> Attachments: 6721-master-webUI.patch, HBASE-6721
> GroupBasedLoadBalancer Sequence Diagram.xml, HBASE-6721-DesigDoc.pdf,
> HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf,
> HBASE-6721_0.98_2.patch, HBASE-6721_10.patch, HBASE-6721_11.patch,
> HBASE-6721_12.patch, HBASE-6721_13.patch, HBASE-6721_14.patch,
> HBASE-6721_15.patch, HBASE-6721_8.patch, HBASE-6721_9.patch,
> HBASE-6721_9.patch, HBASE-6721_94.patch, HBASE-6721_94.patch,
> HBASE-6721_94_2.patch, HBASE-6721_94_3.patch, HBASE-6721_94_3.patch,
> HBASE-6721_94_4.patch, HBASE-6721_94_5.patch, HBASE-6721_94_6.patch,
> HBASE-6721_94_7.patch, HBASE-6721_98_1.patch, HBASE-6721_98_2.patch,
> HBASE-6721_hbase-6721_addendum.patch, HBASE-6721_trunk.patch,
> HBASE-6721_trunk.patch, HBASE-6721_trunk.patch, HBASE-6721_trunk1.patch,
> HBASE-6721_trunk2.patch, balanceCluster Sequence Diagram.svg,
> hbase-6721-v15-branch-1.1.patch, hbase-6721-v16.patch, hbase-6721-v17.patch,
> hbase-6721-v18.patch, hbase-6721-v19.patch, immediateAssignments Sequence
> Diagram.svg, randomAssignment Sequence Diagram.svg, retainAssignment Sequence
> Diagram.svg, roundRobinAssignment Sequence Diagram.svg
>
>
> In multi-tenant deployments of HBase, it is likely that a RegionServer will
> be serving out regions from a number of different tables owned by various
> client applications. Being able to group a subset of running RegionServers
> and assign specific tables to it, provides a client application a level of
> isolation and resource allocation.
> The proposal essentially is to have an AssignmentManager which is aware of
> RegionServer groups and assigns tables to region servers based on groupings.
> Load balancing will occur on a per group basis as well.
> This is essentially a simplification of the approach taken in HBASE-4120. See
> attached document.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-14982) Add metrics for how many bytes are read off disk
Elliott Clark created HBASE-14982: - Summary: Add metrics for how many bytes are read off disk Key: HBASE-14982 URL: https://issues.apache.org/jira/browse/HBASE-14982 Project: HBase Issue Type: Improvement Reporter: Elliott Clark It would be nice to have numbers for: * Bytes read off disk * Bytes written to disk * Bytes read for compaction * Bytes written for compaction -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14956) [HBase ZKcli] JLine support is disabled. Better to enable this in HBase.
[
https://issues.apache.org/jira/browse/HBASE-14956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058524#comment-15058524
]
Esteban Gutierrez commented on HBASE-14956:
---
We cannot bump JLine to a newer version since the version of JRuby we ship is
an old one (see HBASE-13338). Also this shouldn't cause any issue to use zkcli
since it only disables the auto complete functionality. Another option is to
use a version of ZK that doesn't have ZOOKEEPER-1718.
> [HBase ZKcli] JLine support is disabled. Better to enable this in HBase.
> -
>
> Key: HBASE-14956
> URL: https://issues.apache.org/jira/browse/HBASE-14956
> Project: HBase
> Issue Type: Bug
> Components: Client, Zookeeper
>Affects Versions: 1.0.2
>Reporter: Y. SREENIVASULU REDDY
>Assignee: Pankaj Kumar
>
> To perform the zkcli operations using hbase,
> jline is disabled,
> {code}
> [ERROR] Terminal initialization failed; falling back to unsupported
> java.lang.IncompatibleClassChangeError: Found class jline.Terminal, but
> interface was expected
> at jline.TerminalFactory.create(TerminalFactory.java:101)
> at jline.TerminalFactory.get(TerminalFactory.java:158)
> at jline.console.ConsoleReader.(ConsoleReader.java:229)
> at jline.console.ConsoleReader.(ConsoleReader.java:221)
> at jline.console.ConsoleReader.(ConsoleReader.java:209)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
> at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:335)
> at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:303)
> at
> org.apache.hadoop.hbase.zookeeper.ZooKeeperMainServer.main(ZooKeeperMainServer.java:108)
> JLine support is disabled
> {code}
> To enable this jline-.jar is needed in hbase libraries.
> eg: jline-2.11.jar should be exist in hbase/lib directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14830) Fix broken links in 0.94 generated docs
[
https://issues.apache.org/jira/browse/HBASE-14830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misty Stanley-Jones updated HBASE-14830:
Attachment: HBASE-14830-v1.patch
This patch makes the 4 classes private. When I ran mvn clean package locally,
it failed a test but I think it is unrelated:
{code}
Failed tests:
testSingleMember(org.apache.hadoop.hbase.procedure.TestZKProcedure): (..)
Tests run: 932, Failures: 1, Errors: 0, Skipped: 2
{code}
> Fix broken links in 0.94 generated docs
> ---
>
> Key: HBASE-14830
> URL: https://issues.apache.org/jira/browse/HBASE-14830
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 0.94.27
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 0.94.28
>
> Attachments: HBASE-14830-v1.patch, HBASE-14830.patch
>
>
> {code}
> host: hbase.apache.org
> date: Mon, 16-Nov-2015 10:56:28 (local)
> Linklint version: 2.3.5_ingo_020
> #
> # ERROR 2 missing html files (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/generated/HBase.html
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/package-summary.html
> /0.94/devapidocs/src-html/org/apache/hadoop/hbase/io/encoding/BufferedDataBlockEncoder.html
> used in 4 files:
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/CopyKeyDataBlockEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/DiffKeyDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/FastDiffDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/PrefixKeyDeltaEncoder.html
> #
> # ERROR 1 missing other file (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/HADOOP-1581
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/HTableDescriptor.html
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14830) Fix broken links in 0.94 generated docs
[
https://issues.apache.org/jira/browse/HBASE-14830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misty Stanley-Jones updated HBASE-14830:
Status: Open (was: Patch Available)
> Fix broken links in 0.94 generated docs
> ---
>
> Key: HBASE-14830
> URL: https://issues.apache.org/jira/browse/HBASE-14830
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 0.94.27
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 0.94.28
>
> Attachments: HBASE-14830-v1.patch, HBASE-14830.patch
>
>
> {code}
> host: hbase.apache.org
> date: Mon, 16-Nov-2015 10:56:28 (local)
> Linklint version: 2.3.5_ingo_020
> #
> # ERROR 2 missing html files (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/generated/HBase.html
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/package-summary.html
> /0.94/devapidocs/src-html/org/apache/hadoop/hbase/io/encoding/BufferedDataBlockEncoder.html
> used in 4 files:
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/CopyKeyDataBlockEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/DiffKeyDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/FastDiffDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/PrefixKeyDeltaEncoder.html
> #
> # ERROR 1 missing other file (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/HADOOP-1581
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/HTableDescriptor.html
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13425) Documentation nit in REST Gateway impersonation section
[
https://issues.apache.org/jira/browse/HBASE-13425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misty Stanley-Jones updated HBASE-13425:
Attachment: HBASE-13425-v1.patch
Addressed Jerry's concern by changing the order a bit. I'll push this since I
already got a +1 from Jon.
> Documentation nit in REST Gateway impersonation section
> ---
>
> Key: HBASE-13425
> URL: https://issues.apache.org/jira/browse/HBASE-13425
> Project: HBase
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.0.0
>Reporter: Jeremie Gomez
>Assignee: Misty Stanley-Jones
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-13425-v1.patch, HBASE-13425.patch
>
>
> In section "55.8. REST Gateway Impersonation Configuration", there is another
> property that needs to be set (and thus documented).
> After this sentence ("To enable REST gateway impersonation, add the following
> to the hbase-site.xml file for every REST gateway."), we should add :
>
>hbase.rest.support.proxyuser
> true
>
> It not set, doing a curl call on the rest gateway gives the error "support
> for proxyuser is not configured".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13425) Documentation nit in REST Gateway impersonation section
[
https://issues.apache.org/jira/browse/HBASE-13425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misty Stanley-Jones updated HBASE-13425:
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
> Documentation nit in REST Gateway impersonation section
> ---
>
> Key: HBASE-13425
> URL: https://issues.apache.org/jira/browse/HBASE-13425
> Project: HBase
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.0.0
>Reporter: Jeremie Gomez
>Assignee: Misty Stanley-Jones
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-13425-v1.patch, HBASE-13425.patch
>
>
> In section "55.8. REST Gateway Impersonation Configuration", there is another
> property that needs to be set (and thus documented).
> After this sentence ("To enable REST gateway impersonation, add the following
> to the hbase-site.xml file for every REST gateway."), we should add :
>
>hbase.rest.support.proxyuser
> true
>
> It not set, doing a curl call on the rest gateway gives the error "support
> for proxyuser is not configured".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14830) Fix broken links in 0.94 generated docs
[
https://issues.apache.org/jira/browse/HBASE-14830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058648#comment-15058648
]
Hadoop QA commented on HBASE-14830:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12777801/HBASE-14830-v1.patch
against master branch at commit 64c55b4893ba134f2b2ba849c23027c891638b5c.
ATTACHMENT ID: 12777801
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+0 tests included{color}. The patch appears to be a
documentation patch that doesn't require tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/16864//console
This message is automatically generated.
> Fix broken links in 0.94 generated docs
> ---
>
> Key: HBASE-14830
> URL: https://issues.apache.org/jira/browse/HBASE-14830
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 0.94.27
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 0.94.28
>
> Attachments: HBASE-14830-v1.patch, HBASE-14830.patch
>
>
> {code}
> host: hbase.apache.org
> date: Mon, 16-Nov-2015 10:56:28 (local)
> Linklint version: 2.3.5_ingo_020
> #
> # ERROR 2 missing html files (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/generated/HBase.html
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/package-summary.html
> /0.94/devapidocs/src-html/org/apache/hadoop/hbase/io/encoding/BufferedDataBlockEncoder.html
> used in 4 files:
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/CopyKeyDataBlockEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/DiffKeyDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/FastDiffDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/PrefixKeyDeltaEncoder.html
> #
> # ERROR 1 missing other file (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/HADOOP-1581
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/HTableDescriptor.html
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14968) ConcurrentModificationException in region close resulting in the region staying in closing state
[
https://issues.apache.org/jira/browse/HBASE-14968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-14968:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 1.0.4
1.1.4
Status: Resolved (was: Patch Available)
Thanks Stack for looking. I've pushe to 1.0+.
bq. You want to synchronize the coprocessorHosts in the load method too?
I think this is not needed since coprocessorNames is already wrapped in
{{Collections.synchronizedSet()}}. Only for iterating over the elements of a
synchronized collection, we need the {{synchronized}} block.
> ConcurrentModificationException in region close resulting in the region
> staying in closing state
>
>
> Key: HBASE-14968
> URL: https://issues.apache.org/jira/browse/HBASE-14968
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4, 1.0.4
>
> Attachments: hbase-14968_v1.patch
>
>
> We have seen this in our tests. The region gets closed, but the region close
> handler gets an unexpected exception causing the region to stay in closing
> state until RS is restarted.
> The Phoenix and security coprocessors were loaded in that region. Here is the
> stack trace:
> {code}
> java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.shutdown(CoprocessorHost.java:442)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionEnvironment.shutdown(RegionCoprocessorHost.java:155)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.shutdown(CoprocessorHost.java:272)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$5.postEnvCall(RegionCoprocessorHost.java:496)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1761)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.postClose(RegionCoprocessorHost.java:489)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doClose(HRegion.java:1502)
> at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1349)
> at
> org.apache.hadoop.hbase.regionserver.handler.CloseRegionHandler.process(CloseRegionHandler.java:138)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:128)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14982) Add metrics for how many bytes are read off disk
[ https://issues.apache.org/jira/browse/HBASE-14982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058694#comment-15058694 ] Nick Dimiduk commented on HBASE-14982: -- Separate from HDFS's metrics? Call out ssr vs local blocks vs remote blocks? > Add metrics for how many bytes are read off disk > > > Key: HBASE-14982 > URL: https://issues.apache.org/jira/browse/HBASE-14982 > Project: HBase > Issue Type: Improvement >Reporter: Elliott Clark > > It would be nice to have numbers for: > * Bytes read off disk > * Bytes written to disk > * Bytes read for compaction > * Bytes written for compaction -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-14981) Shell unit tests are not running in trunk?
Francis Liu created HBASE-14981: --- Summary: Shell unit tests are not running in trunk? Key: HBASE-14981 URL: https://issues.apache.org/jira/browse/HBASE-14981 Project: HBase Issue Type: Bug Reporter: Francis Liu Assignee: Francis Liu TestShell seems to be replaced by an AbstractTestShell class. Thus it does not seem that any of the shell unit tests are running? If so, is the intent to create a TestShell which subclasses the abstract class? On a related note I've written shell unit tests for HBASE-6721 and it requires a different Shell subclass as I need to have a different balancer and coprocessor installed. I'm hoping we can address that use case in this jira as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-14983) Create metrics for per block type hit/miss ratios
Elliott Clark created HBASE-14983: - Summary: Create metrics for per block type hit/miss ratios Key: HBASE-14983 URL: https://issues.apache.org/jira/browse/HBASE-14983 Project: HBase Issue Type: Improvement Reporter: Elliott Clark Missing a root index block is worse than missing a data block. We should know the difference -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14830) Fix broken links in 0.94 generated docs
[
https://issues.apache.org/jira/browse/HBASE-14830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misty Stanley-Jones updated HBASE-14830:
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
> Fix broken links in 0.94 generated docs
> ---
>
> Key: HBASE-14830
> URL: https://issues.apache.org/jira/browse/HBASE-14830
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 0.94.27
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 0.94.28
>
> Attachments: HBASE-14830-v1.patch, HBASE-14830.patch
>
>
> {code}
> host: hbase.apache.org
> date: Mon, 16-Nov-2015 10:56:28 (local)
> Linklint version: 2.3.5_ingo_020
> #
> # ERROR 2 missing html files (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/generated/HBase.html
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/package-summary.html
> /0.94/devapidocs/src-html/org/apache/hadoop/hbase/io/encoding/BufferedDataBlockEncoder.html
> used in 4 files:
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/CopyKeyDataBlockEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/DiffKeyDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/FastDiffDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/PrefixKeyDeltaEncoder.html
> #
> # ERROR 1 missing other file (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/HADOOP-1581
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/HTableDescriptor.html
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14534) Bump yammer/coda/dropwizard metrics dependency version
[ https://issues.apache.org/jira/browse/HBASE-14534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058707#comment-15058707 ] Nick Dimiduk commented on HBASE-14534: -- +1 > Bump yammer/coda/dropwizard metrics dependency version > -- > > Key: HBASE-14534 > URL: https://issues.apache.org/jira/browse/HBASE-14534 > Project: HBase > Issue Type: Task >Reporter: Nick Dimiduk >Assignee: Mikhail Antonov >Priority: Minor > Attachments: HBASE-14534-v2.patch, HBASE-14534.patch, wip.patch > > > After HBASE-12911 lands, let's update our dependency to the latest > incarnation of this library. I guess they're now calling it Dropwizard > Metrics. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14534) Bump yammer/coda/dropwizard metrics dependency version
[ https://issues.apache.org/jira/browse/HBASE-14534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058711#comment-15058711 ] Mikhail Antonov commented on HBASE-14534: - Pushed to master. Thanks for review! > Bump yammer/coda/dropwizard metrics dependency version > -- > > Key: HBASE-14534 > URL: https://issues.apache.org/jira/browse/HBASE-14534 > Project: HBase > Issue Type: Task >Reporter: Nick Dimiduk >Assignee: Mikhail Antonov >Priority: Minor > Attachments: HBASE-14534-v2.patch, HBASE-14534.patch, wip.patch > > > After HBASE-12911 lands, let's update our dependency to the latest > incarnation of this library. I guess they're now calling it Dropwizard > Metrics. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14978) Don't allow Multi to retain too many blocks
[ https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-14978: -- Attachment: HBASE-14978-v3.patch > Don't allow Multi to retain too many blocks > --- > > Key: HBASE-14978 > URL: https://issues.apache.org/jira/browse/HBASE-14978 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-14978-v1.patch, HBASE-14978-v2.patch, > HBASE-14978-v3.patch, HBASE-14978.patch > > > Scans and Multi's have limits on the total size of cells that can be > returned. However if those requests are not all pointing at the same blocks > then the KeyValues can keep alive a lot more data than their size. > Take the following example: > A multi with a list of 1 gets to a fat row. Each column being returned in > in a different block. Each column is small 32 bytes or so. > So the total cell size will be 32 * 1 = ~320kb. However if each block is > 128k then total retained heap size will be almost 2gigs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14804) HBase shell's create table command ignores 'NORMALIZATION_ENABLED' attribute
[
https://issues.apache.org/jira/browse/HBASE-14804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058422#comment-15058422
]
Hudson commented on HBASE-14804:
ABORTED: Integrated in HBase-0.98-matrix #272 (See
[https://builds.apache.org/job/HBase-0.98-matrix/272/])
HBASE-14804 HBase shell's create table command ignores (apurtell: rev
40d7fa2eccc881f0ebec5c001e9ddd6e27b75b09)
* hbase-shell/src/main/ruby/hbase/admin.rb
> HBase shell's create table command ignores 'NORMALIZATION_ENABLED' attribute
>
>
> Key: HBASE-14804
> URL: https://issues.apache.org/jira/browse/HBASE-14804
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.2.0, 1.1.2
>Reporter: Romil Choksi
>Assignee: Jean-Marc Spaggiari
>Priority: Minor
> Labels: beginner
> Fix For: 2.0.0, 1.2.0, 1.3.0, 0.98.17
>
> Attachments: HBASE-14804.v0-trunk.patch, HBASE-14804.v1-trunk.patch
>
>
> I am trying to create a new table and set the NORMALIZATION_ENABLED as true,
> but seems like the argument NORMALIZATION_ENABLED is being ignored. And the
> attribute NORMALIZATION_ENABLED is not displayed on doing a desc command on
> that table
> {code}
> hbase(main):020:0> create 'test-table-4', 'cf', {NORMALIZATION_ENABLED =>
> 'true'}
> An argument ignored (unknown or overridden): NORMALIZATION_ENABLED
> 0 row(s) in 4.2670 seconds
> => Hbase::Table - test-table-4
> hbase(main):021:0> desc 'test-table-4'
> Table test-table-4 is ENABLED
>
>
> test-table-4
>
>
> COLUMN FAMILIES DESCRIPTION
>
>
> {NAME => 'cf', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY => 'false',
> KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL =>
> 'FOREVER', COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOC
> KCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE => '0'}
>
>
> 1 row(s) in 0.0430 seconds
> {code}
> However, on doing an alter command on that table we can set the
> NORMALIZATION_ENABLED attribute for that table
> {code}
> hbase(main):022:0> alter 'test-table-4', {NORMALIZATION_ENABLED => 'true'}
> Unknown argument ignored: NORMALIZATION_ENABLED
> Updating all regions with the new schema...
> 1/1 regions updated.
> Done.
> 0 row(s) in 2.3640 seconds
> hbase(main):023:0> desc 'test-table-4'
> Table test-table-4 is ENABLED
>
>
> test-table-4, {TABLE_ATTRIBUTES => {NORMALIZATION_ENABLED => 'true'}
>
>
> COLUMN FAMILIES DESCRIPTION
>
>
> {NAME => 'cf', BLOOMFILTER => 'ROW', VERSIONS => '1', IN_MEMORY => 'false',
> KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL =>
> 'FOREVER', COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOC
> KCACHE => 'true', BLOCKSIZE => '65536', REPLICATION_SCOPE => '0'}
>
>
> 1 row(s) in 0.0190 seconds
> {code}
> I think it would be better to have a single step process to enable
> normalization while creating the table itself, rather than a two step process
> to alter the table later on to enable normalization
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14866) VerifyReplication should use peer configuration in peer connection
[
https://issues.apache.org/jira/browse/HBASE-14866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058423#comment-15058423
]
Hudson commented on HBASE-14866:
ABORTED: Integrated in HBase-0.98-matrix #272 (See
[https://builds.apache.org/job/HBase-0.98-matrix/272/])
HBASE-14866 VerifyReplication and ReplicationAdmin should use full peer
(apurtell: rev 229c430fa144f1fc7a418a56e1ab180f5b4e3ff5)
* hbase-server/src/test/java/org/apache/hadoop/hbase/TestZooKeeper.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/client/replication/ReplicationAdmin.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKConfig.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/SyncTable.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationEndpoint.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationStateZKImpl.java
* hbase-common/src/test/java/org/apache/hadoop/hbase/TestHBaseConfiguration.java
* hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationPeersZKImpl.java
* hbase-common/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKConfig.java
* hbase-common/src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java
*
hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationStateZKBase.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/client/replication/TestReplicationAdmin.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/replication/VerifyReplication.java
* hbase-client/src/test/java/org/apache/hadoop/hbase/zookeeper/TestZKUtil.java
* hbase-server/src/test/java/org/apache/hadoop/hbase/zookeeper/TestZKConfig.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/TableOutputFormat.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestReplicationStateBasic.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/TableMapReduceUtil.java
* hbase-common/src/test/java/org/apache/hadoop/hbase/zookeeper/TestZKConfig.java
> VerifyReplication should use peer configuration in peer connection
> --
>
> Key: HBASE-14866
> URL: https://issues.apache.org/jira/browse/HBASE-14866
> Project: HBase
> Issue Type: Improvement
> Components: Replication
>Reporter: Gary Helmling
>Assignee: Gary Helmling
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: HBASE-14866-0.98.patch, HBASE-14866.patch,
> HBASE-14866_v1.patch, hbase-14866-branch-1-v1.patch, hbase-14866-v4.patch,
> hbase-14866-v5.patch, hbase-14866-v6.patch, hbase-14866_v2.patch,
> hbase-14866_v3.patch
>
>
> VerifyReplication uses the replication peer's configuration to construct the
> ZooKeeper quorum address for the peer connection. However, other
> configuration properties in the peer's configuration are dropped. It should
> merge all configuration properties from the {{ReplicationPeerConfig}} when
> creating the peer connection and obtaining a credentials for the peer cluster.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14960) Fallback to using default RPCControllerFactory if class cannot be loaded
[ https://issues.apache.org/jira/browse/HBASE-14960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058424#comment-15058424 ] Hudson commented on HBASE-14960: ABORTED: Integrated in HBase-0.98-matrix #272 (See [https://builds.apache.org/job/HBase-0.98-matrix/272/]) HBASE-14960 Fallback to using default RPCControllerFactory if class (apurtell: rev ee1e453609e7838d8e447bea34b07fa27f11b336) * hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcControllerFactory.java * hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestRpcControllerFactory.java > Fallback to using default RPCControllerFactory if class cannot be loaded > > > Key: HBASE-14960 > URL: https://issues.apache.org/jira/browse/HBASE-14960 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Enis Soztutar > Fix For: 2.0.0, 1.2.0, 1.3.0, 0.98.17 > > Attachments: HBASE-14960-0.98.patch, hbase-14960_v1.patch, > hbase-14960_v2.patch, hbase-14960_v3.patch, hbase-14960_v4.patch > > > In Phoenix + HBase clusters, the hbase-site.xml configuration will point to a > custom rpc controller factory which is a Phoenix-specific one to configure > the priorities for index and system catalog table. > However, sometimes these Phoenix-enabled clusters are used from pure-HBase > client applications resulting in ClassNotFoundExceptions in application code > or MapReduce jobs. Since hbase configuration is shared between > Phoenix-clients and HBase clients, having different configurations at the > client side is hard. > We can instead try to load up the RPCControllerFactory from conf, and if not > found, fallback to the default one (in case this is a pure HBase client). In > case Phoenix is already in the classpath, it will work as usual. > This does not affect the rpc scheduler factory since it is only used at the > server side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14967) Remove max-width constraint from website skin
[ https://issues.apache.org/jira/browse/HBASE-14967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058615#comment-15058615 ] Hudson commented on HBASE-14967: SUCCESS: Integrated in HBase-Trunk_matrix #555 (See [https://builds.apache.org/job/HBase-Trunk_matrix/555/]) HBASE-14967 Remove max-width constraint from website skin (mstanleyjones: rev 64c55b4893ba134f2b2ba849c23027c891638b5c) * src/main/site/resources/css/site.css > Remove max-width constraint from website skin > - > > Key: HBASE-14967 > URL: https://issues.apache.org/jira/browse/HBASE-14967 > Project: HBase > Issue Type: Bug > Components: website >Reporter: Misty Stanley-Jones >Assignee: Misty Stanley-Jones > Attachments: HBASE-14967.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14830) Fix broken links in 0.94 generated docs
[
https://issues.apache.org/jira/browse/HBASE-14830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058638#comment-15058638
]
Matteo Bertozzi commented on HBASE-14830:
-
yeah, the test is a flaky. patch looks good to me
> Fix broken links in 0.94 generated docs
> ---
>
> Key: HBASE-14830
> URL: https://issues.apache.org/jira/browse/HBASE-14830
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 0.94.27
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 0.94.28
>
> Attachments: HBASE-14830-v1.patch, HBASE-14830.patch
>
>
> {code}
> host: hbase.apache.org
> date: Mon, 16-Nov-2015 10:56:28 (local)
> Linklint version: 2.3.5_ingo_020
> #
> # ERROR 2 missing html files (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/generated/HBase.html
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/package-summary.html
> /0.94/devapidocs/src-html/org/apache/hadoop/hbase/io/encoding/BufferedDataBlockEncoder.html
> used in 4 files:
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/CopyKeyDataBlockEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/DiffKeyDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/FastDiffDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/PrefixKeyDeltaEncoder.html
> #
> # ERROR 1 missing other file (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/HADOOP-1581
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/HTableDescriptor.html
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14534) Bump yammer/coda/dropwizard metrics dependency version
[ https://issues.apache.org/jira/browse/HBASE-14534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058675#comment-15058675 ] Elliott Clark commented on HBASE-14534: --- +1 Looks good to me for master. > Bump yammer/coda/dropwizard metrics dependency version > -- > > Key: HBASE-14534 > URL: https://issues.apache.org/jira/browse/HBASE-14534 > Project: HBase > Issue Type: Task >Reporter: Nick Dimiduk >Assignee: Mikhail Antonov >Priority: Minor > Attachments: HBASE-14534-v2.patch, HBASE-14534.patch, wip.patch > > > After HBASE-12911 lands, let's update our dependency to the latest > incarnation of this library. I guess they're now calling it Dropwizard > Metrics. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14830) Fix broken links in 0.94 generated docs
[
https://issues.apache.org/jira/browse/HBASE-14830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Misty Stanley-Jones updated HBASE-14830:
Status: Patch Available (was: Open)
> Fix broken links in 0.94 generated docs
> ---
>
> Key: HBASE-14830
> URL: https://issues.apache.org/jira/browse/HBASE-14830
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 0.94.27
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 0.94.28
>
> Attachments: HBASE-14830-v1.patch, HBASE-14830.patch
>
>
> {code}
> host: hbase.apache.org
> date: Mon, 16-Nov-2015 10:56:28 (local)
> Linklint version: 2.3.5_ingo_020
> #
> # ERROR 2 missing html files (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/generated/HBase.html
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/package-summary.html
> /0.94/devapidocs/src-html/org/apache/hadoop/hbase/io/encoding/BufferedDataBlockEncoder.html
> used in 4 files:
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/CopyKeyDataBlockEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/DiffKeyDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/FastDiffDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/PrefixKeyDeltaEncoder.html
> #
> # ERROR 1 missing other file (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/HADOOP-1581
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/HTableDescriptor.html
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14970) Backport HBASE-13082 and its sub-jira to branch-1
[
https://issues.apache.org/jira/browse/HBASE-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057609#comment-15057609
]
Hadoop QA commented on HBASE-14970:
---
{color:green}+1 overall{color}.
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/16861//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/16861//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/16861//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/16861//console
This message is automatically generated.
> Backport HBASE-13082 and its sub-jira to branch-1
> -
>
> Key: HBASE-14970
> URL: https://issues.apache.org/jira/browse/HBASE-14970
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Attachments: HBASE-13082-branch-1.patch, HBASE-14970_branch-1.patch,
> HBASE-14970_branch-1.patch, HBASE-14970_branch-1.patch,
> HBASE-14970_branch-1_1.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14978) Don't allow Multi to retain too many blocks
[ https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057636#comment-15057636 ] Elliott Clark commented on HBASE-14978: --- bq.So with off heap Cells, withe very cell, we will treat it as coming from a new block? Yep which bb controls which gets really interesting so I went with the more conservative. bq.In fact with off heap Cell, which are delivered from L2 off heap cache, we wont get any OOME issue We won't get an OOME instead we'll kill the cache and be un-able to read anything from disk. The end result is about the same. Disaster. Moving the data off heap doesn't really solve any of the issues. It just means that we don't have the gc cleaning up. We have our own reference counting. > Don't allow Multi to retain too many blocks > --- > > Key: HBASE-14978 > URL: https://issues.apache.org/jira/browse/HBASE-14978 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-14978-v1.patch, HBASE-14978.patch > > > Scans and Multi's have limits on the total size of cells that can be > returned. However if those requests are not all pointing at the same blocks > then the KeyValues can keep alive a lot more data than their size. > Take the following example: > A multi with a list of 1 gets to a fat row. Each column being returned in > in a different block. Each column is small 32 bytes or so. > So the total cell size will be 32 * 1 = ~320kb. However if each block is > 128k then total retained heap size will be almost 2gigs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14970) Backport HBASE-13082 and its sub-jira to branch-1
[ https://issues.apache.org/jira/browse/HBASE-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057776#comment-15057776 ] ramkrishna.s.vasudevan commented on HBASE-14970: Ping for reviews. > Backport HBASE-13082 and its sub-jira to branch-1 > - > > Key: HBASE-14970 > URL: https://issues.apache.org/jira/browse/HBASE-14970 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Attachments: HBASE-13082-branch-1.patch, HBASE-14970_branch-1.patch, > HBASE-14970_branch-1.patch, HBASE-14970_branch-1.patch, > HBASE-14970_branch-1_1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14978) Don't allow Multi to retain too many blocks
[
https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057602#comment-15057602
]
Anoop Sam John commented on HBASE-14978:
So with off heap Cells, withe very cell, we will treat it as coming from a new
block?
bq.if (c.getRowArray() != lastBlock) {
Even with array backed cells also this wont work as expected when we use DBE.
In that case every Cell will have new byte[] backing the key parts at least..
Now with Cells in place every where, this kind of assumption taking is not
correct IMHO.
> Don't allow Multi to retain too many blocks
> ---
>
> Key: HBASE-14978
> URL: https://issues.apache.org/jira/browse/HBASE-14978
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>Priority: Critical
> Attachments: HBASE-14978-v1.patch, HBASE-14978.patch
>
>
> Scans and Multi's have limits on the total size of cells that can be
> returned. However if those requests are not all pointing at the same blocks
> then the KeyValues can keep alive a lot more data than their size.
> Take the following example:
> A multi with a list of 1 gets to a fat row. Each column being returned in
> in a different block. Each column is small 32 bytes or so.
> So the total cell size will be 32 * 1 = ~320kb. However if each block is
> 128k then total retained heap size will be almost 2gigs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14978) Don't allow Multi to retain too many blocks
[ https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057620#comment-15057620 ] Anoop Sam John commented on HBASE-14978: The check is still on getRowArray() and uses value array for knowing that block's size. > Don't allow Multi to retain too many blocks > --- > > Key: HBASE-14978 > URL: https://issues.apache.org/jira/browse/HBASE-14978 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-14978-v1.patch, HBASE-14978.patch > > > Scans and Multi's have limits on the total size of cells that can be > returned. However if those requests are not all pointing at the same blocks > then the KeyValues can keep alive a lot more data than their size. > Take the following example: > A multi with a list of 1 gets to a fat row. Each column being returned in > in a different block. Each column is small 32 bytes or so. > So the total cell size will be 32 * 1 = ~320kb. However if each block is > 128k then total retained heap size will be almost 2gigs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14460) [Perf Regression] Merge of MVCC and SequenceId (HBASE-HBASE-8763) slowed Increments, CheckAndPuts, batch operations
[ https://issues.apache.org/jira/browse/HBASE-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057635#comment-15057635 ] stack commented on HBASE-14460: --- [~jingcheng...@intel.com] But at the start of the increment when we do this... mvcc.await(rowLockPair.getFirst().getRowOperationContext()); ... the rowOperationContext does not have our rows sequenceid, right? That does not get assigned much later when we do the append way down inside this method. The mvcc.await at the head of the increment is working with the initial setting, -1, so is not waiting at all? Maybe I am not following. Please correct me if I am misreading. Thanks [~jingcheng...@intel.com] The difference you see when you run the test is interesting in of it itself. > [Perf Regression] Merge of MVCC and SequenceId (HBASE-HBASE-8763) slowed > Increments, CheckAndPuts, batch operations > --- > > Key: HBASE-14460 > URL: https://issues.apache.org/jira/browse/HBASE-14460 > Project: HBase > Issue Type: Bug > Components: Performance >Reporter: stack >Assignee: stack >Priority: Critical > Attachments: 0.94.test.patch, 0.98.test.patch, 14460.txt, > HBASE-14460-discussion.patch, flamegraph-13120.svg.master.singlecell.svg, > flamegraph-26636.094.100.svg, flamegraph-28066.098.singlecell.svg, > flamegraph-28767.098.100.svg, flamegraph-31647.master.100.svg, > flamegraph-9466.094.singlecell.svg, m.test.patch, region_lock.png, > testincrement.094.patch, testincrement.098.patch, testincrement.master.patch > > > As reported by 鈴木俊裕 up on the mailing list -- see "Performance degradation > between CDH5.3.1(HBase0.98.6) and CDH5.4.5(HBase1.0.0)" -- our unification of > sequenceid and MVCC slows Increments (and other ops) as the mvcc needs to > 'catch up' to our current point before we can read the last Increment value > that we need to update. > We can say that our Increment is just done wrong, we should just be writing > Increments and summing on read, but checkAndPut as well as batching > operations have the same issue. Fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14460) [Perf Regression] Merge of MVCC and SequenceId (HBASE-HBASE-8763) slowed Increments, CheckAndPuts, batch operations
[ https://issues.apache.org/jira/browse/HBASE-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057684#comment-15057684 ] Jingcheng Du commented on HBASE-14460: -- The assigning of the write number is done in begin(RowOperationContext... rowOperationContexts) method which is invoked in mvcc.await(rowOperationContexts), right? > [Perf Regression] Merge of MVCC and SequenceId (HBASE-HBASE-8763) slowed > Increments, CheckAndPuts, batch operations > --- > > Key: HBASE-14460 > URL: https://issues.apache.org/jira/browse/HBASE-14460 > Project: HBase > Issue Type: Bug > Components: Performance >Reporter: stack >Assignee: stack >Priority: Critical > Attachments: 0.94.test.patch, 0.98.test.patch, 14460.txt, > HBASE-14460-discussion.patch, flamegraph-13120.svg.master.singlecell.svg, > flamegraph-26636.094.100.svg, flamegraph-28066.098.singlecell.svg, > flamegraph-28767.098.100.svg, flamegraph-31647.master.100.svg, > flamegraph-9466.094.singlecell.svg, m.test.patch, region_lock.png, > testincrement.094.patch, testincrement.098.patch, testincrement.master.patch > > > As reported by 鈴木俊裕 up on the mailing list -- see "Performance degradation > between CDH5.3.1(HBase0.98.6) and CDH5.4.5(HBase1.0.0)" -- our unification of > sequenceid and MVCC slows Increments (and other ops) as the mvcc needs to > 'catch up' to our current point before we can read the last Increment value > that we need to update. > We can say that our Increment is just done wrong, we should just be writing > Increments and summing on read, but checkAndPut as well as batching > operations have the same issue. Fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14978) Don't allow Multi to retain too many blocks
[ https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-14978: -- Attachment: HBASE-14978-v2.patch > Don't allow Multi to retain too many blocks > --- > > Key: HBASE-14978 > URL: https://issues.apache.org/jira/browse/HBASE-14978 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-14978-v1.patch, HBASE-14978-v2.patch, > HBASE-14978.patch > > > Scans and Multi's have limits on the total size of cells that can be > returned. However if those requests are not all pointing at the same blocks > then the KeyValues can keep alive a lot more data than their size. > Take the following example: > A multi with a list of 1 gets to a fat row. Each column being returned in > in a different block. Each column is small 32 bytes or so. > So the total cell size will be 32 * 1 = ~320kb. However if each block is > 128k then total retained heap size will be almost 2gigs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14460) [Perf Regression] Merge of MVCC and SequenceId (HBASE-HBASE-8763) slowed Increments, CheckAndPuts, batch operations
[ https://issues.apache.org/jira/browse/HBASE-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057719#comment-15057719 ] Jingcheng Du commented on HBASE-14460: -- in the method begin(RowOperationContext... rowOperationContexts), it does several things. 1. Generate the next write number. 2. Get the last write number that the current WritenEntry concerns ( by comparing the exiting RowOperationContext in this batch and get the biggest one). 3. Set the next writer number for each RowOperationContext in this batch. 4. Set the next writer number to the current WriteEntry and add it to the write queue. > [Perf Regression] Merge of MVCC and SequenceId (HBASE-HBASE-8763) slowed > Increments, CheckAndPuts, batch operations > --- > > Key: HBASE-14460 > URL: https://issues.apache.org/jira/browse/HBASE-14460 > Project: HBase > Issue Type: Bug > Components: Performance >Reporter: stack >Assignee: stack >Priority: Critical > Attachments: 0.94.test.patch, 0.98.test.patch, 14460.txt, > HBASE-14460-discussion.patch, flamegraph-13120.svg.master.singlecell.svg, > flamegraph-26636.094.100.svg, flamegraph-28066.098.singlecell.svg, > flamegraph-28767.098.100.svg, flamegraph-31647.master.100.svg, > flamegraph-9466.094.singlecell.svg, m.test.patch, region_lock.png, > testincrement.094.patch, testincrement.098.patch, testincrement.master.patch > > > As reported by 鈴木俊裕 up on the mailing list -- see "Performance degradation > between CDH5.3.1(HBase0.98.6) and CDH5.4.5(HBase1.0.0)" -- our unification of > sequenceid and MVCC slows Increments (and other ops) as the mvcc needs to > 'catch up' to our current point before we can read the last Increment value > that we need to update. > We can say that our Increment is just done wrong, we should just be writing > Increments and summing on read, but checkAndPut as well as batching > operations have the same issue. Fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14978) Don't allow Multi to retain too many blocks
[ https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057639#comment-15057639 ] Elliott Clark commented on HBASE-14978: --- bq.The check is still on getRowArray() Everything should be on value. > Don't allow Multi to retain too many blocks > --- > > Key: HBASE-14978 > URL: https://issues.apache.org/jira/browse/HBASE-14978 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-14978-v1.patch, HBASE-14978.patch > > > Scans and Multi's have limits on the total size of cells that can be > returned. However if those requests are not all pointing at the same blocks > then the KeyValues can keep alive a lot more data than their size. > Take the following example: > A multi with a list of 1 gets to a fat row. Each column being returned in > in a different block. Each column is small 32 bytes or so. > So the total cell size will be 32 * 1 = ~320kb. However if each block is > 128k then total retained heap size will be almost 2gigs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14979) Update to the newest Zookeeper release
[ https://issues.apache.org/jira/browse/HBASE-14979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057688#comment-15057688 ] Hudson commented on HBASE-14979: FAILURE: Integrated in HBase-1.3-IT #375 (See [https://builds.apache.org/job/HBase-1.3-IT/375/]) HBASE-14979 Update to the newest Zookeeper release (eclark: rev a290a5d978a5eb730d9708bc2c0384d22fc37fb6) * pom.xml > Update to the newest Zookeeper release > -- > > Key: HBASE-14979 > URL: https://issues.apache.org/jira/browse/HBASE-14979 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-14979.patch > > > ZOOKEEPER-706 is nice to have for anyone running replication that sometimes > gets stalled. We should update to the latest patch version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14979) Update to the newest Zookeeper release
[ https://issues.apache.org/jira/browse/HBASE-14979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057725#comment-15057725 ] Hudson commented on HBASE-14979: SUCCESS: Integrated in HBase-1.2-IT #341 (See [https://builds.apache.org/job/HBase-1.2-IT/341/]) HBASE-14979 Update to the newest Zookeeper release (eclark: rev f64cdf44b5c420d0ec29f84a48d3145441113351) * pom.xml > Update to the newest Zookeeper release > -- > > Key: HBASE-14979 > URL: https://issues.apache.org/jira/browse/HBASE-14979 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-14979.patch > > > ZOOKEEPER-706 is nice to have for anyone running replication that sometimes > gets stalled. We should update to the latest patch version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14929) There is a space missing from Table "foo" is not currently available.
[
https://issues.apache.org/jira/browse/HBASE-14929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057556#comment-15057556
]
Hudson commented on HBASE-14929:
FAILURE: Integrated in HBase-1.1-JDK8 #1707 (See
[https://builds.apache.org/job/HBase-1.1-JDK8/1707/])
HBASE-14929 There is a space missing from table "foo" is not currently
(jmhsieh: rev bc11455f0b2fdd47bbac175a9b86e978a31e7579)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/LoadIncrementalHFiles.java
> There is a space missing from Table "foo" is not currently available.
> -
>
> Key: HBASE-14929
> URL: https://issues.apache.org/jira/browse/HBASE-14929
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Malaska
>Assignee: Carlos A. Morillo
>Priority: Trivial
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.3
>
> Attachments: HBASE-14929.patch
>
>
> Go to the following line in LoadIncrementalHFiles.java
> throw new TableNotFoundException("Table " + table.getName() + "is not
> currently available.");
> and add a space before is and after '
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14978) Don't allow Multi to retain too many blocks
[ https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057604#comment-15057604 ] ramkrishna.s.vasudevan commented on HBASE-14978: bq.In that case every Cell will have new byte[] backing the key parts at least. Ya I was about to say that but in the latest patch it is the valueBuffer and valueArray. > Don't allow Multi to retain too many blocks > --- > > Key: HBASE-14978 > URL: https://issues.apache.org/jira/browse/HBASE-14978 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-14978-v1.patch, HBASE-14978.patch > > > Scans and Multi's have limits on the total size of cells that can be > returned. However if those requests are not all pointing at the same blocks > then the KeyValues can keep alive a lot more data than their size. > Take the following example: > A multi with a list of 1 gets to a fat row. Each column being returned in > in a different block. Each column is small 32 bytes or so. > So the total cell size will be 32 * 1 = ~320kb. However if each block is > 128k then total retained heap size will be almost 2gigs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-14978) Don't allow Multi to retain too many blocks
[
https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057602#comment-15057602
]
Anoop Sam John edited comment on HBASE-14978 at 12/15/15 8:33 AM:
--
So with off heap Cells, withe very cell, we will treat it as coming from a new
block?
In fact with off heap Cell, which are delivered from L2 off heap cache, we wont
get any OOME issue whatever be the #blocks one request touches. We avoid
copying of block data from L2 off heap space to temp byte[]. So these Cells
refer to the L2 cache space only.
bq.if (c.getRowArray() != lastBlock) {
Even with array backed cells also this wont work as expected when we use DBE.
In that case every Cell will have new byte[] backing the key parts at least..
Now with Cells in place every where, this kind of assumption taking is not
correct IMHO.
was (Author: anoop.hbase):
So with off heap Cells, withe very cell, we will treat it as coming from a new
block?
bq.if (c.getRowArray() != lastBlock) {
Even with array backed cells also this wont work as expected when we use DBE.
In that case every Cell will have new byte[] backing the key parts at least..
Now with Cells in place every where, this kind of assumption taking is not
correct IMHO.
> Don't allow Multi to retain too many blocks
> ---
>
> Key: HBASE-14978
> URL: https://issues.apache.org/jira/browse/HBASE-14978
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>Priority: Critical
> Attachments: HBASE-14978-v1.patch, HBASE-14978.patch
>
>
> Scans and Multi's have limits on the total size of cells that can be
> returned. However if those requests are not all pointing at the same blocks
> then the KeyValues can keep alive a lot more data than their size.
> Take the following example:
> A multi with a list of 1 gets to a fat row. Each column being returned in
> in a different block. Each column is small 32 bytes or so.
> So the total cell size will be 32 * 1 = ~320kb. However if each block is
> 128k then total retained heap size will be almost 2gigs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14978) Don't allow Multi to retain too many blocks
[ https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057628#comment-15057628 ] ramkrishna.s.vasudevan commented on HBASE-14978: bqThe check is still on getRowArray() I see. I missed that. bq.In fact with off heap Cell, which are delivered from L2 off heap cache, we wont get any OOME issue whatever be the #blocks one request touches. We avoid copying of block data from L2 off heap space to temp byte[]. So these Cells refer to the L2 cache space only. Yes. I too think so.. See my above comment 'For the offheap case may be this will not happen- '. > Don't allow Multi to retain too many blocks > --- > > Key: HBASE-14978 > URL: https://issues.apache.org/jira/browse/HBASE-14978 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-14978-v1.patch, HBASE-14978.patch > > > Scans and Multi's have limits on the total size of cells that can be > returned. However if those requests are not all pointing at the same blocks > then the KeyValues can keep alive a lot more data than their size. > Take the following example: > A multi with a list of 1 gets to a fat row. Each column being returned in > in a different block. Each column is small 32 bytes or so. > So the total cell size will be 32 * 1 = ~320kb. However if each block is > 128k then total retained heap size will be almost 2gigs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14978) Don't allow Multi to retain too many blocks
[ https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057869#comment-15057869 ] Anoop Sam John commented on HBASE-14978: Understand your point of cache is being blocked for longer time.. ( i mean some buckets) But my worry is the fact of considering every off heap Cell to be from a new block. This will kill all the perf improvements we made in HBASE-11425. In patch we increment the block size for each cell by the underlying value buffer capacity. In case of off heap Cells from L2 cache, this buffer is the bucket buffer being created in ByteBufferArray which is of size 4 MB. So any size limit we make, with the off heap cells from L2 cache, we will reach there so easily and will make much more RPCs! > Don't allow Multi to retain too many blocks > --- > > Key: HBASE-14978 > URL: https://issues.apache.org/jira/browse/HBASE-14978 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-14978-v1.patch, HBASE-14978-v2.patch, > HBASE-14978.patch > > > Scans and Multi's have limits on the total size of cells that can be > returned. However if those requests are not all pointing at the same blocks > then the KeyValues can keep alive a lot more data than their size. > Take the following example: > A multi with a list of 1 gets to a fat row. Each column being returned in > in a different block. Each column is small 32 bytes or so. > So the total cell size will be 32 * 1 = ~320kb. However if each block is > 128k then total retained heap size will be almost 2gigs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14978) Don't allow Multi to retain too many blocks
[ https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057783#comment-15057783 ] ramkrishna.s.vasudevan commented on HBASE-14978: bq.We won't get an OOME instead we'll kill the cache and be un-able to read anything from disk Just wanted to understand your concern here. In HBase branch-1.3 even if we configure the BucketCache (L2) offheap every time we bring in the block onheap before serving any read request. So in case of multi Gets there could be n number of blocks being copied to the onheap and all those will have references in the Result till the results are transferred to the client. So the heap can grow upto 2GB as per your decription. But in the latest trunk this copy to onheap will never happen so the Cells that are created in the Results will only refer directly to the offheap area and as you said we do the ref counting of these blocks in offheap. The only thing that could happen now is that till all the Results could be transferred to the client we may hold the block and so any such blocks cannot be evicted till the reference is cleared. > Don't allow Multi to retain too many blocks > --- > > Key: HBASE-14978 > URL: https://issues.apache.org/jira/browse/HBASE-14978 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-14978-v1.patch, HBASE-14978-v2.patch, > HBASE-14978.patch > > > Scans and Multi's have limits on the total size of cells that can be > returned. However if those requests are not all pointing at the same blocks > then the KeyValues can keep alive a lot more data than their size. > Take the following example: > A multi with a list of 1 gets to a fat row. Each column being returned in > in a different block. Each column is small 32 bytes or so. > So the total cell size will be 32 * 1 = ~320kb. However if each block is > 128k then total retained heap size will be almost 2gigs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14978) Don't allow Multi to retain too many blocks
[ https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057850#comment-15057850 ] Elliott Clark commented on HBASE-14978: --- Yeah so we'll oom if we're bringing things on heap ( branch-1.2 ). We'll kill the block cache by not allowing blocks to be free'd on other branches. bq.The only thing that could happen now is that till all the Results could be transferred to the client we may hold the block and so any such blocks cannot be evicted till the reference is cleared. Yeah. So if you have a high traffic server it's pretty easy to get to a state where this really hurts. 30 (default min) Threads * 2 gb (easy to get to example) of data blocks makes for a very unhappy block cache. On heap vs off heap is not substantially changing the issue. We are holding onto datablocks regardless of size needed or reserved. On heap we're encroaching into the memstore/blockcache reserved space. Causing the JVM to run out of memory and have to either full GC or just OOME. Off heap and we're encroaching into the index blocks and bloom blocks. Causing the block cache to either run out of memory and be un-able to release anything, or to release the most important index and bloom blocks. In any scenario we're just moving around which subsystem of the regionserver is running out of memory it thinks should be available. > Don't allow Multi to retain too many blocks > --- > > Key: HBASE-14978 > URL: https://issues.apache.org/jira/browse/HBASE-14978 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-14978-v1.patch, HBASE-14978-v2.patch, > HBASE-14978.patch > > > Scans and Multi's have limits on the total size of cells that can be > returned. However if those requests are not all pointing at the same blocks > then the KeyValues can keep alive a lot more data than their size. > Take the following example: > A multi with a list of 1 gets to a fat row. Each column being returned in > in a different block. Each column is small 32 bytes or so. > So the total cell size will be 32 * 1 = ~320kb. However if each block is > 128k then total retained heap size will be almost 2gigs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14979) Update to the newest Zookeeper release
[ https://issues.apache.org/jira/browse/HBASE-14979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057918#comment-15057918 ] Hudson commented on HBASE-14979: FAILURE: Integrated in HBase-1.2 #443 (See [https://builds.apache.org/job/HBase-1.2/443/]) HBASE-14979 Update to the newest Zookeeper release (eclark: rev f64cdf44b5c420d0ec29f84a48d3145441113351) * pom.xml > Update to the newest Zookeeper release > -- > > Key: HBASE-14979 > URL: https://issues.apache.org/jira/browse/HBASE-14979 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-14979.patch > > > ZOOKEEPER-706 is nice to have for anyone running replication that sometimes > gets stalled. We should update to the latest patch version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14979) Update to the newest Zookeeper release
[ https://issues.apache.org/jira/browse/HBASE-14979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057946#comment-15057946 ] Hudson commented on HBASE-14979: FAILURE: Integrated in HBase-1.3 #437 (See [https://builds.apache.org/job/HBase-1.3/437/]) HBASE-14979 Update to the newest Zookeeper release (eclark: rev a290a5d978a5eb730d9708bc2c0384d22fc37fb6) * pom.xml > Update to the newest Zookeeper release > -- > > Key: HBASE-14979 > URL: https://issues.apache.org/jira/browse/HBASE-14979 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.2.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-14979.patch > > > ZOOKEEPER-706 is nice to have for anyone running replication that sometimes > gets stalled. We should update to the latest patch version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14978) Don't allow Multi to retain too many blocks
[
https://issues.apache.org/jira/browse/HBASE-14978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057975#comment-15057975
]
Hadoop QA commented on HBASE-14978:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12777679/HBASE-14978-v1.patch
against master branch at commit ef92a6a067230cae96d3e3267da5a18ac5ad89c6.
ATTACHMENT ID: 12777679
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 4 new
or modified tests.
{color:green}+1 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.6.1 2.7.0
2.7.1)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 1
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not generate new
checkstyle errors.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn post-site goal succeeds with this
patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
{color:green}+1 zombies{color}. No zombie tests found running at the end of
the build.
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/16862//testReport/
Release Findbugs (version 2.0.3)warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/16862//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/16862//artifact/patchprocess/checkstyle-aggregate.html
Javadoc warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/16862//artifact/patchprocess/patchJavadocWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/16862//console
This message is automatically generated.
> Don't allow Multi to retain too many blocks
> ---
>
> Key: HBASE-14978
> URL: https://issues.apache.org/jira/browse/HBASE-14978
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>Priority: Critical
> Attachments: HBASE-14978-v1.patch, HBASE-14978-v2.patch,
> HBASE-14978.patch
>
>
> Scans and Multi's have limits on the total size of cells that can be
> returned. However if those requests are not all pointing at the same blocks
> then the KeyValues can keep alive a lot more data than their size.
> Take the following example:
> A multi with a list of 1 gets to a fat row. Each column being returned in
> in a different block. Each column is small 32 bytes or so.
> So the total cell size will be 32 * 1 = ~320kb. However if each block is
> 128k then total retained heap size will be almost 2gigs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14534) Bump yammer/coda/dropwizard metrics dependency version
[ https://issues.apache.org/jira/browse/HBASE-14534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-14534: Resolution: Fixed Fix Version/s: 2.0.0 Release Note: Updated yammer metrics to version 3.1.2 (now it's been renamed to dropwizard). API has changed quite a bit, consult https://dropwizard.github.io/metrics/3.1.0/manual/core/ for additional information. Note that among other things, in yammer 2.2.0 histograms were by default created in non-biased mode (uniform sampling), while in 3.1.0 histograms created via MetricsRegistry.histogram(...) are by default exponentially decayed. This shouldn't affect end users, though. Status: Resolved (was: Patch Available) > Bump yammer/coda/dropwizard metrics dependency version > -- > > Key: HBASE-14534 > URL: https://issues.apache.org/jira/browse/HBASE-14534 > Project: HBase > Issue Type: Task >Reporter: Nick Dimiduk >Assignee: Mikhail Antonov >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-14534-v2.patch, HBASE-14534.patch, wip.patch > > > After HBASE-12911 lands, let's update our dependency to the latest > incarnation of this library. I guess they're now calling it Dropwizard > Metrics. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13976) release manager list in ref guide is missing 0.94 line
[ https://issues.apache.org/jira/browse/HBASE-13976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-13976: Fix Version/s: 2.0.0 Status: Patch Available (was: Open) Ready for review. > release manager list in ref guide is missing 0.94 line > -- > > Key: HBASE-13976 > URL: https://issues.apache.org/jira/browse/HBASE-13976 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Sean Busbey >Assignee: Misty Stanley-Jones > Fix For: 2.0.0 > > Attachments: HBASE-13976.patch > > > 0.94 has slowed substantially, but we haven't EOLed it yet so we should make > sure folks looking to get a fix included know where to look. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-14983) Create metrics for per block type hit/miss ratios
[ https://issues.apache.org/jira/browse/HBASE-14983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark reassigned HBASE-14983: - Assignee: Elliott Clark > Create metrics for per block type hit/miss ratios > - > > Key: HBASE-14983 > URL: https://issues.apache.org/jira/browse/HBASE-14983 > Project: HBase > Issue Type: Improvement >Reporter: Elliott Clark >Assignee: Elliott Clark > > Missing a root index block is worse than missing a data block. We should know > the difference -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13976) release manager list in ref guide is missing 0.94 line
[ https://issues.apache.org/jira/browse/HBASE-13976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058740#comment-15058740 ] Sean Busbey commented on HBASE-13976: - +1 > release manager list in ref guide is missing 0.94 line > -- > > Key: HBASE-13976 > URL: https://issues.apache.org/jira/browse/HBASE-13976 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Sean Busbey >Assignee: Misty Stanley-Jones > Fix For: 2.0.0 > > Attachments: HBASE-13976.patch > > > 0.94 has slowed substantially, but we haven't EOLed it yet so we should make > sure folks looking to get a fix included know where to look. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14968) ConcurrentModificationException in region close resulting in the region staying in closing state
[
https://issues.apache.org/jira/browse/HBASE-14968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058905#comment-15058905
]
Hudson commented on HBASE-14968:
SUCCESS: Integrated in HBase-1.2 #444 (See
[https://builds.apache.org/job/HBase-1.2/444/])
HBASE-14968 ConcurrentModificationException in region close resulting in (enis:
rev f391b137111d9467b0f3a2930081d41eb2c5f5df)
*
hbase-server/src/test/java/org/apache/hadoop/hbase/executor/TestExecutorService.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/handler/RegionReplicaFlushHandler.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/executor/EventHandler.java
> ConcurrentModificationException in region close resulting in the region
> staying in closing state
>
>
> Key: HBASE-14968
> URL: https://issues.apache.org/jira/browse/HBASE-14968
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4, 1.0.4
>
> Attachments: hbase-14968_v1.patch
>
>
> We have seen this in our tests. The region gets closed, but the region close
> handler gets an unexpected exception causing the region to stay in closing
> state until RS is restarted.
> The Phoenix and security coprocessors were loaded in that region. Here is the
> stack trace:
> {code}
> java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.shutdown(CoprocessorHost.java:442)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionEnvironment.shutdown(RegionCoprocessorHost.java:155)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.shutdown(CoprocessorHost.java:272)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$5.postEnvCall(RegionCoprocessorHost.java:496)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1761)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.postClose(RegionCoprocessorHost.java:489)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doClose(HRegion.java:1502)
> at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1349)
> at
> org.apache.hadoop.hbase.regionserver.handler.CloseRegionHandler.process(CloseRegionHandler.java:138)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:128)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14984) Allow memcached block cache to set optimze to false
[ https://issues.apache.org/jira/browse/HBASE-14984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-14984: -- Component/s: BlockCache > Allow memcached block cache to set optimze to false > --- > > Key: HBASE-14984 > URL: https://issues.apache.org/jira/browse/HBASE-14984 > Project: HBase > Issue Type: Improvement > Components: BlockCache >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-14984.patch > > > In order to keep latency consistent it might not be good to allow the spy > memcached client to optimize. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14984) Allow memcached block cache to set optimze to false
[ https://issues.apache.org/jira/browse/HBASE-14984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-14984: -- Fix Version/s: 1.3.0 1.2.0 2.0.0 Affects Version/s: 1.3.0 1.2.0 2.0.0 Status: Patch Available (was: Open) > Allow memcached block cache to set optimze to false > --- > > Key: HBASE-14984 > URL: https://issues.apache.org/jira/browse/HBASE-14984 > Project: HBase > Issue Type: Improvement > Components: BlockCache >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-14984.patch > > > In order to keep latency consistent it might not be good to allow the spy > memcached client to optimize. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13976) release manager list in ref guide is missing 0.94 line
[ https://issues.apache.org/jira/browse/HBASE-13976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Misty Stanley-Jones updated HBASE-13976: Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to master. > release manager list in ref guide is missing 0.94 line > -- > > Key: HBASE-13976 > URL: https://issues.apache.org/jira/browse/HBASE-13976 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Sean Busbey >Assignee: Misty Stanley-Jones > Fix For: 2.0.0 > > Attachments: HBASE-13976.patch > > > 0.94 has slowed substantially, but we haven't EOLed it yet so we should make > sure folks looking to get a fix included know where to look. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14968) ConcurrentModificationException in region close resulting in the region staying in closing state
[
https://issues.apache.org/jira/browse/HBASE-14968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059006#comment-15059006
]
Hudson commented on HBASE-14968:
SUCCESS: Integrated in HBase-1.3 #438 (See
[https://builds.apache.org/job/HBase-1.3/438/])
HBASE-14968 ConcurrentModificationException in region close resulting in (enis:
rev fbad4d2466441d09f45d6fd42486b5e6dc00a893)
*
hbase-server/src/test/java/org/apache/hadoop/hbase/executor/TestExecutorService.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/handler/RegionReplicaFlushHandler.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/executor/EventHandler.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java
> ConcurrentModificationException in region close resulting in the region
> staying in closing state
>
>
> Key: HBASE-14968
> URL: https://issues.apache.org/jira/browse/HBASE-14968
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4, 1.0.4
>
> Attachments: hbase-14968_v1.patch
>
>
> We have seen this in our tests. The region gets closed, but the region close
> handler gets an unexpected exception causing the region to stay in closing
> state until RS is restarted.
> The Phoenix and security coprocessors were loaded in that region. Here is the
> stack trace:
> {code}
> java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.shutdown(CoprocessorHost.java:442)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionEnvironment.shutdown(RegionCoprocessorHost.java:155)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.shutdown(CoprocessorHost.java:272)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$5.postEnvCall(RegionCoprocessorHost.java:496)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1761)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.postClose(RegionCoprocessorHost.java:489)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doClose(HRegion.java:1502)
> at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1349)
> at
> org.apache.hadoop.hbase.regionserver.handler.CloseRegionHandler.process(CloseRegionHandler.java:138)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:128)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14977) ChoreService.shutdown may result in ConcurrentModificationException
[ https://issues.apache.org/jira/browse/HBASE-14977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-14977: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 1.1.4 1.3.0 1.2.0 Status: Resolved (was: Patch Available) I've pushed to 1.1+ (issue only affects 1.1+). Thanks Vladimir. > ChoreService.shutdown may result in ConcurrentModificationException > --- > > Key: HBASE-14977 > URL: https://issues.apache.org/jira/browse/HBASE-14977 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Minor > Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4 > > Attachments: HBASE-14977-v1.patch > > > As seen in this test: > https://builds.apache.org/job/HBase-1.3/jdk=latest1.8,label=Hadoop/425/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.regionserver.compactions.TestFIFOCompactionPolicy-output.txt > We need to make shutdown method synchronized to avoid this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14936) CombinedBlockCache should overwrite CacheStats#rollMetricsPeriod()
[
https://issues.apache.org/jira/browse/HBASE-14936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-14936:
--
Fix Version/s: (was: 1.0)
(was: 1.3)
(was: 1.1)
(was: 1.2)
> CombinedBlockCache should overwrite CacheStats#rollMetricsPeriod()
> --
>
> Key: HBASE-14936
> URL: https://issues.apache.org/jira/browse/HBASE-14936
> Project: HBase
> Issue Type: Bug
> Components: BlockCache
>Affects Versions: 1.1.2
>Reporter: Jianwei Cui
>Assignee: Jianwei Cui
> Fix For: 2.0.0
>
> Attachments: HBASE-14936-branch-1.0-1.1.patch,
> HBASE-14936-branch-1.0-addendum.patch, HBASE-14936-trunk-v1.patch,
> HBASE-14936-trunk-v2.patch, HBASE-14936-trunk.patch
>
>
> It seems CombinedBlockCache should overwrite CacheStats#rollMetricsPeriod() as
> {code}
> public void rollMetricsPeriod() {
> lruCacheStats.rollMetricsPeriod();
> bucketCacheStats.rollMetricsPeriod();
> }
> {code}
> otherwise, CombinedBlockCache.getHitRatioPastNPeriods() and
> CombinedBlockCache.getHitCachingRatioPastNPeriods() will always return 0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14936) CombinedBlockCache should overwrite CacheStats#rollMetricsPeriod()
[
https://issues.apache.org/jira/browse/HBASE-14936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-14936:
--
Fix Version/s: 1.0.4
1.1.4
1.3.0
1.2.0
> CombinedBlockCache should overwrite CacheStats#rollMetricsPeriod()
> --
>
> Key: HBASE-14936
> URL: https://issues.apache.org/jira/browse/HBASE-14936
> Project: HBase
> Issue Type: Bug
> Components: BlockCache
>Affects Versions: 1.1.2
>Reporter: Jianwei Cui
>Assignee: Jianwei Cui
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4, 1.0.4
>
> Attachments: HBASE-14936-branch-1.0-1.1.patch,
> HBASE-14936-branch-1.0-addendum.patch, HBASE-14936-trunk-v1.patch,
> HBASE-14936-trunk-v2.patch, HBASE-14936-trunk.patch
>
>
> It seems CombinedBlockCache should overwrite CacheStats#rollMetricsPeriod() as
> {code}
> public void rollMetricsPeriod() {
> lruCacheStats.rollMetricsPeriod();
> bucketCacheStats.rollMetricsPeriod();
> }
> {code}
> otherwise, CombinedBlockCache.getHitRatioPastNPeriods() and
> CombinedBlockCache.getHitCachingRatioPastNPeriods() will always return 0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14943) Procedure-V2: Deadlock in WALProcedureStore
[ https://issues.apache.org/jira/browse/HBASE-14943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-14943: Resolution: Fixed Fix Version/s: 1.1.3 1.2.0 2.0.0 Status: Resolved (was: Patch Available) committed HBASE-14943 which removes the 2nd lock > Procedure-V2: Deadlock in WALProcedureStore > --- > > Key: HBASE-14943 > URL: https://issues.apache.org/jira/browse/HBASE-14943 > Project: HBase > Issue Type: Bug > Components: proc-v2 >Affects Versions: 2.0.0, 1.2.0, 1.1.3 >Reporter: Ashu Pachauri >Assignee: Matteo Bertozzi >Priority: Blocker > Fix For: 2.0.0, 1.2.0, 1.1.3 > > Attachments: HBASE-14943-v0.patch, deadlock-jstack.out > > > Found deadlock in WALProcedureStore between the WALProcedureSyncThread and > WALProcedureStore#update/delete/insert API which is used by the > ProcedureExecutor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14030) HBase Backup/Restore Phase 1
[ https://issues.apache.org/jira/browse/HBASE-14030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-14030: -- Attachment: (was: HBASE-14030-v20.patch) > HBase Backup/Restore Phase 1 > > > Key: HBASE-14030 > URL: https://issues.apache.org/jira/browse/HBASE-14030 > Project: HBase > Issue Type: Umbrella >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-14030-v0.patch, HBASE-14030-v1.patch, > HBASE-14030-v10.patch, HBASE-14030-v11.patch, HBASE-14030-v12.patch, > HBASE-14030-v13.patch, HBASE-14030-v14.patch, HBASE-14030-v15.patch, > HBASE-14030-v17.patch, HBASE-14030-v18.patch, HBASE-14030-v2.patch, > HBASE-14030-v3.patch, HBASE-14030-v4.patch, HBASE-14030-v5.patch, > HBASE-14030-v6.patch, HBASE-14030-v7.patch, HBASE-14030-v8.patch > > > This is the umbrella ticket for Backup/Restore Phase 1. See HBASE-7912 design > doc for the phase description. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14984) Allow memcached block cache to set optimze to false
[ https://issues.apache.org/jira/browse/HBASE-14984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-14984: -- Attachment: HBASE-14984.patch > Allow memcached block cache to set optimze to false > --- > > Key: HBASE-14984 > URL: https://issues.apache.org/jira/browse/HBASE-14984 > Project: HBase > Issue Type: Improvement >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-14984.patch > > > In order to keep latency consistent it might not be good to allow the spy > memcached client to optimize. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14984) Allow memcached block cache to set optimze to false
[ https://issues.apache.org/jira/browse/HBASE-14984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-14984: -- Description: In order to keep latency consistent it might not be good to allow the spy memcached client to optimize. (was: In order to keep latency down it might not be good to allow the spy memcached client to optimize.) > Allow memcached block cache to set optimze to false > --- > > Key: HBASE-14984 > URL: https://issues.apache.org/jira/browse/HBASE-14984 > Project: HBase > Issue Type: Improvement >Reporter: Elliott Clark >Assignee: Elliott Clark > > In order to keep latency consistent it might not be good to allow the spy > memcached client to optimize. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14830) Fix broken links in 0.94 generated docs
[
https://issues.apache.org/jira/browse/HBASE-14830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058875#comment-15058875
]
Hudson commented on HBASE-14830:
FAILURE: Integrated in HBase-0.94-JDK7 #243 (See
[https://builds.apache.org/job/HBase-0.94-JDK7/243/])
HBASE-14830 Make encoding classes @InterfaceAudience.Private (mstanleyjones:
rev 0f35a32ab123ee299f4aaaea02b4ba2d2b43cff2)
* src/main/java/org/apache/hadoop/hbase/io/encoding/DiffKeyDeltaEncoder.java
* src/main/java/org/apache/hadoop/hbase/io/encoding/CopyKeyDataBlockEncoder.java
* src/main/java/org/apache/hadoop/hbase/io/encoding/PrefixKeyDeltaEncoder.java
* src/main/java/org/apache/hadoop/hbase/io/encoding/FastDiffDeltaEncoder.java
> Fix broken links in 0.94 generated docs
> ---
>
> Key: HBASE-14830
> URL: https://issues.apache.org/jira/browse/HBASE-14830
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 0.94.27
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 0.94.28
>
> Attachments: HBASE-14830-v1.patch, HBASE-14830.patch
>
>
> {code}
> host: hbase.apache.org
> date: Mon, 16-Nov-2015 10:56:28 (local)
> Linklint version: 2.3.5_ingo_020
> #
> # ERROR 2 missing html files (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/generated/HBase.html
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/avro/package-summary.html
> /0.94/devapidocs/src-html/org/apache/hadoop/hbase/io/encoding/BufferedDataBlockEncoder.html
> used in 4 files:
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/CopyKeyDataBlockEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/DiffKeyDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/FastDiffDeltaEncoder.html
>
> /0.94/devapidocs/org/apache/hadoop/hbase/io/encoding/PrefixKeyDeltaEncoder.html
> #
> # ERROR 1 missing other file (cross referenced)
> #
> /0.94/devapidocs/org/apache/hadoop/hbase/HADOOP-1581
> used in 1 file:
> /0.94/devapidocs/org/apache/hadoop/hbase/HTableDescriptor.html
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14030) HBase Backup/Restore Phase 1
[
https://issues.apache.org/jira/browse/HBASE-14030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058869#comment-15058869
]
Hadoop QA commented on HBASE-14030:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12777825/HBASE-14030-v20.patch
against master branch at commit 60d33ce34191533bb858852584bd9bddfeb16a23.
ATTACHMENT ID: 12777825
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 23 new
or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/16866//console
This message is automatically generated.
> HBase Backup/Restore Phase 1
>
>
> Key: HBASE-14030
> URL: https://issues.apache.org/jira/browse/HBASE-14030
> Project: HBase
> Issue Type: Umbrella
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Attachments: HBASE-14030-v0.patch, HBASE-14030-v1.patch,
> HBASE-14030-v10.patch, HBASE-14030-v11.patch, HBASE-14030-v12.patch,
> HBASE-14030-v13.patch, HBASE-14030-v14.patch, HBASE-14030-v15.patch,
> HBASE-14030-v17.patch, HBASE-14030-v18.patch, HBASE-14030-v2.patch,
> HBASE-14030-v20.patch, HBASE-14030-v3.patch, HBASE-14030-v4.patch,
> HBASE-14030-v5.patch, HBASE-14030-v6.patch, HBASE-14030-v7.patch,
> HBASE-14030-v8.patch
>
>
> This is the umbrella ticket for Backup/Restore Phase 1. See HBASE-7912 design
> doc for the phase description.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14970) Backport HBASE-13082 and its sub-jira to branch-1
[ https://issues.apache.org/jira/browse/HBASE-14970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-14970: -- Affects Version/s: (was: 1.3) 1.3.0 > Backport HBASE-13082 and its sub-jira to branch-1 > - > > Key: HBASE-14970 > URL: https://issues.apache.org/jira/browse/HBASE-14970 > Project: HBase > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Attachments: HBASE-13082-branch-1.patch, HBASE-14970_branch-1.patch, > HBASE-14970_branch-1.patch, HBASE-14970_branch-1.patch, > HBASE-14970_branch-1_1.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14955) OOME: cannot create native thread is back
[ https://issues.apache.org/jira/browse/HBASE-14955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-14955: -- Affects Version/s: (was: test) > OOME: cannot create native thread is back > - > > Key: HBASE-14955 > URL: https://issues.apache.org/jira/browse/HBASE-14955 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: stack > Attachments: HBASE-14955-branch-1.patch > > > This fail is OOME cannot create native thread. Two MR jobs fail: > > org.apache.hadoop.hbase.mapreduce.TestImportTSVWithVisibilityLabels.org.apache.hadoop.hbase.mapreduce.TestImportTSVWithVisibilityLabels46 > ms1 > org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1.org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan142 > ms1 > Was running 1.3 tests on H0. > Could try and purge resources used by these tests. > Making issue in meantime to keep an eye on it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14947) WALProcedureStore improvements
[ https://issues.apache.org/jira/browse/HBASE-14947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-14947: Resolution: Fixed Fix Version/s: 1.1.3 1.2.0 2.0.0 Status: Resolved (was: Patch Available) > WALProcedureStore improvements > -- > > Key: HBASE-14947 > URL: https://issues.apache.org/jira/browse/HBASE-14947 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Ashu Pachauri >Assignee: Matteo Bertozzi >Priority: Blocker > Fix For: 2.0.0, 1.2.0, 1.1.3 > > Attachments: HBASE-14947-v0.patch, HBASE-14947-v1.patch > > > We ended up with a deadlock in HBASE-14943, with the storeTracker and lock > acquired in reverse order by syncLoop() and insert/update/delete. In the > syncLoop() with don't need the lock when we try to roll or removeInactive. > also we can move the insert/update/delete tracker check in the syncLoop > avoiding to the extra lock operation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14030) HBase Backup/Restore Phase 1
[ https://issues.apache.org/jira/browse/HBASE-14030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-14030: -- Attachment: HBASE-14030-v20.patch > HBase Backup/Restore Phase 1 > > > Key: HBASE-14030 > URL: https://issues.apache.org/jira/browse/HBASE-14030 > Project: HBase > Issue Type: Umbrella >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-14030-v0.patch, HBASE-14030-v1.patch, > HBASE-14030-v10.patch, HBASE-14030-v11.patch, HBASE-14030-v12.patch, > HBASE-14030-v13.patch, HBASE-14030-v14.patch, HBASE-14030-v15.patch, > HBASE-14030-v17.patch, HBASE-14030-v18.patch, HBASE-14030-v2.patch, > HBASE-14030-v20.patch, HBASE-14030-v3.patch, HBASE-14030-v4.patch, > HBASE-14030-v5.patch, HBASE-14030-v6.patch, HBASE-14030-v7.patch, > HBASE-14030-v8.patch > > > This is the umbrella ticket for Backup/Restore Phase 1. See HBASE-7912 design > doc for the phase description. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14030) HBase Backup/Restore Phase 1
[ https://issues.apache.org/jira/browse/HBASE-14030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-14030: -- Status: Open (was: Patch Available) > HBase Backup/Restore Phase 1 > > > Key: HBASE-14030 > URL: https://issues.apache.org/jira/browse/HBASE-14030 > Project: HBase > Issue Type: Umbrella >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-14030-v0.patch, HBASE-14030-v1.patch, > HBASE-14030-v10.patch, HBASE-14030-v11.patch, HBASE-14030-v12.patch, > HBASE-14030-v13.patch, HBASE-14030-v14.patch, HBASE-14030-v15.patch, > HBASE-14030-v17.patch, HBASE-14030-v18.patch, HBASE-14030-v2.patch, > HBASE-14030-v20.patch, HBASE-14030-v3.patch, HBASE-14030-v4.patch, > HBASE-14030-v5.patch, HBASE-14030-v6.patch, HBASE-14030-v7.patch, > HBASE-14030-v8.patch > > > This is the umbrella ticket for Backup/Restore Phase 1. See HBASE-7912 design > doc for the phase description. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14030) HBase Backup/Restore Phase 1
[ https://issues.apache.org/jira/browse/HBASE-14030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-14030: -- Status: Patch Available (was: Open) > HBase Backup/Restore Phase 1 > > > Key: HBASE-14030 > URL: https://issues.apache.org/jira/browse/HBASE-14030 > Project: HBase > Issue Type: Umbrella >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Attachments: HBASE-14030-v0.patch, HBASE-14030-v1.patch, > HBASE-14030-v10.patch, HBASE-14030-v11.patch, HBASE-14030-v12.patch, > HBASE-14030-v13.patch, HBASE-14030-v14.patch, HBASE-14030-v15.patch, > HBASE-14030-v17.patch, HBASE-14030-v18.patch, HBASE-14030-v2.patch, > HBASE-14030-v20.patch, HBASE-14030-v3.patch, HBASE-14030-v4.patch, > HBASE-14030-v5.patch, HBASE-14030-v6.patch, HBASE-14030-v7.patch, > HBASE-14030-v8.patch > > > This is the umbrella ticket for Backup/Restore Phase 1. See HBASE-7912 design > doc for the phase description. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14929) There is a space missing from Table "foo" is not currently available.
[
https://issues.apache.org/jira/browse/HBASE-14929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058868#comment-15058868
]
Jonathan Hsieh commented on HBASE-14929:
failures are unrelated to this patch.
> There is a space missing from Table "foo" is not currently available.
> -
>
> Key: HBASE-14929
> URL: https://issues.apache.org/jira/browse/HBASE-14929
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Malaska
>Assignee: Carlos A. Morillo
>Priority: Trivial
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.3
>
> Attachments: HBASE-14929.patch
>
>
> Go to the following line in LoadIncrementalHFiles.java
> throw new TableNotFoundException("Table " + table.getName() + "is not
> currently available.");
> and add a space before is and after '
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14795) Enhance the spark-hbase scan operations
[
https://issues.apache.org/jira/browse/HBASE-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058902#comment-15058902
]
Jonathan Hsieh commented on HBASE-14795:
If you look at the test path script, the new warnings from javadoc and javac
are likely from these scala warnings:
{code}
[INFO] --- scala-maven-plugin:3.2.0:compile (scala-compile-first) @ hbase-spark
---
[INFO]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase/hbase-spark/src/main/java:-1:
info: compiling
[INFO]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase/hbase-spark/src/main/scala:-1:
info: compiling
[INFO] Compiling 38 source files to
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase/hbase-spark/target/classes
at 1449855286283
[WARNING] warning: there were 3 feature warning(s); re-run with -feature for
details
[WARNING] one warning found
[INFO] prepare-compile in 0 s
[INFO] compile in 23 s
[INFO]
[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ hbase-spark ---
[INFO] Compiling 8 source files to
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase/hbase-spark/target/classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
hbase-spark ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO]
[INFO] --- scala-maven-plugin:3.2.0:testCompile (scala-test-compile) @
hbase-spark ---
[INFO]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase/hbase-spark/src/test/java:-1:
info: compiling
[INFO]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase/hbase-spark/src/test/scala:-1:
info: compiling
[INFO] Compiling 7 source files to
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase/hbase-spark/target/test-classes
at 1449855310486
[WARNING] warning: Class org.apache.hadoop.mapred.MiniMRCluster not found -
continuing with a stub.
[WARNING] one warning found
[INFO] prepare-compile in 0 s
[INFO] compile in 20 s
{code}
The a previous build didn't have the warning in the scala sections. [2]
{code}
[INFO] --- scala-maven-plugin:3.2.0:compile (scala-compile-first) @ hbase-spark
---
[INFO]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase/hbase-spark/src/main/java:-1:
info: compiling
[INFO]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase/hbase-spark/src/main/scala:-1:
info: compiling
[INFO] Compiling 33 source files to
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase/hbase-spark/target/classes
at 1449897694709
[INFO] prepare-compile in 0 s
[INFO] compile in 19 s
[INFO]
[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ hbase-spark ---
[INFO] Compiling 8 source files to
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase/hbase-spark/target/classes
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
hbase-spark ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO]
[INFO] --- scala-maven-plugin:3.2.0:testCompile (scala-test-compile) @
hbase-spar
{code}
Can one of you guys follow up or addendum to clean up these newly introduced
warnings? Maybe enable the -feature options suggested by the build?
[2] https://builds.apache.org/job/PreCommit-HBASE-Build/16839//console
> Enhance the spark-hbase scan operations
> ---
>
> Key: HBASE-14795
> URL: https://issues.apache.org/jira/browse/HBASE-14795
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Malaska
>Assignee: Zhan Zhang
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments:
> 0001-HBASE-14795-Enhance-the-spark-hbase-scan-operations.patch,
> HBASE-14795-1.patch, HBASE-14795-2.patch, HBASE-14795-3.patch,
> HBASE-14795-4.patch
>
>
> This is a sub-jira of HBASE-14789. This jira is to focus on the replacement
> of TableInputFormat for a more custom scan implementation that will make the
> following use case more effective.
> Use case:
> In the case you have multiple scan ranges on a single table with in a single
> query. TableInputFormat will scan the the outer range of the scan start and
> end range where this implementation can be more pointed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14795) Enhance the spark-hbase scan operations
[ https://issues.apache.org/jira/browse/HBASE-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058997#comment-15058997 ] Zhan Zhang commented on HBASE-14795: [~jmhsieh] Thanks for bring this up. I am working on HBASE-14849, and also doing some cleanup work, which will also fix following warnings. warning: there were 3 feature warning(s); re-run with -feature for details Regarding below warning, it is a legacy one and HBASE-14159 has already open for it. warning: Class org.apache.hadoop.mapred.MiniMRCluster not found - continuing with a stub. > Enhance the spark-hbase scan operations > --- > > Key: HBASE-14795 > URL: https://issues.apache.org/jira/browse/HBASE-14795 > Project: HBase > Issue Type: Improvement >Reporter: Ted Malaska >Assignee: Zhan Zhang >Priority: Minor > Fix For: 2.0.0 > > Attachments: > 0001-HBASE-14795-Enhance-the-spark-hbase-scan-operations.patch, > HBASE-14795-1.patch, HBASE-14795-2.patch, HBASE-14795-3.patch, > HBASE-14795-4.patch > > > This is a sub-jira of HBASE-14789. This jira is to focus on the replacement > of TableInputFormat for a more custom scan implementation that will make the > following use case more effective. > Use case: > In the case you have multiple scan ranges on a single table with in a single > query. TableInputFormat will scan the the outer range of the scan start and > end range where this implementation can be more pointed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14955) OOME: cannot create native thread is back
[ https://issues.apache.org/jira/browse/HBASE-14955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-14955: -- Assignee: Heng Chen Status: Patch Available (was: Open) > OOME: cannot create native thread is back > - > > Key: HBASE-14955 > URL: https://issues.apache.org/jira/browse/HBASE-14955 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: stack >Assignee: Heng Chen > Attachments: HBASE-14955-branch-1.patch > > > This fail is OOME cannot create native thread. Two MR jobs fail: > > org.apache.hadoop.hbase.mapreduce.TestImportTSVWithVisibilityLabels.org.apache.hadoop.hbase.mapreduce.TestImportTSVWithVisibilityLabels46 > ms1 > org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1.org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan142 > ms1 > Was running 1.3 tests on H0. > Could try and purge resources used by these tests. > Making issue in meantime to keep an eye on it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14955) OOME: cannot create native thread is back
[ https://issues.apache.org/jira/browse/HBASE-14955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059063#comment-15059063 ] stack commented on HBASE-14955: --- Patch looks great to me. Submitted it to get a run in. > OOME: cannot create native thread is back > - > > Key: HBASE-14955 > URL: https://issues.apache.org/jira/browse/HBASE-14955 > Project: HBase > Issue Type: Sub-task > Components: test >Reporter: stack >Assignee: Heng Chen > Attachments: HBASE-14955-branch-1.patch > > > This fail is OOME cannot create native thread. Two MR jobs fail: > > org.apache.hadoop.hbase.mapreduce.TestImportTSVWithVisibilityLabels.org.apache.hadoop.hbase.mapreduce.TestImportTSVWithVisibilityLabels46 > ms1 > org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan1.org.apache.hadoop.hbase.mapreduce.TestTableInputFormatScan142 > ms1 > Was running 1.3 tests on H0. > Could try and purge resources used by these tests. > Making issue in meantime to keep an eye on it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14968) ConcurrentModificationException in region close resulting in the region staying in closing state
[
https://issues.apache.org/jira/browse/HBASE-14968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059077#comment-15059077
]
Hudson commented on HBASE-14968:
FAILURE: Integrated in HBase-1.3-IT #376 (See
[https://builds.apache.org/job/HBase-1.3-IT/376/])
HBASE-14968 ConcurrentModificationException in region close resulting in (enis:
rev fbad4d2466441d09f45d6fd42486b5e6dc00a893)
*
hbase-server/src/test/java/org/apache/hadoop/hbase/executor/TestExecutorService.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/executor/EventHandler.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/handler/RegionReplicaFlushHandler.java
> ConcurrentModificationException in region close resulting in the region
> staying in closing state
>
>
> Key: HBASE-14968
> URL: https://issues.apache.org/jira/browse/HBASE-14968
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4, 1.0.4
>
> Attachments: hbase-14968_v1.patch
>
>
> We have seen this in our tests. The region gets closed, but the region close
> handler gets an unexpected exception causing the region to stay in closing
> state until RS is restarted.
> The Phoenix and security coprocessors were loaded in that region. Here is the
> stack trace:
> {code}
> java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.shutdown(CoprocessorHost.java:442)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionEnvironment.shutdown(RegionCoprocessorHost.java:155)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.shutdown(CoprocessorHost.java:272)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$5.postEnvCall(RegionCoprocessorHost.java:496)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1761)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.postClose(RegionCoprocessorHost.java:489)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doClose(HRegion.java:1502)
> at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1349)
> at
> org.apache.hadoop.hbase.regionserver.handler.CloseRegionHandler.process(CloseRegionHandler.java:138)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:128)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14947) WALProcedureStore improvements
[ https://issues.apache.org/jira/browse/HBASE-14947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059078#comment-15059078 ] Hudson commented on HBASE-14947: FAILURE: Integrated in HBase-1.3-IT #376 (See [https://builds.apache.org/job/HBase-1.3-IT/376/]) HBASE-14947 WALProcedureStore improvements (matteo.bertozzi: rev bf7c36fccac5477d08e296ad93671d2c30ae2dc8) * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/WALProcedureStore.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/ProcedureStoreTracker.java * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/store/wal/TestWALProcedureStore.java * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/TestProcedureRecovery.java * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/store/TestProcedureStoreTracker.java > WALProcedureStore improvements > -- > > Key: HBASE-14947 > URL: https://issues.apache.org/jira/browse/HBASE-14947 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Ashu Pachauri >Assignee: Matteo Bertozzi >Priority: Blocker > Fix For: 2.0.0, 1.2.0, 1.1.3 > > Attachments: HBASE-14947-v0.patch, HBASE-14947-v1.patch > > > We ended up with a deadlock in HBASE-14943, with the storeTracker and lock > acquired in reverse order by syncLoop() and insert/update/delete. In the > syncLoop() with don't need the lock when we try to roll or removeInactive. > also we can move the insert/update/delete tracker check in the syncLoop > avoiding to the extra lock operation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14977) ChoreService.shutdown may result in ConcurrentModificationException
[ https://issues.apache.org/jira/browse/HBASE-14977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059076#comment-15059076 ] Hudson commented on HBASE-14977: FAILURE: Integrated in HBase-1.3-IT #376 (See [https://builds.apache.org/job/HBase-1.3-IT/376/]) HBASE-14977 ChoreService.shutdown may result in (enis: rev 31d73a4bdec59ba2ca6bdc04d881f2bc3726e903) * hbase-common/src/main/java/org/apache/hadoop/hbase/ChoreService.java > ChoreService.shutdown may result in ConcurrentModificationException > --- > > Key: HBASE-14977 > URL: https://issues.apache.org/jira/browse/HBASE-14977 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Minor > Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4 > > Attachments: HBASE-14977-v1.patch > > > As seen in this test: > https://builds.apache.org/job/HBase-1.3/jdk=latest1.8,label=Hadoop/425/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.regionserver.compactions.TestFIFOCompactionPolicy-output.txt > We need to make shutdown method synchronized to avoid this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14968) ConcurrentModificationException in region close resulting in the region staying in closing state
[
https://issues.apache.org/jira/browse/HBASE-14968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059134#comment-15059134
]
Hudson commented on HBASE-14968:
SUCCESS: Integrated in HBase-1.1-JDK8 #1708 (See
[https://builds.apache.org/job/HBase-1.1-JDK8/1708/])
HBASE-14968 ConcurrentModificationException in region close resulting in (enis:
rev 6ae430f59649c057efbef9ee23439f2f729e3fd8)
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/handler/RegionReplicaFlushHandler.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/executor/TestExecutorService.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/executor/EventHandler.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java
> ConcurrentModificationException in region close resulting in the region
> staying in closing state
>
>
> Key: HBASE-14968
> URL: https://issues.apache.org/jira/browse/HBASE-14968
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4, 1.0.4
>
> Attachments: hbase-14968_v1.patch
>
>
> We have seen this in our tests. The region gets closed, but the region close
> handler gets an unexpected exception causing the region to stay in closing
> state until RS is restarted.
> The Phoenix and security coprocessors were loaded in that region. Here is the
> stack trace:
> {code}
> java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.shutdown(CoprocessorHost.java:442)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionEnvironment.shutdown(RegionCoprocessorHost.java:155)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.shutdown(CoprocessorHost.java:272)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$5.postEnvCall(RegionCoprocessorHost.java:496)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1761)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.postClose(RegionCoprocessorHost.java:489)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doClose(HRegion.java:1502)
> at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1349)
> at
> org.apache.hadoop.hbase.regionserver.handler.CloseRegionHandler.process(CloseRegionHandler.java:138)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:128)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14947) WALProcedureStore improvements
[ https://issues.apache.org/jira/browse/HBASE-14947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059135#comment-15059135 ] Hudson commented on HBASE-14947: SUCCESS: Integrated in HBase-1.1-JDK8 #1708 (See [https://builds.apache.org/job/HBase-1.1-JDK8/1708/]) HBASE-14947 WALProcedureStore improvements (matteo.bertozzi: rev 20b6dba997acd973fb8bd74666c42165bc715dbc) * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/ProcedureStoreTracker.java * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/store/wal/TestWALProcedureStore.java * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/store/TestProcedureStoreTracker.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/WALProcedureStore.java > WALProcedureStore improvements > -- > > Key: HBASE-14947 > URL: https://issues.apache.org/jira/browse/HBASE-14947 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Ashu Pachauri >Assignee: Matteo Bertozzi >Priority: Blocker > Fix For: 2.0.0, 1.2.0, 1.1.3 > > Attachments: HBASE-14947-v0.patch, HBASE-14947-v1.patch > > > We ended up with a deadlock in HBASE-14943, with the storeTracker and lock > acquired in reverse order by syncLoop() and insert/update/delete. In the > syncLoop() with don't need the lock when we try to roll or removeInactive. > also we can move the insert/update/delete tracker check in the syncLoop > avoiding to the extra lock operation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14977) ChoreService.shutdown may result in ConcurrentModificationException
[ https://issues.apache.org/jira/browse/HBASE-14977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059196#comment-15059196 ] Hudson commented on HBASE-14977: FAILURE: Integrated in HBase-Trunk_matrix #556 (See [https://builds.apache.org/job/HBase-Trunk_matrix/556/]) HBASE-14977 ChoreService.shutdown may result in (enis: rev a4bbc461e367994ed7b41673a4accb99bbe5c364) * hbase-common/src/main/java/org/apache/hadoop/hbase/ChoreService.java > ChoreService.shutdown may result in ConcurrentModificationException > --- > > Key: HBASE-14977 > URL: https://issues.apache.org/jira/browse/HBASE-14977 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Minor > Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4 > > Attachments: HBASE-14977-v1.patch > > > As seen in this test: > https://builds.apache.org/job/HBase-1.3/jdk=latest1.8,label=Hadoop/425/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.regionserver.compactions.TestFIFOCompactionPolicy-output.txt > We need to make shutdown method synchronized to avoid this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14968) ConcurrentModificationException in region close resulting in the region staying in closing state
[
https://issues.apache.org/jira/browse/HBASE-14968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059198#comment-15059198
]
Hudson commented on HBASE-14968:
FAILURE: Integrated in HBase-Trunk_matrix #556 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/556/])
HBASE-14968 ConcurrentModificationException in region close resulting in (enis:
rev 3e260631612b4f41638e663b2e451841f522ae49)
* hbase-server/src/main/java/org/apache/hadoop/hbase/executor/EventHandler.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/handler/RegionReplicaFlushHandler.java
*
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java
*
hbase-server/src/test/java/org/apache/hadoop/hbase/executor/TestExecutorService.java
> ConcurrentModificationException in region close resulting in the region
> staying in closing state
>
>
> Key: HBASE-14968
> URL: https://issues.apache.org/jira/browse/HBASE-14968
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4, 1.0.4
>
> Attachments: hbase-14968_v1.patch
>
>
> We have seen this in our tests. The region gets closed, but the region close
> handler gets an unexpected exception causing the region to stay in closing
> state until RS is restarted.
> The Phoenix and security coprocessors were loaded in that region. Here is the
> stack trace:
> {code}
> java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
> at java.util.ArrayList$Itr.next(ArrayList.java:851)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost$Environment.shutdown(CoprocessorHost.java:442)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionEnvironment.shutdown(RegionCoprocessorHost.java:155)
> at
> org.apache.hadoop.hbase.coprocessor.CoprocessorHost.shutdown(CoprocessorHost.java:272)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$5.postEnvCall(RegionCoprocessorHost.java:496)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1761)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.postClose(RegionCoprocessorHost.java:489)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doClose(HRegion.java:1502)
> at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1349)
> at
> org.apache.hadoop.hbase.regionserver.handler.CloseRegionHandler.process(CloseRegionHandler.java:138)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:128)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14534) Bump yammer/coda/dropwizard metrics dependency version
[ https://issues.apache.org/jira/browse/HBASE-14534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059200#comment-15059200 ] Hudson commented on HBASE-14534: FAILURE: Integrated in HBase-Trunk_matrix #556 (See [https://builds.apache.org/job/HBase-Trunk_matrix/556/]) HBASE-14534 Bump yammer/coda/dropwizard metrics dependency version (antonov: rev abe30b52a8036078f833dc5b3d2b03daa2e93dfc) * hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/BlockCacheViewTmpl.jamon * hbase-it/pom.xml * hbase-shell/pom.xml * hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestMetricsConnection.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFilePrettyPrinter.java * hbase-client/src/main/java/org/apache/hadoop/hbase/client/MetricsConnection.java * hbase-server/src/test/java/org/apache/hadoop/hbase/TestPerformanceEvaluation.java * hbase-resource-bundle/src/main/resources/supplemental-models.xml * hbase-server/pom.xml * hbase-server/src/test/java/org/apache/hadoop/hbase/wal/WALPerformanceEvaluation.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/AgeSnapshot.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/BlockCacheUtil.java * hbase-hadoop2-compat/src/main/java/org/apache/hadoop/metrics2/lib/MutableHistogram.java * hbase-server/src/test/java/org/apache/hadoop/hbase/PerformanceEvaluation.java * hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/CacheStats.java * hbase-shaded/pom.xml * pom.xml * hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/TableMapReduceUtil.java * hbase-server/src/main/java/org/apache/hadoop/hbase/util/YammerHistogramUtils.java * hbase-hadoop2-compat/pom.xml * hbase-client/pom.xml * hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/ServerMetricsTmpl.jamon * hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestClientPushback.java * hbase-it/src/test/java/org/apache/hadoop/hbase/IntegrationTestRegionReplicaPerf.java > Bump yammer/coda/dropwizard metrics dependency version > -- > > Key: HBASE-14534 > URL: https://issues.apache.org/jira/browse/HBASE-14534 > Project: HBase > Issue Type: Task >Reporter: Nick Dimiduk >Assignee: Mikhail Antonov >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-14534-v2.patch, HBASE-14534.patch, wip.patch > > > After HBASE-12911 lands, let's update our dependency to the latest > incarnation of this library. I guess they're now calling it Dropwizard > Metrics. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13425) Documentation nit in REST Gateway impersonation section
[
https://issues.apache.org/jira/browse/HBASE-13425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059201#comment-15059201
]
Hudson commented on HBASE-13425:
FAILURE: Integrated in HBase-Trunk_matrix #556 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/556/])
HBASE-13425 Documentation nit in REST Gateway impersonation section
(mstanleyjones: rev f0a97a1fdf0d8386f089306fdc1089080758e973)
* src/main/asciidoc/_chapters/security.adoc
> Documentation nit in REST Gateway impersonation section
> ---
>
> Key: HBASE-13425
> URL: https://issues.apache.org/jira/browse/HBASE-13425
> Project: HBase
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 2.0.0
>Reporter: Jeremie Gomez
>Assignee: Misty Stanley-Jones
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-13425-v1.patch, HBASE-13425.patch
>
>
> In section "55.8. REST Gateway Impersonation Configuration", there is another
> property that needs to be set (and thus documented).
> After this sentence ("To enable REST gateway impersonation, add the following
> to the hbase-site.xml file for every REST gateway."), we should add :
>
>hbase.rest.support.proxyuser
> true
>
> It not set, doing a curl call on the rest gateway gives the error "support
> for proxyuser is not configured".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14947) WALProcedureStore improvements
[ https://issues.apache.org/jira/browse/HBASE-14947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059199#comment-15059199 ] Hudson commented on HBASE-14947: FAILURE: Integrated in HBase-Trunk_matrix #556 (See [https://builds.apache.org/job/HBase-Trunk_matrix/556/]) HBASE-14947 WALProcedureStore improvements (matteo.bertozzi: rev 60d33ce34191533bb858852584bd9bddfeb16a23) * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/store/TestProcedureStoreTracker.java * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/TestProcedureRecovery.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/ProcedureStoreTracker.java * hbase-procedure/src/test/java/org/apache/hadoop/hbase/procedure2/store/wal/TestWALProcedureStore.java * hbase-procedure/src/main/java/org/apache/hadoop/hbase/procedure2/store/wal/WALProcedureStore.java > WALProcedureStore improvements > -- > > Key: HBASE-14947 > URL: https://issues.apache.org/jira/browse/HBASE-14947 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Ashu Pachauri >Assignee: Matteo Bertozzi >Priority: Blocker > Fix For: 2.0.0, 1.2.0, 1.1.3 > > Attachments: HBASE-14947-v0.patch, HBASE-14947-v1.patch > > > We ended up with a deadlock in HBASE-14943, with the storeTracker and lock > acquired in reverse order by syncLoop() and insert/update/delete. In the > syncLoop() with don't need the lock when we try to roll or removeInactive. > also we can move the insert/update/delete tracker check in the syncLoop > avoiding to the extra lock operation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13976) release manager list in ref guide is missing 0.94 line
[ https://issues.apache.org/jira/browse/HBASE-13976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059197#comment-15059197 ] Hudson commented on HBASE-13976: FAILURE: Integrated in HBase-Trunk_matrix #556 (See [https://builds.apache.org/job/HBase-Trunk_matrix/556/]) HBASE-13976 Add 0.94 Release Manager to docs (mstanleyjones: rev b8539c62e8d970ac82cf6ace0e8aa258bab1b97c) * src/main/asciidoc/_chapters/developer.adoc > release manager list in ref guide is missing 0.94 line > -- > > Key: HBASE-13976 > URL: https://issues.apache.org/jira/browse/HBASE-13976 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Sean Busbey >Assignee: Misty Stanley-Jones > Fix For: 2.0.0 > > Attachments: HBASE-13976.patch > > > 0.94 has slowed substantially, but we haven't EOLed it yet so we should make > sure folks looking to get a fix included know where to look. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13070) Fix possibly zero length family and qualifier is TestCacheOnWrite
[ https://issues.apache.org/jira/browse/HBASE-13070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-13070: - Summary: Fix possibly zero length family and qualifier is TestCacheOnWrite (was: Fix TestCacheOnWrite) > Fix possibly zero length family and qualifier is TestCacheOnWrite > - > > Key: HBASE-13070 > URL: https://issues.apache.org/jira/browse/HBASE-13070 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.11 > > Attachments: HBASE-13070-0.98.patch, HBASE-13070.patch, > HBASE-13070_1.patch, HBASE-13070_2.patch > > > TestCacheOnWrite uses TestHFileWriterV2.randomOrderedKey to generate a random > byte array, then use first 32 bytes as row and remaining part as family and > qualifier. But TestHFileWriterV2.randomOrderedKey may return a byte array > only contains 32 bytes, so there will be zero length family and qualifier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14986) Display the key range for each region in the Regionserver UI
[ https://issues.apache.org/jira/browse/HBASE-14986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Govind Kamat updated HBASE-14986: - Attachment: rs.jpg > Display the key range for each region in the Regionserver UI > > > Key: HBASE-14986 > URL: https://issues.apache.org/jira/browse/HBASE-14986 > Project: HBase > Issue Type: New Feature > Components: regionserver, UI >Reporter: Govind Kamat >Assignee: Govind Kamat >Priority: Minor > Attachments: rs.jpg > > > The regionserver UI shows the start and end keys for each region, but it is > hard for users to deduce the byte range between these. > Unbalanced ranges can potentially lead to hot spots. Giving users an easy > way to view the key range for each region and how these ranges compare across > regions may help alleviate this problem. > Key ranges may become non-uniform as a consequence of auto-splitting or due > to users setting them up incorrectly to begin with. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14977) ChoreService.shutdown may result in ConcurrentModificationException
[ https://issues.apache.org/jira/browse/HBASE-14977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059133#comment-15059133 ] Hudson commented on HBASE-14977: SUCCESS: Integrated in HBase-1.1-JDK8 #1708 (See [https://builds.apache.org/job/HBase-1.1-JDK8/1708/]) HBASE-14977 ChoreService.shutdown may result in (enis: rev 2c9361602ca4ed12746d992c1161d2dbc08d8d64) * hbase-common/src/main/java/org/apache/hadoop/hbase/ChoreService.java > ChoreService.shutdown may result in ConcurrentModificationException > --- > > Key: HBASE-14977 > URL: https://issues.apache.org/jira/browse/HBASE-14977 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Minor > Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4 > > Attachments: HBASE-14977-v1.patch > > > As seen in this test: > https://builds.apache.org/job/HBase-1.3/jdk=latest1.8,label=Hadoop/425/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.regionserver.compactions.TestFIFOCompactionPolicy-output.txt > We need to make shutdown method synchronized to avoid this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14849) Add option to set block cache to false on SparkSQL executions
[ https://issues.apache.org/jira/browse/HBASE-14849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhan Zhang updated HBASE-14849: --- Status: Open (was: Patch Available) > Add option to set block cache to false on SparkSQL executions > - > > Key: HBASE-14849 > URL: https://issues.apache.org/jira/browse/HBASE-14849 > Project: HBase > Issue Type: New Feature > Components: spark >Reporter: Ted Malaska >Assignee: Zhan Zhang > Attachments: HBASE-14849.patch > > > I was working at a client with a ported down version of the Spark module for > HBase and realized we didn't add an option to turn of block cache for the > scans. > At the client I just disabled all caching with Spark SQL, this is an easy but > very impactful fix. > The fix for this patch will make this configurable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14977) ChoreService.shutdown may result in ConcurrentModificationException
[ https://issues.apache.org/jira/browse/HBASE-14977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059155#comment-15059155 ] Hudson commented on HBASE-14977: SUCCESS: Integrated in HBase-1.2-IT #342 (See [https://builds.apache.org/job/HBase-1.2-IT/342/]) HBASE-14977 ChoreService.shutdown may result in (enis: rev ef19c2147d9c8cf88d8145bfe9e9bf25ff01206d) * hbase-common/src/main/java/org/apache/hadoop/hbase/ChoreService.java > ChoreService.shutdown may result in ConcurrentModificationException > --- > > Key: HBASE-14977 > URL: https://issues.apache.org/jira/browse/HBASE-14977 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Minor > Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.4 > > Attachments: HBASE-14977-v1.patch > > > As seen in this test: > https://builds.apache.org/job/HBase-1.3/jdk=latest1.8,label=Hadoop/425/artifact/hbase-server/target/surefire-reports/org.apache.hadoop.hbase.regionserver.compactions.TestFIFOCompactionPolicy-output.txt > We need to make shutdown method synchronized to avoid this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14849) Add option to set block cache to false on SparkSQL executions
[ https://issues.apache.org/jira/browse/HBASE-14849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhan Zhang updated HBASE-14849: --- Attachment: HBASE-14849.patch > Add option to set block cache to false on SparkSQL executions > - > > Key: HBASE-14849 > URL: https://issues.apache.org/jira/browse/HBASE-14849 > Project: HBase > Issue Type: New Feature > Components: spark >Reporter: Ted Malaska >Assignee: Zhan Zhang > Attachments: HBASE-14849.patch > > > I was working at a client with a ported down version of the Spark module for > HBase and realized we didn't add an option to turn of block cache for the > scans. > At the client I just disabled all caching with Spark SQL, this is an easy but > very impactful fix. > The fix for this patch will make this configurable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14849) Add option to set block cache to false on SparkSQL executions
[ https://issues.apache.org/jira/browse/HBASE-14849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhan Zhang updated HBASE-14849: --- Status: Patch Available (was: Open) > Add option to set block cache to false on SparkSQL executions > - > > Key: HBASE-14849 > URL: https://issues.apache.org/jira/browse/HBASE-14849 > Project: HBase > Issue Type: New Feature > Components: spark >Reporter: Ted Malaska >Assignee: Zhan Zhang > Attachments: HBASE-14849.patch > > > I was working at a client with a ported down version of the Spark module for > HBase and realized we didn't add an option to turn of block cache for the > scans. > At the client I just disabled all caching with Spark SQL, this is an easy but > very impactful fix. > The fix for this patch will make this configurable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14986) Display the key range for each region in the Regionserver UI
[ https://issues.apache.org/jira/browse/HBASE-14986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059165#comment-15059165 ] Elliott Clark commented on HBASE-14986: --- I'm not sure that's a very usable piece of information for them. Also for users with variable length keys it will be a very misleading number. > Display the key range for each region in the Regionserver UI > > > Key: HBASE-14986 > URL: https://issues.apache.org/jira/browse/HBASE-14986 > Project: HBase > Issue Type: New Feature > Components: regionserver, UI >Reporter: Govind Kamat >Assignee: Govind Kamat >Priority: Minor > Attachments: rs.jpg > > > The regionserver UI shows the start and end keys for each region, but it is > hard for users to deduce the byte range between these. > Unbalanced ranges can potentially lead to hot spots. Giving users an easy > way to view the key range for each region and how these ranges compare across > regions may help alleviate this problem. > Key ranges may become non-uniform as a consequence of auto-splitting or due > to users setting them up incorrectly to begin with. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14944) Minimize or eliminate source incompatible changes due to HBASE-14605, HBASE-14631, and HBASE-14655
[
https://issues.apache.org/jira/browse/HBASE-14944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059174#comment-15059174
]
Nick Dimiduk commented on HBASE-14944:
--
Ping also [~jamestaylor], [~chrajeshbab...@gmail.com], [~eowhadi] -- you fellas
have any concern over these changes in the coproc APIs?
> Minimize or eliminate source incompatible changes due to HBASE-14605,
> HBASE-14631, and HBASE-14655
> --
>
> Key: HBASE-14944
> URL: https://issues.apache.org/jira/browse/HBASE-14944
> Project: HBase
> Issue Type: Sub-task
>Reporter: Andrew Purtell
>Priority: Blocker
> Fix For: 1.1.3, 1.0.4
>
>
> Minimize or eliminate source incompatible changes due to HBASE-14605,
> HBASE-14631, and HBASE-14655. The changes are due to abstract method
> additions to carry the correct (not current) {{User}} through to where
> authoritative decisions or audit is performed.
> HBASE-14605 introduces source incompatible changes to the SplitTransaction
> interface:
> - Adds abstract method execute(Server, RegionServerServices, User)
> - Adds abstract method rollback(Server, RegionServerServices, User)
> HBASE-14631 introduces source incompatible changes to the
> RegionMergeTransaction interface:
> - Adds abstract method execute(Server, RegionServerServices, User)
> - Adds abstract method rollback(Server, RegionServerServices, User)
> HBASE-14655 introduces source incompatible changes to the Store interface:
> - Adds abstract method compact(CompactionContext,
> CompactionThroughputController, User)
> - Adds abstract method requestCompaction( int, CompactionRequest, User)
> Default implementations are provided for binary compatibility but
> implementors of these interface won't recompile until implementations of the
> new methods are added.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14983) Create metrics for per block type hit/miss ratios
[ https://issues.apache.org/jira/browse/HBASE-14983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-14983: -- Attachment: HBASE-14983-v1.patch Yeah it's awful copy paste code, however it is always O(1). I really want a pre-processor. > Create metrics for per block type hit/miss ratios > - > > Key: HBASE-14983 > URL: https://issues.apache.org/jira/browse/HBASE-14983 > Project: HBase > Issue Type: Improvement >Reporter: Elliott Clark >Assignee: Elliott Clark > Attachments: HBASE-14983-v1.patch, HBASE-14983.patch, Screen Shot > 2015-12-15 at 3.33.09 PM.png > > > Missing a root index block is worse than missing a data block. We should know > the difference -- This message was sent by Atlassian JIRA (v6.3.4#6332)
