StackPrefetchTool no longer support maxSimultaneousRequests

[Betalos]

Prerequisites

• [x] Which version are you using? 4.0.0 (Is it latest?) YES
• [x] Are you reporting to the correct repository?
• [x] Did you search existing issues? (Were any related?) No

Description

The 3.x.x version used to have a prop for maxSimultanousRequests when configuring StackPrefetchTool. The new version has moved to requestPoolManager (imageLoadPoolManager) provided by cornerstone-core for such functionality but it's not there.

Expected behavior: Allow the possibility to specify the maxSimultaneousRequests.

Actual behavior: All the the image are loaded in the same time instead of chunking them

[swederik]

Hi @Betalos,

We are a bit behind on our documentation here but intend to clarify things ASAP. The maximum simultaneous requests option has been removed because with HTTP2, it's no longer a major issue to have 6 or fewer requests open. It also felt a bit redundant to have that option, plus the per-type (interactive, prefetch, ...) options.

With the latest set of Cornerstone Core / WADO Image Loader libraries, the loading step is essentially three queues:

A queue for Image Loading (default is 1000 simultaneous loads, you can change it here https://github.com/cornerstonejs/cornerstone/blob/master/src/requestPool/imageLoadPoolManager.ts#L6). Inside each image load is

• Retrieval (https://github.com/cornerstonejs/cornerstone/blob/master/src/requestPool/imageRetrievalPoolManager.ts, default is 20 simultaneous requests per type). The retrieval step is the actual XMLHTTPRequest portion of the image load
• Decoding (these tasks are placed in another queue and handled by a pool of Web Workers here: https://github.com/cornerstonejs/cornerstoneWADOImageLoader/blob/master/src/imageLoader/webWorkerManager.js#L80)

The idea is that if number of cores or CPU speed is your bottleneck, you can retrieve as many files as possible while waiting for decoding operations to take place. This might also be an issue with larger images.

An issue that we noticed was that with the old system, the requestPoolManager queue was at the image load (i.e. retrieval + decode) level, which meant that while images were decoding, we were wasting valuable time that could have been used to transfer additional images in parallel.

Hope that helps!

[Betalos]

Hi @swederik,

Thanks for the quick replay. Well for my particular use case the bottle neck is the backend (if I send chunks of request the loading of large series - 600+ instances - is better).

What I have noticed that link is not used properly or not working as intended since here they would be loaded at the same time (XHR request triggered)

[swederik]

Oh good catch, that is very true it is not being used properly! I'll fix that (https://github.com/cornerstonejs/cornerstoneTools/blob/master/src/stackTools/stackPrefetch.js#L234).

Thanks!

[Betalos]

Your welcome, glade I can help.