Skip to content

Conversation

@njwhite
Copy link

@njwhite njwhite commented Apr 22, 2016

What changes were proposed in this pull request?

Store the serializer that we should use to serialize RDD transformation
functions on the SparkContext, defaulting to a CloudPickleSerializer if not
given. Allow a user to change this serializer when first constructing the
SparkContext.

How was this patch tested?

Unit tests and manual integration tests.

Store the serializer that we should use to serialize RDD transformation
functions on the SparkContext, defaulting to a CloudPickleSerializer if not
given. Allow a user to change this serializer when first constructing the
SparkContext.
@AmplabJenkins
Copy link

Can one of the admins verify this patch?

@holdenk
Copy link
Contributor

holdenk commented Apr 25, 2016

Is this functionality we want to add? cc @davies ?

@holdenk
Copy link
Contributor

holdenk commented Apr 25, 2016

If we do end up adding this we would probably want to add a test of using a custom serializer (but maybe don't rush to do this since I think if we want to expose this is maybe not yet clear).

@davies
Copy link
Contributor

davies commented Apr 25, 2016

@njwhite We still use PickleSerializer to deserialize the functions, so it means the serializer MUST be compatible with Pickle, I'm not sure make it configurable will be really helpful (not a good API interface).

If you really want to hack it in your case, I think you could have many ways to hack it in Python.

@njwhite
Copy link
Author

njwhite commented Apr 25, 2016

@davies I'm using this to use the "dill" serializer, as it can pickle more things (and allows more fine-grained control) than the cloud-pickle serializer. What about making that the default for functions?

@davies
Copy link
Contributor

davies commented Apr 25, 2016

Can we support dill directly and have a flag to choose from the two serializer? cloud-pickler could be the default one.

@holdenk
Copy link
Contributor

holdenk commented Oct 7, 2016

I don't see much progress around this - would it maybe make sense to close and just focus on improving cloudpickle (or upgrading our cloudpickle)?

@HyukjinKwon
Copy link
Member

@njwhite It seems inactive for few months. Would this be better to close this for now if you are currently not able to proceed this further?

@asfgit asfgit closed this in ed338f7 Feb 17, 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.

What I mean by "stale" here includes that there are some review comments by reviewers but the author looks inactive without any answer to them more than a month.

I left some comments roughly a week ago to ping and the author looks still inactive in these PR below

These below includes some PR suggested to be closed and a PR against another branch which seems obviously inappropriate.

Given the comments in the last three PRs below, they are probably worth being taken over by anyone who is interested in it.

Closes apache#7963
Closes apache#8374
Closes apache#11192
Closes apache#11374
Closes apache#11692
Closes apache#12243
Closes apache#12583
Closes apache#12620
Closes apache#12675
Closes apache#12697
Closes apache#12800
Closes apache#13715
Closes apache#14266
Closes apache#15053
Closes apache#15159
Closes apache#15209
Closes apache#15264
Closes apache#15267
Closes apache#15871
Closes apache#15861
Closes apache#16319
Closes apache#16324
Closes apache#16890

Closes apache#12398
Closes apache#12933
Closes apache#14517

## How was this patch tested?

N/A

Author: hyukjinkwon <gurwls223@gmail.com>

Closes apache#16937 from HyukjinKwon/stale-prs-close.
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