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

Andrew Purtell commented on PHOENIX-938:
----------------------------------------

bq. Current version supports running on both 0.98.3 and .4... I'd like to keep 
that compatibility if we can, but missing the .3 point version isn't the end of 
the world... thoughts?

Would be best to move to the LimitedPrivate interfaces we've set up to avoid 
future issues. Perhaps it would be enough to document the discontinuity at the 
0.98.3 to 0.98.4 transition for Phoenix users? There are 84 issues fixed in .4, 
with 6 more pending, 7 of them blockers. How strongly do you feel about 
supporting 0.98 versions < 4? We could possibly synthesize the index RPC 
controller using ASM to avoid compilation issues and then instantiate it with 
reflection. A fair amount of work there.

> Use higher priority queue for index updates to prevent deadlock
> ---------------------------------------------------------------
>
>                 Key: PHOENIX-938
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-938
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.0.0, 4.1
>            Reporter: James Taylor
>            Assignee: Jesse Yates
>             Fix For: 5.0.0, 4.1
>
>         Attachments: PHOENIX-938-master-v3.patch, phoenix-938-4.0-v0.patch, 
> phoenix-938-master-v0.patch, phoenix-938-master-v1.patch, 
> phoenix-938-master-v2.patch
>
>
> With our current global secondary indexing solution, a batched Put of table 
> data causes a RS to do a batch Put to other RSs. This has the potential to 
> lead to a deadlock if all RS are overloaded and unable to process the pending 
> batched Put. To prevent this, we should use a higher priority queue to submit 
> these Puts so that they're always processed before other Puts. This will 
> prevent the potential for a deadlock under high load. Note that this will 
> likely require some HBase 0.98 code changes and would not be feasible to 
> implement for HBase 0.94.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to