xnat deployment on AWS 404 page not found

192 views
Skip to first unread message

Gang Fu

unread,
Jul 13, 2021, 5:38:01 PM7/13/21
to xnat_discussion

Hi,

I am developing a cloudformation to deploy XNAT on AWS. I started with the containerized XNAT, and am able o deploy it on AWS ECS now. But when I curl the page, I got 404 error:
<!doctype html><html lang="en"><head><title>HTTP Status 404 – Not Found</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 404 – Not Found</h1><hr class="line" /><p><b>Type</b> Status Report</p><p><b>Description</b> The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.</p><hr class="line" /><h3>Apache Tomcat/9.0.50</h3></body></html>

Everything looks good in catalina log:
13-Jul-2021 20:48:54.722 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]
13-Jul-2021 20:48:54.833 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [1482] milliseconds

and conf file /usr/local/share/xnat/xnat-conf.properties is well formatted.

When I psql to database, it has no tables there.

Is there anyone can help me out?

Thx a lot!

Herrick, Rick

unread,
Jul 13, 2021, 7:47:32 PM7/13/21
to xnat_di...@googlegroups.com

That doesn’t look as if it’s starting up with XNAT at all. 1,482 milliseconds is way too quick for XNAT start-up, so I think you’re getting a 404 because XNAT’s actually not there to be found.

 

-- 

Rick Herrick

XNAT Architect/Developer

Computational Imaging Laboratory

Washington University School of Medicine

 

 

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of Gang Fu <gangf...@gmail.com>
Date: Tuesday, July 13, 2021 at 4:38 PM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: [XNAT Discussion] xnat deployment on AWS 404 page not found

* External Email - Caution *

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/631a9f59-df94-4b94-a832-290dd18e9858n%40googlegroups.com.

 


The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

Gang Fu

unread,
Jul 13, 2021, 8:31:25 PM7/13/21
to xnat_discussion
Hi Rick,

I made some progress here, it can start now and I can see Database is up to date. But I got the following error:
14-Jul-2021 00:24:53.668 SEVERE [Thread-39] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@cf366c]) and a value of type [org.restlet.data.Response] (value [org.restlet.data.Response@7395a044]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.


14-Jul-2021 00:24:53.667 WARNING [Thread-39] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [ROOT] appears to have started a thread named [DefaultQuartzScheduler_QuartzSchedulerThread] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:

Do you know what is going on here?
Screen Shot 2021-07-13 at 5.27.26 PM.png

Herrick, Rick

unread,
Jul 13, 2021, 8:36:23 PM7/13/21
to xnat_di...@googlegroups.com
Those messages are common on Tomcat shutdown and don’t really mean anything.

Sent: Tuesday, July 13, 2021 7:31:25 PM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: Re: [XNAT Discussion] xnat deployment on AWS 404 page not found
 

Gang Fu

unread,
Jul 13, 2021, 9:50:22 PM7/13/21
to xnat_discussion
Hi Rick,

The container shut off by itself, I cannot get much information from there, is there anything you need to debug it? I would be happy to jump on a call with you or anyone in the team :)

Best,
Steve

Herrick, Rick

unread,
Jul 14, 2021, 11:32:01 AM7/14/21
to xnat_di...@googlegroups.com

You should be able to get logs from the container after it’s terminated. I haven’t used CloudFormation so I don’t know how to configure logging on that, but there’s always a way to capture forensics info. Things that would be useful:

 

  • The Tomcat logs, from start-up to shutdown
  • The XNAT logs, if any are created (if whatever’s causing Tomcat to terminate is happening early enough, it’s possible that XNAT isn’t starting up to the point where logging is initiated)

 

Without that information, we wouldn’t be able to debug or troubleshoot at all.

 

Also, what is your configuration like and what are you using to deploy? Just deploying the containerized XNAT is insufficient because it doesn’t include PostgreSQL (that said, Tomcat should still start but XNAT won’t work at all). Configuring XNAT so that it finds its configuration files and the like is also critical.

Gang Fu

unread,
Jul 15, 2021, 6:37:19 PM7/15/21
to xnat_discussion
Hi Rick,

Which port shall I use for xnat-web? from the docker compose file, it looks like the container expose 8104: https://github.com/NrgXnat/xnat-docker-compose/blob/master/docker-compose.yml#L23
but the dockerfile expose 8080 and nginx does reverse proxy to 8080:

Best,
Steve

Gang Fu

unread,
Jul 15, 2021, 11:24:03 PM7/15/21
to xnat_discussion
I suppose the web portal is 8080 and dimse is port 8104. So I need to have application load balancer for port 8080 and network load balancer for port 8104. It seems working now.

Herrick, Rick

unread,
Jul 16, 2021, 4:43:10 PM7/16/21
to xnat_di...@googlegroups.com

Right, 8080 is the port to which nginx passes proxied requests, so it only needs to be exposed, i.e. open within the private network used by the docker-compose configuration but inaccessible from outside. 8104 is the default port for DICOM operations. If you want to be able to send DICOM to your XNAT using standard DICOM tools like dcmsend, storescu, Horos or Osirix, etc., the port(s) for your DICOM SCP receivers have to be accessible from outside the private network, i.e. published.

Gang Fu

unread,
Jul 19, 2021, 9:24:22 AM7/19/21
to xnat_di...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages