> 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 <[email protected]> wrote: > On Fri, Sep 4, 2015 at 10:03 AM, [email protected] < > [email protected]> 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. > -- Swarnim
