phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4683) Cap timeouts for stats precompact hook logic
Date Tue, 03 Apr 2018 23:50:00 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16424780#comment-16424780
] 

James Taylor commented on PHOENIX-4683:
---------------------------------------

bq. I don't see the long timeout anymore.
That's good news.

Do you think there are cases where we wouldn't want to use the DelegateHTableFactory? If no,
probably better to not have the boolean in the constructor and just always use it. Also, given
that we're using this DelegateHTableFactory, do you think it makes sense to move IndexWriterUtils.getDefaultDelegateHTableFactory()
to a more general util class like maybe ServerUtil?


> Cap timeouts for stats precompact hook logic
> --------------------------------------------
>
>                 Key: PHOENIX-4683
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4683
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.13.0
>            Reporter: Vincent Poon
>            Assignee: Vincent Poon
>            Priority: Major
>         Attachments: PHOENIX-4683.v1.0.98.patch, PHOENIX-4683.v2.0.98.patch, PHOENIX-4683.v3.0.98.patch,
PHOENIX-4683.v4.0.98.patch
>
>
> In UngroupedAggregateRegionObserver#preCompact we call DefaultStatisticsCollector.createCompactionScanner. 
It uses the env config which in turn contains the RS server rpc timeout of 20 minutes.  That's
too long for a compaction hook.
> Like in PHOENIX-4169, we should cap the timeout so the compaction doesn't get blocked.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message