Skip to content

Conversation

@cenyuhai
Copy link
Contributor

What changes were proposed in this pull request?

Task are sorted by "Index" in Stage Page, but user are always concerned about tasks which are failed(see error messages) or still running (maybe it is skewed). When there are too many tasks, it is too slow to sort. So it is better to set the default sort column to ”Status“.

@SparkQA
Copy link

SparkQA commented Aug 21, 2016

Test build #64160 has finished for PR 14739 at commit c1f3c9e.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@srowen
Copy link
Member

srowen commented Aug 21, 2016

I think this has come up before and not been accepted. This happens to have the desired behavior because "FAILED" comes before "RUNNING". It doesn't sort by ID as a secondary key. It's a behavior change and most other things in Spark and elsewhere sort by ID. It's easy to sort by status.

@cenyuhai
Copy link
Contributor Author

cenyuhai commented Aug 21, 2016

@srowen YES, "FAILED" will come before "RUNNING".That is what I want, because we want to know why task will fail more than the need to sort by ID, "Errors" are more import than the informations of the runnning tasks, because if there are too many failed tasks, there must be something wrong with the application.
ID is just a unique identifier for task, in the most cases, we don't care about it.But we will care about why tasks will fail, why tasks are running such a long time.
When there are too many tasks, it is not easy to sort by status, it is very slow.

@srowen
Copy link
Member

srowen commented Aug 23, 2016

I can see that argument, but it would be consistent with other parts of Spark and other UIs. If for some reason we had a new state that sorted before "FAILED" this wouldn't work. Users can easily sort tasks too.

@cenyuhai
Copy link
Contributor Author

cenyuhai commented Aug 23, 2016

@srowen can we make it an option, default by "Index", users can choose "Status" or anything else?
Now the pagination is by jquery datatable, not by server side. When tasks are more than 10,000, It will start to become slower. If not happened in production environment, I would not have opened this PR, users advised me to sort by status.

@jiangxb1987
Copy link
Contributor

@srowen should we close this?

@srowen srowen mentioned this pull request Jun 25, 2017
@gatorsmile
Copy link
Member

Really appreciate your contribution! Sorry, based on the comment, we might need to close this PR, but please submit more PRs in the future. Thanks again!

@asfgit asfgit closed this in b32bd00 Jun 27, 2017
zifeif2 pushed a commit to zifeif2/spark that referenced this pull request Nov 22, 2025
## What changes were proposed in this pull request?

This PR proposes to close stale PRs, mostly the same instances with apache#18017

I believe the author in apache#14807 removed his account.

Closes apache#7075
Closes apache#8927
Closes apache#9202
Closes apache#9366
Closes apache#10861
Closes apache#11420
Closes apache#12356
Closes apache#13028
Closes apache#13506
Closes apache#14191
Closes apache#14198
Closes apache#14330
Closes apache#14807
Closes apache#15839
Closes apache#16225
Closes apache#16685
Closes apache#16692
Closes apache#16995
Closes apache#17181
Closes apache#17211
Closes apache#17235
Closes apache#17237
Closes apache#17248
Closes apache#17341
Closes apache#17708
Closes apache#17716
Closes apache#17721
Closes apache#17937

Added:
Closes apache#14739
Closes apache#17139
Closes apache#17445
Closes apache#18042
Closes apache#18359

Added:
Closes apache#16450
Closes apache#16525
Closes apache#17738

Added:
Closes apache#16458
Closes apache#16508
Closes apache#17714

Added:
Closes apache#17830
Closes apache#14742

## How was this patch tested?

N/A

Author: hyukjinkwon <[email protected]>

Closes apache#18417 from HyukjinKwon/close-stale-pr.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants