[
https://issues.apache.org/jira/browse/PHOENIX-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14058546#comment-14058546
]
James Taylor commented on PHOENIX-938:
--------------------------------------
[~jesse_yates] - wrt transactions, the plumbing for secondary indexing won't
change (except for the writing-index-updates-to-WAL bit). The transaction ID
would be propagated to Puts for the index updates (cross RS or not) to prevent
the possibility of getting into an inconsistent state. So we'd still have the
potential for a deadlock if this isn't fixed. Otherwise, all the work your
doing to handle out-of-order updates would have to be done on the client
instead of the RS which would require raw scans and returning a bunch of extra
data to the client.
> 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, 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)
