-
Notifications
You must be signed in to change notification settings - Fork 3
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
Conversation
|
||
public void checkReadSize(int[] shape) { | ||
long length = length(shape); | ||
long maxLength = maxPlaneWidth * maxPlaneHeight; |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.
There was a problem hiding this 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
src/test/java/com/glencoesoftware/omero/zarr/ZarrPixelBufferTest.java
Outdated
Show resolved
Hide resolved
resolutions); | ||
|
||
// Hack the .zarray so we can appear as though we have more data than | ||
// we actually have written above. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
src/main/java/com/glencoesoftware/omero/zarr/ZarrPixelBuffer.java
Outdated
Show resolved
Hide resolved
8083a7c
to
8a695fa
Compare
@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. |
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? |
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