If my memory servers me right T5 was having these problems all the way to 5.0.15 or 16, but today all of those are fixed afaik.
- Ville titöf 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 > > > -- View this message in context: http://www.nabble.com/T5-ConcurrentBarrier---Deadlock-tp22356659p22357014.html Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
