hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "kulkarni.swarnim@gmail.com" <kulkarni.swar...@gmail.com>
Subject Re: Question about RPC queues
Date Fri, 04 Sep 2015 17:35:36 GMT
> if you receive [scan, get] the get has to wait the scan to complete.

Agreed. And like I mentioned in my original post, this is what I was
expecting too to happen with FIFO but did not see. May be having multiple
handlers in the wait queue was the reason[1] even though I put the num RPC
handlers on the RS down to 1 but not sure.

Also thanks for the explanation on the "deadline" concept. It makes much
more sense now.

[1] http://imgur.com/tUu4y8r

On Fri, Sep 4, 2015 at 12:12 PM, Matteo Bertozzi <theo.bertozzi@gmail.com>

> 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