drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abdel Hakim Deneche <adene...@maprtech.com>
Subject Re: Why DataServer doesn't propagate exceptions back to sender
Date Thu, 07 Jan 2016 19:44:48 GMT
Thanks Jacques,

I just created DRILL-4252 <https://issues.apache.org/jira/browse/DRILL-4252>
to track the change.

On Wed, Jan 6, 2016 at 5:32 PM, Jacques Nadeau <jacques@dremio.com> wrote:

> Agree we should throw a UserRpcException. This used to be the pattern
> everywhere before we added an accommodation to support non-connection
> terminating exceptions. I came to the conclusion that the Ack.Fail pattern
> was actually an anti-pattern since it requires the sender to check the
> nature of the message to determine if it was successful and makes things
> like outcome listeners much more complicated. I thought we fixed this
> everywhere but apparently not.
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Wed, Jan 6, 2016 at 3:57 PM, Abdel Hakim Deneche <adeneche@maprtech.com
> > wrote:
>
>> Looking at DataServer.send() when we hit an IOException or a
>> FragmentSetupException we log the error and return a FAILED acknowledgment
>> to the sender. The query fails and displays a generic "Data not accepted
>> downstream" message instead of the real exception.
>>
>> Is there a specific reason we do it this way ? Why not just throw an
>> exception and let the RPC layer propagate the root cause to the sender ?
>>
>> Thanks
>>
>> --
>>
>> Abdelhakim Deneche
>>
>> Software Engineer
>>
>>   <http://www.mapr.com/>
>>
>>
>> Now Available - Free Hadoop On-Demand Training
>> <http://www.mapr.com/training?utm_source=Email&utm_medium=Signature&utm_campaign=Free%20available>
>>
>
>


-- 

Abdelhakim Deneche

Software Engineer

  <http://www.mapr.com/>


Now Available - Free Hadoop On-Demand Training
<http://www.mapr.com/training?utm_source=Email&utm_medium=Signature&utm_campaign=Free%20available>

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