[jira] [Commented] (HBASE-13590) TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey
[ https://issues.apache.org/jira/browse/HBASE-13590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14654943#comment-14654943 ] Andrey Stepachev commented on HBASE-13590: -- [~ndimiduk] no, sorry, don't working on that for now. > TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey > --- > > Key: HBASE-13590 > URL: https://issues.apache.org/jira/browse/HBASE-13590 > Project: HBase > Issue Type: Test > Components: master >Reporter: Nick Dimiduk > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.3 > > > Looking at our [build > history|https://builds.apache.org/job/HBase-1.1/buildTimeTrend], it seems > this test is flakey. See builds 429, 431, 439. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13590) TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey
[ https://issues.apache.org/jira/browse/HBASE-13590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13590: - Assignee: (was: Andrey Stepachev) > TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey > --- > > Key: HBASE-13590 > URL: https://issues.apache.org/jira/browse/HBASE-13590 > Project: HBase > Issue Type: Test > Components: master >Reporter: Nick Dimiduk > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.3 > > > Looking at our [build > history|https://builds.apache.org/job/HBase-1.1/buildTimeTrend], it seems > this test is flakey. See builds 429, 431, 439. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12016) Reduce number of versions in Meta table. Make it configurable
[ https://issues.apache.org/jira/browse/HBASE-12016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-12016: - Release Note: Clients fetch META table descriptor using RPC. That gives an opportunity to change META table parameters on running cluster. Prior this change all clients used statically compiled META table descriptor and to apply new parameters new code need to be deployed. META table versions can be configured by 'hbase.meta.versions' and now has 3 versions by default (was 10). Block size for META table can be configured by 'hbase.meta.blocksize' (default 8k) was: Clients fetch META table descriptor using RPC. That gives an opportunity to change META table parameters on running cluster. Prior this change all clients used statically compiled META table descriptor and to apply new parameters new code need to be deployed. META table now has 3 versions by default instead of 10. > Reduce number of versions in Meta table. Make it configurable > - > > Key: HBASE-12016 > URL: https://issues.apache.org/jira/browse/HBASE-12016 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Fix For: 1.0.0, 2.0.0 > > Attachments: HBASE-12016.patch, HBASE-12016.patch, HBASE-12016.patch, > HBASE-12016.patch, HBASE-12016.patch, HBASE-12016.patch, HBASE-12016.patch > > > Currently meta keeps up to 10 versions of each KV. > For big metas it leads to substantial memory overhead and scan slowdowns. > (see https://issues.apache.org/jira/browse/HBASE-11165 ) > Need to keep reasonable number of versions (suggested value is 3). > Number of versions configurable via parameter: hbase.meta.versions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12016) Reduce number of versions in Meta table. Make it configurable
[ https://issues.apache.org/jira/browse/HBASE-12016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14622260#comment-14622260 ] Andrey Stepachev commented on HBASE-12016: -- [~anoop.hbase] Thank for pointing that. Updated. > Reduce number of versions in Meta table. Make it configurable > - > > Key: HBASE-12016 > URL: https://issues.apache.org/jira/browse/HBASE-12016 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Fix For: 1.0.0, 2.0.0 > > Attachments: HBASE-12016.patch, HBASE-12016.patch, HBASE-12016.patch, > HBASE-12016.patch, HBASE-12016.patch, HBASE-12016.patch, HBASE-12016.patch > > > Currently meta keeps up to 10 versions of each KV. > For big metas it leads to substantial memory overhead and scan slowdowns. > (see https://issues.apache.org/jira/browse/HBASE-11165 ) > Need to keep reasonable number of versions (suggested value is 3). > Number of versions configurable via parameter: hbase.meta.versions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-12016) Reduce number of versions in Meta table. Make it configurable
[ https://issues.apache.org/jira/browse/HBASE-12016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-12016: - Release Note: Clients fetch META table descriptor using RPC. That gives an opportunity to change META table parameters on running cluster. Prior this change all clients used statically compiled META table descriptor and to apply new parameters new code need to be deployed. META table now has 3 versions by default instead of 10. > Reduce number of versions in Meta table. Make it configurable > - > > Key: HBASE-12016 > URL: https://issues.apache.org/jira/browse/HBASE-12016 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Fix For: 1.0.0, 2.0.0 > > Attachments: HBASE-12016.patch, HBASE-12016.patch, HBASE-12016.patch, > HBASE-12016.patch, HBASE-12016.patch, HBASE-12016.patch, HBASE-12016.patch > > > Currently meta keeps up to 10 versions of each KV. > For big metas it leads to substantial memory overhead and scan slowdowns. > (see https://issues.apache.org/jira/browse/HBASE-11165 ) > Need to keep reasonable number of versions (suggested value is 3). > Number of versions configurable via parameter: hbase.meta.versions -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13017) Backport HBASE-12035 Keep table state in Meta to branch-1
[ https://issues.apache.org/jira/browse/HBASE-13017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14596215#comment-14596215 ] Andrey Stepachev commented on HBASE-13017: -- [~busbey] Not sure is it possible to make that in branch-1. I was stuck with HBASE-13147 which is needed to distinguish old metas from new metas. If we'll find a way to make that backward compatible (as in HBASE-13147) for branch-1, so we can apply this patch once more. > Backport HBASE-12035 Keep table state in Meta to branch-1 > - > > Key: HBASE-13017 > URL: https://issues.apache.org/jira/browse/HBASE-13017 > Project: HBase > Issue Type: Improvement > Components: master >Affects Versions: 1.1.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Labels: backport > Fix For: 1.3.0 > > Attachments: HBASE-13017-branch-1.patch, > HBASE-13017-branch-1.v1.patch, HBASE-13017-branch-1.v1.patch, > HBASE-13017-branch-1.v2.patch, HBASE-13017-branch-1.v3.patch, > HBASE-13017-branch-1.v4.patch, HBASE-13017-branch-1.v5.patch, > HBASE-13017-branch-1.v6.patch > > > Lets backport that feature to branch-1.0 adapting HBASE-12035 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev resolved HBASE-13647. -- Resolution: Fixed done, thank you for reviewing. > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 0.98.13, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Blocker > Fix For: 2.0.0, 1.0.2, 1.2.0, 1.1.1, 0.98.13 > > Attachments: HBASE-13647.patch, HBASE-13647.v2.patch, > HBASE-13647.v3.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14567121#comment-14567121 ] Andrey Stepachev commented on HBASE-13647: -- bq. I would recommend 20 minutes. The idea is that if a machine fails and the recovery needs a hdfs timeout (10:30 mins) we have some extra time. As well, iirc with the default retries number and pause we around 15 minutes today. It seems better to default above that. Thanks [~nkeywal] for pointing that, sounds reasonable for most usecases. I'm going to apply v3. patch with 20 minutes to versions mentioned in fix versions. [~enis], [~apurtell] does it sound good? > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 0.98.13, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Blocker > Fix For: 2.0.0, 0.98.13, 1.0.2, 1.2.0, 1.1.1 > > Attachments: HBASE-13647.patch, HBASE-13647.v2.patch, > HBASE-13647.v3.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13647: - Attachment: HBASE-13647.v3.patch > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 0.98.13, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Blocker > Fix For: 2.0.0, 0.98.13, 1.0.2, 1.2.0, 1.1.1 > > Attachments: HBASE-13647.patch, HBASE-13647.v2.patch, > HBASE-13647.v3.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13647: - Attachment: HBASE-13647.v2.patch yeah, quite surprising, how it happens. reattached correct one > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 0.98.13, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Critical > Fix For: 2.0.0, 0.98.13, 1.0.2, 1.2.0, 1.1.1 > > Attachments: HBASE-13647.patch, HBASE-13647.v2.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13647: - Attachment: (was: HBASE-5238.v2.patch) > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 0.98.13, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Critical > Fix For: 2.0.0, 0.98.13, 1.0.2, 1.2.0, 1.1.1 > > Attachments: HBASE-13647.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13647: - Attachment: HBASE-5238.v2.patch patch with 10minutes as timeout > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 0.98.13, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Critical > Fix For: 2.0.0, 0.98.13, 1.0.2, 1.2.0, 1.1.1 > > Attachments: HBASE-13647.patch, HBASE-5238.v2.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14565885#comment-14565885 ] Andrey Stepachev edited comment on HBASE-13647 at 5/30/15 8:07 AM: --- [~enis] sure, lets fix that. I'm going to set that to 10 minutes. Did lookup for all places where this timeout used (for 2.0) and it seems not all places are good for 10 minutes timeouts (especially in conjunction with number of retries). || class || used for || should be || | AsyncRpcClient | as netty connection timeout | relates to sockets, so SOCKET_TIMEOUT_CONNECT is more appropriate | | HBaseAdmin | used for all calls like createTable | ideally it should be separate and much larger then 3-5 minutes | | HRegionServer | used for replica flush call | Integer.MAX not bad for this usecase | | RegionCoprocessorRpcChannel | used to call coprocessors | separate config option is better, but regular HBASE_RPC_TIMEOUT_KEY can suite well too | | RegionReplicaReplicationEndpoint | used to replicate WAL entries | separate config option is better to allow user to configure how long replication will retry to push WAL edits | | HTable (via TableConfiguration) | methods which not use AsyncProcess, as [~enis] mentioned before | HBASE_RPC_TIMEOUT_KEY is more appropriate as timeout | Taking into account this brief scan of usages it seems that we can set not very aggressive timeout to 5 or 10 minutes, but need to clean up this in separate jiras. was (Author: octo47): [~enis] sure, lets fix that. did lookup for all places where this timeout used (for 2.0). || class || used for || should be || | AsyncRpcClient | as netty connection timeout | relates to sockets, so SOCKET_TIMEOUT_CONNECT is more appropriate | | HBaseAdmin | used for all calls like createTable | ideally it should be separate and much larger then 3-5 minutes | | HRegionServer | used for replica flush call | Integer.MAX not bad for this usecase | | RegionCoprocessorRpcChannel | used to call coprocessors | separate config option is better, but regular HBASE_RPC_TIMEOUT_KEY can suite well too | | RegionReplicaReplicationEndpoint | used to replicate WAL entries | separate config option is better to allow user to configure how long replication will retry to push WAL edits | | HTable (via TableConfiguration) | methods which not use AsyncProcess, as [~enis] mentioned before | HBASE_RPC_TIMEOUT_KEY is more appropriate as timeout | Taking into account this brief scan of usages it seems that we can set not very aggressive timeout to 5 or 10 minutes, but need to clean up this in separate jiras. > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 0.98.13, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Critical > Fix For: 2.0.0, 0.98.13, 1.0.2, 1.2.0, 1.1.1 > > Attachments: HBASE-13647.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14565885#comment-14565885 ] Andrey Stepachev commented on HBASE-13647: -- [~enis] sure, lets fix that. did lookup for all places where this timeout used (for 2.0). || class || used for || should be || | AsyncRpcClient | as netty connection timeout | relates to sockets, so SOCKET_TIMEOUT_CONNECT is more appropriate | | HBaseAdmin | used for all calls like createTable | ideally it should be separate and much larger then 3-5 minutes | | HRegionServer | used for replica flush call | Integer.MAX not bad for this usecase | | RegionCoprocessorRpcChannel | used to call coprocessors | separate config option is better, but regular HBASE_RPC_TIMEOUT_KEY can suite well too | | RegionReplicaReplicationEndpoint | used to replicate WAL entries | separate config option is better to allow user to configure how long replication will retry to push WAL edits | | HTable (via TableConfiguration) | methods which not use AsyncProcess, as [~enis] mentioned before | HBASE_RPC_TIMEOUT_KEY is more appropriate as timeout | Taking into account this brief scan of usages it seems that we can set not very aggressive timeout to 5 or 10 minutes, but need to clean up this in separate jiras. > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 0.98.13, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Critical > Fix For: 2.0.0, 0.98.13, 1.0.2, 1.2.0, 1.1.1 > > Attachments: HBASE-13647.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[
https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14565312#comment-14565312
]
Andrey Stepachev commented on HBASE-13647:
--
[~enis]
{quote} bq. But we have the same situation with rpc timeout. Should we make an
issue to do something with other timeouts and review them.
RPC timeout is for a single RPC. operation timeout is for the operation with
retrying RPCs. We should not default op timeout to be the operation timeout
since it might mean only a single try, and no retries.
{quote}
Sure. It is overused constant. It seems that it is better to introduce
independent value for region rpc timeout and client operation.
{quote} bq. Say, we can add warnings, or fix them (with some common method like
pullUpToZkTimeout)?
Warnings won't cut it. It should be ok to auto set the op timeout by looking at
the zk timeout. If we want (by default) a table operation to ride over RS
crashes is taking into account MTTR: detection + recovery + assignment. Worst
case detection is zk session timeout. For recovery and assignment there is no
easy way to infer that. So the default op timeout should be > zk session
timeout IMO.
{quote}
Currently this constant is used for admin operations and endpoint operations.
Would it be better to have separate timeouts? Am I wrong to think that endpoint
invocation should be treated as simple rpc (hense having small rpc comparable
timeouts) and operations like HBaseAdmin operations, which sure can be infinite
by default.
> Default value for hbase.client.operation.timeout is too high
>
>
> Key: HBASE-13647
> URL: https://issues.apache.org/jira/browse/HBASE-13647
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0, 1.0.1, 0.98.13, 1.2.0, 1.1.1
>Reporter: Andrey Stepachev
>Assignee: Andrey Stepachev
>Priority: Critical
> Fix For: 2.0.0, 0.98.13, 1.0.2, 1.2.0, 1.1.1
>
> Attachments: HBASE-13647.patch
>
>
> Default value for hbase.client.operation.timeout is too high, it is LONG.Max.
> That value will block any service calls to coprocessor endpoints indefinitely.
> Should we introduce better default value for that?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14565274#comment-14565274 ] Andrey Stepachev commented on HBASE-13647: -- [~enis] But we have the same situation with rpc timeout. Should we make an issue to do something with other timeouts and review them. Say, we can add warnings, or fix them (with some common method like pullUpToZkTimeout)? I thought that if someone change zk timeouts he should be very sure what is he doing. We have plenty of places where timeouts could become inappropriate for increased zk timeouts. > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 0.98.13, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-13647.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13646: - Attachment: HBASE-13646-branch-1.patch attaching patch for branch-1 > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Fix For: 2.0.0 > > Attachments: HBASE-13646-branch-1.patch, HBASE-13646.patch, > HBASE-13646.v2.patch, HBASE-13646.v2.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13646: - Status: Patch Available (was: Open) > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Fix For: 2.0.0 > > Attachments: HBASE-13646-branch-1.patch, HBASE-13646.patch, > HBASE-13646.v2.patch, HBASE-13646.v2.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13646: - Status: Open (was: Patch Available) > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Fix For: 2.0.0 > > Attachments: HBASE-13646.patch, HBASE-13646.v2.patch, > HBASE-13646.v2.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14543591#comment-14543591 ] Andrey Stepachev commented on HBASE-13646: -- [~ndimiduk] can you take a look on this? it seems we can include that in branch-1. > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Fix For: 2.0.0 > > Attachments: HBASE-13646.patch, HBASE-13646.v2.patch, > HBASE-13646.v2.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13646: - Fix Version/s: 2.0.0 > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Fix For: 2.0.0 > > Attachments: HBASE-13646.patch, HBASE-13646.v2.patch, > HBASE-13646.v2.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13647: - Resolution: Pending Closed Status: Resolved (was: Patch Available) > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-13647.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14543549#comment-14543549 ] Andrey Stepachev commented on HBASE-13647: -- [~ndimiduk], would you mind if I apply this 1.x branches? > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-13647.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13647: - Fix Version/s: 2.0.0 > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-13647.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14543547#comment-14543547 ] Andrey Stepachev commented on HBASE-13647: -- commited, thank you [~stack] for reviewing. > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-13647.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13646: - Attachment: HBASE-13646.v2.patch retry > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13646.patch, HBASE-13646.v2.patch, > HBASE-13646.v2.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13646: - Status: Patch Available (was: Open) > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13646.patch, HBASE-13646.v2.patch, > HBASE-13646.v2.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13646: - Status: Open (was: Patch Available) > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13646.patch, HBASE-13646.v2.patch, > HBASE-13646.v2.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13647: - Assignee: Andrey Stepachev Status: Patch Available (was: Open) > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 1.0.1, 2.0.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Critical > Attachments: HBASE-13647.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13647: - Attachment: HBASE-13647.patch here is simple change, just default value to 6 > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 1.1.1 >Reporter: Andrey Stepachev >Priority: Critical > Attachments: HBASE-13647.patch > > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14541851#comment-14541851 ] Andrey Stepachev commented on HBASE-13646: -- [~stack] we are exposing NameNodeProtocol as rpc endpoint in https://github.com/GiraffaFS/giraffa and stumbled on complex protobuf messages which need to be faked to be buildable even if rpc call was unsuccessfull. (for example if there some deep hierarchy of protobuf message with 'required' fields). So that patch will allow to just throw IOException or DontRetryIOException and rpc handler will not fail with message that it can't build incomplete protobuf message. > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13646.patch, HBASE-13646.v2.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13646: - Status: Patch Available (was: Open) > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13646.patch, HBASE-13646.v2.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14541844#comment-14541844 ] Andrey Stepachev commented on HBASE-13647: -- [~stack] having something hang forever generally bad idea. I'd propose to use default value of hbase.rpc.timeout. Looks better to go from different position, let's RPC will rerty and die shortly, and if someone need that, will change that value. > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 1.1.1 >Reporter: Andrey Stepachev >Priority: Critical > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13646: - Attachment: HBASE-13646.v2.patch style fixes. > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13646.patch, HBASE-13646.v2.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13646: - Status: Open (was: Patch Available) > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13646.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13648) test-patch.sh should ignore 'protobuf.generated'
[ https://issues.apache.org/jira/browse/HBASE-13648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13648: - Resolution: Fixed Status: Resolved (was: Patch Available) > test-patch.sh should ignore 'protobuf.generated' > > > Key: HBASE-13648 > URL: https://issues.apache.org/jira/browse/HBASE-13648 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 2.0.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13648.patch > > > test-patch.sh has hardcoded what packages it ignores while checking line > lenght. It could be more convient to ignore any packages > 'protobuf.generated', not only 'hbase.protobuf.generated'. For example > coprocessor tests use ''protobuf.generated' suffix for packages of example > classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13648) test-patch.sh should ignore 'protobuf.generated'
[ https://issues.apache.org/jira/browse/HBASE-13648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14534955#comment-14534955 ] Andrey Stepachev commented on HBASE-13648: -- Thank you Ted for reviewing. > test-patch.sh should ignore 'protobuf.generated' > > > Key: HBASE-13648 > URL: https://issues.apache.org/jira/browse/HBASE-13648 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 2.0.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13648.patch > > > test-patch.sh has hardcoded what packages it ignores while checking line > lenght. It could be more convient to ignore any packages > 'protobuf.generated', not only 'hbase.protobuf.generated'. For example > coprocessor tests use ''protobuf.generated' suffix for packages of example > classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13648) test-patch.sh should ignore 'protobuf.generated'
[ https://issues.apache.org/jira/browse/HBASE-13648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13648: - Description: test-patch.sh has hardcoded what packages it ignores while checking line lenght. It could be more convient to ignore any packages 'protobuf.generated', not only 'hbase.protobuf.generated'. For example coprocessor tests use ''protobuf.generated' suffix for packages of example classes. (was: test-patch.sh has hardcoded what packages it ignore while checking line lenght. It could be more convient to ignore any packages 'protobuf.generated', not only 'hbase.protobuf.generated'. For example coprocessor tests use ''protobuf.generated' suffix for packages of example classes.) > test-patch.sh should ignore 'protobuf.generated' > > > Key: HBASE-13648 > URL: https://issues.apache.org/jira/browse/HBASE-13648 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 2.0.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13648.patch > > > test-patch.sh has hardcoded what packages it ignores while checking line > lenght. It could be more convient to ignore any packages > 'protobuf.generated', not only 'hbase.protobuf.generated'. For example > coprocessor tests use ''protobuf.generated' suffix for packages of example > classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13646: - Status: Patch Available (was: Open) > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13646.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14534402#comment-14534402 ] Andrey Stepachev edited comment on HBASE-13646 at 5/8/15 12:07 PM: --- Patch: 1. Checking that we have exception and throw it. 2. Fixing wrong controller used to call (that is why checks didn't work actually) (and have long lines because of HBASE-13648) was (Author: octo47): have long lines because of HBASE-13648 > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13646.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14534402#comment-14534402 ] Andrey Stepachev edited comment on HBASE-13646 at 5/8/15 12:07 PM: --- Patch: 1. Checking that we have exception and throw it before trying to build() message using Builder. 2. Fixing wrong controller used to call (that is why checks didn't work actually) (and have long lines because of HBASE-13648) was (Author: octo47): Patch: 1. Checking that we have exception and throw it. 2. Fixing wrong controller used to call (that is why checks didn't work actually) (and have long lines because of HBASE-13648) > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13646.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13646: - Attachment: HBASE-13646.patch have long lines because of HBASE-13648 > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13646.patch > > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13648) test-patch.sh should ignore 'protobuf.generated'
[ https://issues.apache.org/jira/browse/HBASE-13648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13648: - Affects Version/s: 1.1.1 2.0.0 > test-patch.sh should ignore 'protobuf.generated' > > > Key: HBASE-13648 > URL: https://issues.apache.org/jira/browse/HBASE-13648 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 2.0.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13648.patch > > > test-patch.sh has hardcoded what packages it ignore while checking line > lenght. It could be more convient to ignore any packages > 'protobuf.generated', not only 'hbase.protobuf.generated'. For example > coprocessor tests use ''protobuf.generated' suffix for packages of example > classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13648) test-patch.sh should ignore 'protobuf.generated'
[ https://issues.apache.org/jira/browse/HBASE-13648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13648: - Status: Patch Available (was: Open) > test-patch.sh should ignore 'protobuf.generated' > > > Key: HBASE-13648 > URL: https://issues.apache.org/jira/browse/HBASE-13648 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 2.0.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13648.patch > > > test-patch.sh has hardcoded what packages it ignore while checking line > lenght. It could be more convient to ignore any packages > 'protobuf.generated', not only 'hbase.protobuf.generated'. For example > coprocessor tests use ''protobuf.generated' suffix for packages of example > classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13648) test-patch.sh should ignore 'protobuf.generated'
[ https://issues.apache.org/jira/browse/HBASE-13648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13648: - Attachment: HBASE-13648.patch > test-patch.sh should ignore 'protobuf.generated' > > > Key: HBASE-13648 > URL: https://issues.apache.org/jira/browse/HBASE-13648 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 2.0.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13648.patch > > > test-patch.sh has hardcoded what packages it ignore while checking line > lenght. It could be more convient to ignore any packages > 'protobuf.generated', not only 'hbase.protobuf.generated'. For example > coprocessor tests use ''protobuf.generated' suffix for packages of example > classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13648) test-patch.sh should ignore 'protobuf.generated'
Andrey Stepachev created HBASE-13648: Summary: test-patch.sh should ignore 'protobuf.generated' Key: HBASE-13648 URL: https://issues.apache.org/jira/browse/HBASE-13648 Project: HBase Issue Type: Bug Components: build Reporter: Andrey Stepachev Assignee: Andrey Stepachev Priority: Minor test-patch.sh has hardcoded what packages it ignore while checking line lenght. It could be more convient to ignore any packages 'protobuf.generated', not only 'hbase.protobuf.generated'. For example coprocessor tests use ''protobuf.generated' suffix for packages of example classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
[ https://issues.apache.org/jira/browse/HBASE-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13647: - Priority: Critical (was: Major) > Default value for hbase.client.operation.timeout is too high > > > Key: HBASE-13647 > URL: https://issues.apache.org/jira/browse/HBASE-13647 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.0.1, 1.1.1 >Reporter: Andrey Stepachev >Priority: Critical > > Default value for hbase.client.operation.timeout is too high, it is LONG.Max. > That value will block any service calls to coprocessor endpoints indefinitely. > Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13647) Default value for hbase.client.operation.timeout is too high
Andrey Stepachev created HBASE-13647: Summary: Default value for hbase.client.operation.timeout is too high Key: HBASE-13647 URL: https://issues.apache.org/jira/browse/HBASE-13647 Project: HBase Issue Type: Bug Affects Versions: 1.0.1, 2.0.0, 1.1.1 Reporter: Andrey Stepachev Default value for hbase.client.operation.timeout is too high, it is LONG.Max. That value will block any service calls to coprocessor endpoints indefinitely. Should we introduce better default value for that? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13646) HRegion#execService should not try to build incomplete messages
[ https://issues.apache.org/jira/browse/HBASE-13646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13646: - Description: If some RPC service, called on region throws exception, execService still tries to build Message. In case of complex messages with required fields it complicates service code because service need to pass fake protobuf objects, so they can be barely buildable. To mitigate that I propose to check that controller was failed and return null from call instead of failing with exception. was: If some RPC service, called on region throws exception, execService still tries to build Message. In case of complex messages with required fields it complicates service code because service need to pass fake protobuf objects, so they can be barely buildable. To mitigate that I propose to check that controller was failed and return null from call instead of failing with exception. Sure, we can go other direction and throw exception right from execService. Let me know if you think that it is better that what I did in provided patch. > HRegion#execService should not try to build incomplete messages > --- > > Key: HBASE-13646 > URL: https://issues.apache.org/jira/browse/HBASE-13646 > Project: HBase > Issue Type: Bug > Components: Coprocessors, regionserver >Affects Versions: 2.0.0, 1.2.0, 1.1.1 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > > If some RPC service, called on region throws exception, execService still > tries to build Message. In case of complex messages with required fields it > complicates service code because service need to pass fake protobuf objects, > so they can be barely buildable. > To mitigate that I propose to check that controller was failed and return > null from call instead of failing with exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13646) HRegion#execService should not try to build incomplete messages
Andrey Stepachev created HBASE-13646: Summary: HRegion#execService should not try to build incomplete messages Key: HBASE-13646 URL: https://issues.apache.org/jira/browse/HBASE-13646 Project: HBase Issue Type: Bug Components: Coprocessors, regionserver Affects Versions: 2.0.0, 1.2.0, 1.1.1 Reporter: Andrey Stepachev Assignee: Andrey Stepachev If some RPC service, called on region throws exception, execService still tries to build Message. In case of complex messages with required fields it complicates service code because service need to pass fake protobuf objects, so they can be barely buildable. To mitigate that I propose to check that controller was failed and return null from call instead of failing with exception. Sure, we can go other direction and throw exception right from execService. Let me know if you think that it is better that what I did in provided patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13590) TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey
[
https://issues.apache.org/jira/browse/HBASE-13590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528790#comment-14528790
]
Andrey Stepachev commented on HBASE-13590:
--
yeah, finally got a different exception:
{noformat}
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 40.651 sec <<<
FAILURE! - in org.apache.hadoop.hbase.master.handler.TestEnableTableHandler
testEnableTableWithNoRegionServers(org.apache.hadoop.hbase.master.handler.TestEnableTableHandler)
Time elapsed: 13.329 sec <<< FAILURE!
java.lang.AssertionError: expected:<2> but was:<1>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.hadoop.hbase.master.handler.TestEnableTableHandler.testEnableTableWithNoRegionServers(TestEnableTableHandler.java:110)
{noformat}
Quite interesting...
> TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey
> ---
>
> Key: HBASE-13590
> URL: https://issues.apache.org/jira/browse/HBASE-13590
> Project: HBase
> Issue Type: Test
> Components: master
>Reporter: Nick Dimiduk
>Assignee: Andrey Stepachev
>Priority: Critical
> Fix For: 2.0.0, 1.2.0, 1.1.1
>
>
> Looking at our [build
> history|https://builds.apache.org/job/HBase-1.1/buildTimeTrend], it seems
> this test is flakey. See builds 429, 431, 439.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (HBASE-13590) TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey
[ https://issues.apache.org/jira/browse/HBASE-13590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13590: - Comment: was deleted (was: [~ndimiduk] was not able to reproduce on branch-1) > TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey > --- > > Key: HBASE-13590 > URL: https://issues.apache.org/jira/browse/HBASE-13590 > Project: HBase > Issue Type: Test > Components: master >Reporter: Nick Dimiduk >Assignee: Andrey Stepachev >Priority: Critical > Fix For: 2.0.0, 1.2.0, 1.1.1 > > > Looking at our [build > history|https://builds.apache.org/job/HBase-1.1/buildTimeTrend], it seems > this test is flakey. See builds 429, 431, 439. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13590) TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey
[ https://issues.apache.org/jira/browse/HBASE-13590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14528319#comment-14528319 ] Andrey Stepachev commented on HBASE-13590: -- [~ndimiduk] was not able to reproduce on branch-1 > TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey > --- > > Key: HBASE-13590 > URL: https://issues.apache.org/jira/browse/HBASE-13590 > Project: HBase > Issue Type: Test > Components: master >Reporter: Nick Dimiduk >Assignee: Andrey Stepachev >Priority: Critical > Fix For: 2.0.0, 1.2.0, 1.1.1 > > > Looking at our [build > history|https://builds.apache.org/job/HBase-1.1/buildTimeTrend], it seems > this test is flakey. See builds 429, 431, 439. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (HBASE-13590) TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey
[ https://issues.apache.org/jira/browse/HBASE-13590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev reassigned HBASE-13590: Assignee: Andrey Stepachev > TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey > --- > > Key: HBASE-13590 > URL: https://issues.apache.org/jira/browse/HBASE-13590 > Project: HBase > Issue Type: Test > Components: master >Reporter: Nick Dimiduk >Assignee: Andrey Stepachev >Priority: Critical > Fix For: 2.0.0, 1.1.0, 1.2.0 > > > Looking at our [build > history|https://builds.apache.org/job/HBase-1.1/buildTimeTrend], it seems > this test is flakey. See builds 429, 431, 439. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13147) Load actual META table descriptor, don't use statically defined one.
[
https://issues.apache.org/jira/browse/HBASE-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14519000#comment-14519000
]
Andrey Stepachev edited comment on HBASE-13147 at 4/29/15 9:09 AM:
---
Thank you [~ram_krish] for looking at this thing.
{quote}
remove(META_VERSION_KEY);
{quote}
Yeah. That is to remove version from non-meta descriptors. But for now I'm
thinking to make
field tableVersion visible to users. So user can use this version for its own
versioning if needed.
And we can use versions for other tables if needed.
{quote}
Just on master coming up we will do the migration
{quote}
yes, when master is starting and didn't found descriptor
it will upgrade meta. Next meta should be reassigned
to recent region server, and that is next jira i think, because
there are serveral ways to do so.
was (Author: octo47):
Thank you [~ram_krish] for looking at this thing.
{quote}
remove(META_VERSION_KEY);
{quote}
Yeah. That is to remove version from meta. But for now I'm thinking to make
field tableVersion visible to users. So user can use this version for its own
versioning if needed.
And we can use versions for other tables if needed.
{quote}
Just on master coming up we will do the migration
{quote}
yes, when master is starting and didn't found descriptor
it will upgrade meta. Next meta should be reassigned
to recent region server, and that is next jira i think, because
there are serveral ways to do so.
> Load actual META table descriptor, don't use statically defined one.
>
>
> Key: HBASE-13147
> URL: https://issues.apache.org/jira/browse/HBASE-13147
> Project: HBase
> Issue Type: Bug
> Components: master, regionserver
>Affects Versions: 2.0.0
>Reporter: Andrey Stepachev
>Assignee: Andrey Stepachev
> Attachments: HBASE-13147-branch-1.patch,
> HBASE-13147-branch-1.v2.patch, HBASE-13147.patch, HBASE-13147.v2.patch,
> HBASE-13147.v3.patch, HBASE-13147.v4.patch, HBASE-13147.v4.patch,
> HBASE-13147.v5.patch, HBASE-13147.v6.patch, HBASE-13147.v7.patch
>
>
> In HBASE-13087 stumbled on the fact, that region servers don't see actual
> meta descriptor, they use their own, statically compiled.
> Need to fix that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13147) Load actual META table descriptor, don't use statically defined one.
[
https://issues.apache.org/jira/browse/HBASE-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14519000#comment-14519000
]
Andrey Stepachev commented on HBASE-13147:
--
Thank you [~ram_krish] for looking at this thing.
{quote}
remove(META_VERSION_KEY);
{quote}
Yeah. That is to remove version from meta. But for now I'm thinking to make
field tableVersion visible to users. So user can use this version for its own
versioning if needed.
And we can use versions for other tables if needed.
{quote}
Just on master coming up we will do the migration
{quote}
yes, when master is starting and didn't found descriptor
it will upgrade meta. Next meta should be reassigned
to recent region server, and that is next jira i think, because
there are serveral ways to do so.
> Load actual META table descriptor, don't use statically defined one.
>
>
> Key: HBASE-13147
> URL: https://issues.apache.org/jira/browse/HBASE-13147
> Project: HBase
> Issue Type: Bug
> Components: master, regionserver
>Affects Versions: 2.0.0
>Reporter: Andrey Stepachev
>Assignee: Andrey Stepachev
> Attachments: HBASE-13147-branch-1.patch,
> HBASE-13147-branch-1.v2.patch, HBASE-13147.patch, HBASE-13147.v2.patch,
> HBASE-13147.v3.patch, HBASE-13147.v4.patch, HBASE-13147.v4.patch,
> HBASE-13147.v5.patch, HBASE-13147.v6.patch, HBASE-13147.v7.patch
>
>
> In HBASE-13087 stumbled on the fact, that region servers don't see actual
> meta descriptor, they use their own, statically compiled.
> Need to fix that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13590) TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey
[ https://issues.apache.org/jira/browse/HBASE-13590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14518812#comment-14518812 ] Andrey Stepachev commented on HBASE-13590: -- [~ndimiduk] I'll take it. > TestEnableTableHandler.testEnableTableWithNoRegionServers is flakey > --- > > Key: HBASE-13590 > URL: https://issues.apache.org/jira/browse/HBASE-13590 > Project: HBase > Issue Type: Test > Components: master >Reporter: Nick Dimiduk >Priority: Critical > Fix For: 2.0.0, 1.1.0, 1.2.0 > > > Looking at our [build > history|https://builds.apache.org/job/HBase-1.1/buildTimeTrend], it seems > this test is flakey. See builds 429, 431, 439. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13147) Load actual META table descriptor, don't use statically defined one.
[
https://issues.apache.org/jira/browse/HBASE-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14517417#comment-14517417
]
Andrey Stepachev edited comment on HBASE-13147 at 4/28/15 5:03 PM:
---
Thank you [~anoop.hbase] for reviewing.
{quote}
For CATALOG_FAMILY family we have allowed user to configure the number of max
versions but for the newly added TABLE_FAMILY HCD, it is again hard coded to
10. Why?
{quote}
Should be the same, will fix that.
But with this patch it is not relevant actually, Meta descriptor stored on disc
and all settings are preserved.
So if you modify number of versions, they would be preserved between restarts
and meta migrations.
{quote}
Just change the doc around HConstant#META_VERSION - It speaks abt keeping the
META version in the ROOT table. Instead we (will) rely on the meta version
which comes from the HTD attributes.
{quote}
It seems we need to file additional jira. There is a bunch of code which states
that. This patch doesn't use this constant.
(for example HRegion#addRegionToMETA says about root too, which is incorrect
and should be fixed).
{quote}
May be we will need another to Jira to clean up things. In the public exposed
HConstant only keep things which need to be exposed. For sharing common
constants (which are not be public exposed) let us have another constants file.
{quote}
Not sure that version is private (in compare to other exposed fields of meta).
I'd keep that as is until we will really want to hide meta from user.
{quote}
HTableDescriptor metaDescriptor = TableDescriptor.metaTableDescriptor(c)
This is still a static HTD. WHy?
{quote}
No, it is not. It is created from config. Static method is for bootstrap, when
we are formatting cluster
or repairing it in fsck. Otherwise with this patch htd from filesystem will be
used.
{quote}
Do we really need to add public APIs to HTD (which is client side public
exposed)? Can we deal with getValue() only?
{quote}
This method encapsulate logic for default version used. So it better to stick
code locally.
But if there better alternative, can think about.
{quote}
While creating the HTDs and TableDescriptors from reading from FS, we will call
So for old descriptor with no meta version in it, we consider as new version
Will the below code in MetaMigration will get used then?
else if (current.getMetaVersion() < HConstants.META_VERSION) {
...
{quote}
Meta will not exist on filesystem without version. It was never created in such
way
(it was always created on the fly), so this code is basically for future version
updates (meta will have version in it).
But it seems a place for bugs here, if meta will accidentally contain no
version at all.
I think we need to handle no-version explicitly and take care of places where we
can allow no-version meta (it doesn't make sense actually, because without
version
it is much safe to create new meta then trying to find out what this meta
version is).
Thanks for pointing to that.
was (Author: octo47):
Thank you [~anoop.hbase] for reviewing.
{quote}
For CATALOG_FAMILY family we have allowed user to configure the number of max
versions but for the newly added TABLE_FAMILY HCD, it is again hard coded to
10. Why?
{quote}
Should be the same, will fix that.
But with this patch it is not relevant actually, Meta descriptor sotred on disc
and all settings are preserved.
So if you modify number of versions, they would be preserved between restarts
and meta migrations.
{quote}
Just change the doc around HConstant#META_VERSION - It speaks abt keeping the
META version in the ROOT table. Instead we (will) rely on the meta version
which comes from the HTD attributes.
{quote}
It seems we need to file additional jira. There is a bunch of code which states
that. This patch doesn't use this constant.
(for example HRegion#addRegionToMETA says about root too, which is incorrect
and should be fixed).
{quote}
May be we will need another to Jira to clean up things. In the public exposed
HConstant only keep things which need to be exposed. For sharing common
constants (which are not be public exposed) let us have another constants file.
{quote}
Not sure that version is private (in compare to other exposed fields of meta).
I'd keep that as is until we will really want to hide meta from user.
{quote}
HTableDescriptor metaDescriptor = TableDescriptor.metaTableDescriptor(c)
This is still a static HTD. WHy?
{quote}
No, it is not. It is created from config. Static method is for bootstrap, when
we are formatting cluster
or repairing it in fsck. Otherwise with this patch htd from filesystem will be
used.
{quote}
Do we really need to add public APIs to HTD (which is client side public
exposed)? Can we deal with getValue() only?
{quote}
This method encapsulate logic for default version used. So it better to stick
code locally.
But if there better alternative, can
[jira] [Updated] (HBASE-13147) Load actual META table descriptor, don't use statically defined one.
[ https://issues.apache.org/jira/browse/HBASE-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13147: - Status: Open (was: Patch Available) > Load actual META table descriptor, don't use statically defined one. > > > Key: HBASE-13147 > URL: https://issues.apache.org/jira/browse/HBASE-13147 > Project: HBase > Issue Type: Bug > Components: master, regionserver >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13147-branch-1.patch, > HBASE-13147-branch-1.v2.patch, HBASE-13147.patch, HBASE-13147.v2.patch, > HBASE-13147.v3.patch, HBASE-13147.v4.patch, HBASE-13147.v4.patch, > HBASE-13147.v5.patch, HBASE-13147.v6.patch, HBASE-13147.v7.patch > > > In HBASE-13087 stumbled on the fact, that region servers don't see actual > meta descriptor, they use their own, statically compiled. > Need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13147) Load actual META table descriptor, don't use statically defined one.
[
https://issues.apache.org/jira/browse/HBASE-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14517417#comment-14517417
]
Andrey Stepachev commented on HBASE-13147:
--
Thank you [~anoop.hbase] for reviewing.
{quote}
For CATALOG_FAMILY family we have allowed user to configure the number of max
versions but for the newly added TABLE_FAMILY HCD, it is again hard coded to
10. Why?
{quote}
Should be the same, will fix that.
But with this patch it is not relevant actually, Meta descriptor sotred on disc
and all settings are preserved.
So if you modify number of versions, they would be preserved between restarts
and meta migrations.
{quote}
Just change the doc around HConstant#META_VERSION - It speaks abt keeping the
META version in the ROOT table. Instead we (will) rely on the meta version
which comes from the HTD attributes.
{quote}
It seems we need to file additional jira. There is a bunch of code which states
that. This patch doesn't use this constant.
(for example HRegion#addRegionToMETA says about root too, which is incorrect
and should be fixed).
{quote}
May be we will need another to Jira to clean up things. In the public exposed
HConstant only keep things which need to be exposed. For sharing common
constants (which are not be public exposed) let us have another constants file.
{quote}
Not sure that version is private (in compare to other exposed fields of meta).
I'd keep that as is until we will really want to hide meta from user.
{quote}
HTableDescriptor metaDescriptor = TableDescriptor.metaTableDescriptor(c)
This is still a static HTD. WHy?
{quote}
No, it is not. It is created from config. Static method is for bootstrap, when
we are formatting cluster
or repairing it in fsck. Otherwise with this patch htd from filesystem will be
used.
{quote}
Do we really need to add public APIs to HTD (which is client side public
exposed)? Can we deal with getValue() only?
{quote}
This method encapsulate logic for default version used. So it better to stick
code locally.
But if there better alternative, can think about.
{quote}
While creating the HTDs and TableDescriptors from reading from FS, we will call
So for old descriptor with no meta version in it, we consider as new version
Will the below code in MetaMigration will get used then?
else if (current.getMetaVersion() < HConstants.META_VERSION) {
...
{quote}
Meta will not exist on filesystem without version. It was never created in such
way
(it was always created on the fly), so this code is basically for future version
updates (meta will have version in it).
But it seems a place for bugs here, if meta will accidentally contain no
version at all.
I think we need to handle no-version explicitly and take care of places where we
can allow no-version meta (it doesn't make sense actually, because without
version
it is much safe to create new meta then trying to find out what this meta
version is).
Thanks for pointing to that.
> Load actual META table descriptor, don't use statically defined one.
>
>
> Key: HBASE-13147
> URL: https://issues.apache.org/jira/browse/HBASE-13147
> Project: HBase
> Issue Type: Bug
> Components: master, regionserver
>Affects Versions: 2.0.0
>Reporter: Andrey Stepachev
>Assignee: Andrey Stepachev
> Attachments: HBASE-13147-branch-1.patch,
> HBASE-13147-branch-1.v2.patch, HBASE-13147.patch, HBASE-13147.v2.patch,
> HBASE-13147.v3.patch, HBASE-13147.v4.patch, HBASE-13147.v4.patch,
> HBASE-13147.v5.patch, HBASE-13147.v6.patch, HBASE-13147.v7.patch
>
>
> In HBASE-13087 stumbled on the fact, that region servers don't see actual
> meta descriptor, they use their own, statically compiled.
> Need to fix that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13322) Replace explicit HBaseAdmin creation with connection#getAdmin()
[ https://issues.apache.org/jira/browse/HBASE-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13322: - Fix Version/s: 2.0.0 > Replace explicit HBaseAdmin creation with connection#getAdmin() > --- > > Key: HBASE-13322 > URL: https://issues.apache.org/jira/browse/HBASE-13322 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-13322.patch, HBASE-13322.v2.patch, > HBASE-13322.v3.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13575) TestChoreService has to make sure that the opened ChoreService is closed for each unit test
[ https://issues.apache.org/jira/browse/HBASE-13575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13575: - Labels: beginner (was: ) > TestChoreService has to make sure that the opened ChoreService is closed for > each unit test > --- > > Key: HBASE-13575 > URL: https://issues.apache.org/jira/browse/HBASE-13575 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0, 1.1.0, 1.2.0 >Reporter: Stephen Yuan Jiang >Assignee: Stephen Yuan Jiang >Priority: Trivial > Labels: beginner > > The TestChoreService shut down the opened ChoreService after each individual > unit test. This is to avoid test failure with enormous amount of active > threads at the end of test on slow virtual host (see HBASE-12992). However, > the service shut down was not wrapped around the 'finally'-block to guarantee > the execution when exception throws. The fix is trial. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13574) Broken TestHBaseFsck in master with hadoop 2.6.0
[
https://issues.apache.org/jira/browse/HBASE-13574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514670#comment-14514670
]
Andrey Stepachev commented on HBASE-13574:
--
[~ndimiduk] thanks, I think that we could do nothing there.
it should be fixed upstream in hdfs. seems that is anyway
wrong behaviour to retry for existent file almost 1 minute.
that as mininum should be configurable.
> Broken TestHBaseFsck in master with hadoop 2.6.0
>
>
> Key: HBASE-13574
> URL: https://issues.apache.org/jira/browse/HBASE-13574
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0
>Reporter: Andrey Stepachev
>Assignee: Andrey Stepachev
>Priority: Critical
> Attachments: HBASE-13574.patch
>
>
> Got following exception and it reproducible (I can see it in recent tests
> runs from other patches).
> {noformat}
> Running org.apache.hadoop.hbase.util.TestHBaseFsck
> Tests run: 51, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 348.628 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.util.TestHBaseFsck
> testParallelWithRetriesHbck(org.apache.hadoop.hbase.util.TestHBaseFsck) Time
> elapsed: 30.052 sec <<< ERROR!
> java.util.concurrent.ExecutionException: java.io.IOException: Duplicate hbck
> - Abort
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testParallelWithRetriesHbck(TestHBaseFsck.java:634)
> Caused by: java.io.IOException: Duplicate hbck - Abort
> at org.apache.hadoop.hbase.util.HBaseFsck.connect(HBaseFsck.java:473)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:53)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:43)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:38)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:625)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:621)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13574) Broken TestHBaseFsck in master with hadoop 2.6.0
[
https://issues.apache.org/jira/browse/HBASE-13574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Stepachev updated HBASE-13574:
-
Summary: Broken TestHBaseFsck in master with hadoop 2.6.0 (was: Broken
TestHBaseFsck in master)
> Broken TestHBaseFsck in master with hadoop 2.6.0
>
>
> Key: HBASE-13574
> URL: https://issues.apache.org/jira/browse/HBASE-13574
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0
>Reporter: Andrey Stepachev
>Assignee: Andrey Stepachev
>Priority: Critical
> Attachments: HBASE-13574.patch
>
>
> Got following exception and it reproducible (I can see it in recent tests
> runs from other patches).
> {noformat}
> Running org.apache.hadoop.hbase.util.TestHBaseFsck
> Tests run: 51, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 348.628 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.util.TestHBaseFsck
> testParallelWithRetriesHbck(org.apache.hadoop.hbase.util.TestHBaseFsck) Time
> elapsed: 30.052 sec <<< ERROR!
> java.util.concurrent.ExecutionException: java.io.IOException: Duplicate hbck
> - Abort
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testParallelWithRetriesHbck(TestHBaseFsck.java:634)
> Caused by: java.io.IOException: Duplicate hbck - Abort
> at org.apache.hadoop.hbase.util.HBaseFsck.connect(HBaseFsck.java:473)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:53)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:43)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:38)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:625)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:621)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13339) Update default Hadoop version to 2.6.0
[ https://issues.apache.org/jira/browse/HBASE-13339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514665#comment-14514665 ] Andrey Stepachev commented on HBASE-13339: -- in 2.6 seems behaviour of create() changed, so any operations which use hdfs for locking would experience long timeouts (60seconds). https://issues.apache.org/jira/browse/HDFS-8270 > Update default Hadoop version to 2.6.0 > -- > > Key: HBASE-13339 > URL: https://issues.apache.org/jira/browse/HBASE-13339 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 2.0.0, 1.1.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Blocker > Fix For: 2.0.0, 1.1.0, 1.2.0 > > Attachments: HBASE-13339-v1.patch, HBASE-13339.patch > > > Current default Hadoop version is getting a little long in the tooth. We > should update to the latest version. The latest version is backwards > compatible with 2.5.1's dfs and mr so this should be painless. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13574) Broken TestHBaseFsck in master
[
https://issues.apache.org/jira/browse/HBASE-13574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514662#comment-14514662
]
Andrey Stepachev commented on HBASE-13574:
--
created issue for that in HDFS project
https://issues.apache.org/jira/browse/HDFS-8270
> Broken TestHBaseFsck in master
> --
>
> Key: HBASE-13574
> URL: https://issues.apache.org/jira/browse/HBASE-13574
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0
>Reporter: Andrey Stepachev
>Assignee: Andrey Stepachev
>Priority: Critical
> Attachments: HBASE-13574.patch
>
>
> Got following exception and it reproducible (I can see it in recent tests
> runs from other patches).
> {noformat}
> Running org.apache.hadoop.hbase.util.TestHBaseFsck
> Tests run: 51, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 348.628 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.util.TestHBaseFsck
> testParallelWithRetriesHbck(org.apache.hadoop.hbase.util.TestHBaseFsck) Time
> elapsed: 30.052 sec <<< ERROR!
> java.util.concurrent.ExecutionException: java.io.IOException: Duplicate hbck
> - Abort
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testParallelWithRetriesHbck(TestHBaseFsck.java:634)
> Caused by: java.io.IOException: Duplicate hbck - Abort
> at org.apache.hadoop.hbase.util.HBaseFsck.connect(HBaseFsck.java:473)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:53)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:43)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:38)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:625)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:621)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13574) Broken TestHBaseFsck in master
[
https://issues.apache.org/jira/browse/HBASE-13574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514619#comment-14514619
]
Andrey Stepachev commented on HBASE-13574:
--
Ok, here is a fix, that broke things:
https://issues.apache.org/jira/browse/HDFS-6478.
Prior to it RemoteException didn't handled properly.
> Broken TestHBaseFsck in master
> --
>
> Key: HBASE-13574
> URL: https://issues.apache.org/jira/browse/HBASE-13574
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0
>Reporter: Andrey Stepachev
>Assignee: Andrey Stepachev
>Priority: Critical
> Attachments: HBASE-13574.patch
>
>
> Got following exception and it reproducible (I can see it in recent tests
> runs from other patches).
> {noformat}
> Running org.apache.hadoop.hbase.util.TestHBaseFsck
> Tests run: 51, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 348.628 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.util.TestHBaseFsck
> testParallelWithRetriesHbck(org.apache.hadoop.hbase.util.TestHBaseFsck) Time
> elapsed: 30.052 sec <<< ERROR!
> java.util.concurrent.ExecutionException: java.io.IOException: Duplicate hbck
> - Abort
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testParallelWithRetriesHbck(TestHBaseFsck.java:634)
> Caused by: java.io.IOException: Duplicate hbck - Abort
> at org.apache.hadoop.hbase.util.HBaseFsck.connect(HBaseFsck.java:473)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:53)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:43)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:38)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:625)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:621)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13574) Broken TestHBaseFsck in master
[
https://issues.apache.org/jira/browse/HBASE-13574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Stepachev updated HBASE-13574:
-
Status: Open (was: Patch Available)
hm, need to fix that properly for 2.6.
> Broken TestHBaseFsck in master
> --
>
> Key: HBASE-13574
> URL: https://issues.apache.org/jira/browse/HBASE-13574
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0
>Reporter: Andrey Stepachev
>Assignee: Andrey Stepachev
>Priority: Critical
> Attachments: HBASE-13574.patch
>
>
> Got following exception and it reproducible (I can see it in recent tests
> runs from other patches).
> {noformat}
> Running org.apache.hadoop.hbase.util.TestHBaseFsck
> Tests run: 51, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 348.628 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.util.TestHBaseFsck
> testParallelWithRetriesHbck(org.apache.hadoop.hbase.util.TestHBaseFsck) Time
> elapsed: 30.052 sec <<< ERROR!
> java.util.concurrent.ExecutionException: java.io.IOException: Duplicate hbck
> - Abort
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testParallelWithRetriesHbck(TestHBaseFsck.java:634)
> Caused by: java.io.IOException: Duplicate hbck - Abort
> at org.apache.hadoop.hbase.util.HBaseFsck.connect(HBaseFsck.java:473)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:53)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:43)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:38)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:625)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:621)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13087) branch-1 isn't rolling upgradable from 0.98
[
https://issues.apache.org/jira/browse/HBASE-13087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514521#comment-14514521
]
Andrey Stepachev commented on HBASE-13087:
--
Because it can have no code for coprocessors for example.
So when we add new coprocessors we should be sure, that
those coprocessors have recent code. That is why it much better
to have strict policy on which RS can run system tables.
(actually that is wider problem, any system coprocessors
need to be consistent with expected structure of system table).
> branch-1 isn't rolling upgradable from 0.98
> ---
>
> Key: HBASE-13087
> URL: https://issues.apache.org/jira/browse/HBASE-13087
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Elliott Clark
>Assignee: Rajesh Nishtala
>Priority: Blocker
> Fix For: 1.1.0
>
> Attachments: HBASE-13087-v1.txt
>
>
> {code}org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException:
> Failed 1 action:
> org.apache.hadoop.hbase.regionserver.NoSuchColumnFamilyException: Column
> family table does not exist in region hbase:meta,,1.1588230740 in table
> 'hbase:meta', {TABLE_ATTRIBUTES => {IS_META => 'true', coprocessor$1 =>
> '|org.apache.hadoop.hbase.coprocessor.MultiRowMutationEndpoint|536870911|'},
> {NAME => 'info', BLOOMFILTER => 'NONE', VERSIONS => '10', IN_MEMORY =>
> 'true', KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL =>
> 'FOREVER', COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOCKCACHE => 'true',
> BLOCKSIZE => '8192', REPLICATION_SCOPE => '0'}
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.doBatchOp(HRegionServer.java:4513)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.doNonAtomicRegionMutation(HRegionServer.java:3687)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.multi(HRegionServer.java:3576)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:30816)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2029)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107)
> at java.lang.Thread.run(Thread.java:745)
> : 1 time,
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:228)
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$1700(AsyncProcess.java:208)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForAllPreviousOpsAndReset(AsyncProcess.java:1689)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.backgroundFlushCommits(BufferedMutatorImpl.java:208)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.flush(BufferedMutatorImpl.java:183)
> at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1404)
> at org.apache.hadoop.hbase.client.HTable.put(HTable.java:1017)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.put(MetaTableAccessor.java:1123)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.putToMetaTable(MetaTableAccessor.java:1113)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.updateTableState(MetaTableAccessor.java:1436)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.updateTableState(MetaTableAccessor.java:948)
> at
> org.apache.hadoop.hbase.master.TableStateManager.writeMetaState(TableStateManager.java:195)
> at
> org.apache.hadoop.hbase.master.TableStateManager.setTableState(TableStateManager.java:69)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.setEnabledTable(AssignmentManager.java:3427)
> at org.apache.hadoop.hbase.master.HMaster.assignMeta(HMaster.java:903)
> at
> org.apache.hadoop.hbase.master.HMaster.finishActiveMasterInitialization(HMaster.java:698)
> at org.apache.hadoop.hbase.master.HMaster.access$500(HMaster.java:166)
> at org.apache.hadoop.hbase.master.HMaster$1.run(HMaster.java:1494)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13322) Replace explicit HBaseAdmin creation with connection#getAdmin()
[ https://issues.apache.org/jira/browse/HBASE-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514328#comment-14514328 ] Andrey Stepachev commented on HBASE-13322: -- Commited, thank you [~stack]. Now will backport this to branch-1 -- Andrey. > Replace explicit HBaseAdmin creation with connection#getAdmin() > --- > > Key: HBASE-13322 > URL: https://issues.apache.org/jira/browse/HBASE-13322 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13322.patch, HBASE-13322.v2.patch, > HBASE-13322.v3.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13574) Broken TestHBaseFsck in master
[
https://issues.apache.org/jira/browse/HBASE-13574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514275#comment-14514275
]
Andrey Stepachev commented on HBASE-13574:
--
It seems that test is broken due of the new create retry policy in hadoop 2.6.
Namenode proxy now created with custom RetryPolicy for
AlreadyBeingCreatedException which
is implies timeout on this operations up to
HdfsConstants.LEASE_SOFTLIMIT_PERIOD (60seconds).
So we should expect that create can execute as minimum as this constant if file
already exists.
So for now we can fix that by hardcoding greater timeouts to HBaseFsck (for now
they
are 15 seconds in test and 30seconds in HbaseFsck itself).
This change should not break production usage of HBaseFsck, except of it will
take longer to
find out that other instance of HbaseFsck is running.
> Broken TestHBaseFsck in master
> --
>
> Key: HBASE-13574
> URL: https://issues.apache.org/jira/browse/HBASE-13574
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0
>Reporter: Andrey Stepachev
>Priority: Critical
>
> Got following exception and it reproducible (I can see it in recent tests
> runs from other patches).
> {noformat}
> Running org.apache.hadoop.hbase.util.TestHBaseFsck
> Tests run: 51, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 348.628 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.util.TestHBaseFsck
> testParallelWithRetriesHbck(org.apache.hadoop.hbase.util.TestHBaseFsck) Time
> elapsed: 30.052 sec <<< ERROR!
> java.util.concurrent.ExecutionException: java.io.IOException: Duplicate hbck
> - Abort
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testParallelWithRetriesHbck(TestHBaseFsck.java:634)
> Caused by: java.io.IOException: Duplicate hbck - Abort
> at org.apache.hadoop.hbase.util.HBaseFsck.connect(HBaseFsck.java:473)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:53)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:43)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:38)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:625)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:621)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13574) Broken TestHBaseFsck in master
[
https://issues.apache.org/jira/browse/HBASE-13574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Stepachev updated HBASE-13574:
-
Assignee: Andrey Stepachev
Status: Patch Available (was: Open)
> Broken TestHBaseFsck in master
> --
>
> Key: HBASE-13574
> URL: https://issues.apache.org/jira/browse/HBASE-13574
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0
>Reporter: Andrey Stepachev
>Assignee: Andrey Stepachev
>Priority: Critical
> Attachments: HBASE-13574.patch
>
>
> Got following exception and it reproducible (I can see it in recent tests
> runs from other patches).
> {noformat}
> Running org.apache.hadoop.hbase.util.TestHBaseFsck
> Tests run: 51, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 348.628 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.util.TestHBaseFsck
> testParallelWithRetriesHbck(org.apache.hadoop.hbase.util.TestHBaseFsck) Time
> elapsed: 30.052 sec <<< ERROR!
> java.util.concurrent.ExecutionException: java.io.IOException: Duplicate hbck
> - Abort
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testParallelWithRetriesHbck(TestHBaseFsck.java:634)
> Caused by: java.io.IOException: Duplicate hbck - Abort
> at org.apache.hadoop.hbase.util.HBaseFsck.connect(HBaseFsck.java:473)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:53)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:43)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:38)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:625)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:621)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13574) Broken TestHBaseFsck in master
[
https://issues.apache.org/jira/browse/HBASE-13574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Stepachev updated HBASE-13574:
-
Attachment: HBASE-13574.patch
> Broken TestHBaseFsck in master
> --
>
> Key: HBASE-13574
> URL: https://issues.apache.org/jira/browse/HBASE-13574
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0
>Reporter: Andrey Stepachev
>Priority: Critical
> Attachments: HBASE-13574.patch
>
>
> Got following exception and it reproducible (I can see it in recent tests
> runs from other patches).
> {noformat}
> Running org.apache.hadoop.hbase.util.TestHBaseFsck
> Tests run: 51, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 348.628 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.util.TestHBaseFsck
> testParallelWithRetriesHbck(org.apache.hadoop.hbase.util.TestHBaseFsck) Time
> elapsed: 30.052 sec <<< ERROR!
> java.util.concurrent.ExecutionException: java.io.IOException: Duplicate hbck
> - Abort
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testParallelWithRetriesHbck(TestHBaseFsck.java:634)
> Caused by: java.io.IOException: Duplicate hbck - Abort
> at org.apache.hadoop.hbase.util.HBaseFsck.connect(HBaseFsck.java:473)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:53)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:43)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:38)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:625)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:621)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (HBASE-13339) Update default Hadoop version to 2.6.0
[ https://issues.apache.org/jira/browse/HBASE-13339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev resolved HBASE-13339. -- Resolution: Fixed > Update default Hadoop version to 2.6.0 > -- > > Key: HBASE-13339 > URL: https://issues.apache.org/jira/browse/HBASE-13339 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 2.0.0, 1.1.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.1.0, 1.2.0 > > Attachments: HBASE-13339-v1.patch, HBASE-13339.patch > > > Current default Hadoop version is getting a little long in the tooth. We > should update to the latest version. The latest version is backwards > compatible with 2.5.1's dfs and mr so this should be painless. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13339) Update default Hadoop version to 2.6.0
[ https://issues.apache.org/jira/browse/HBASE-13339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514242#comment-14514242 ] Andrey Stepachev commented on HBASE-13339: -- 2.6 seem have special retry policy for creating files, so it will retry up to HdfsConstants.LEASE_SOFTLIMIT_PERIOD. that seems should not break any significant except for mentioned above test. Close this, sorry. > Update default Hadoop version to 2.6.0 > -- > > Key: HBASE-13339 > URL: https://issues.apache.org/jira/browse/HBASE-13339 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 2.0.0, 1.1.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.1.0, 1.2.0 > > Attachments: HBASE-13339-v1.patch, HBASE-13339.patch > > > Current default Hadoop version is getting a little long in the tooth. We > should update to the latest version. The latest version is backwards > compatible with 2.5.1's dfs and mr so this should be painless. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13339) Update default Hadoop version to 2.6.0
[ https://issues.apache.org/jira/browse/HBASE-13339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514024#comment-14514024 ] Andrey Stepachev edited comment on HBASE-13339 at 4/27/15 12:25 PM: I want to reopen this issue. HBASE-13574 shows that introducing 2.6 hadoop break something in filesystem operations. Specifically TestHBaseFsck test shows that something broken. That is for master. was (Author: octo47): I want to reopen this issue. HBASE-13574 shows that introducing 2.6 hadoop break something in filesystem operations. > Update default Hadoop version to 2.6.0 > -- > > Key: HBASE-13339 > URL: https://issues.apache.org/jira/browse/HBASE-13339 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 2.0.0, 1.1.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.1.0, 1.2.0 > > Attachments: HBASE-13339-v1.patch, HBASE-13339.patch > > > Current default Hadoop version is getting a little long in the tooth. We > should update to the latest version. The latest version is backwards > compatible with 2.5.1's dfs and mr so this should be painless. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (HBASE-13339) Update default Hadoop version to 2.6.0
[ https://issues.apache.org/jira/browse/HBASE-13339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev reopened HBASE-13339: -- I want to reopen this issue. HBASE-13574 shows that introducing 2.6 hadoop break something in filesystem operations. > Update default Hadoop version to 2.6.0 > -- > > Key: HBASE-13339 > URL: https://issues.apache.org/jira/browse/HBASE-13339 > Project: HBase > Issue Type: Bug > Components: build >Affects Versions: 2.0.0, 1.1.0 >Reporter: Elliott Clark >Assignee: Elliott Clark > Fix For: 2.0.0, 1.1.0, 1.2.0 > > Attachments: HBASE-13339-v1.patch, HBASE-13339.patch > > > Current default Hadoop version is getting a little long in the tooth. We > should update to the latest version. The latest version is backwards > compatible with 2.5.1's dfs and mr so this should be painless. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13574) Broken TestHBaseFsck in master
[
https://issues.apache.org/jira/browse/HBASE-13574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514023#comment-14514023
]
Andrey Stepachev commented on HBASE-13574:
--
reverting HBASE-13339 makes test run, so can confirm that HBASE-13339
introduced problem (suppose somewhere in proxy and close() method, will dig
deeper).
> Broken TestHBaseFsck in master
> --
>
> Key: HBASE-13574
> URL: https://issues.apache.org/jira/browse/HBASE-13574
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0
>Reporter: Andrey Stepachev
>Priority: Critical
>
> Got following exception and it reproducible (I can see it in recent tests
> runs from other patches).
> {noformat}
> Running org.apache.hadoop.hbase.util.TestHBaseFsck
> Tests run: 51, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 348.628 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.util.TestHBaseFsck
> testParallelWithRetriesHbck(org.apache.hadoop.hbase.util.TestHBaseFsck) Time
> elapsed: 30.052 sec <<< ERROR!
> java.util.concurrent.ExecutionException: java.io.IOException: Duplicate hbck
> - Abort
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testParallelWithRetriesHbck(TestHBaseFsck.java:634)
> Caused by: java.io.IOException: Duplicate hbck - Abort
> at org.apache.hadoop.hbase.util.HBaseFsck.connect(HBaseFsck.java:473)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:53)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:43)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:38)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:625)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:621)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13322) Replace explicit HBaseAdmin creation with connection#getAdmin()
[ https://issues.apache.org/jira/browse/HBASE-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514010#comment-14514010 ] Andrey Stepachev commented on HBASE-13322: -- TestHBaseFsck is broken due of HBASE-13574. So I'd consider this patch is clean in term of tests. Can we commit this? > Replace explicit HBaseAdmin creation with connection#getAdmin() > --- > > Key: HBASE-13322 > URL: https://issues.apache.org/jira/browse/HBASE-13322 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13322.patch, HBASE-13322.v2.patch, > HBASE-13322.v3.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13574) Broken TestHBaseFsck in master
[
https://issues.apache.org/jira/browse/HBASE-13574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14514001#comment-14514001
]
Andrey Stepachev commented on HBASE-13574:
--
it seems introduced by HBASE-13339, something in hadoop-2.6 makes it broken.
> Broken TestHBaseFsck in master
> --
>
> Key: HBASE-13574
> URL: https://issues.apache.org/jira/browse/HBASE-13574
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0
>Reporter: Andrey Stepachev
>Priority: Critical
>
> Got following exception and it reproducible (I can see it in recent tests
> runs from other patches).
> {noformat}
> Running org.apache.hadoop.hbase.util.TestHBaseFsck
> Tests run: 51, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 348.628 sec
> <<< FAILURE! - in org.apache.hadoop.hbase.util.TestHBaseFsck
> testParallelWithRetriesHbck(org.apache.hadoop.hbase.util.TestHBaseFsck) Time
> elapsed: 30.052 sec <<< ERROR!
> java.util.concurrent.ExecutionException: java.io.IOException: Duplicate hbck
> - Abort
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck.testParallelWithRetriesHbck(TestHBaseFsck.java:634)
> Caused by: java.io.IOException: Duplicate hbck - Abort
> at org.apache.hadoop.hbase.util.HBaseFsck.connect(HBaseFsck.java:473)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:53)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:43)
> at
> org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:38)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:625)
> at
> org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:621)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-13574) Broken TestHBaseFsck in master
Andrey Stepachev created HBASE-13574:
Summary: Broken TestHBaseFsck in master
Key: HBASE-13574
URL: https://issues.apache.org/jira/browse/HBASE-13574
Project: HBase
Issue Type: Bug
Components: test
Affects Versions: 2.0.0
Reporter: Andrey Stepachev
Priority: Critical
Got following exception and it reproducible (I can see it in recent tests runs
from other patches).
{noformat}
Running org.apache.hadoop.hbase.util.TestHBaseFsck
Tests run: 51, Failures: 0, Errors: 1, Skipped: 1, Time elapsed: 348.628 sec
<<< FAILURE! - in org.apache.hadoop.hbase.util.TestHBaseFsck
testParallelWithRetriesHbck(org.apache.hadoop.hbase.util.TestHBaseFsck) Time
elapsed: 30.052 sec <<< ERROR!
java.util.concurrent.ExecutionException: java.io.IOException: Duplicate hbck -
Abort
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:188)
at
org.apache.hadoop.hbase.util.TestHBaseFsck.testParallelWithRetriesHbck(TestHBaseFsck.java:634)
Caused by: java.io.IOException: Duplicate hbck - Abort
at org.apache.hadoop.hbase.util.HBaseFsck.connect(HBaseFsck.java:473)
at
org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:53)
at
org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:43)
at
org.apache.hadoop.hbase.util.hbck.HbckTestingUtil.doFsck(HbckTestingUtil.java:38)
at
org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:625)
at
org.apache.hadoop.hbase.util.TestHBaseFsck$2RunHbck.call(TestHBaseFsck.java:621)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-13087) branch-1 isn't rolling upgradable from 0.98
[
https://issues.apache.org/jira/browse/HBASE-13087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513903#comment-14513903
]
Andrey Stepachev commented on HBASE-13087:
--
[~ndimiduk], [~eclark], I'll try to resolve HBASE-13147 as soon as possible.
Sorry for delay here. As soon we will be able to distinguish what version of
meta is used
it should be possible to do rolling upgrade.
Once we have meta version we need to invent some way to let AssignmentManager
to know what version of Meta RegionServer is expected.
We could add to server status, reported by RS, version
of expected META, so AM could consult this infomation and assign meta
to compatible RS only.
As I think it should looks like:
1. Master restarted.
2. AM checks META versions and in case mismatch unassign META from
RS with old expected version.
3. Once there is RS with compatible version META could be assigned to it
(in case of rolling upgrade exepected delay could be time of master
restart + 1 region server restart).
> branch-1 isn't rolling upgradable from 0.98
> ---
>
> Key: HBASE-13087
> URL: https://issues.apache.org/jira/browse/HBASE-13087
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Elliott Clark
>Assignee: Rajesh Nishtala
>Priority: Blocker
> Fix For: 1.1.0
>
> Attachments: HBASE-13087-v1.txt
>
>
> {code}org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException:
> Failed 1 action:
> org.apache.hadoop.hbase.regionserver.NoSuchColumnFamilyException: Column
> family table does not exist in region hbase:meta,,1.1588230740 in table
> 'hbase:meta', {TABLE_ATTRIBUTES => {IS_META => 'true', coprocessor$1 =>
> '|org.apache.hadoop.hbase.coprocessor.MultiRowMutationEndpoint|536870911|'},
> {NAME => 'info', BLOOMFILTER => 'NONE', VERSIONS => '10', IN_MEMORY =>
> 'true', KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL =>
> 'FOREVER', COMPRESSION => 'NONE', MIN_VERSIONS => '0', BLOCKCACHE => 'true',
> BLOCKSIZE => '8192', REPLICATION_SCOPE => '0'}
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.doBatchOp(HRegionServer.java:4513)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.doNonAtomicRegionMutation(HRegionServer.java:3687)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.multi(HRegionServer.java:3576)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:30816)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2029)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107)
> at java.lang.Thread.run(Thread.java:745)
> : 1 time,
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.makeException(AsyncProcess.java:228)
> at
> org.apache.hadoop.hbase.client.AsyncProcess$BatchErrors.access$1700(AsyncProcess.java:208)
> at
> org.apache.hadoop.hbase.client.AsyncProcess.waitForAllPreviousOpsAndReset(AsyncProcess.java:1689)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.backgroundFlushCommits(BufferedMutatorImpl.java:208)
> at
> org.apache.hadoop.hbase.client.BufferedMutatorImpl.flush(BufferedMutatorImpl.java:183)
> at org.apache.hadoop.hbase.client.HTable.flushCommits(HTable.java:1404)
> at org.apache.hadoop.hbase.client.HTable.put(HTable.java:1017)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.put(MetaTableAccessor.java:1123)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.putToMetaTable(MetaTableAccessor.java:1113)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.updateTableState(MetaTableAccessor.java:1436)
> at
> org.apache.hadoop.hbase.MetaTableAccessor.updateTableState(MetaTableAccessor.java:948)
> at
> org.apache.hadoop.hbase.master.TableStateManager.writeMetaState(TableStateManager.java:195)
> at
> org.apache.hadoop.hbase.master.TableStateManager.setTableState(TableStateManager.java:69)
> at
> org.apache.hadoop.hbase.master.AssignmentManager.setEnabledTable(AssignmentManager.java:3427)
> at org.apache.hadoop.hbase.master.HMaster.assignMeta(HMaster.java:903)
> at
> org.apache.hadoop.hbase.master.HMaster.finishActiveMasterInitialization(HMaster.java:698)
> at org.apache.hadoop.hbase.master.HMaster.access$500(HMaster.java:166)
> at org.apache.hadoop.hbase.master.HMaster$1.run(HMaster.java:1494)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-13334) FindBugs should create precise report for new bugs introduced
[ https://issues.apache.org/jira/browse/HBASE-13334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13334: - Resolution: Fixed Status: Resolved (was: Patch Available) > FindBugs should create precise report for new bugs introduced > - > > Key: HBASE-13334 > URL: https://issues.apache.org/jira/browse/HBASE-13334 > Project: HBase > Issue Type: Improvement > Components: build >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13334.patch, HBASE-13334.v2.patch > > > Currently findbugs build process reports only number of bugs introduced. And > there is no report on what acutally was introduced. > Lets improve that: we can use computeBugHistory to generate precise report on > new bugs (and optionally missed bugs). > Report should be available in html format. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13334) FindBugs should create precise report for new bugs introduced
[ https://issues.apache.org/jira/browse/HBASE-13334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513839#comment-14513839 ] Andrey Stepachev commented on HBASE-13334: -- yeah. :) didn't realize that. So, I close this. > FindBugs should create precise report for new bugs introduced > - > > Key: HBASE-13334 > URL: https://issues.apache.org/jira/browse/HBASE-13334 > Project: HBase > Issue Type: Improvement > Components: build >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13334.patch, HBASE-13334.v2.patch > > > Currently findbugs build process reports only number of bugs introduced. And > there is no report on what acutally was introduced. > Lets improve that: we can use computeBugHistory to generate precise report on > new bugs (and optionally missed bugs). > Report should be available in html format. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13573) Backport HBase-12990: MetaScanner should be replaced by MetaTableAccessor
[ https://issues.apache.org/jira/browse/HBASE-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13573: - Description: Lets leave only one of access method to Meta. MetaScanner should be removed. > Backport HBase-12990: MetaScanner should be replaced by MetaTableAccessor > - > > Key: HBASE-13573 > URL: https://issues.apache.org/jira/browse/HBASE-13573 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 1.2.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > > Lets leave only one of access method to Meta. MetaScanner should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-13573) Backport HBase-12990: MetaScanner should be replaced by MetaTableAccessor
Andrey Stepachev created HBASE-13573: Summary: Backport HBase-12990: MetaScanner should be replaced by MetaTableAccessor Key: HBASE-13573 URL: https://issues.apache.org/jira/browse/HBASE-13573 Project: HBase Issue Type: Bug Components: Client Affects Versions: 1.2.0 Reporter: Andrey Stepachev Assignee: Andrey Stepachev -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13322) Replace explicit HBaseAdmin creation with connection#getAdmin()
[ https://issues.apache.org/jira/browse/HBASE-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13322: - Status: Patch Available (was: Open) > Replace explicit HBaseAdmin creation with connection#getAdmin() > --- > > Key: HBASE-13322 > URL: https://issues.apache.org/jira/browse/HBASE-13322 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13322.patch, HBASE-13322.v2.patch, > HBASE-13322.v3.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13322) Replace explicit HBaseAdmin creation with connection#getAdmin()
[ https://issues.apache.org/jira/browse/HBASE-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13322: - Attachment: HBASE-13322.v3.patch tableDetails.jsp now uses HMaster connection two tests were fixed. > Replace explicit HBaseAdmin creation with connection#getAdmin() > --- > > Key: HBASE-13322 > URL: https://issues.apache.org/jira/browse/HBASE-13322 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13322.patch, HBASE-13322.v2.patch, > HBASE-13322.v3.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13322) Replace explicit HBaseAdmin creation with connection#getAdmin()
[ https://issues.apache.org/jira/browse/HBASE-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13322: - Status: Open (was: Patch Available) > Replace explicit HBaseAdmin creation with connection#getAdmin() > --- > > Key: HBASE-13322 > URL: https://issues.apache.org/jira/browse/HBASE-13322 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13322.patch, HBASE-13322.v2.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13322) Replace explicit HBaseAdmin creation with connection#getAdmin()
[ https://issues.apache.org/jira/browse/HBASE-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513806#comment-14513806 ] Andrey Stepachev commented on HBASE-13322: -- [~ndimiduk] It seems that RegionSizeCalculator(HTable) constructor is not used anymore, it deprecated. So it basically shouldn't hurt. As for tableDetails, sure, that was bad idea to create connection. Fixed now and reuse master connection. > Replace explicit HBaseAdmin creation with connection#getAdmin() > --- > > Key: HBASE-13322 > URL: https://issues.apache.org/jira/browse/HBASE-13322 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13322.patch, HBASE-13322.v2.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13334) FindBugs should create precise report for new bugs introduced
[ https://issues.apache.org/jira/browse/HBASE-13334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513771#comment-14513771 ] Andrey Stepachev commented on HBASE-13334: -- [~busbey], [~ndimiduk] does it looks good for branch-1? (I'm about general idea to pull that into branch1?) > FindBugs should create precise report for new bugs introduced > - > > Key: HBASE-13334 > URL: https://issues.apache.org/jira/browse/HBASE-13334 > Project: HBase > Issue Type: Improvement > Components: build >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev >Priority: Minor > Attachments: HBASE-13334.patch, HBASE-13334.v2.patch > > > Currently findbugs build process reports only number of bugs introduced. And > there is no report on what acutally was introduced. > Lets improve that: we can use computeBugHistory to generate precise report on > new bugs (and optionally missed bugs). > Report should be available in html format. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13147) Load actual META table descriptor, don't use statically defined one.
[ https://issues.apache.org/jira/browse/HBASE-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13147: - Status: Open (was: Patch Available) > Load actual META table descriptor, don't use statically defined one. > > > Key: HBASE-13147 > URL: https://issues.apache.org/jira/browse/HBASE-13147 > Project: HBase > Issue Type: Bug > Components: master, regionserver >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13147-branch-1.patch, > HBASE-13147-branch-1.v2.patch, HBASE-13147.patch, HBASE-13147.v2.patch, > HBASE-13147.v3.patch, HBASE-13147.v4.patch, HBASE-13147.v4.patch, > HBASE-13147.v5.patch, HBASE-13147.v6.patch, HBASE-13147.v7.patch > > > In HBASE-13087 stumbled on the fact, that region servers don't see actual > meta descriptor, they use their own, statically compiled. > Need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13147) Load actual META table descriptor, don't use statically defined one.
[ https://issues.apache.org/jira/browse/HBASE-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13147: - Status: Patch Available (was: Open) > Load actual META table descriptor, don't use statically defined one. > > > Key: HBASE-13147 > URL: https://issues.apache.org/jira/browse/HBASE-13147 > Project: HBase > Issue Type: Bug > Components: master, regionserver >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13147-branch-1.patch, > HBASE-13147-branch-1.v2.patch, HBASE-13147.patch, HBASE-13147.v2.patch, > HBASE-13147.v3.patch, HBASE-13147.v4.patch, HBASE-13147.v4.patch, > HBASE-13147.v5.patch, HBASE-13147.v6.patch, HBASE-13147.v7.patch > > > In HBASE-13087 stumbled on the fact, that region servers don't see actual > meta descriptor, they use their own, statically compiled. > Need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-13147) Load actual META table descriptor, don't use statically defined one.
[ https://issues.apache.org/jira/browse/HBASE-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13147: - Attachment: HBASE-13147.v7.patch > Load actual META table descriptor, don't use statically defined one. > > > Key: HBASE-13147 > URL: https://issues.apache.org/jira/browse/HBASE-13147 > Project: HBase > Issue Type: Bug > Components: master, regionserver >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13147-branch-1.patch, > HBASE-13147-branch-1.v2.patch, HBASE-13147.patch, HBASE-13147.v2.patch, > HBASE-13147.v3.patch, HBASE-13147.v4.patch, HBASE-13147.v4.patch, > HBASE-13147.v5.patch, HBASE-13147.v6.patch, HBASE-13147.v7.patch > > > In HBASE-13087 stumbled on the fact, that region servers don't see actual > meta descriptor, they use their own, statically compiled. > Need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13147) Load actual META table descriptor, don't use statically defined one.
[ https://issues.apache.org/jira/browse/HBASE-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513727#comment-14513727 ] Andrey Stepachev commented on HBASE-13147: -- [~ndimiduk] not yet ready, doing versioning (so meta layout can have version in htabledecriptor). That would prevent from opening new meta by old code. That is partially done for master, and later will be ported to branch-1. > Load actual META table descriptor, don't use statically defined one. > > > Key: HBASE-13147 > URL: https://issues.apache.org/jira/browse/HBASE-13147 > Project: HBase > Issue Type: Bug > Components: master, regionserver >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13147-branch-1.patch, > HBASE-13147-branch-1.v2.patch, HBASE-13147.patch, HBASE-13147.v2.patch, > HBASE-13147.v3.patch, HBASE-13147.v4.patch, HBASE-13147.v4.patch, > HBASE-13147.v5.patch, HBASE-13147.v6.patch > > > In HBASE-13087 stumbled on the fact, that region servers don't see actual > meta descriptor, they use their own, statically compiled. > Need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (HBASE-13147) Load actual META table descriptor, don't use statically defined one.
[ https://issues.apache.org/jira/browse/HBASE-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Stepachev updated HBASE-13147: - Comment: was deleted (was: [~ndimiduk], this is for branch-1 initially. I'm now doing versioning for meta format, so we will be able to handle rolling upgrade. It seems after this patch will be done, I'll port it to master.) > Load actual META table descriptor, don't use statically defined one. > > > Key: HBASE-13147 > URL: https://issues.apache.org/jira/browse/HBASE-13147 > Project: HBase > Issue Type: Bug > Components: master, regionserver >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13147-branch-1.patch, > HBASE-13147-branch-1.v2.patch, HBASE-13147.patch, HBASE-13147.v2.patch, > HBASE-13147.v3.patch, HBASE-13147.v4.patch, HBASE-13147.v4.patch, > HBASE-13147.v5.patch, HBASE-13147.v6.patch > > > In HBASE-13087 stumbled on the fact, that region servers don't see actual > meta descriptor, they use their own, statically compiled. > Need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13147) Load actual META table descriptor, don't use statically defined one.
[ https://issues.apache.org/jira/browse/HBASE-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513722#comment-14513722 ] Andrey Stepachev edited comment on HBASE-13147 at 4/27/15 8:41 AM: --- [~ndimiduk], this is for branch-1 initially. I'm now doing versioning for meta, so we will be able to handle rolling upgrade. It seems after this patch will be done, I'll port it to master. was (Author: octo47): [~ndimiduk], this is for branch-1 initially. I'm now doing versioning for meta, so we will be able to handle rolling upgrade. It seems after this patch will be done, I'll port it to branch-2. Hope do that soon. > Load actual META table descriptor, don't use statically defined one. > > > Key: HBASE-13147 > URL: https://issues.apache.org/jira/browse/HBASE-13147 > Project: HBase > Issue Type: Bug > Components: master, regionserver >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13147-branch-1.patch, > HBASE-13147-branch-1.v2.patch, HBASE-13147.patch, HBASE-13147.v2.patch, > HBASE-13147.v3.patch, HBASE-13147.v4.patch, HBASE-13147.v4.patch, > HBASE-13147.v5.patch, HBASE-13147.v6.patch > > > In HBASE-13087 stumbled on the fact, that region servers don't see actual > meta descriptor, they use their own, statically compiled. > Need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (HBASE-13147) Load actual META table descriptor, don't use statically defined one.
[ https://issues.apache.org/jira/browse/HBASE-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513722#comment-14513722 ] Andrey Stepachev edited comment on HBASE-13147 at 4/27/15 8:41 AM: --- [~ndimiduk], this is for branch-1 initially. I'm now doing versioning for meta format, so we will be able to handle rolling upgrade. It seems after this patch will be done, I'll port it to master. was (Author: octo47): [~ndimiduk], this is for branch-1 initially. I'm now doing versioning for meta, so we will be able to handle rolling upgrade. It seems after this patch will be done, I'll port it to master. > Load actual META table descriptor, don't use statically defined one. > > > Key: HBASE-13147 > URL: https://issues.apache.org/jira/browse/HBASE-13147 > Project: HBase > Issue Type: Bug > Components: master, regionserver >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13147-branch-1.patch, > HBASE-13147-branch-1.v2.patch, HBASE-13147.patch, HBASE-13147.v2.patch, > HBASE-13147.v3.patch, HBASE-13147.v4.patch, HBASE-13147.v4.patch, > HBASE-13147.v5.patch, HBASE-13147.v6.patch > > > In HBASE-13087 stumbled on the fact, that region servers don't see actual > meta descriptor, they use their own, statically compiled. > Need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-13147) Load actual META table descriptor, don't use statically defined one.
[ https://issues.apache.org/jira/browse/HBASE-13147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14513722#comment-14513722 ] Andrey Stepachev commented on HBASE-13147: -- [~ndimiduk], this is for branch-1 initially. I'm now doing versioning for meta, so we will be able to handle rolling upgrade. It seems after this patch will be done, I'll port it to branch-2. Hope do that soon. > Load actual META table descriptor, don't use statically defined one. > > > Key: HBASE-13147 > URL: https://issues.apache.org/jira/browse/HBASE-13147 > Project: HBase > Issue Type: Bug > Components: master, regionserver >Affects Versions: 2.0.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Attachments: HBASE-13147-branch-1.patch, > HBASE-13147-branch-1.v2.patch, HBASE-13147.patch, HBASE-13147.v2.patch, > HBASE-13147.v3.patch, HBASE-13147.v4.patch, HBASE-13147.v4.patch, > HBASE-13147.v5.patch, HBASE-13147.v6.patch > > > In HBASE-13087 stumbled on the fact, that region servers don't see actual > meta descriptor, they use their own, statically compiled. > Need to fix that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12990) MetaScanner should be replaced by MetaTableAccessor
[ https://issues.apache.org/jira/browse/HBASE-12990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14481695#comment-14481695 ] Andrey Stepachev commented on HBASE-12990: -- thanks [~stack], I thought :) that it will be addendum, but there was much more differences that seemed at first glance. > MetaScanner should be replaced by MetaTableAccessor > --- > > Key: HBASE-12990 > URL: https://issues.apache.org/jira/browse/HBASE-12990 > Project: HBase > Issue Type: Improvement > Components: Client >Affects Versions: 2.0.0, 1.1.0 >Reporter: Andrey Stepachev >Assignee: Andrey Stepachev > Fix For: 2.0.0, 1.1.0 > > Attachments: HBASE-12990-branch-1.v1.patch, HBASE-12990.patch, > HBASE-12990.v2.patch, HBASE-12990.v3.patch, HBASE-12990.v4.patch, > HBASE-12990.v5.patch, HBASE-12990.v5.patch, HBASE-12990.v5.patch, > HBASE-12990.v6.patch, HBASE-12990.v7.patch, HBASE-12990.v7.patch, > HBASE-12990.v7.patch, HBASE-12990.v8.patch > > > MetaScanner and MetaTableAccessor do similar things, but seems they tend to > diverge. Let's have only one thing to enquiry META. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
