You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@phoenix.apache.org by "Geoffrey Jacoby (Jira)" <ji...@apache.org> on 2019/10/10 20:36:00 UTC
[jira] [Commented] (PHOENIX-5514) Index read repair should use
index rpc handlers
[ https://issues.apache.org/jira/browse/PHOENIX-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16948932#comment-16948932 ]
Geoffrey Jacoby commented on PHOENIX-5514:
------------------------------------------
+1 assuming tests pass.
> Index read repair should use index rpc handlers
> -----------------------------------------------
>
> Key: PHOENIX-5514
> URL: https://issues.apache.org/jira/browse/PHOENIX-5514
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 4.14.3
> Reporter: Geoffrey Jacoby
> Assignee: Gokcen Iskender
> Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-5514.master.001.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Consider base tables T1 and T2, each of which has a global mutable index, call them IDX1 and IDX2.
> RegionServer A hosts a T1 region and an IDX2 region.
> RegionServer B hosts a T2 region and an IDX1 region.
>
> Because of prior problems, both IDX1 and IDX2 have lots of unverified rows. Both are under heavy read-load from clients.
>
> IDX1 coprocs try to scan the T1 region on RS A, but can't because the standard RPC queue is full on RS A because of all the IDX2 clients waiting on cross-server read repairs.
> IDX2 coprocs try to scan the T2 region on RS B, but can't because the standard RPC queue is full on RS B because of the IDX1 clients waiting on cross-server read repairs .
>
> It's not a permanent deadlock (eventually we'll start throwing RegionTooBusyExceptions), but it would be unpleasant for clients.
>
> If read-repair used the index RPC pool instead of the standard one, this scenario couldn't happen (unless there were _also_ too many mutable index writes, in which case we're just saturated and back to lots of exceptions.)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)