Atlas on Tomcat works from remote host but not localhost

Christophe_Lambert · October 3, 2016, 4:01pm

Usually the problem is the reverse, but in my case, I can connect to Atlas from a remote host, but when I try to connect via the localhost that runs Tomcat, the browser page just spins with the Atlas logo. Conversely AchillesWeb works fine both locally and remotely, also running within Tomcat. Note, I am using Tomcat to host both the web pages and the WebAPI .jar file (I tried first to do the web hosting with Apache Web Server, and couldn’t figure out the system administration).

When I look at the the localhost_access_log for Tomcat for the unsuccessful page load (localhost:8080/Atlas), I see only the following (the web page endlessly shows the Atlas spinning logo):

::1 - - [03/Oct/2016:08:27:36 -0600] "GET /Atlas HTTP/1.1" 302 -
::1 - - [03/Oct/2016:08:28:37 -0600] "GET /Atlas HTTP/1.1" 302 -

The successful remote access of Atlas (hostname.edu:8080/Atlas) shows the logo, then advances to the functional home page. The analogous log messages for the successful remote host page load are:

64.234.168.192 - - [03/Oct/2016:08:54:55 -0600] "GET /Atlas HTTP/1.1" 302 -
64.234.168.192 - - [03/Oct/2016:08:54:56 -0600] "GET /Atlas/js/components/home.js HTTP/1.1" 200 710
64.234.168.192 - - [03/Oct/2016:08:54:56 -0600] "GET /Atlas/js/components/home.html HTTP/1.1" 200 2260
64.234.168.192 - - [03/Oct/2016:08:54:56 -0600] "GET /Atlas/js/fonts/fontawesome-webfont.woff2?v=4.4.0 HTTP/1.1" 200 64464
64.234.168.192 - - [03/Oct/2016:08:54:56 -0600] "GET /Atlas/js/images/sort_both.png HTTP/1.1" 200 1136
64.234.168.192 - - [03/Oct/2016:08:54:56 -0600] "GET /Atlas/js/images/sort_desc.png HTTP/1.1" 200 298

I’m guessing the localhost failure to advance to the home page may have something to do with a redirect not working (perhaps related to WebAPI?) – does anyone have thoughts on what could be wrong or how to go about troubleshooting? I am running RedHat Linux Workstation release 7.2.

By the way, to get Atlas to work on Tomcat there are numerous system configuration issues to be aware of that took me many hours to sort out:

Tomcat needs SSL to be configured and a certificate created. Useful instructions are here. I ended up with this statement in my /etc/tomcat/server.xml file:

<Connector port="8443" maxHttpHeaderSize="1048576"
      protocol="org.apache.coyote.http11.Http11Protocol"
      maxThreads="150" SSLEnabled="true" scheme="https" secure="true" 
      keystoreFile="/etc/tomcat/.keystore" keystorePass="password123"
      clientAuth="false" sslProtocol="TLS" />

Beware needed ports tied up by other processes – in my case VMware was using port 443.
Beware issues with necessary ports not being open with your firewall (e.g. 5432, 80, 443, 8080, 8443).
Beware issues with postgres not accepting necessary connections (modify pg_hba.conf).
It is really easy to have the wrong settings in your webapi.source and webapi.source_daimon tables that make WebAPI fail.

Christophe_Lambert · October 5, 2016, 2:25pm

Barring an answer to my specific question, at every stage of my misconfiguration of Atlas I got the spinning Atlas logo, but no error messages to indicate what was wrong. In general, how do Atlas folks recommend troubleshooting when you just see the spinning logo and get no further? For example, is there a way to enable verbose logging?

Frank · October 5, 2016, 3:46pm

There is some error handling already that should tell you what is wrong, for example, if the WebAPI isn’t configured properly. If you are stuck on the spinning logo, then opening the developer console in chrome (CONTROL-SHIFT-I on Windows) should let you see what error is occurring. If you can let me know what error is there we can add more error handling to prevent getting stuck at this screen.

Christophe_Lambert · October 5, 2016, 8:50pm

Here is the error messages I see in the console when loading from localhost:8080/Atlas:

