[
https://issues.apache.org/jira/browse/PHOENIX-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14057826#comment-14057826
]
Jesse Yates commented on PHOENIX-938:
-------------------------------------
I think I can do a version that supports 0.98.3./4 - and is backwards
compatible - and then I'll see if we can get those interfaces visible for
future releases. Its a bit a reflection trickery, but should be alright.
bq. I don't think transactions is really going to help with this
They would in that (theoretically) they won't need this mechanism, and we can
do indexing ala transactions, so all this can just go away. But, until then...
this will have to do.
> 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)
