I straightened out a number of startup deadlock issues for 5.2. They can
be very challenging to root out.
On Thu, Jun 14, 2012 at 9:47 PM, Jens Breitenstein TOC <
jens.breitenst...@t-o-c.biz> wrote:
> Hi Howard,
>
> In the past we had severe problems with T5 when a tomcat was started under
> heavy load. It deadlocked reproduceble in the classloader / bytecode
> instrumentation area. Thus we workaround this issue but clicking the index
> page manually ones before adding the tomcat to the loadbalancer (T5.0.x).
> Yesterday we faced a similar issue with the latest T5.3rc, but this is
> under investigation right , details will follow. I just want you to make
> aware that it is not uncommon to start T5 under heavy load as heavy load is
> the reason for adding new servers to the cluster ;-)
> Personally I think startup should be bulletproof.
>
I agree, but it is in the nature of race conditions to be difficult to
prove correctness in this area.
>
> Jens
>
> Von meinem iPad gesendet
>
> Am 14.06.2012 um 19:28 schrieb Howard Lewis Ship <hls...@gmail.com>:
>
> > I'm already somewhat unhappy at the complexity of the code; I'd prefer
> not
> > to make it any more complicated. I think race conditions on the write
> lock
> > are going to be pretty rare and probably only occur on a somewhat
> saturated
> > server at initial startup. I think twisting the code ever further.
> >
> > In addition, in a ReentrantReadWriteLock, the write lock appears to
> return
> > false if any thread has the read lock, which could result in
> > the initialization code never being run.
> >
> > On Thu, Jun 14, 2012 at 2:36 AM, Denis Stepanov <
> denis.stepa...@gmail.com>wrote:
> >
> >> Concurrency topic:
> >>
> >> Would it be possible to change the lazy init to check if write lock is
> >> already locked? It will eliminate the posibility of locking the write
> lock
> >> by more then one thread.
> >>
> >> try {
> >>
> >> readLock.lock();
> >>
> >> if(is need to init)
> >> {
> >> boolean hasWriteLock = false;
> >> try {
> >> readLock.unlock();
> >> hasWriteLock = writeLock.tryLock(); // Could be locked
> >> only once
> >> if(hasWriteLock)
> >> doInit();
> >> } finally
> >> {
> >> if(hasWriteLock)
> >> writeLock.unlock();
> >>
> >> readLock.lock(); // If the write lock is locked read threads
> >> will wait
> >> }
> >> }
> >> return ...
> >>
> >> } finally
> >> {
> >> readLock.unlock();
> >> }
> >>
> >>
> >
> >
> > --
> > Howard M. Lewis Ship
> >
> > Creator of Apache Tapestry
> >
> > The source for Tapestry training, mentoring and support. Contact me to
> > learn how I can get you up and productive in Tapestry fast!
> >
> > (971) 678-5210
> > http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
