Uh oh!
There was an error while loading. Please reload this page.
SPARK-1187, Added missing Python APIs - #75
Closed
prabinB wants to merge 1 commit into
Closed
Conversation
AmplabJenkins
commented
Mar 4, 2014
Can one of the admins verify this patch? |
mateiz
commented
Mar 5, 2014
Contributor
Jenkins, this is ok to test |
AmplabJenkins
commented
Mar 5, 2014
Merged build triggered. |
AmplabJenkins
commented
Mar 5, 2014
Merged build started. |
AmplabJenkins
commented
Mar 5, 2014
Merged build finished. |
AmplabJenkins
commented
Mar 5, 2014
All automated tests passed. |
pwendell
commented
Mar 6, 2014
Contributor
I played around with these and it looks good to me. Thanks! |
jhartlaub referenced
this pull request
in jhartlaub/spark
May 27, 2014
Code de-duplication in BlockManager The BlockManager has a few methods that duplicate most of their code. This pull request extracts the duplicated code into private doPut(), doGetLocal(), and doGetRemote() methods that unify the storing/reading of bytes or objects. I believe that I preserved the logic of the original code, but I'd appreciate some help in reviewing this. (cherry picked from commit edc5e3f) Signed-off-by: Aaron Davidson <aaron@databricks.com> Conflicts: core/src/main/scala/org/apache/spark/storage/BlockManager.scala
jhartlaub referenced
this pull request
in jhartlaub/spark
May 27, 2014
Manually merge BlockManager refactor alteryx#75 PR alteryx#75 was unfortunately not cherry-picked into 0.8.0, which caused a build breakage earlier and now again due to later changes being cherry-picked. This merges alteryx#75 and replays alteryx#139 on top of it. I have confirmed that alteryx#75 has made exactly the changes it did on master. So long as all BlockManager patches from master should have gone into branch-0.8, this PR should do the right thing.
JasonMWhite pushed a commit
to JasonMWhite/spark
that referenced
this pull request
Dec 2, 2015
Update spark to 2015-09-04
lins05 pushed a commit
to lins05/spark
that referenced
this pull request
Feb 9, 2017
* Use readiness probe instead of client-side ping. Keep one ping() just as a sanity check, but otherwise set up the readiness probe to report the container as ready only when the ping endpoint can be reached. Also add a liveliness probe for convenience and symmetry. * Extract common HTTP get action * Remove some code * Add delay to liveliness check * Fix merge conflicts. * Fix more merge conflicts * Fix more merge conflicts * Revamp readiness check logic * Add addresses ready condition to endpoints watch * Rearrange the logic some more. * Remove liveness probe, retry against servers * Fix compiler error * Fix another compiler error * Delay between retries. Remove unintended test modification * FIx another compiler error * Extract method * Address comments * Deduplicate node addresses, use lower initial connect timeout * Drop maxRetriesPerServer from 10 to 3
lins05 pushed a commit
to lins05/spark
that referenced
this pull request
Apr 23, 2017
* Use readiness probe instead of client-side ping. Keep one ping() just as a sanity check, but otherwise set up the readiness probe to report the container as ready only when the ping endpoint can be reached. Also add a liveliness probe for convenience and symmetry. * Extract common HTTP get action * Remove some code * Add delay to liveliness check * Fix merge conflicts. * Fix more merge conflicts * Fix more merge conflicts * Revamp readiness check logic * Add addresses ready condition to endpoints watch * Rearrange the logic some more. * Remove liveness probe, retry against servers * Fix compiler error * Fix another compiler error * Delay between retries. Remove unintended test modification * FIx another compiler error * Extract method * Address comments * Deduplicate node addresses, use lower initial connect timeout * Drop maxRetriesPerServer from 10 to 3
erikerlandson pushed a commit
to erikerlandson/spark
that referenced
this pull request
Jul 28, 2017
* Use readiness probe instead of client-side ping. Keep one ping() just as a sanity check, but otherwise set up the readiness probe to report the container as ready only when the ping endpoint can be reached. Also add a liveliness probe for convenience and symmetry. * Extract common HTTP get action * Remove some code * Add delay to liveliness check * Fix merge conflicts. * Fix more merge conflicts * Fix more merge conflicts * Revamp readiness check logic * Add addresses ready condition to endpoints watch * Rearrange the logic some more. * Remove liveness probe, retry against servers * Fix compiler error * Fix another compiler error * Delay between retries. Remove unintended test modification * FIx another compiler error * Extract method * Address comments * Deduplicate node addresses, use lower initial connect timeout * Drop maxRetriesPerServer from 10 to 3
jamesrgrinter pushed a commit
to jamesrgrinter/spark
that referenced
this pull request
Apr 22, 2018
Signed-off-by: Rostyslav Sotnychenko <rsotnychenko@maprtech.com> (cherry picked from commit fc17f1a)
Igosuki pushed a commit
to Adikteev/spark
that referenced
this pull request
Jul 31, 2018
Make sure LIBPROCESS_IP is defined before setting SPARK_LOCAL_IP to it.
ashangit added a commit
to ashangit/spark
that referenced
this pull request
Dec 11, 2018
[SPARK-18838][CORE] Add separate listener queues to LiveListenerBus.
bzhaoopenstack pushed a commit
to bzhaoopenstack/spark
that referenced
this pull request
Sep 11, 2019
Without this config, the test result will succeed even if it actually has failed test cases.
arjunshroff pushed a commit
to arjunshroff/spark
that referenced
this pull request
Nov 24, 2020
MaxGekk added a commit
to MaxGekk/spark
that referenced
this pull request
Sep 2, 2026
### What changes were proposed in this pull request? A plan only, no code: `sql/varka/plans/PLAN_TASK_45.md`, plus a pointer from `PLAN_MILESTONE_4.md`'s task-45 row. Task 32's no-validity ceiling variant priced the validity write at 55.6-56.7% of a four-field calendar kernel's time (`PLAN_TASK_32.md` 7.2, finding 2). Reading the emitter for this plan found that the dense path pays it too, despite the class doc saying the dense side "runs with no validity bookkeeping at all": `emitLaneGroup` ends every value output, dense or masked, with an `orValidityBitsAt(seg, i, -1L, lanes)` call - a non-inlining helper (task 32's `-XX:+PrintInlining` evidence) doing a bounds check, a four-arm switch and a read-modify-write once per lane group per output, to OR all-ones into a bitmap the driver zeroed a moment earlier. On the dense path every value output is valid on every row before the loop starts. The plan: a `VarkaVectorSupport.setValid(seg, rows)` helper that sets exactly `rows` bits (not a whole-byte fill - the suite compares dense and masked validity byte for byte, and bit-exactness with today's output is what lets the existing matrix be the oracle); the dense driver calling it instead of `zero()` for every value output, with `Cond` roots keeping `zero()` + OR since their slot is the selection bitmap; and the dense loop and epilogue dropping the per-group OR. All behind a `denseValidityOnce` emit option so the two variants are compared bit for bit and priced as an A/B in one run. The masked path is untouched and asserted so by `codeSize`. Measurement uses existing parity rows only, each with a required direction (`year, null-free` and the shared four-field null-free row must rise; every mixed-null row and the task-17 budget rows must not move; the chunk-63/64 rows guard the fill's per-batch cost), at both widths, plus `PrintInlining` confirming no call site remains in `loopDense0`. Eight predictions registered, including a larger gain at 128-bit and one for task 32 B2 to score. Two commits: mechanism default-off, then measurement and the default flip. One risk the plan flags for later work rather than solving: the fill rests on task 11's "valid in, valid out" invariant, so a future node that can null a valid input (task 30's `try_*`) cannot use the dense body as it stands; the guard belongs with that node. ### Why are the changes needed? It is the largest measured cost in the milestone, it applies to every kernel that writes a null-free output rather than to the calendar family, and the fix is one helper and three emitter sites. Writing it down first is the project's standing practice, and this one has a precise correctness contract (bit-exact with today's dense output) that is easier to state before the code than to reverse-engineer after. ### Does this PR introduce _any_ user-facing change? No. Documentation only. ### How was this patch tested? Not applicable - plan files only. ASCII checked; prose width matches the sibling plan files. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Fable 5.1)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The following Python APIs are added,
RDD.id()
SparkContext.setJobGroup()
SparkContext.setLocalProperty()
SparkContext.getLocalProperty()
SparkContext.sparkUser()
was raised earlier as a part of apache/incubator-spark#486