Github user JamesRTaylor commented on the pull request:
https://github.com/apache/phoenix/pull/49#issuecomment-83363422
Somewhere in Indexer surrounding the point at which a batch of mutations is
send over the wire, maybe in doPostWithExceptions, we should call
IndexQosCompat.addIndexQosForTable(tableName, batchUUID) which would create a
key out of tableName together with batchUUID and add it to the concurrent map.
Then, when the batch has been sent, it'd call
IndexQosCompat.removeIndexQosForTable(tableName, batchUUID), constructing the
same key to remove it from the map. The IndexQosRpcControllerFactory would do a
get on the concurrent map using only a key with only the tableName (that
matches any batchUUID) in order to know it should use the special queue. That
way, the map still gets cleaned up, but works when many different callers are
writing index updates at the same time (as the tableName + batch UUID would
always be unique). This also avoids the corner case of an index being dropped
and subsequently a table being created with the same name. The current Config
based approach would find that
table name for the table and use the high priority queue.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
