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

Fix and expand range checks when performing tile retrieval #11

Merged
merged 10 commits into from
Oct 3, 2024

Conversation

chris-allan
Copy link
Member

Much more thorough range changes for tile retrieval. In particular this will prevent the allocation of intermediate large arrays during the tile caching phase of tile retrieval only for the resulting read to fail.

/cc @mabruce


public void checkReadSize(int[] shape) {
long length = length(shape);
long maxLength = maxPlaneWidth * maxPlaneHeight;
Copy link
Member

Choose a reason for hiding this comment

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

Would it be worth doing long multiplication here too? Or do we know for sure that maxPlaneWidth * maxPlaneHeight will always be less than Integer.MAX_VALUE?

Copy link
Member Author

Choose a reason for hiding this comment

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

We don't know for sure but if you were to configure your server like that all sorts of other stuff would break spectacularly.

Copy link
Member

@sbesson sbesson left a comment

Choose a reason for hiding this comment

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

A few inline comments. Primary question is about the prefered location of the max tile size check. But otherwise 👍 for additional checkpoints that makes the usage of this pixel buffer safer and the corresponding unit tests

resolutions);

// Hack the .zarray so we can appear as though we have more data than
// we actually have written above.
Copy link
Member

@sbesson sbesson Oct 2, 2024

Choose a reason for hiding this comment

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

I assume the rationale if that is we want to generate an OME-Zarr of a given dimensions without actually writing the underlying test data (which increases the test time for no value).

@melissalinkert this makes me wonder whether we could introduce an option in bioformats2raw to generate Zarr datasets with sparse data

Copy link
Member Author

Choose a reason for hiding this comment

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

I assume the rationale if that is we want to generate an OME-Zarr of a given dimensions without actually writing the underlying test data (which increases the test time for no value).

Correct. Creating an array large enough to not end up with earlier out of bounds checks can take minutes.

@chris-allan
Copy link
Member Author

@melissalinkert: Anything else you'd like to see here before we merge this. It won't go into a release for a while anyway so it also won't be a problem to adjust if you think of something later.

@sbesson sbesson merged commit deabf58 into glencoesoftware:master Oct 3, 2024
3 checks passed
@sbesson
Copy link
Member

sbesson commented Oct 3, 2024

Thought about cutting a patch release with these additional checks ? Or are there other quick fixes/features we'd like to get in as well?

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