phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kadir OZDEMIR (Jira)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-5514) Index read repair should use index rpc handlers
Date Sat, 12 Oct 2019 23:00:00 GMT

     [ https://issues.apache.org/jira/browse/PHOENIX-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kadir OZDEMIR updated PHOENIX-5514:
-----------------------------------
    Attachment: PHOENIX-5514.4.14-HBase-1.3.001.patch

> 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.4.14-HBase-1.3.001.patch, 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)

Mime
View raw message