[jira] [Created] (HBASE-20712) HBase eclipse formatter should not format the ASF license header
Nihal Jain created HBASE-20712:
--
Summary: HBase eclipse formatter should not format the ASF license
header
Key: HBASE-20712
URL: https://issues.apache.org/jira/browse/HBASE-20712
Project: HBase
Issue Type: Bug
Reporter: Nihal Jain
Assignee: Nihal Jain
Whenever we add a new class along with the ASF license header, we cannot press
{{ctrl + A}} to format the whole file as it also formats the header text.
IMO we should disable formatting of headers in our code formatter.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20711) Save on a Cell iteration when writing
stack created HBASE-20711: - Summary: Save on a Cell iteration when writing Key: HBASE-20711 URL: https://issues.apache.org/jira/browse/HBASE-20711 Project: HBase Issue Type: Sub-task Components: Performance Reporter: stack Assignee: stack This is a minor savings. We were doing a spin through all Cells on receipt just to check their size when subsequently, we were doing an iteration of all Cells to insert. It manifest as a little spike in perf output. This change removes the purposed spin through Cells and just does size check as part of the general Cell insert (perf spike no longer shows but the cost of the size check still remains). There is also a minor bug fix where on receipt we were using the Puts row rather than the Cells row; client may have succeeded in submitting a Cell that disagreed with the hosting Mutation and it would have been written as something else altogether -- with the Puts row -- rather than being rejected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20710) extra cloneFamily() in Mutation.add(Cell)
huaxiang sun created HBASE-20710: Summary: extra cloneFamily() in Mutation.add(Cell) Key: HBASE-20710 URL: https://issues.apache.org/jira/browse/HBASE-20710 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 2.0.1 Reporter: huaxiang sun Assignee: huaxiang sun The cpu profiling shows that during PE randomWrite testing, about 1 percent of time is spent in cloneFamily. Reviewing code found that when a cell is DBB backed ByteBuffKeyValueCell (which is default with Netty Rpc), cell.getFamilyArray() will call cloneFamily() and there is again a cloneFamily() in the following line of the code. since this is the critical write path processing, this needs to be optimized. https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Mutation.java#L791 https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Mutation.java#L795 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20709) CompatRemoteProcedureResolver should call remoteCallFailed method instead of throw UnsupportedOperationException
Guanghao Zhang created HBASE-20709:
--
Summary: CompatRemoteProcedureResolver should call
remoteCallFailed method instead of throw UnsupportedOperationException
Key: HBASE-20709
URL: https://issues.apache.org/jira/browse/HBASE-20709
Project: HBase
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Guanghao Zhang
Assignee: Guanghao Zhang
hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/RSProcedureDispatcher.java
{code:java}
@Override
public void dispatchServerOperations(MasterProcedureEnv env,
List operations) {
throw new UnsupportedOperationException();
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20708) Make sure there is no race between the RMP scheduled when start up and the SCP
Duo Zhang created HBASE-20708: - Summary: Make sure there is no race between the RMP scheduled when start up and the SCP Key: HBASE-20708 URL: https://issues.apache.org/jira/browse/HBASE-20708 Project: HBase Issue Type: Sub-task Components: proc-v2, Region Assignment Reporter: Duo Zhang Fix For: 3.0.0, 2.1.0, 2.0.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (HBASE-20689) Docker fails to install rubocop for precommit
[
https://issues.apache.org/jira/browse/HBASE-20689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi reopened HBASE-20689:
---
On branch-1 [~mihir6692] noticed the same problem. Reopening.
> Docker fails to install rubocop for precommit
> -
>
> Key: HBASE-20689
> URL: https://issues.apache.org/jira/browse/HBASE-20689
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Blocker
> Fix For: 3.0.0, 2.1.0, 2.0.1
>
> Attachments: HBASE-20689.master.001.patch
>
>
> Precommit started to fail with rubocop install in 'Building base image' phase.
> The used maven:3.5-jdk8 image was updated ~10h ago, probably related.
> [https://hub.docker.com/r/library/maven/]
> One of the failed jobs:
> [https://builds.apache.org/job/PreCommit-HBASE-Build/13105/console]
> {noformat}
> 14:42:23 Setting up ruby (1:2.3.3) ...
> 14:42:23 Processing triggers for libc-bin (2.24-11+deb9u3) ...
> 14:42:23 Successfully installed rake-12.3.1
> 14:42:23 Parsing documentation for rake-12.3.1
> 14:42:23 Installing ri documentation for rake-12.3.1
> 14:42:23 Done installing documentation for rake after 1 seconds
> 14:42:23 Building native extensions. This could take a while...
> 14:42:23 [91mERROR: Error installing rubocop:
> 14:42:23 ERROR: Failed to build gem native extension.
> 14:42:23
> 14:42:23 current directory:
> /var/lib/gems/2.3.0/gems/jaro_winkler-1.4.0/ext/jaro_winkler
> 14:42:23 /usr/bin/ruby2.3 -r ./siteconf20180606-949-99wdpz.rb extconf.rb
> 14:42:23 mkmf.rb can't find header files for ruby at
> /usr/lib/ruby/include/ruby.h
> 14:42:23
> 14:42:23 extconf failed, exit code 1
> 14:42:23
> 14:42:23 Gem files will remain installed in
> /var/lib/gems/2.3.0/gems/jaro_winkler-1.4.0 for inspection.
> 14:42:23 Results logged to
> /var/lib/gems/2.3.0/extensions/x86_64-linux/2.3.0/jaro_winkler-1.4.0/gem_make.out
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (HBASE-20698) Master don't record right server version until new started region server call regionServerReport method
[
https://issues.apache.org/jira/browse/HBASE-20698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang reopened HBASE-20698:
Reopen this as I found another problem... When a region server expired, it will
be removed from onlineServers. Now getServerVersion may return 0 when the
server is not in onlineServers. RSProcedureDispatcher is a ServerListener and
there are race between ServerManager and RSProcedureDispatcher. For a
RefreshPeerProcedure which target server expired, addOperationToNode may
succeed but may get version 0 when remoteDispatch. Then this
RefreshPeerProcedure will fail to dispatch...
> Master don't record right server version until new started region server call
> regionServerReport method
> ---
>
> Key: HBASE-20698
> URL: https://issues.apache.org/jira/browse/HBASE-20698
> Project: HBase
> Issue Type: Bug
> Components: proc-v2
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: HBASE-20698.master.001.patch,
> HBASE-20698.master.002.patch, HBASE-20698.master.003.patch
>
>
> When a new region server started, it will call regionServerStartup first.
> Master will record this server as a new online server and may dispath
> RemoteProcedure to the new server. But master only record the server version
> when the new region server call regionServerReport method. Dispatch a new
> RemoteProcedure to this new regionserver will fail if version is not right.
> {code:java}
> @Override
> protected void remoteDispatch(final ServerName serverName,
> final Set remoteProcedures) {
> final int rsVersion =
> master.getAssignmentManager().getServerVersion(serverName);
> if (rsVersion >= RS_VERSION_WITH_EXEC_PROCS) {
> LOG.trace("Using procedure batch rpc execution for serverName={}
> version={}",
> serverName, rsVersion);
> submitTask(new ExecuteProceduresRemoteCall(serverName,
> remoteProcedures));
> } else {
> LOG.info(String.format(
> "Fallback to compat rpc execution for serverName=%s version=%s",
> serverName, rsVersion));
> submitTask(new CompatRemoteProcedureResolver(serverName,
> remoteProcedures));
> }
> }
> {code}
> The above code use version to resolve compatibility problem. So dispatch will
> work right for old version region server. But for RefreshPeerProcedure, it is
> new since hbase 2.0. So RefreshPeerProcedure don't need this. But the new
> region server version is not right, it will use CompatRemoteProcedureResolver
> for RefreshPeerProcedure, too. So the RefreshPeerProcedure can't be executed
> rightly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