Uncaught SyntaxError: Unexpected token =
jnj.chart.js:1964 Uncaught SyntaxError: Unexpected token =
app.js:1428 Uncaught TypeError: Cannot read property 'dirtyFlag' of undefinedappModel @ app.js:1428(anonymous function) @ main.js:131i.execCb @ require.js:29Z.check @ require.js:18(anonymous function) @ require.js:23(anonymous function) @ require.js:8(anonymous function) @ require.js:23v @ require.js:7Z.emit @ require.js:23Z.check @ require.js:19(anonymous function) @ require.js:23(anonymous function) @ require.js:8(anonymous function) @ require.js:23v @ require.js:7Z.emit @ require.js:23Z.check @ require.js:19(anonymous function) @ require.js:23(anonymous function) @ require.js:8(anonymous function) @ require.js:23v @ require.js:7Z.emit @ require.js:23Z.check @ require.js:19Z.enable @ require.js:23Z.init @ require.js:17E @ require.js:14i.completeLoad @ require.js:28i.onScriptLoad @ require.js:30

In contrast, here are the non-error console messages I see when I load Atlas from my remote host:

using cache for http://muse.health.unm.edu:8080/WebAPI/source/sources. remove .* from ohdsi.util.ALLOW_CACHING to disable caching for it
ohdsi.util.js:1483 using cache for http://muse.health.unm.edu:8080/WebAPI/synpuf5_cdm/vocabulary/info. remove .* from ohdsi.util.ALLOW_CACHING to disable caching for it
ohdsi.util.js:1483 using cache for http://muse.health.unm.edu:8080/WebAPI/vocab/vocabulary/info. remove .* from ohdsi.util.ALLOW_CACHING to disable caching for it

Thank you!

anthonysena · October 6, 2016, 1:38pm

Christophe, it appears that the issue here is happening inside one of the JavaScript dependencies. I wanted to confirm that you are using Atlas release v1.3.0: https://github.com/OHDSI/Atlas/tree/v1.3.0? I only ask since the error message you shared doesn’t seem to match the code that is in that release:

github.com

