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 > >
