Skip to content

Conversation

srowen
Copy link
Member

@srowen srowen commented Jan 27, 2015

This change reshuffles the order of initialization in ConnectionManager so that the last thing that happens is running selectorThread, which invokes a method that relies on object state in ConnectionManager

@zsxwing also reported a similar problem in BlockManager in the JIRA, but I can't find a similar pattern there. Maybe it was subsequently fixed?

…g thread in constructor that accesses object's state
@SparkQA
Copy link

SparkQA commented Jan 27, 2015

Test build #26170 has started for PR 4225 at commit c4dec3b.

  • This patch merges cleanly.

@SparkQA
Copy link

SparkQA commented Jan 27, 2015

Test build #26170 has finished for PR 4225 at commit c4dec3b.

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

@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/26170/
Test PASSed.

@pwendell
Copy link
Contributor

@zsxwing - want to take a look at this?

@zsxwing
Copy link
Member

zsxwing commented Jan 28, 2015

LGTM.

@zsxwing also reported a similar problem in BlockManager in the JIRA, but I can't find a similar pattern there. Maybe it was subsequently fixed?

I checked the history. It's already fixed in #3087

@pwendell
Copy link
Contributor

Thanks @srowen and @zsxwing.

@asfgit asfgit closed this in 9b18009 Jan 28, 2015
@srowen srowen deleted the SPARK-1934 branch January 29, 2015 10:44
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