You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tez.apache.org by "Mustafa İman (Jira)" <ji...@apache.org> on 2020/11/25 00:31:00 UTC
[jira] [Created] (TEZ-4253) Revert TEZ-4170
Mustafa İman created TEZ-4253:
---------------------------------
Summary: Revert TEZ-4170
Key: TEZ-4253
URL: https://issues.apache.org/jira/browse/TEZ-4253
Project: Apache Tez
Issue Type: Bug
Reporter: Mustafa İman
Assignee: Mustafa İman
There are two performance improvements in https://issues.apache.org/jira/browse/TEZ-4170
# Move construction of InputInitializers to background thread
# Remove RootInputInitializerManager's thread pool and move all threads using this executor to DagAppMaster's thread pool.
Item 1: This is an incorrect optimization which may cause data races in VertexImpl regarding handling of events. This was mitigated in https://issues.apache.org/jira/browse/TEZ-4204 however the solution basically reverts back the initial optimization only with a more complicated approach. Apart from these, it unnecessarily complicates Tez application master. The scenario where this is useful is when a custom InputInitializer constructor contains a lot of heavyweight operations. However, the solution to this problem belongs to client application. Client application can easily move heavyweight operations to InputInitializer#initialize method.
Item 2: The benefit of this is doubtful. Supposedly a root input initializer is offloaded to a cached thread in appcontext instead of creating a new one in RootInputInitializerManager. The number of threads of this pool is limited. When many root input initializer depends on InputInitializerEvents all threads may get blocked. In that case the rest of the vertices (which are supposed to send the InputInitializerEvents) cannot run. So we run into a deadlock.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)