August 2011 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1523) JBoss Cache MBean print* operations return Object's toString()

by Ondrej Žižka (JIRA)

JBoss Cache MBean print* operations return Object's toString() -------------------------------------------------------------- Key: JBCACHE-1523 URL: https://jira.jboss.org/jira/browse/JBCACHE-1523 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Ondrej Žižka Assignee: Manik Surtani Priority: Minor 1) Run EAP 5, all config 2) Go to JMX console, jboss.cache:config=ha-partition,service=Cache 3) Invoke print* operations. Cache details: "/ null", as HTML /  null<br/> "Print configuration" returns only java.lang.Object's toString(), e.g. org.jboss.cache.config.Configuration@af91c6fa etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1410) Cache loaders that use StripedLock do not adequately lock root node when the root node is first added.

by Manik Surtani (JIRA)

Cache loaders that use StripedLock do not adequately lock root node when the root node is first added. ------------------------------------------------------------------------------------------------------ Key: JBCACHE-1410 URL: https://jira.jboss.org/jira/browse/JBCACHE-1410 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.0.0.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.0.0.GA, 2.X See detail on the forum post. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

4
12
0 / 0

[JBoss JIRA] Created: (JBCACHE-1603) Default eviction wakeupIntervalSeconds is 5000 with legacy configuration

by Dennis Reed (JIRA)

Default eviction wakeupIntervalSeconds is 5000 with legacy configuration ------------------------------------------------------------------------ Key: JBCACHE-1603 URL: https://issues.jboss.org/browse/JBCACHE-1603 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 3.2.7.GA Reporter: Dennis Reed Assignee: Dennis Reed When using the legacy eviction policy configuration format: <attribute name="EvictionPolicyConfig"> <config> <region name="/_default_" policyClass="org.jboss.cache.eviction.LRUPolicy"> <attribute name="timeToLiveSeconds">60</attribute> </region> </config> </attribute> without specifying wakeUpIntervalSeconds, the default is set to 5000 seconds instead of 5. (due to a mixup between milliseconds and seconds). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1600) CacheJmxWrapper ignores ClusterConfig attribute

by Dennis Reed (JIRA)

CacheJmxWrapper ignores ClusterConfig attribute ----------------------------------------------- Key: JBCACHE-1600 URL: https://issues.jboss.org/browse/JBCACHE-1600 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: 3.2.5.GA Reporter: Dennis Reed Assignee: Dennis Reed Attachments: test-service.xml When creating a cache using the CacheJmxWrapper: <mbean code="org.jboss.cache.jmx.CacheJmxWrapper" name="test:service=TreeCache"> <attribute name="CacheMode">REPL_SYNC</attribute> <attribute name="ClusterName">Test</attribute> <attribute name="ClusterConfig"> <config> <TCP start_port="12345" the ClusterConfig section is ignored, and a default JGroups configuration is used. The root cause is CacheJmxWrapper#setClusterConfig parses the contents of <ClusterConfig>, but doesn't save it, and always sets the result to null. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1585) JBossCache eviction thread creating a Timer without making the new thread a daemon thread

by Mats Henrikson (JIRA)

JBossCache eviction thread creating a Timer without making the new thread a daemon thread ----------------------------------------------------------------------------------------- Key: JBCACHE-1585 URL: https://jira.jboss.org/browse/JBCACHE-1585 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP13 Reporter: Mats Henrikson Assignee: Manik Surtani There is a problem where the class org.jboss.cache.eviction.RegionManager.EvictionTreeCacheListener.cacheStarted(), line 499: {code} evictionThread_ = new Timer(); {code} Since the new Timer() is created without telling it that it is a daemon thread this Timer thread will actually cause the JVM to not exit when the main() method of the application finishes - it makes it necessary to call System.exit() to shut the JVM down. Since this is the thread that periodically runs the specified eviction policy there is no need for it to cause the JVM to stay running - it's up to the developer to say if the JVM should stay running or not, not JBossCache. The line should be changed to something like: {code} evictionThread_ = new Timer(true); {code} in order to specify that this is a daemon thread. (At the same time it would also be good if the Timer is passed a thread name like for instance "JBossCache Eviction Thread".) Please see the JDK docs for more info: http://java.sun.com/j2se/1.5.0/docs/api/java/util/Timer.html#Timer(java.l... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
2
0 / 0

[JBoss JIRA] Commented: (JBCACHE-1332) Lock in eviction.Region:putNodeEvent()

by Yohan Liyanage (JIRA)

