Jens, once again, I'm not the right person to respond to the question of whether it's possible to move the reloading to a different thread if changes exist - probably a queston for one of the core devs. Although, if you say that the root of the issue is a bug in the 64 bit JVM (that may be fixed some day), I'm not sure how much water the argument would hold.
On your issues around T5 versions : although I don't recall the details, I definitely know that some deadlock issues (with the startup of the app) were dealt with in the versions between 5.0.13 and 5.0.18; thus, trying out 5.0.18 would be strongly recommended before the option above. Cheers, Alex Kotchnev On Mon, Mar 9, 2009 at 7:08 PM, <mailingl...@j-b-s.de> wrote: > 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 > >
