OHDSI Home | Forums | Wiki | Github

Public Atlas stops at the loading screen

Developers
#1

Hi,

I have tried to access http://www.ohdsi.org/web/atlas/ today without success. I get to the loading icon, but I don’t get any further than that. Do you have any ideas what’s going on?

Kind regards

#2

I’m seeing a 500 error from Atlas attempts to load javascripts from an external site.

For example

https://unpkg.com/urijs@1.19.1/src/IPv6.js?_=exl0xb

As an experiment, if I try:

https://unpkg.com/urijs@1.19.1/src/IPv6.js

The call succeeds.

@Chris_Knoll or @anthonysena - I’d appreciate your thoughts on potential solutions/workarounds?

#3

The unpkg.com CDN does haeve the occasional downtime. With v2.6 we have an improved bundling mechanism that could help here. But it will require additional scripting steps to do the npm run build step, copy files over from the bundled location, and finally update index.html to use the bundle. Sounds complicated, but it’s very script-able.

All that being said, i was able to pull up the public atlas instance.

1 Like
#4

Hi Chris, thank you for looking into this issue. Looking at the network log when I try to access Atlas I seem to have a similar issue to Lee with https://unpkg.com/urijs@1.19.1/src/URI.js?_=3tfju returning a http 500 error.

#5

Some of the current response times from unpkg.com are 30+ seconds in length.

I’ve increased the requirejs js module loader timeout on the public Atlas from the default 7 seconds to 60 seconds, as an initial mitigation step.

#6

I am running into the problem using the public instance and our Broadsea installation. Is there a workaround?
From Broadsea:
Failed to load resource: the server responded with a status of 500 ()
require.js:8 Uncaught Error: Script error for: ohdsi-api
http://requirejs.org/docs/errors.html#scripterror
at C (require.js:8)
at HTMLScriptElement.onScriptError (require.js:30)

#7

@rkiefer You can increase the requirers timeout by adding the following code to your config-local.js:

require.config({
       "waitSeconds" : 60
});
#8

Thanks @admin for the tip. @rkiefer made the change, and now we are very sporadically seeing our local instance of ATLAS work. I am using the same testing approach where I do the hard cache refresh in Chrome (have verified across multiple browsers) and reload the page. Occasionally it will work, other times we still get errors from requirejs.org or unpkg.org. For example:
GET https://unpkg.com/@ohdsi/atlascharts@1.5.0/dist/atlascharts.min.js?_=duyy2g net::ERR_ABORTED 500

The packages that it fails on differs sometimes too (e.g. atlascharts, IPv6, punycode). Should we try a higher timeout value?

EDIT: @rkiefer has noted that the public site will load for him, although it fails for me (even after clearing cache).

#9

I’ve now deployed an updated version of the public Atlas in the OHDSI cloud which removes the problem dependency on “unpkg.org” by bundling the node modules with the code.

Thanks @anthonysena for your explanation of how to fix the issue and for providing the required modules files and updated settings.js file.

1 Like
#10

guys, probably late to the game but just in case. This is why ATLAS should be packaging all dependent libraries instead of referring to external sites. I believe this functionality was added in v2.6 to enable deployments in lockdown environments that block external internet traffic (very common in healthcare or payer settings)

1 Like
#11

100% agreed @gregk - with the upcoming Atlas v2.7 release, packaging all dependent libraries will be the preferred approach instead of using references from content delivery networks such as unpkg.org. Unfortunately, the release of Atlas v2.6 has a bug where packaging the references using npm is not working properly and so I worked with Lee to come up with a work-around. For others that may be experiencing the same issue when running Atlas v2.6, I’ve posted up the work-around and supporting details on GitHub: https://github.com/OHDSI/Atlas/issues/1312.

1 Like
#12

Agreed.

t