Michael,

On 8/16/21 16:14, Michael Richardson wrote:

Christopher Schultz <ch...@christopherschultz.net> wrote:
     > Okay, all that looks fine to me, except the "9.0.16" part. That version
     > is *very/8 old. I see you are running Ubuntu: are you running the
     > latest release? That 9.0.16 number if rinning a bell about an older
     > release which was capped at 9.0.16. YOu might want to consider
     > upgrading everything once you figure all of this out. No need to muddy
     > the waters quite, yet, though.

Ubuntu 18.04.  I shall look for a ppa with newer tomcat.
It's a VM, I could go to Core 20.

Okay. We can get to that, later, but it's probably a good idea since it's probably nearing EOL. (I didn't bother checking.)

     > A few more things:

     > 1. It takes 12 seconds to initialize the server? That seems
     > ... slow. Is this on Amazon? What instance type? The memory size
     > 3.75GiB is ringing a bell, too.

I could go to 8G for the VM if you think that's relevant.
My reading is that I'm not even using 1G of ram at this point.

Nah, it's not important. But if it were an EC2 VM it's entirely possible that you are simply asking too much of it and the slowness/100% CPU is just "it's trying to do too much work."

No, it's not in Amazon.  It's a Dell Xeon workstation in the basement of my
wife's clinic.  Patient record confidentiality would probably contraindicate 
EC2 :-)

Not at all. EC2 is entirely reasonable for such purposes. Amazon will even grant you a signed BAA if you ask for one.

     > 2. You shouldn't have the "docs"
     > project depployed on a production system.

I installed it there to grep/read them, then decided that I'd install
that on my desktop.
Okay, no problem. As long as you know what you are doing. Often, seeing the "docs" application deployed means (somewhat ironically) "someone didn't read the documentation for going to production."

     > 3. I don't see any message
     > "Deploying deployment descriptor blah/blah/oscar/blah"

Yes, exactly.

Hmm.

Christopher Schultz <ch...@christopherschultz.net> wrote:
     >> 14-Aug-2021 17:16:45.464 SEVERE [Catalina-utility-1]
     >> org.apache.catalina.startup.HostConfig.deployWAR Error deploying web
     >> application archive [/var/lib/tomcat9/webapps/oscar.war]
     >> java.lang.IllegalStateException: Error starting child at
     >> 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:716)
     >> ...
     >>

     > That certainly looks bad. Are you building OSCAR yourself, or is it
     > pre-built? I'm assuming that all local customizations are done using
     > separate config files or in the database, right? Can you get a fresh
     > copy of the oscar.war file?

No, I'm not building myself.
There is an oscar.deb, which btw, results in the same 100%.

Okay, good. Does OSCAR distribute the .deb file? I'm ... weirdly surprised by that.

It also does other stuff like configure mariadb locally (which I don't want).

Interesting. You want control over your own database, or you don't want the db to be local (e.g. you want a remote db)?

But, I've used the oscar.war from that deb, and also the oscar.war which
is on the bare-metal version that is running.

Okay.

     >> 14-Aug-2021 17:16:45.506 INFO [Catalina-utility-1]
     >> org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
     >> application archive [/var/lib/tomcat9/webapps/oscar.war] has finished
     >> in [1,684] ms

     > That's nice and fast.

No, it's in error.

:) I was mostly joking.

     >> 14-Aug-2021 17:16:55.661 INFO [Catalina-utility-2]
     >> org.apache.catalina.startup.HostConfig.undeploy Undeploying context
     >> [/oscar] 14-Aug-2021 17:16:58.286 INFO [Catalina-utility-2]
     >> org.apache.catalina.startup.HostConfig.deployWAR Deploying web
     >> application archive [/var/lib/tomcat9/webapps/oscar.war]

     > Strange that it's deploying, then undeploying, then deploying again. Is
     > it possible that there are weird file timestamps? Maybe something in
     > the future?

I think that the cp of the 220M oscar.war hasn't completed when it starts
that first deploy.  That's why the ZIP error.

     >> My guess is that the cp oscar.war /var/lib/tomcat9/webapps hadn't
     >> actually finished yet when it tried to deploy it.

     > That can definitely break things. If you are going to drop a WAR file
     > on Tomcat, make sure that either Tomcat isn't running, or you are using
     > the Manager web application to upload-and-deploy the WAR file which
     > protects you from deploying mid-copy.

This is the only time I've seen this error, I've also used the manager web
application before.

Hmm. Same error there? Or same 100% CPU circumstances there?

     >> So the port is open, so I attempt to visit the /manage URL
     >>
     >> oscar-serv03-[~] root 31 #netstat -tan Active Internet connections
     >> (servers and established) Proto Recv-Q Send-Q Local Address Foreign
     >> Address State tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN tcp 0 0
     >> 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN
     >> tcp 0 0 192.168.2.13:22 192.168.2.3:56896 ESTABLISHED tcp 0 0
     >> 192.168.2.13:22 192.168.2.3:56898 ESTABLISHED tcp6 0 0 :::22 :::*
     >> LISTEN tcp6 0 0 :::8080 :::* LISTEN tcp6 559 0 192.168.2.9:8080
     >> 192.168.2.3:37486 ESTABLISHED
     >>
     >> And it just stalls.

     > Is there anything between Tomcat and your web browser? Like a reverse
     > proxy, firewall, etc.? What URL are you trying to hit?

I have an ssh -L 8080:192.168.2.9:8080 tunnel from my desktop.
There is nothing else in between.

     >> I went to eat lunch and watch TV, so waited a few hours, and it's the
     >> same afterwards.  Note that it never told me that it had finished
     >> deploying this war.
     >>
     >> I've tried kill-3 repeatedly, on the main PID of the process, and
     >> gotten no output.

     > Anything in the other log files?

Nope.

     > Instead of kill -3, what if you use the "jstack" utility and provide
     > the PID of the running process? (You'll want to provide the PID of the
     > parent JVM process, not a specific thread.)

I tried that.  It says something about there being no socket open.
My impression is that "jstack" was an Oracle Java only tool.

Nope, it's in all of the OpenJDK builds. You might need a "JDK" instead of a"JRE".

When you issue "kill -3", the thread dump should appear on stdout, which should be captured in logs/catalina.[date].log. If that's not happening, then I'm a bit confused...

Okay, try this:

1. Stop Tomcat, clear all logs, delete your oscar.war file and the exploded directory in CATALINA_BASE/webapps/oscar (or wherever your appBase points to). 2. Copy your oscar.war file into appBase, making sure that operation completes
3. Start Tomcat, but like this instead of what you usually do:

   $ sudo -iu tomcatuser
   $ $CATALINA_BASE/bin/catalina.sh run

That "run" is important: it will run Tomcat in the current console instead of in the background as a service. You'll get stdout directly on your console, no log files to worry about.

Watch everything try to start up. See what happens, obviously, specifically with oscar.war.

If you hit that 100% CPU (checking via another ssh connection, of course), then in the Tomcat connection you can press CTRL-\ on your keyboard to send a SIGQUIT to the current program (the JVM). That should generate a thread dump right on that console. Feel free to paste the entire thing into a post to this mailing list.

-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to