I appreciate your responses, but I'm afraid I don't know what a blocking
entropy is. Also, I don't appear to have any issues in resolving or
referencing DTDs during building.
I had posted another email indicating some more behavior, basically that
the delay occurs only when a new WAR file is deployed. If the WAR file
doesn't change, I can re-deploy it without any delays.
In addition, I grabbed some thread dumps during the delay. But I don't
know enough to know what to look for. I compared two of the thread
dumps taken one-minute apart. The only two differences in the files are
the timestamp at the top and the JNI global references count at the
bottom (the earlier dump showed 921, the later, 959).
Here is the earlier thread dump. Again, any help is greatly
appreciated:
--------------------------------------------------->8-------------------
------------------------------------------
2009-10-06 19:44:47
Full thread dump Java HotSpot(TM) Client VM (11.2-b01 mixed mode,
sharing):
"Low Memory Detector" daemon prio=6 tid=0x02c41800 nid=0xae0 runnable
[0x00000000..0x00000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"CompilerThread0" daemon prio=10 tid=0x02c3bc00 nid=0x490 waiting on
condition [0x00000000..0x02eef9bc]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"Attach Listener" daemon prio=10 tid=0x02c3a400 nid=0xd2c waiting on
condition [0x00000000..0x00000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"Signal Dispatcher" daemon prio=10 tid=0x02c39000 nid=0xc18 runnable
[0x00000000..0x00000000]
java.lang.Thread.State: RUNNABLE
Locked ownable synchronizers:
- None
"Finalizer" daemon prio=8 tid=0x02c30c00 nid=0x99c in Object.wait()
[0x02dff000..0x02dffa94]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x088f0288> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
- locked <0x088f0288> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
at
java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
Locked ownable synchronizers:
- None
"Reference Handler" daemon prio=10 tid=0x02c2f800 nid=0x9ec in
Object.wait() [0x02daf000..0x02dafb14]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x088f0310> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:485)
at
java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
- locked <0x088f0310> (a java.lang.ref.Reference$Lock)
Locked ownable synchronizers:
- None
"main" prio=6 tid=0x002a7000 nid=0xd5c runnable [0x0090f000..0x0090fe54]
java.lang.Thread.State: RUNNABLE
at java.io.FileOutputStream.close0(Native Method)
at java.io.FileOutputStream.close(FileOutputStream.java:279)
at java.io.FilterOutputStream.close(FilterOutputStream.java:143)
at
org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:324)
at
org.apache.catalina.startup.ExpandWar.expand(ExpandWar.java:158)
at
org.apache.catalina.startup.ContextConfig.fixDocBase(ContextConfig.java:
883)
at
org.apache.catalina.startup.ContextConfig.init(ContextConfig.java:1012)
at
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.j
ava:279)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSu
pport.java:117)
at
org.apache.catalina.core.StandardContext.init(StandardContext.java:5338)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4086
)
- locked <0x088f0710> (a
org.apache.catalina.core.StandardContext)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.ja
va:791)
- locked <0x088f08a0> (a java.util.HashMap)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at
org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:830)
at
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:719)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:490)
at
org.apache.catalina.startup.HostConfig.start(HostConfig.java:1149)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:31
1)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSu
pport.java:117)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
- locked <0x088f0500> (a org.apache.catalina.core.StandardHost)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
- locked <0x088f0500> (a org.apache.catalina.core.StandardHost)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
- locked <0x088f0a08> (a
org.apache.catalina.core.StandardEngine)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:516)
- locked <0x088f0a08> (a
org.apache.catalina.core.StandardEngine)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
- locked <0x088f0ae0> (a [Lorg.apache.catalina.Service;)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Locked ownable synchronizers:
- None
"VM Thread" prio=10 tid=0x02c2e000 nid=0xfa8 runnable
"VM Periodic Task Thread" prio=10 tid=0x02c4bc00 nid=0x5cc waiting on
condition
JNI global references: 921
--------------------------------------------------->8-------------------
------------------------------------------
-----Original Message-----
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, October 07, 2009 5:16 PM
To: Tomcat Users List
Subject: Re: Tomcat hangs for minutes between ContextConfig and
StandardContext (Starting the app)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rainer,
On 10/6/2009 2:00 PM, Rainer Jung wrote:
> On 06.10.2009 17:41, Christopher Schultz wrote:
>
>> Another possibility is that SecureRandom is taking forever to
>> initialize: if your JVM is configured to use a blocking source of
>> entropy, that may be the problem. This often happens in *NIX
>> environments, but it appears that you are running on Microsoft
>> Windows, so that's unlikely to be the problem.
>
> ... and should only be a problem if SSL is involved.
Doesn't Tomcat use SecureRandom for session id generation, at least
under certain configurations? This would trip over a blocking entropy
source regardless of SSL configuration, right?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkrNBQMACgkQ9CaO5/Lv0PC5igCgjVbDsu74+cKSGW4geTCezF9r
fE0An2X4LgJg8/jpkSV+Vgn+yjqdTpF/
=+3Ms
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
