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 > http://svn.apache.org/viewvc?view=revision&revision=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. Agreed. > 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
