You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by ma...@j-b-s.de on 2009/03/05 18:40:43 UTC
T5 ConcurrentBarrier / Deadlock
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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 ConcurrentBarrier / Deadlock
Posted by Andy Pahne <an...@googlemail.com>.
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, <ma...@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 ConcurrentBarrier / Deadlock
Posted by Alex Kotchnev <ak...@gmail.com>.
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, <ma...@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5 ConcurrentBarrier / Deadlock
Posted by Ville Virtanen <vi...@cerion.fi>.
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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org