[
https://issues.apache.org/jira/browse/PHOENIX-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056805#comment-14056805
]
Andrew Purtell commented on PHOENIX-938:
----------------------------------------
bq. Really, this stems from the RpcScheduler code being a private interface in
HBase but wanting to leverage it outside HBase.
What we did with HBASE-11355 is admit additional interfaces that can give some
in the HBase community flexibility to experiment with RPC improvements without
needing to modify core beyond that change. I think the same applies to Phoenix.
You are right that these are currently private interfaces, so dislocations like
you are experiencing from .3 to .4 can happen and might happen again, however
by all means we could have a discussion over on dev@hbase on promoting these
RPC interfaces to Public+Evolving so you have a stable leg to stand on.
> 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-4.0-v0.patch, phoenix-938-master-v0.patch,
> phoenix-938-master-v1.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)
