spark-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Rosen (JIRA)" <>
Subject [jira] [Commented] (SPARK-2321) Design a proper progress reporting & event listener API
Date Mon, 22 Sep 2014 17:03:33 GMT


Josh Rosen commented on SPARK-2321:

... maybe we should redesign the SparkListener event API, and add job id info into Stage/Task
event in Scheduler before post it to listener bus.

A stage may be used by multiple jobs, so we'd have to think carefully about how the API should
reflect this.  It looks like DAGScheduler's internal {{Stage}} class tracks the id of the
job that first submitted the stage, and {{activeJobForStage}} finds "the earliest-created
active job that needs the stage."  It might make sense to associate Stage/Task start events
with the list of active jobs that depend on them.

> Design a proper progress reporting & event listener API
> -------------------------------------------------------
>                 Key: SPARK-2321
>                 URL:
>             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
> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message