impala-reviews mailing list archives

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

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


Patch Set 4:

> > > > (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.

 > > > 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()).

-- 
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: 4
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