tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Tomcat-7.0.23 startup deadlocks
Date Tue, 29 Nov 2011 19:56:18 GMT
On 29/11/2011 19:27, Zampani, Michael wrote:
>> I think you are right. When no realm is configured in server.xml and in the
>> 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 the
>> context of your webapp or globally in server.xml.
>> To fix the problem we will have to look at the locking for setRealm in
>> ContainerBase.
>> Regards
>>   Felix
> I can confirm that reverting CLN 1190190
> fixes this.
> Alternatively, removing the synchronized block from setRealm() also 'fixes' this.
> It looks like we can add some locks around Realm,

That fix has just been applied to trunk and will be back-ported shortly.

> but it doesn't look like ContainerBase is even close to being actually threadsafe.


> I'm not sure what the existing standards for Tomcat code are in this area.

That is a grey area. Generally, we avoid making code thread safe unless
we have to. The ContainerBase and related code generally doesn't need to
be thread safe as there is only ever one thread working with that code.
The threaded deployment doesn't really change that. Where thread safety
does come in is when we consider on-the-fly updating e.g. via JMX while
the component is in the STARTED state. Generally, we look at those
issues on a case-by-case basis and where there is a good case for
on-the-fly updates, we make it thread safe, where there isn't we make it
read-only. One of the parts of the GSOC project that looked at JMX a few
years ago was meant to review all attributes for thread-safety (and
expected to make most of them read-only). Unfortunately, that project
didn't make much progress.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message