Viewers: OHIF study listing hanging: For some reason we could not list the studies

[HowardLander]

I am having trouble listing the studies that I have in my orthanc db. When I start the viewer, I get the UI, but no studies, just the word Loading and a spinning circle. This issue seems a bit similar to #113, but I don't think that the problem is with the orthanc dicom plugin. Full disclosure: I am using docker-compose for this effort. The OHIF docker is version travis-829. I'm using jodogne/orthanc-plugins:latest and mongo:latest as well. Lot's of config/results below: Thanks in advance for any assistance, I'm a little stumped.

Howard

Here's a bit of what I get from the orthanc server when I try it directly:

which looks OK to me.
I've also got an nginx reverse proxy server configured: it looks like this

  location /orthanc/ {
      proxy_pass http://orthanc:8042;
      proxy_set_header HOST $host;
      proxy_set_header X-Real-IP $remote_addr;
      rewrite /orthanc(.*) $1 break;
      add_header 'Access-Control-Allow-Credentials' 'true';
      add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type';
      add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
      add_header 'Access-Control-Allow-Origin' '*';
   }

Here's what I have in the web console:

Here's my config script (minus the hotkeys for brevity)

window.config = {
  // default: '/'
  routerBasename: '/',
  extensions: [],
  showStudyList: true,
  // default: ''
  relativeWebWorkerScriptsPath: '',
  servers: {
    dicomWeb: [
      {
        name: 'Orthanc',
        wadoUriRoot: '/orthanc/wado',
        qidoRoot: '/orthanc/dicom-web',
        wadoRoot: '/orthanc/dicom-web',
        qidoSupportsIncludeField: false,
        imageRendering: 'wadors',
        thumbnailRendering: 'wadors',
        requestOptions: {
          requestFromBrowser: true,
        },
      },
    ],
  },

Here's the error from the terminal where I start the docker:

viewer      | { Error: request failed
viewer      |     at XMLHttpRequest.request.onreadystatechange (/app/bundle/programs/server/npm/node_modules/meteor/ohif_studies/node_modules/dicomweb-client/build/dicomweb-client.js:391:29)
viewer      |     at XMLHttpRequestEventTarget.dispatchEvent (/app/bundle/programs/server/npm/node_modules/meteor/ohif_studies/node_modules/xhr2/lib/xhr2.js:64:18)
viewer      |     at XMLHttpRequest._setReadyState (/app/bundle/programs/server/npm/node_modules/meteor/ohif_studies/node_modules/xhr2/lib/xhr2.js:354:12)
viewer      |     at XMLHttpRequest._onHttpRequestError (/app/bundle/programs/server/npm/node_modules/meteor/ohif_studies/node_modules/xhr2/lib/xhr2.js:544:12)
viewer      |     at ClientRequest.<anonymous> (/app/bundle/programs/server/npm/node_modules/meteor/ohif_studies/node_modules/xhr2/lib/xhr2.js:414:24)
viewer      |     at emitOne (events.js:116:13)
viewer      |     at ClientRequest.emit (events.js:211:7)
viewer      |     at Socket.socketErrorListener (_http_client.js:387:9)
viewer      |     at emitOne (events.js:116:13)
viewer      |     at Socket.emit (events.js:211:7)
viewer      |     at emitErrorNT (internal/streams/destroy.js:64:8)
viewer      |     at _combinedTickCallback (internal/process/next_tick.js:138:11)
viewer      |     at process._tickDomainCallback (internal/process/next_tick.js:218:9)
viewer      |   request:
viewer      |    XMLHttpRequest {
viewer      |      onloadstart: [Function],
viewer      |      onprogress: null,
viewer      |      onabort: null,
viewer      |      onerror: null,
viewer      |      onload: null,
viewer      |      ontimeout: null,
viewer      |      onloadend: [Function],
viewer      |      _listeners: {},
viewer      |      onreadystatechange: [Function],
viewer      |      _anonymous: undefined,
viewer      |      readyState: 4,
viewer      |      response: null,
viewer      |      responseText: '',
viewer      |      responseType: 'json',
viewer      |      responseURL: '',
viewer      |      status: 0,
viewer      |      statusText: '',
viewer      |      timeout: 0,
viewer      |      upload:
viewer      |       XMLHttpRequestUpload {
viewer      |         onloadstart: null,
viewer      |         onprogress: null,
viewer      |         onabort: null,
viewer      |         onerror: null,
viewer      |         onload: null,
viewer      |         ontimeout: null,
viewer      |         onloadend: null,
viewer      |         _listeners: {},
viewer      |         _request: [Circular],
viewer      |         _contentType: null,
viewer      |         _body: <Buffer > },
viewer      |      _method: 'GET',
viewer      |      _url:
viewer      |       Url {
viewer      |         protocol: 'http:',
viewer      |         slashes: true,
viewer      |         auth: null,
viewer      |         host: 'pacsip:8042',
viewer      |         port: '8042',
viewer      |         hostname: 'pacsip',
viewer      |         hash: null,
viewer      |         search: '?limit=25&offset=0&includefield=all',
viewer      |         query: 'limit=25&offset=0&includefield=all',
viewer      |         pathname: '/dicom-web/studies',
viewer      |         path: '/dicom-web/studies?limit=25&offset=0&includefield=all',
viewer      |         href: 'http://pacsip:8042/dicom-web/studies?limit=25&offset=0&includefield=all' },
viewer      |      _sync: false,
viewer      |      _headers:
viewer      |       { Accept: 'application/dicom+json',
viewer      |         Authorization: 'Basic b3J0aGFuYzpvcnRoYW5j',
viewer      |         Connection: 'keep-alive',
viewer      |         Host: 'pacsip:8042',
viewer      |         'User-Agent': 'Mozilla/5.0 (Linux x64) node.js/8.10.0 v8/6.2.414.50',
viewer      |         'Content-Length': '0' },
viewer      |      _loweredHeaders: { accept: 'Accept', authorization: 'Authorization' },
viewer      |      _mimeOverride: null,
viewer      |      _request: null,
viewer      |      _response: null,
viewer      |      _responseParts: null,
viewer      |      _responseHeaders: null,
viewer      |      _aborting: null,
viewer      |      _error: null,
viewer      |      _loadedBytes: 0,
viewer      |      _totalBytes: 0,
viewer      |      _lengthComputable: false },
viewer      |   response: null,
viewer      |   status: 0 }

[dannyrb]

@HowardLander, that is not a recent image. We have not used travis or meteor since version 1. Our latest released docker publish, while on v2, is a bit old. I have on my list to restore the automated publishing. I'll try to clear up the tags as well when I do to make thing clearer. I should have an update for you tonight/tomorrow.

[HowardLander]

@dannyrb Thanks much. I'll plug in the new version and let you know what happens as soon as you publish it. It is funny though, because docker hub claims that tag was last updated 7 days ago. Does that seem strange to you?

Howard

[dannyrb]

@HowardLander, that is odd. At the very least, this repository's master branch shouldn't be publishing to docker at the moment (especially using travis). Maybe an odd PR snuck into the pinned v1 branch and kicked off the process?

[HowardLander]

@dannyrb Yeah, I guess that could be. In any case, just let me know when you are ready and I'll pull down another image to try.
Howard

[HowardLander]

@dannyrb Any progress on this issue? Is it possible for me to build the docker myself? I cloned https://github.com/OHIF/Viewers.git but I wasn't sure which, if either of

./platform/viewer/.recipes/OpenResty-Orthanc/dockerfile
./platform/viewer/.recipes/OpenResty-Orthanc-Keycloak/dockerfile

I wanted to use. Those were the only dockerfiles I saw...

Howard

[dannyrb]

Just merged: https://github.com/OHIF/Viewers/pull/952
Docker Hub: https://cloud.docker.com/u/ohif/repository/docker/ohif/viewer

Recent tags:

• ohif/viewer:latest
• ohif/viewer:v1.1.14.3708 (vBREAKING.FEATURE.PATCH.BUILD)

[dannyrb]

Lots of ways to achieve your desired setup. We have a rough guide here:

• https://docs.ohif.org/deployment/recipes/nginx--image-archive.html
• ./platform/viewer/.recipes/OpenResty-Orthanc/dockerfile

The docker files for those recipes need updated slightly to account for the monorepo build steps, but the dockerfile, docker-compose.yml, and nginx.conf should still serve as good learning pieces.

[HowardLander]

Hi @dannyrb

I inserted your new docker (v1.1.14.3708) into my docker compose file and did an up. The viewer came up as expected, but is getting its data from https://server.dcmjs.org/. I have to admit I've been unable to get it to find my ortha server. I have this in the ohif viewer section of my docker compose file:

      volumes:
         - ${VIEWER_CONFIG:-./config/renci.js}:/usr/share/nginx/html/config/default.js
         - ${NGINX_CONFIG:-./config/nginx-with-proxy.conf}:/etc/nginx/conf.d/default.conf
      environment:
         - MONGO_URL=mongodb://mongo:27017/ohif
         - APP_CONFIG=/usr/share/nginx/html/config/default.js

with the thought that this would map my renci.js file in place of docker_openresty-orthanc.js, but while the renci.js file is where I expected and the ENV variable is set, I am still getting the test data. When I log into the running ohif viewer docker, I can't find a file called docker_openresty-orthanc.js, nor do I seem to find an openresty dir. So that's confusing. Any help you can offer would be greatly appreciated.

Thanks
Howard

[dannyrb]

@HowardLander:

Here is the directory that contains recipes:

• https://github.com/OHIF/Viewers/tree/master/platform/viewer/.recipes

The viewer config is at a new location. The change actually came up in a recent issue.

• Previous location: /usr/share/nginx/html/config/default.js
• New location: /usr/share/nginx/html/app-config.js

This change is largely due to some clean-up in our Progressive Web App's output. We used to copy _everything_ from platform/viewer/public, but we're now a bit more deliberate.

You can find example app config files here:

• https://github.com/OHIF/Viewers/tree/master/platform/viewer/public/config

Hopefully that's a little more helpful. Please keep me updated! It seems like you're close.

[HowardLander]

Hi @dannyrb
Yeah, changing the correct config file helped a lot. No surprise there!

I've still got some issues, getting the data from orthanc over to the viewer. Which version of orthanc are you using? I've tried both latest and 1.5.6, but I'd like to try whatever you are using. One other thing: how do I set the "studyListDateFilterNumDays" property? We have a bunch of data whose study date shows up as Jan 1 1900!

Thanks
Howard

[dannyrb]

https://github.com/OHIF/Viewers/blob/master/platform/viewer/.recipes/OpenResty-Orthanc/docker-compose.yml#L37

Is the image we use. It comes with the DicomWeb plugin.

What issues are you having connecting? Does any of the advice spelled out here help?

https://github.com/OHIF/Viewers/issues/965

[HowardLander]

I'll have to look more on Monday. We are using 1.5.6 so that's good. We have a working proxy config and I'm not sure that's the problem either. I was wondering if maybe the issue is that our studies are more than 25000 days old, which is why I was asking about studyListDateFilterNumDays. The funny thing is that if I go to orthanc:latest I can get the studylist, but the data only comes across sporadically (like some timeout value is being set!). I thought I could just not have a date range in the UI, but when I try to do that, the viewer does not seem to generate another request...

Howard

[dannyrb]

That's odd. How much data do you have? I know that DicomWeb doesn't support paging, so the date range (or other filters) help limit the size and time it takes to receive a response.

[HowardLander]

We have a lot of data and, for privacy reasons, it all has the same date. Jan 1 1900! Si.com web does , I think, support the count parameter, but maybe I'm wrong?

Howard

---

From: Danny Brown [e-mail]
Sent: Friday, September 27, 2019 5:44:37 PM
To: OHIF/Viewers [e-mail]
Cc: Lander, Howard Michael [e-mail]; Mention [e-mail]
Subject: Re: [OHIF/Viewers] OHIF study listing hanging: For some reason we could not list the studies (#943)

That's odd. How much data do you have? I know that DicomWeb doesn't support paging, so the date range (or other filters) help limit the size and time it takes to receive a response.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/OHIF/Viewers/issues/943?email_source=notifications&email_token=AAJUNLK3UN4XZVUPLGE7W4TQLZ5ELA5CNFSM4IZSUIF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD72FKBA#issuecomment-536106244, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAJUNLNKJ76UD5T27THB7Z3QLZ5ELANCNFSM4IZSUIFQ.

[dannyrb]

Hmm.. How do you normally seek/find/filter your studies? We could show none by default, and initiate queries after X number of letters in the "name" filter? I'll double check on Monday -- if there is a count parameter, a reasonable default limit might make sense, so long as we indicate one is applied somewhere.

[HowardLander]

There is no normally yet really, as this is a system under development. The target audience is, at least to some degree, researchers as opposed to practicing physicians. They will probably use some sort of external tool to develop a cohort listing.

So I now have it all connected up and working. I would still like a way to control the default date range, but once the user hits the x in the study dates area, the studies do appear. The biggest issue I have now is performance and I'm not sure that it's an OHIF problem The metadata for the selected studies once I select a particular study is taking 20 or 30 seconds to appear. When I look at the docker log, it seem to be executing a query like this:

GET /orthanc/dicom-web/studies/1.2.124.113532.129.255.5.220.20081114.92724.6800289/metadata

and that query seems to be taking an inordinate amount of time to complete. I confirmed this by doing a curl at the command line. Once the metadata is received and the images start to load, the performance is great. Have you seen this issue before? BTW, I am using orthanc:latest, whose performance was much better than that of 1.5.6

Thanks for all the help
Howard

[dannyrb]

@HowardLander, I know there are a number of things both you and we can do to improve the performance for large studies. If you're using nginx to proxy requests, you can:

• Enable gzip compression (significant performance boost)
• Make sure you're using http2
• Depending on your requirements, cache metadata requests for a short period of time

On our end, this in-progress PR aims to split the metadata requests by series so you can begin viewing much more quickly while the remaining data loads in the background:

https://github.com/OHIF/Viewers/pull/953

We have thoughts around additional enhancements, but that alone appears to provide a pretty good boost.

[HowardLander]

@dannyrb Thanks for the pointers and #953 does look promising. Each of our studies has 4 series, so we could potentially see a significant drop in perceived latency. Any idea when that might be available to try?

We are, in fact, using an nginx proxy. I'll have a look at each of your suggestions!
Thanks
Howard

[swederik]

If the query is taking a long time to complete via cURL, that's an issue with Orthanc or your proxy set up. 20-30 seconds to retrieve metadata is very long and absolutely not normal. Maybe try their PostgreSQL database option? Or add some caching once the metadata bundle has been created? In terms of study size, how many instances are in these studies? Are you using an SSD? What type of VM is this on?

953 has been merged, could you update and take a look again and let us know if you are still seeing performance issues. What is the average time it takes for Orthanc to return a WADO-RS series metadata bundle for your series?

[HowardLander]

Hi @swederik
I am using the PostgreSQL plugin and the db is on an SSD, so those two things are covered. This is an Amazon EC2 instance with 8 CPUS and 32 Gb of memory. Load average is not a problem. As far as the study size, typically each study has 4 series with between 400 and 700 images per, so the studies are not small. One thing worth mentioning is that this is run with docker-compose. I wondered if the docker to docker network performance is an issue, so I ran the curl command from inside the docker image running orthanc. Still way too slow. So I am now leaning towards the idea that whatever optimization is to be done should start on the orthanc side. I will still try #953, however I'm going to pound away at orthanc for a bit first!

Thanks to both you and @dannyrb for your help. Maybe we should keep the issue open long enough for me to find the resolution and post it for the next person?

Howard

[pieper]

Are you tied to Orthanc? Other DICOMweb servers might be faster.

[HowardLander]

Possibly not. Which other DICOMWeb servers do you like? One thing is that this is an academic project which means it has to be fairly low cost/free.

[pieper]

Well, we typically use dcm4chee and have good luck. At least as of a few years ago it was known to have a more efficient DICOMweb interface (don't know if that's still true but might be worth comparing).

My sentimental favorite is the one we are developing here: https://github.com/dcmjs-org/dicomweb-server. It's definitely still a work in progress, but I'm able to host a pretty good sized dataset and serve it to OHIF. It would be interesting to know if it works for your use case - it has a lot of headroom for scalability and customization.

[HowardLander]

Is there a docker build for dicomweb-server?

[pieper]

We don't provide a Dockerfile, but you can get a couchdb docker and then dicomweb-server is just a single node server.

[HowardLander]

953 has been merged, could you update and take a look again and let us know if you are still seeing performance issues. What is the average time it takes for Orthanc to return a WADO-RS series metadata bundle for your series?

@swederik : Is there a docker label I should be using to get the #953 functionality?
Howard

[HowardLander]

Since I promised to update this issue:

So as of now, it looks like the speed issue with the metadata call is the following: it turns out when you load files into the Orthanc database, you are only loading metadata. That makes sense. But apparently the dicom-web call to get the metadata needs more metadata than is loaded into the database. So the code has to open every file in the study to get additional metadata, so depending on how many files comprise the study and on what technology they are stored, the query can slow down. In our case the data is stored on an Amazon EFS drive, which has many virtues, but speed isn't one of them...

Howard

[swederik]

@swederik : Is there a docker label I should be using to get the #953 functionality?

It's in ohif/viewer:latest now that it has been merged to master. The CI publishes an updated docker image on each merge, assuming all the end-to-end tests pass.

For anyone else arriving at this issue, here is the relevant discussion on the Orthanc / DICOMweb endpoint performance questions:
https://groups.google.com/forum/#!topic/orthanc-users/y1N5zOFVk0M

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.