Skip to content

Cap maximum shard size at the size of an integer#5141

Merged
jrbourbeau merged 2 commits intodask:mainfrom
mrocklin:ssl-max-int-size
Jul 29, 2021
Merged

Cap maximum shard size at the size of an integer#5141
jrbourbeau merged 2 commits intodask:mainfrom
mrocklin:ssl-max-int-size

Conversation

@mrocklin
Copy link
Member

Supercedes #5134

Copying over the summary of that PR

Works around the OpenSSL 1.0.2 bug demonstrated in issue ( #4538 ), except unlike PR ( #5115 ) which did this for reading, this does the same thing for writing. The error may be less likely to show up in the write path (as frames may simply be smaller than this limit). Still it seems like a good idea to protect against OverflowErrors from OpenSSL

  • Closes #xxxx
  • Tests added / passed
  • Passes black distributed / flake8 distributed / isort distributed

Supercedes dask#5134

Copying over the summary of that PR

Works around the OpenSSL 1.0.2 bug demonstrated in issue ( dask#4538 ), except unlike PR ( dask#5115 ) which did this for reading, this does the same thing for writing. The error may be less likely to show up in the write path (as frames may simply be smaller than this limit). Still it seems like a good idea to protect against OverflowErrors from OpenSSL
@mrocklin mrocklin mentioned this pull request Jul 29, 2021
3 tasks
@jakirkham
Copy link
Member

Guessing we will want to replace this as well ( #5115 )?

An established communication based on an underlying Tornado IOStream.
"""

max_shard_size = dask.utils.parse_bytes(dask.config.get("distributed.comm.shard"))
Copy link
Member

Choose a reason for hiding this comment

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

This seems to be 64 MiB. Do we want to limit it to that? Would it be worthwhile to have a different value for TCP specifically?

Copy link
Member Author

Choose a reason for hiding this comment

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

This PR doesn't change the behavior for TCP (this value is what is used by default for everything in to_frames). All it does is make sure that TLS has a possibly different value that is capped by the max int size, which I think was the intent of the other PR.

Copy link
Member

@jakirkham jakirkham Jul 29, 2021

Choose a reason for hiding this comment

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

Got it. So this was 64 MiB before?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yup.

Co-authored-by: jakirkham <jakirkham@gmail.com>
Copy link
Member

@jrbourbeau jrbourbeau left a comment

Choose a reason for hiding this comment

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

@jrbourbeau jrbourbeau merged commit 89f8789 into dask:main Jul 29, 2021
@mrocklin mrocklin deleted the ssl-max-int-size branch July 29, 2021 22:05
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