RE: Tomcat-7.0.23 startup deadlocks

Felix Schumacher Tue, 29 Nov 2011 00:46:56 -0800

Am 29.11.2011 01:28, schrieb Zampani, Michael:

-----Original Message-----
From: ma...@apache.org [mailto:ma...@apache.org]
Sent: Monday, November 28, 2011 4:02 PM
To: Tomcat Users List
Subject: Re: Tomcat-7.0.23 startup deadlocks


"Zampani, Michael" <zamp...@amazon.com> wrote:

>Hi,
>

>I'm trying to upgrade an existing webapp installation from 7.0.22->

>7.0.23.
>
>On startup, it appears to deadlock, with the threads stuck in
>ContainerBase.setRealm HostConfig.deployDirectories
>ContainerBase.startInternal
>
>server.xml and thread dump attached.
>Note that I do not define any <Realm>s in server.xml
>
>The webapp is simple and contains only static html, js, css, and
>images.
>Copying the web.xml from the example webapp shipped with tomcat
seems
>to fix it, but this worked in previous versions of Tomcat.
>Not sure if it's relevant, but it is the ROOT webapp.
>

>I've attached a sample WAR file to reproduce it. It should workfine

>once deployed.  Remove WEB-INF/web.xml and restart Tomcat to see it
>fail.
>
>Any ideas?
>
>-Michael
>

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

Attachments are usually blocked. Better to paste in-line.

Is there an actual deadlock or do things just seem to stop movingforwards?


Possible causes:

- threaded container starts (although they are still single threadedby default)

- caching of global web.xml to improve start times
- changes to redeployment code to correctly redeploy on context.xml
changes

If adding an empty web.xml works around this then at least there isa simple

fix for anyone that hits this issue (whatever it is).

Mark




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



Things certainly seem to stop moving forward.
If I attach JProfiler, I see two threads waiting on the same lock,
but I'm not familiar enough with the application to know if it's a
'real' deadlock.

I think you are right. When no realm is configured in server.xml and inthe context of a webapp, StandardEngine tries to set a default realm.That is guarded by a lock, which is held by the main thread.

To work around this problem, you can define a simple realm inside thecontext of your webapp or globally in server.xml.

To fix the problem we will have to look at the locking for setRealm inContainerBase.


Regards
 Felix


The webapp can be built simply by:
rm -r webapps/*
mkdir -p webapps/ROOT/WEB-INF
echo "<html><head><title>Hello world</title></head><body>Hello
World</body></html>" > webapps/ROOT/index.html

Web.xml[1] included before(copied from the example shipped withtomcat)

Thread dump attached at [2].  Hopefully my email client doesn’t'
clobber it beyond recognition.
Server.xml at [3]

[1]
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee";
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd";

  version="3.0"
  metadata-complete="true">

  <display-name>Welcome to Tomcat</display-name>
  <description>
     Welcome to Tomcat
  </description>

</web-app>

[2]
Full thread dump Java HotSpot(TM) Server VM (20.2-b06 mixed mode):

"pool-2-thread-1" prio=10 tid=0x0a0a0800 nid=0x326a waiting for
monitor entry [0x7bb94000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at

org.apache.catalina.core.ContainerBase.setRealm(ContainerBase.java:738)
        - waiting to lock <0x80aa2d70> (a
org.apache.catalina.core.StandardEngine)
        at

org.apache.catalina.core.StandardEngine.getRealm(StandardEngine.java:135)
        at

org.apache.catalina.core.ContainerBase.getRealm(ContainerBase.java:723)
        at

org.apache.catalina.core.ContainerBase.getRealm(ContainerBase.java:723)
        at

org.apache.catalina.startup.ContextConfig.authenticatorConfig(ContextConfig.java:380)

- locked <0xa32e0780> (aorg.apache.catalina.startup.ContextConfig)

        at

org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:839)

- locked <0xa32e0780> (aorg.apache.catalina.startup.ContextConfig)

        at

org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:302)
        at

org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
        at

org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
        at

org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5148)

- locked <0xa3265ec8> (aorg.apache.catalina.core.StandardContext)

        at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)

- locked <0xa3265ec8> (aorg.apache.catalina.core.StandardContext)

        at

org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:866)
        at

org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:842)
        at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
        at

org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1095)
        at

org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1617)
        at

java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)

atjava.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)

        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at

java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:662)

"pool-1-thread-1" prio=10 tid=0x7bcde000 nid=0x3269 waiting on
condition [0x7bbe5000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0xa31e0918> (a
java.util.concurrent.FutureTask$Sync)

atjava.util.concurrent.locks.LockSupport.park(LockSupport.java:156)

        at

java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
        at

java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
        at

java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)

atjava.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:218)

        at java.util.concurrent.FutureTask.get(FutureTask.java:83)
        at

org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1018)
        at

org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:473)

atorg.apache.catalina.startup.HostConfig.start(HostConfig.java:1412)

        at

org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:312)
        at

org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
        at

org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
        at

org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:401)