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
