[jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1332) Lock in eviction.Region:putNodeEvent()
Nicolas Lebreton (JIRA)
jira-events at lists.jboss.org
Tue May 6 05:39:20 EDT 2008
[ http://jira.jboss.com/jira/browse/JBCACHE-1332?page=comments#action_12411848 ]
Nicolas Lebreton commented on JBCACHE-1332:
-------------------------------------------
Hi Manik,
I have tried to update JBoss Cache to the version 1.4.1 SP9. I have seen on "JBoss Application Server, JBossCache and JGroups Compatibility Matrix" document, that this version of JBoss Cache is only compatible with JGroups 2.2.9.x and 2.3.x. Unfortunately, Tomcat cluster was not able to find expected methods with JGroups 2.2.9 SP4 and JGroups 2.3.
Any suggestions ?
Cheers,
Nicolas.
> Lock in eviction.Region:putNodeEvent()
> --------------------------------------
>
> Key: JBCACHE-1332
> URL: http://jira.jboss.com/jira/browse/JBCACHE-1332
> Project: JBoss Cache
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Eviction
> Affects Versions: 1.4.1.SP1
> Environment: JBoss 4.05
> Hibernate 3.2.6.ga
> Reporter: Nicolas Lebreton
> Assigned To: Manik Surtani
> Priority: Critical
> Fix For: 1.4.X
>
> Attachments: 2008-04-10-molene.nexotelematics.com_susan_node2_Percentage db connections in use.jpg, 2008-04-25 locktree.svg, jboss-service.xml, ThreadDumps.zip
>
>
> JBoss TreeCache is used as cache provider. Please find attached jboss-service.xml configuration file.
> The second level cache is actitated, and several read-only classes are cacheable:
> <cache usage="read-only"/>
> The query cache is activated, and few queries are cacheable:
> <query name="ActorType.listAll.named" cacheable="true">
>
> We encounter an issue. It can be reproduced on an environment with only few users connected (less than 10). For those users, screen is refreshed every 30 seconds through Ajax requests.
> Application is running in a cluster. On the other hand, this issue occurs with only one node started. A JBoss is started. Less than 24 hours later, application is becoming unresponsive. JBoss then needs to be recycled. And it works.
> Before stoping the node, I have taken several thread dumps separated by at least 30 seconds. Please find attached 10th, 11th, 25th's output files. We noticed thread locks in these 3 snapshots. The stack trace of the culprit was always the same (please see attached outputs for more details):
> # java.lang.Object:wait
> # waiting on-->EDU.oswego.cs.dl.util.concurrent.BoundedLinkedQueue(0x9331fd60)
> # java.lang.Object:wait(Object.java:474)
> # EDU.oswego.cs.dl.util.concurrent.BoundedLinkedQueue:put
> # locked-->EDU.oswego.cs.dl.util.concurrent.BoundedLinkedQueue(0x9331fd60)
> # locked-->java.lang.Object(0x9331fe78)
> # org.jboss.cache.eviction.Region:putNodeEvent(Region.java:141)
> # org.jboss.cache.interceptors.EvictionInterceptor:doEventUpdatesOnRegionManager(EvictionInterceptor.java:145)
> # org.jboss.cache.interceptors.EvictionInterceptor:updateNode(EvictionInterceptor.java:118)
> # org.jboss.cache.interceptors.EvictionInterceptor:invoke(EvictionInterceptor.java:93)
> Nicolas
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list