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 <sail...@cloudera.com> Gerrit-Reviewer: Dan Hecht <dhe...@cloudera.com> Gerrit-Reviewer: Matthew Jacobs <m...@cloudera.com> Gerrit-Reviewer: Sailesh Mukil <sail...@cloudera.com> Gerrit-Reviewer: Tim Armstrong <tarmstr...@cloudera.com> Gerrit-HasComments: No
