hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matteo Bertozzi <theo.berto...@gmail.com>
Subject Re: Question about RPC queues
Date Fri, 04 Sep 2015 17:12:37 GMT
On Fri, Sep 4, 2015 at 10:03 AM, kulkarni.swarnim@gmail.com <
kulkarni.swarnim@gmail.com> wrote:

> Ah ok. So if I understand you right, irrespective of which queue type I
> use, if a get comes when a chunk is being processed, it is going to wait.

assuming no other threads (handlers) are available, yes.
we don't have the ability to eject in-progress requests.

> > what fifo vs deadline does is pushing the scan chunk back in the queue if
> you have multiple operation with higher priority.
> So, if I set the queue type to FIFO, the scans shouldn't get pushed back
> correct? Wouldn't this mean that a "get" would be after a scan in the queue
> if the scan was submitted before? Or is it still possible in this case for
> the handler to switch between the scan chunks, quickly execute the "get"
> and then get back to execute the rest of the chunks?

using fifo, the requests are executed in the other the server receives them.
assuming 1 thread (handler). if you receive [scan, get] the get has to wait
the scan to complete.
if you receive [get, scan] the scan has to wait the get to complete.
currently, there is no way to interrupt the operation being executed and
execute the one with higher priority.

deadline does this thing:
let say you have 1 thread, and that you are executing one operation.
a scan comes in, and then a get comes in.
the other operation is not completed yet. so your request order looks like
[scan, get]
the deadline queue reorders the operations as [get, scan] if the scan
should be pushed back.
but this reorder happens before execution. they are still in the queue when
they are reordered.
for now, once one operation is in execution there is no way to switch to
another with higher-priority.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message