OHIF / Viewers

OHIF zero-footprint DICOM viewer and oncology specific Lesion Tracker, plus shared extension packages
https://docs.ohif.org/
MIT License
3.1k stars 3.27k forks source link

Browser crash when uploading large files #845

Closed ohif-bot closed 11 months ago

ohif-bot commented 5 years ago

Download this image:

ftp://medical.nema.org/medical/dicom/Datasets/WG26/Hamamatsu/Dog_15x15_20x.dcm

(Navigate to here: ftp://medical.nema.org/medical/dicom/Datasets/WG26/Hamamatsu/ and click on the file if the link above doesn't work)

Try to select the file and upload it to your PACS using the + button in the top of the study list (see video: https://www.dropbox.com/s/pya8eall0727eum/Sep-03-2019%2011-30-19.mp4?dl=0).

Chrome will crash with an Aww Snap error. I am guessing it is running out of memory.

It's not clear yet where it is failing. The Uploading code is here: https://github.com/OHIF/Viewers/blob/1b68c307fcf7a2c73d84ccd095b2bb7cdf66b012/platform/viewer/src/googleCloud/api/DicomUploadService.js#L47-L55

It's possible it's failing when reading the file, but it's also possible that the dicomweb-client is failing while calling storeInstances.

https://github.com/dcmjs-org/dicomweb-client/blob/5c1a0a0138b0a77db661df84a6ac80737668b7e1/src/api.js#L1282-L1298

I can imagine storeInstances failing at the multipartEncode step (https://github.com/dcmjs-org/dicomweb-client/blob/5c1a0a0138b0a77db661df84a6ac80737668b7e1/src/message.js#L132-L178)

First step: Find out what is actually causing the failure (comment out the remaining steps one by one and see if it still fails).

ladeirarodolfo commented 4 years ago

After inspecting it the results are:

  1. Issue is caused by browser memory limit exceeded
  2. We can not precise the correct moment it exceeds, especially because memory consumption gets progressively worse over time. I.e. For current application, considering more code is added over time, equally memory consumption is increasing over time. This was observed after debugging different places it exceeds and for different days.

Possible solutions would be

  1. (Hard solution) Do a full inspection on code implementation and heap snapshots report results, do some refactoring, do some bit manipulation, decrease memory consumption. (op 2 is required anyway)
  2. (Easy solution) Set a valid limit size of files, add a filter to local load (limit it), implement app to recover from memory limit exceed and toast user a message
sedghi commented 11 months ago

Please review the latest code in the master branch. This issue might have been resolved. If it persists, kindly reopen the issue with updated details.

Try viewer-dev.ohif.org instead of viewer.ohif.org Our viewer.ohif.org is deployed from release branch while viewer-dev.ohif.org is our master branch Read more about branch explanations here https://docs.ohif.org/development/getting-started#developing