impala-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sailesh Mukil (Code Review)" <ger...@cloudera.org>
Subject [Impala-ASF-CR] IMPALA-5198: Error messages are sometimes dropped before reaching client
Date Tue, 18 Apr 2017 19:53:19 GMT
Sailesh Mukil has posted comments on this change.

Change subject: IMPALA-5198: Error messages are sometimes dropped before reaching client
......................................................................


Patch Set 5:

> > > > > (1 comment)
 > > >
 > > > > We have an error_log, which is different from error messages,
 > > > which
 > > > > is different from error details. There is a lot of overlap
 > > > between
 > > > > these which results in quite some confusion.
 > > > >
 > > > > The error_log is populated when we call LogError(). The error
 > > > > message is the error associated with a status error. The
 > error
 > > > > details are extra error messages that we attach to a status.
 > > > >
 > > >
 > > > Note that the error_log is really more like a warning log. i.e.
 > > > these "errors" don't necessarily cause query execution to
 > abort.
 > > >
 > > That's not always the case. In some places we add actual errors
 > to
 > > the error_log like here:
 > > https://github.com/apache/incubator-impala/blob/master/be/src/runtime/plan-fragment-executor.cc#L343
 > >
 > 
 > Right, but we should always bubble up those kinds of errors as
 > well.  The point is that the converse is not true -- i.e. an error
 > does not necessarily show up in the error log.


Yes, that's true.


 > 
 > > > > Cumulatively, all tests together end up relying on all 3 of
 > > these
 > > > > being returned. Before this patch, the error_log was never
 > > being
 > > > > printed, but due to the overlap with the error message from
 > the
 > > > > status, all the tests passed. Now, that we print the
 > error_log
 > > > with
 > > > > this patch, a lot of errors get printed twice, which looks
 > > ugly.
 > > > >
 > > >
 > > > Where does this patch cause the error log to be printed? And
 > what
 > > > do you mean by "printed"?
 > > >
 > > Printed meaning, returned to the client, so it prints on the
 > > client's end (impala-shell)
 > 
 > The main error status should be returned via GetOperationStatus(),
 > not the error log.
 > 
 > >
 > > > Also, concerning the original issue, in what cases are error
 > > > message being dropped?
 > >
 > > When we unpack messages from the TStatus object into a Status
 > > object, we don't copy the original ErrorMsg::message_ back to the
 > > new message_, instead we put everything in details_ causing the
 > > message not to be printed (returned to the client), because
 > > GetErrorLog() only looks at ErrorMsg::message_ and not details_.
 > 
 > But GetOperationStatus() includes both, right?
 > 
 > So, I guess what you're saying is that the error_log can drop some
 > messages? But those messages should travel back to the coordinator
 > as part of the error_log in TReportExecStatusParams.  The one that
 > gets returned as a TStatus should end up as *the* query status
 > (i.e. GetOperationStatus()).  (And only because Beeswax doesn't
 > really have this, I think we overload get_log() to include the
 > ultimate query_status()).


Yes, that's right. Also, since the query status and the error_log can have redundant information,
I added some code to merge them so that it doesn't get printed twice.

-- 
To view, visit http://gerrit.cloudera.org:8080/6627
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I5d9d63610eb0d2acae3a9303ce46e1410727ce87
Gerrit-PatchSet: 5
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: Sailesh Mukil <sailesh@cloudera.com>
Gerrit-Reviewer: Dan Hecht <dhecht@cloudera.com>
Gerrit-Reviewer: Matthew Jacobs <mj@cloudera.com>
Gerrit-Reviewer: Sailesh Mukil <sailesh@cloudera.com>
Gerrit-Reviewer: Tim Armstrong <tarmstrong@cloudera.com>
Gerrit-HasComments: No

Mime
View raw message