Hi Alex! Thanks for your answer. We run the app on different JVM's (all 1.6, Linux-64Bit, WindowsXP 32Bit, Mac-OS X 64Bit). I do not think this problem is related to a particular JVM version or an thread local problem at all. Maybe deadlock is the wrong word. Because of the fact that the thread which triggers the T5 reload mechanism never returned the whole application got frozen. None of the other threads can pass the ConcurrentBarrier while one thread is initiating the reload. It's not directly related to concurrency like two thread claim the same resources in different order. It's only one resource (T5-releod) but this one is never released as the request never finishes...
Jens I also recall the deadlock issues manifested themselves on particular JVM versions which were fixed in the latest updates. Which Java version are you running ? Cheers, Alex Kotchnev On Thu, Mar 5, 2009 at 12:40 PM, <mailingl...@j-b-s.de> wrote: > Hi! > > We encountered a "small" problem in the way tapestry detects changes of > tml's and classes which causes a server crash: in our special case the > request which detected changes used the ConcurrentBarrier write-lock to > block all other threads. This is ok as long you guarantee the request will > return. Due to a bug in the 64Bit VM concerning regex execution the regex > parser went into an indefinite loop. This causes a break down of the tomcat > as all other request where blocked when trying to pass the ConcurrentBarrier > which was never unlocked as the responsible thread never finished. Same > applies for example if you need to communicate to external systems and eg a > network/socket problem causes the thread to freeze which also locks the > whole server. Is it possible to move the lock/and rereading of tmls/classes > to a different thread if changes exist? Means regardless if the request > responsible for firing the update ever returns the tomcat remains accessible > after rereading? You can argue chances for this are not high, but since > SEP-08 we had this trouble two times in production... > Before I forget: affected version is T5.0.13. we are currently moving over > to T5.0.18, so maybe there is a solution yet? > > Jens > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
