Skip to content

Conversation

@colorant
Copy link
Contributor

@colorant colorant commented Jul 1, 2014

Workaround Hadoop conf ConcurrentModification issue

@AmplabJenkins
Copy link

Merged build triggered.

@AmplabJenkins
Copy link

Merged build started.

@colorant
Copy link
Contributor Author

colorant commented Jul 1, 2014

as described in #1000

@AmplabJenkins
Copy link

Merged build finished. All automated tests passed.

@AmplabJenkins
Copy link

All automated tests passed.
Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/16281/

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we just use "conf" here and on the next line, instead of broadcastedConf.value.value? This is actually the first guy that assumes conf is not null, though, maybe add an assert for that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aarondav , Yes, I also thought about this before. The reason I keep use broadcastedConf.value.value here is because: though broadcast variable is suggested to be read only and not changed, But I wonder maybe in case someone miss use it and change the value, read the latest value might be helpful. And it read the latest code in the next line in the original code, so I keep this style. But think again, if the value did changed in some place without hold any synchronize lock, this might still not be able to solve the problem. I will update the pull request.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

regard conf , it is wrapped in SerializableWritable which enforce it to be a Writable, I think it won't be a null , or exception already been thrown somewhere before here. What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can keep without the check, the NPE should be apparent on the synchronized block.

@AmplabJenkins
Copy link

Merged build triggered.

@AmplabJenkins
Copy link

Merged build started.

@AmplabJenkins
Copy link

Merged build finished. All automated tests passed.

@AmplabJenkins
Copy link

All automated tests passed.
Refer to this link for build results: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/16330/

@aarondav
Copy link
Contributor

aarondav commented Jul 4, 2014

LGTM, merging into master and branch-1.0.

asfgit pushed a commit that referenced this pull request Jul 4, 2014
Workaround Hadoop conf ConcurrentModification issue

Author: Raymond Liu <[email protected]>

Closes #1273 from colorant/hadoopRDD and squashes the following commits:

994e98b [Raymond Liu] Address comments
e2cda3d [Raymond Liu] Workaround Hadoop conf ConcurrentModification issue

(cherry picked from commit 5fa0a05)
Signed-off-by: Aaron Davidson <[email protected]>
@asfgit asfgit closed this in 5fa0a05 Jul 4, 2014
xiliu82 pushed a commit to xiliu82/spark that referenced this pull request Sep 4, 2014
Workaround Hadoop conf ConcurrentModification issue

Author: Raymond Liu <[email protected]>

Closes apache#1273 from colorant/hadoopRDD and squashes the following commits:

994e98b [Raymond Liu] Address comments
e2cda3d [Raymond Liu] Workaround Hadoop conf ConcurrentModification issue
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.

3 participants