You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@tez.apache.org by "Siddharth Seth (JIRA)" <ji...@apache.org> on 2014/10/28 07:00:44 UTC

[jira] [Commented] (TEZ-1712) SSL context gets destroyed too soon after downloading data from one of the vertices

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

Siddharth Seth commented on TEZ-1712:
-------------------------------------

What impact does not shutting down the ssl connection have in terms of container re-use. Is there a possibility that we'll end up trying to use ssl for subsequent DAGs which may not be configured to use it ? This assumes the ShuffleHandler in YARN/MapReduce can operate in dual mode.
If that's the case, we may end up needing some kind of ref-counting on Inputs using ssl. Alternately at least tracking ssl being enabled per input - rather than relying on sslFactory being non-null to determine whether a specific connection should be established with or without ssl.

The code currently assumes that all Inputs for a task will either use SSL, or not. That seems fair at the moment anyway.

> SSL context gets destroyed too soon after downloading data from one of the vertices
> -----------------------------------------------------------------------------------
>
>                 Key: TEZ-1712
>                 URL: https://issues.apache.org/jira/browse/TEZ-1712
>             Project: Apache Tez
>          Issue Type: Bug
>            Reporter: Rajesh Balamohan
>            Assignee: Rajesh Balamohan
>         Attachments: TEZ-1712.1.patch, tez_1712_syslog_attempt_1414454836629_0004_1_05_000001_0.txt
>
>
> In scenarios where a vertex has to download shuffle data from multiple sources, sslContext gets destroyed soon after data is downloaded from one of the vertex.  This causes SSL handshake exception when data needs to be downloaded from other vertices and fetchers to fail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)