hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ramkrishna.s.vasudevan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12790) Support fairness across parallelized scans
Date Thu, 16 Apr 2015 06:40:58 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14497628#comment-14497628

ramkrishna.s.vasudevan commented on HBASE-12790:

While running some real time cases using PE tool. I got some NPEs here.  After spending time
in digging what's going on, the reason is because once we complete a call we just cleanUp
the calls.
This datastructure AbstractPriorityRoundRobinQueue holds the CallRunner as the Key and the
same is being used in the ProducerList also. (ie) The CallPriorityComparator is used to construct
the Tree Map which acts as the comparator for the keys in the tree map.  
Now after poll() ing for an element in the queue the RPC Executor nullifies the call.  So
when a new element needs to be added this comaprator throws an NPE because already one of
the calls has been nullified. 
>From the design side, we cannot pass the CallRunner directly for these type of cases because
in case of BoundedPriorityQueue it is only the head that is being returned and the pointer
gets moved away from that element as the head itself changes.  But in data structurs like
TreeMap that is not the case.  Interesting to debug this.

> Support fairness across parallelized scans
> ------------------------------------------
>                 Key: HBASE-12790
>                 URL: https://issues.apache.org/jira/browse/HBASE-12790
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: James Taylor
>            Assignee: ramkrishna.s.vasudevan
>              Labels: Phoenix
>         Attachments: AbstractRoundRobinQueue.java, HBASE-12790.patch, HBASE-12790_1.patch
> Some HBase clients parallelize the execution of a scan to reduce latency in getting back
results. This can lead to starvation with a loaded cluster and interleaved scans, since the
RPC queue will be ordered and processed on a FIFO basis. For example, if there are two clients,
A & B that submit largish scans at the same time. Say each scan is broken down into 100
scans by the client (broken down into equal depth chunks along the row key), and the 100 scans
of client A are queued first, followed immediately by the 100 scans of client B. In this case,
client B will be starved out of getting any results back until the scans for client A complete.
> One solution to this is to use the attached AbstractRoundRobinQueue instead of the standard
FIFO queue. The queue to be used could be (maybe it already is) configurable based on a new
config parameter. Using this queue would require the client to have the same identifier for
all of the 100 parallel scans that represent a single logical scan from the clients point
of view. With this information, the round robin queue would pick off a task from the queue
in a round robin fashion (instead of a strictly FIFO manner) to prevent starvation over interleaved
parallelized scans.

This message was sent by Atlassian JIRA

View raw message