OHDSI/Atlas/blob/v1.3.0/js/jnj.chart.js#L1964


				legendWidth += maxWidth + 5;
			}
			*/


			this.layout.positionZones();
			this.layout.positionZones();


			if (cp.lines) {
				var lines = cp.chart.chart.gEl.addChild('lines',
					{ tag: 'line',
						classes:['refline'],
						data: cp.lines,
						updateCb: function(selection, params, opts = {}) {
							var {delay=0, duration=0, transition, cp=self.cp} = opts;
							selection
								.attr('x1', function(lineOpts) {
									return cp.x.scale(lineOpts.x1( cp.x.scale.domain(), cp.y.scale.domain()));
								})
								.attr('x2', function(lineOpts) {
									return cp.x.scale(lineOpts.x2( cp.x.scale.domain(), cp.y.scale.domain()));
								})

It is not clear to my why you would see different behavior when accessing Atlas using localhost versus the fully qualified domain name. In reading this thread, it sounds like you are running a Linux VM hosting Apache Tomcat and PostgreSQL and you are then attempting to access Atlas using Chrome on that VM. Is the DNS entry then pointed to that VM? And are you then accessing Atlas from a different client using Chrome? Just curious about the topology for your setup.

Christophe_Lambert · October 10, 2016, 5:06pm

Hi Anthony, I updated Atlas again this morning from the master branch using git pull, and the line numbers of the error messages have changed over what I last posted:

Uncaught SyntaxError: Unexpected token = ohdsi.util.js:79
Uncaught SyntaxError: Unexpected token = jnj.chart.js:1973
Uncaught SyntaxError: Unexpected token = app.js:1470 Uncaught TypeError: Cannot read property 'dirtyFlag' of undefinedappModel @ app.js:1470(anonymous function) @ main.js:131i.execCb @ require.js:29Z.check @ require.js:18(anonymous function) @ require.js:23(anonymous function) @ require.js:8(anonymous function) @ require.js:23v @ require.js:7Z.emit @ require.js:23Z.check @ require.js:19(anonymous function) @ require.js:23(anonymous function) @ require.js:8(anonymous function) @ require.js:23v @ require.js:7Z.emit @ require.js:23Z.check @ require.js:19Z.enable @ require.js:23Z.init @ require.js:17E @ require.js:14i.completeLoad @ require.js:28i.onScriptLoad @ require.js:30

The code on line 79 of ohdsi.util.js is:

function elementConvert(target, type = "dom") {

The code on line 1973 of jnj.chart.js is:

updateCb: function(selection, cbParams={}, passParams={}, thisD3El) {

The code on line 1470 of app.js is:

self.currentConceptSetDirtyFlag = new ohdsiUtil.dirtyFlag({

I am not running a Linux VM. Linux is the host system that runs Tomcat and PostgreSQL – I do have a Windows VM running on Linux – that was the instance of VMWARE that was tying up port 443. I am accessing Atlas using Chrome on the Linux host system. All of the remote windows clients were Chrome. However, I tried both FireFox and Chrome on the Linux localhost and get the hanging behavior.

I just tried FireFox on a remote Linux machine, and it appears to also hang. Here are the console error messages from FireFox for both local and remote hosts:

Error: Script error for: jquery
http://requirejs.org/docs/errors.html#scripterror require.js:8:251
Error: Load timeout for modules: bootstrap
http://requirejs.org/docs/errors.html#timeout require.js:8:251

I also tried Windows internet explorer from a remote machine and it also hangs. Perhaps Windows Chrome is just more forgiving with some malformed code?

Christophe_Lambert · October 12, 2016, 1:19am

It turns out I was running Chrome version 48.0.2564.116 (64-bit) under Linux, and after upgrading to version 53.0.2785.143 (64-bit) the errors went away and I can load Atlas from localhost. Thanks to Anthony for troubleshooting!

Related to this, Internet Explorer 11.0.9600.18449 does not work, and Firefox 38.6.1 does not work with Atlas. Upgrading FireFox to version 45.4.0 does not appear to fix the problem.

So it does not appear to be a localhost vs. remotehost problem, but rather some sort of incompatibility with certain versions of certain web browsers.

Chris_Knoll · October 12, 2016, 3:36am

There were some recent changes that are using certain advanced features that aren’t supported in all browsers, and I think we’ll need to review those changes, to go to something a bit more adopted. Our target browser continues to be chrome, but we should be supporting versions that have been released for at least 1 year. In comparison, 53.0 was released 2016-08-31. So shame on you for being out of date by 5 weeks! Ha ha, just kidding.

Going a year back, version 46.0 was released. Here is the compatibility table for that:
http://kangax.github.io/compat-table/es6/#chrome46

The picture inproves quite a bit going up to version 49, so perhaps we draw the line at version 49 (which was released 2016-03-02), that’s more than 6 months old, but gives us decent coverage of features.

For IE and Firefox, I can’t promise anything there. Some libraries make it easy to contend with older/other browsers, but other parts require developer discipline. Looking at the compatibility for Firefox, things look 'decen’t at FF45 (which was released March 8th, 2016) so if you want to use firefox, I’d suggest using that version at a minimum.

-Chris

Chris_Knoll · October 12, 2016, 3:51am

Additional info:

All the errors you saw above was using a javascript feature called ‘default parameters’:

The reason for he last error about the ‘dirtyFlag’ is that the ohdsi util module failed to load (due to the above erros).

According to the link above, this first got supported in Chrome 49. Firefox introduced it in 15.0, but continued to update it rhoguh version 41. Fir IE, Opera and Safari, there’s no support!

So, message to the dev contributors: stay clear of features like that, just for our own sake of sanity. The way to handle defaulting parameters is a simple pattern:

function (a, b, c) {
  var a = (a === 'undefined' ?  'defaultA' : a);
  var b = (b === 'undefined' ?  'defaultB' : b);
  var c = (c === 'undefined' ?  'defaultC' : c);

// use a.b,c as normal

}

There’s examples in code where it uses the pattern of var a = a || ‘defaultA’, but this can run into problems if you pass in something like 0 as the parameter (which is falsy) and the default value is something other than 0. The above example ensures that the parameter is ‘undefined’ if it’s going to supply a default value.

-Chris

Christophe_Lambert · October 12, 2016, 1:48pm

I’ll just stick with Chrome. All teasing aside, Chrome 53.0.2785.143 and FireFox 45.4.0 are the latest updates provided by Red Hat commercial support as of today. It is often frustrating how far behind they lag on some software updates, including PostgreSQL. Perhaps keeping an ongoing list of browsers and versions with which Atlas works, as an appendix to the installation instructions, would be helpful.

-Christophe

t_abdul_basser · October 12, 2016, 2:27pm

Thanks for calling this out @Chris_Knoll. We should go into the adoption of ES6 features with our eyes open.

anthonysena · October 12, 2016, 2:49pm

I’ve added a note to the Atlas documentation on the wiki that notes the use of Google Chrome v49 or higher.