There have been issues with Sun JVMs <= 1.6.10. (or < 1.6.10, I don't
recall it exactly).
Andy
Alex Kotchnev schrieb:
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
