drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hanifi GUNES <hanifigu...@gmail.com>
Subject Re: [DISCUSS] Nonblocking RPC
Date Wed, 06 Apr 2016 20:15:31 GMT
I would like to see Drill making less use of blocking calls as well.

Inlined:


*- I was thinking of changing acceptExternalEvents to a boolean flag, and
if not ready, resubmit cancellation and early termination requests as is to
the executor, and not a two phase event. Wouldn't this be sufficient?*

This would eliminate blocking calls but then you will spin CPU for no real
progress. The abstraction we are looking for here is an event driven
serialized executor akin to Guava's ListenableFuture with additional
guarantees on callback execution order(not sure ListenableFuture guarantees
that).


-Hanifi


2016-04-04 21:57 GMT-07:00 Sudheesh Katkam <skatkam@maprtech.com>:

> Yes, resubmit to the serialized executor (RpcEventHandler). I wasn’t
> thinking of changing the channel pipeline, if this is what you mean by
> breaking the encapsulation model.
>
> Maybe handlers can get to this executor through a context object. Right
> now, this will not work with the SameExecutor (stack overflow).
>
> I was thinking of changing acceptExternalEvents to a boolean flag, and if
> not ready, resubmit cancellation and early termination requests as is to
> the executor, and not a two phase event. Wouldn't this be sufficient?
>
> Thank you,
> Sudheesh
>
> P.S. I hope to cleanup and document RPC related code on the way.
>
> > On Apr 1, 2016, at 3:21 PM, Jacques Nadeau <jacques@dremio.com> wrote:
> >
> > I think you're going to really have to break the encapsulation model to
> > accomplish this in the RPC layer.  What about updating the serialized
> > executor for those situations to do a resubmission rather than blocking
> > operation? Basically, it seems like we want a two phase termination:
> > request termination and then confirm termination. It seems like both
> should
> > be non-blocking....
> >
> > The other option is to rethink the model around termination. It might be
> > worth a hangout brainstorm to see if we can come up with ideas that are
> > more outside of the box.
> >
> >
> >
> > --
> > Jacques Nadeau
> > CTO and Co-Founder, Dremio
> >
> > On Fri, Apr 1, 2016 at 2:28 PM, Sudheesh Katkam <sudheesh@apache.org>
> wrote:
> >
> >> Hey y’all,
> >>
> >> There are some blocking requests that could make an event loop *await
> >> uninterruptibly*. At this point, the Drillbit might seem unresponsive.
> This
> >> is worsened if the the event loop is not unblocked (due to a bug), which
> >> requires a Drillbit restart. Although Drill supports *offloading from
> the
> >> event loop* (experimental), this is not sufficient as the thread
> handling
> >> the queue of requests would still block.
> >>
> >> AFAIK there are two such requests:
> >> + when the user cancels
> >> <
> >>
> https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/work/foreman/Foreman.java#L1184
> >>>
> >> the query during planning
> >> + a fragment is canceled
> >> <
> >>
> https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/work/fragment/FragmentExecutor.java#L150
> >>>
> >> or terminated
> >> <
> >>
> https://github.com/apache/drill/blob/master/exec/java-exec/src/main/java/org/apache/drill/exec/work/fragment/FragmentExecutor.java#L501
> >>>
> >> early during setup
> >>
> >> I think a simple solution would be to *re-queue *such requests
> (possible in
> >> above cases). That way other requests get their chance, and all requests
> >> would be eventually handled. Thoughts?
> >>
> >> Thank you,
> >> Sudheesh
> >>
>
>

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