Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SPARK-25827][CORE] Avoid converting incoming encrypted blocks to byte buffers #22917

Closed
wants to merge 2 commits into from

Conversation

squito
Copy link
Contributor

@squito squito commented Oct 31, 2018

What changes were proposed in this pull request?

Avoid converting encrypted bocks to regular ByteBuffers, to ensure they can be sent over the network for replication & remote reads even when > 2GB.

Also updates some TODOs with links to a SPARK-25905 for improving the
handling here.

How was this patch tested?

Tested on a cluster with encrypted data > 2GB (after SPARK-25904 was
applied as well).

Avoid converting encrypted bocks to regular ByteBuffers.

Also updates some TODOs with links to a SPARK-25905 for improving the
handling here.

Tested on a cluster with encrypted data > 2GB (after SPARK-25904 was
applied as well).
@SparkQA
Copy link

SparkQA commented Oct 31, 2018

Test build #98339 has finished for PR 22917 at commit 5b432e7.

  • This patch fails Scala style tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@vanzin
Copy link
Contributor

vanzin commented Oct 31, 2018

The title seems to describe the problem, can you describe the solution instead?

@squito squito changed the title [SPARK-25827][CORE] Encrypted blocks can be over 2GB. [SPARK-25827][CORE] Encrypted blocks not converted to ByteBuffers for network ops Nov 1, 2018
@vanzin
Copy link
Contributor

vanzin commented Nov 1, 2018

LGTM but the title still doesn't parse for me.

Maybe "Avoid converting incoming encrypted blocks to byte buffers".

@squito squito changed the title [SPARK-25827][CORE] Encrypted blocks not converted to ByteBuffers for network ops [SPARK-25827][CORE] Avoid converting incoming encrypted blocks to byte buffers Nov 1, 2018
@SparkQA
Copy link

SparkQA commented Nov 1, 2018

Test build #98358 has finished for PR 22917 at commit d485c9a.

  • This patch fails SparkR unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Nov 2, 2018

Test build #4404 has finished for PR 22917 at commit d485c9a.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Nov 2, 2018

Test build #4407 has finished for PR 22917 at commit d485c9a.

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

@vanzin
Copy link
Contributor

vanzin commented Nov 2, 2018

Merging to master / 2.4.

asfgit pushed a commit that referenced this pull request Nov 2, 2018
…e buffers

## What changes were proposed in this pull request?

Avoid converting encrypted bocks to regular ByteBuffers, to ensure they can be sent over the network for replication & remote reads even when > 2GB.

Also updates some TODOs with links to a SPARK-25905 for improving the
handling here.

## How was this patch tested?

Tested on a cluster with encrypted data > 2GB (after SPARK-25904 was
applied as well).

Closes #22917 from squito/real_SPARK-25827.

Authored-by: Imran Rashid <[email protected]>
Signed-off-by: Marcelo Vanzin <[email protected]>
(cherry picked from commit 7ea594e)
Signed-off-by: Marcelo Vanzin <[email protected]>
@asfgit asfgit closed this in 7ea594e Nov 2, 2018
@squito squito deleted the real_SPARK-25827 branch November 6, 2018 08:42
jackylee-ch pushed a commit to jackylee-ch/spark that referenced this pull request Feb 18, 2019
…e buffers

## What changes were proposed in this pull request?

Avoid converting encrypted bocks to regular ByteBuffers, to ensure they can be sent over the network for replication & remote reads even when > 2GB.

Also updates some TODOs with links to a SPARK-25905 for improving the
handling here.

## How was this patch tested?

Tested on a cluster with encrypted data > 2GB (after SPARK-25904 was
applied as well).

Closes apache#22917 from squito/real_SPARK-25827.

Authored-by: Imran Rashid <[email protected]>
Signed-off-by: Marcelo Vanzin <[email protected]>
kai-chi pushed a commit to kai-chi/spark that referenced this pull request Jul 23, 2019
…e buffers

## What changes were proposed in this pull request?

Avoid converting encrypted bocks to regular ByteBuffers, to ensure they can be sent over the network for replication & remote reads even when > 2GB.

Also updates some TODOs with links to a SPARK-25905 for improving the
handling here.

## How was this patch tested?

Tested on a cluster with encrypted data > 2GB (after SPARK-25904 was
applied as well).

Closes apache#22917 from squito/real_SPARK-25827.

Authored-by: Imran Rashid <[email protected]>
Signed-off-by: Marcelo Vanzin <[email protected]>
(cherry picked from commit 7ea594e)
Signed-off-by: Marcelo Vanzin <[email protected]>
kai-chi pushed a commit to kai-chi/spark that referenced this pull request Aug 1, 2019
…e buffers

## What changes were proposed in this pull request?

Avoid converting encrypted bocks to regular ByteBuffers, to ensure they can be sent over the network for replication & remote reads even when > 2GB.

Also updates some TODOs with links to a SPARK-25905 for improving the
handling here.

## How was this patch tested?

Tested on a cluster with encrypted data > 2GB (after SPARK-25904 was
applied as well).

Closes apache#22917 from squito/real_SPARK-25827.

Authored-by: Imran Rashid <[email protected]>
Signed-off-by: Marcelo Vanzin <[email protected]>
(cherry picked from commit 7ea594e)
Signed-off-by: Marcelo Vanzin <[email protected]>
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