Mailing-List: contact issues-help@hive.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hive.apache.org
Date: Tue, 14 Feb 2017 19:52:41 +0000 (UTC)
From: "Xuefu Zhang (JIRA)" <jira@apache.org>
To: issues@hive.apache.org
Message-ID: <JIRA.13042651.1487013613000.79340.1487101961672@Atlassian.JIRA>
In-Reply-To: <JIRA.13042651.1487013613000@Atlassian.JIRA>
References: <JIRA.13042651.1487013613000@Atlassian.JIRA> <JIRA.13042651.1487013613526@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HIVE-15893) Followup on HIVE-15671
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 14 Feb 2017 19:52:46 -0000


    [ https://issues.apache.org/jira/browse/HIVE-15893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15866506#comment-15866506 ] 

Xuefu Zhang commented on HIVE-15893:
------------------------------------

[~lirui], I didn't mean HIVE-15860 will provide a solution that solves the problem described here, which is about detecting issues in the driver. I was saying that with the job monitoring thread monitor jobs submitted to the driver and the fix here, maybe the problem is mitigated or avoided. If this is true, then we might not need the proposal here. This needs further investigation though.

> Followup on HIVE-15671
> ----------------------
>
>                 Key: HIVE-15893
>                 URL: https://issues.apache.org/jira/browse/HIVE-15893
>             Project: Hive
>          Issue Type: Improvement
>          Components: Spark
>    Affects Versions: 2.2.0
>            Reporter: Xuefu Zhang
>            Assignee: Xuefu Zhang
>
> In HIVE-15671, we fixed a type where server.connect.timeout is used in the place of client.connect.timeout. This might solve some potential problems, but the original problem reported in HIVE-15671 might still exist. (Not sure if HIVE-15860 helps). Here is the proposal suggested by Marcelo:
> {quote}
> bq: server detecting a driver problem after it has connected back to the server.
> Hmm. That is definitely not any of the "connect" timeouts, which probably means it isn't configured and is just using netty's default (which is probably no timeout?). Would probably need something using io.netty.handler.timeout.IdleStateHandler, and also some periodic "ping" so that the connection isn't torn down without reason.
> {quote}
> We will use this JIRA to track the issue.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)