[ https://issues.jboss.org/browse/JBCACHE-1332?page=com.atlassian.jira.plug... ] Yohan Liyanage commented on JBCACHE-1332: ----------------------------------------- We are facing the same issue on JBoss 4.2.3.GA, running on Sun JDK 1.6 on a RHEL 5.3. JBoss is clustered with two nodes. We are using the JBoss cache version shipped with JBoss 4.2.3, which is, Version: 1.4.1.SP9 Codename: Cayenne CVS: $Id: Version.java 5474 2008-03-27 21:49:43Z jiwils $ History: (see http://jira.jboss.com/jira/browse/JBCACHE for details) So I assume this is not related to JBCACHE-1316. Here's a thread dump I have taken from our servers. "http-0.0.0.0-8081-6" daemon prio=10 tid=0x000000004a2be000 nid=0x2d61 in Object.wait() [0x0000000047f92000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at EDU.oswego.cs.dl.util.concurrent.BoundedLinkedQueue.put(BoundedLinkedQueue.java:303) - locked <0x00002aaad1781de0> (a EDU.oswego.cs.dl.util.concurrent.BoundedLinkedQueue) - locked <0x00002aaad1781e20> (a java.lang.Object) at org.jboss.cache.eviction.Region.putNodeEvent(Region.java:141) at org.jboss.cache.interceptors.EvictionInterceptor.doEventUpdatesOnRegionManager(EvictionInterceptor.java:149) at org.jboss.cache.interceptors.EvictionInterceptor.updateNode(EvictionInterceptor.java:122) at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:97) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:206) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) "http-0.0.0.0-8081-7" daemon prio=10 tid=0x000000004a2c0000 nid=0x2d62 waiting for monitor entry [0x0000000048093000] java.lang.Thread.State: BLOCKED (on object monitor) at EDU.oswego.cs.dl.util.concurrent.BoundedLinkedQueue.put(BoundedLinkedQueue.java:296) - waiting to lock <0x00002aaad1781e20> (a java.lang.Object) at org.jboss.cache.eviction.Region.putNodeEvent(Region.java:141) at org.jboss.cache.interceptors.EvictionInterceptor.doEventUpdatesOnRegionManager(EvictionInterceptor.java:149) at org.jboss.cache.interceptors.EvictionInterceptor.updateNode(EvictionInterceptor.java:122) at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:97) "http-0.0.0.0-8081-8" daemon prio=10 tid=0x000000004a2c2000 nid=0x2d63 waiting for monitor entry [0x0000000048194000] java.lang.Thread.State: BLOCKED (on object monitor) at EDU.oswego.cs.dl.util.concurrent.BoundedLinkedQueue.put(BoundedLinkedQueue.java:296) - waiting to lock <0x00002aaad1781e20> (a java.lang.Object) at org.jboss.cache.eviction.Region.putNodeEvent(Region.java:141) at org.jboss.cache.interceptors.EvictionInterceptor.doEventUpdatesOnRegionManager(EvictionInterceptor.java:149) at org.jboss.cache.interceptors.EvictionInterceptor.updateNode(EvictionInterceptor.java:122) at org.jboss.cache.interceptors.EvictionInterceptor.invoke(EvictionInterceptor.java:97) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:206) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.InvalidationInterceptor.invoke(InvalidationInterceptor.java:60) > Lock in eviction.Region:putNodeEvent() > -------------------------------------- > > Key: JBCACHE-1332 > URL: https://issues.jboss.org/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 > Assignee: 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1601) cache.getNode can delete data when using a passivation cache loader

by Dennis Reed (JIRA)

cache.getNode can delete data when using a passivation cache loader ------------------------------------------------------------------- Key: JBCACHE-1601 URL: https://issues.jboss.org/browse/JBCACHE-1601 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.2.5.GA Reporter: Dennis Reed Assignee: Dennis Reed When cache.getNode loads a passivated node, the data is not loaded, but it does trigger an eviction event. When eviction then passivates the node again, the data is overwritten. Similar to JBCACHE-825. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1602) NodeSPI.isDataLoaded is false for new node with optimistic locking

by Dennis Reed (JIRA)

NodeSPI.isDataLoaded is false for new node with optimistic locking ------------------------------------------------------------------ Key: JBCACHE-1602 URL: https://issues.jboss.org/browse/JBCACHE-1602 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.2.5.GA Reporter: Dennis Reed Assignee: Dennis Reed The following prints "true" with MVCC or Pessimistic locking, but "false" with Optimistic. cache.put ( fqn, key, test ); NodeSPI n = (NodeSPI)cache.getNode ( fqn ); System.out.println ( n.isDataLoaded() ); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1596) Initial state transfer with more than 200, 000 nodes deadlock on eviction queue

by Dennis Reed (JIRA)

Initial state transfer with more than 200,000 nodes deadlock on eviction queue ------------------------------------------------------------------------------ Key: JBCACHE-1596 URL: https://issues.jboss.org/browse/JBCACHE-1596 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 1.4.1.SP13 Reporter: Dennis Reed Assignee: Manik Surtani When the cache has more than 200,000 entries, state transfer deadlocks on the joining node, due to filling up and blocking the eviction queue before the eviction thread has been started. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues August 2011