spark-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Rosen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SPARK-2321) Design a proper progress reporting & event listener API
Date Tue, 07 Oct 2014 21:51:33 GMT

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

Josh Rosen commented on SPARK-2321:
-----------------------------------

I've opened a WIP pull request in order to discuss the design / implementation of a pull-based
progress / status API: https://github.com/apache/spark/pull/2696.  I'd like to focus on discussing
the most high-level interface / API design decisions now; once we're happy with those decisions,
we can focus on the details of which pieces of data to expose, etc.

> Design a proper progress reporting & event listener API
> -------------------------------------------------------
>
>                 Key: SPARK-2321
>                 URL: https://issues.apache.org/jira/browse/SPARK-2321
>             Project: Spark
>          Issue Type: Improvement
>          Components: Java API, Spark Core
>    Affects Versions: 1.0.0
>            Reporter: Reynold Xin
>            Assignee: Josh Rosen
>            Priority: Critical
>
> This is a ticket to track progress on redesigning the SparkListener and JobProgressListener
API.
> There are multiple problems with the current design, including:
> 0. I'm not sure if the API is usable in Java (there are at least some enums we used in
Scala and a bunch of case classes that might complicate things).
> 1. The whole API is marked as DeveloperApi, because we haven't paid a lot of attention
to it yet. Something as important as progress reporting deserves a more stable API.
> 2. There is no easy way to connect jobs with stages. Similarly, there is no easy way
to connect job groups with jobs / stages.
> 3. JobProgressListener itself has no encapsulation at all. States can be arbitrarily
mutated by external programs. Variable names are sort of randomly decided and inconsistent.

> We should just revisit these and propose a new, concrete design. 



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

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@spark.apache.org
For additional commands, e-mail: issues-help@spark.apache.org


Mime
View raw message