Mailing-List: contact reviews-help@impala.incubator.apache.org; run by ezmlm
Precedence: bulk
Message-Id: <201709052220.v85MKvPT032663@ip-10-146-233-104.ec2.internal>
Date: Tue, 5 Sep 2017 22:20:57 +0000
From: "Joe McDonnell (Code Review)" <gerrit@cloudera.org>
To: impala-cr@cloudera.com, reviews@impala.incubator.apache.org
CC: Dan Hecht <dhecht@cloudera.com>, Tim Armstrong <tarmstrong@cloudera.com>,
        Sailesh Mukil <sailesh@cloudera.com>
Reply-To: joemcdonnell@cloudera.com
Subject: =?UTF-8?Q?=5BImpala-ASF-CR=5D_IMPALA-5750=3A_Catch_exceptions_from_boost_thread_creation=0A?=
In-Reply-To: <gerrit.1503094817000.I15a2f278dc71892b7fec09593f81b1a57ab725c0@gerrit.cloudera.org>
References: <gerrit.1503094817000.I15a2f278dc71892b7fec09593f81b1a57ab725c0@gerrit.cloudera.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
User-Agent: Gerrit/2.12.7
archived-at: Tue, 05 Sep 2017 22:21:06 -0000

Joe McDonnell has posted comments on this change.

Change subject: IMPALA-5750: Catch exceptions from boost thread creation
......................................................................


Patch Set 8:

(5 comments)

http://gerrit.cloudera.org:8080/#/c/7730/8/be/src/runtime/query-state.cc
File be/src/runtime/query-state.cc:

Line 226:     if (fis->IsPrepared()) {
> should this check that the prepare status is ok? if Prepare() failed, then 
The first thing that Prepare() does is allocate the RuntimeState. It has a comment saying not to return before that. See https://github.com/apache/incubator-impala/blob/master/be/src/runtime/fragment-instance-state.cc#L119
We also check whether fis->profile() is null. So, I think this should be safe.

When IMPALA-5892 goes in, I will just use fis==nullptr. That will make this part of the change unnecessary, as nothing needs to send status for an unprepared fragment instance.


Line 328:       ExecEnv::GetInstance()->query_exec_mgr()->ReleaseQueryState(this);
> this is a little weird since ReleaseQueryState() can delete this. Except it
Added a comment.


PS8, Line 332: true
> passing instances_started=true can lead to a deadlock if the RPC send fails
Good point, changed this to instances_started=false. If the RPC to the coordinator fails, I think there are other ways to hang, but this is clearly wrong. I'll think about whether there is a better way to handle this case.


PS8, Line 336: update fis_map_
> nit: seems excessive
Done


http://gerrit.cloudera.org:8080/#/c/7730/8/be/src/runtime/thread-resource-mgr.h
File be/src/runtime/thread-resource-mgr.h:

Line 288:   if (!in_callback) InvokeCallbacks();
> As we discussed in person, I don't think it's safe even in that case genera
I went with option #1. I added a comment with a warning to thread-resource-mgr.h and noted why we were using skip_callbacks in kudu-scan-node.cc and hdfs-scan-node.cc.


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

Gerrit-MessageType: comment
Gerrit-Change-Id: I15a2f278dc71892b7fec09593f81b1a57ab725c0
Gerrit-PatchSet: 8
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-Owner: Joe McDonnell <joemcdonnell@cloudera.com>
Gerrit-Reviewer: Dan Hecht <dhecht@cloudera.com>
Gerrit-Reviewer: Joe McDonnell <joemcdonnell@cloudera.com>
Gerrit-Reviewer: Sailesh Mukil <sailesh@cloudera.com>
Gerrit-Reviewer: Tim Armstrong <tarmstrong@cloudera.com>
Gerrit-HasComments: Yes