October 2011 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1604) NullPointerException in ResourceDMBean.invoke()

by Takayoshi Kimura (JIRA)

NullPointerException in ResourceDMBean.invoke() ----------------------------------------------- Key: JBCACHE-1604 URL: https://issues.jboss.org/browse/JBCACHE-1604 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: JMX Affects Versions: 3.2.7.GA Reporter: Takayoshi Kimura Assignee: Manik Surtani Priority: Minor ResourceDMBean.invoke(String name, Object[] args, String[] sig) throws NullPointerException when sig == null. JMX spec doesn't guarantee it's non-null, so we should check it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
3
0 / 0

[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, 10 months

3
4
0 / 0

[JBoss JIRA] (JBCACHE-1605) Concurrency issues with multiple threads calling cache.start

by Dennis Reed (Created) (JIRA)

Concurrency issues with multiple threads calling cache.start ------------------------------------------------------------ Key: JBCACHE-1605 URL: https://issues.jboss.org/browse/JBCACHE-1605 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.2.8.GA Reporter: Dennis Reed Assignee: Dennis Reed There is no synchronization on cache.start, and concurrent calls to start the same cache cause errors. This is particularly an issue in AS 5, where caches are retrieved from the EAP CacheManager and the first user of the cache must start it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

5
5
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

13 years

4
12
0 / 0

[JBoss JIRA] (JBCACHE-1606) TimeoutException causes unreleased locks

by Jean-Pierre GRILLON (Created) (JIRA)

TimeoutException causes unreleased locks ---------------------------------------- Key: JBCACHE-1606 URL: https://issues.jboss.org/browse/JBCACHE-1606 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 1.4.1.SP13 Reporter: Jean-Pierre GRILLON Assignee: Manik Surtani 5 nodes in JBoss Cache, pessimistic locking: /a/b/c1 /a/b/c2 /a/b/locked /a/b/c3 /a/b/c4 And the node "/a/b/locked" is write-locked by another thread. Then try to delete entire node "/a/b". Node.acquireAll successfully acquires write-lock on "/a/b/c1" and "/a/b/c2", but a TimeoutException occurs on "/a/b/locked" (which is expected). After this exception, locks on "/a/b/c1" and "/a/b/c2" are not released. Actually, Node.acquireAll shall return acquired locks, but in this case doesn't return anything but throws an exception. So, previously acquired locks are not in "cache.getLockTable()", and can't be released by UnlockInterceptor. TestCase attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

4
4
0 / 0

hi Jboss

by Meena Rajani

hi Jboss what have you been up to? you'll get the hang of this before you know it http://t.co/m6Cezebw

13 years, 2 months

1
0
0 / 0

Re: [jbosscache-issues] Hi Jboss

by Meena Rajani

hi Jboss how have you been doing? i'm so lucky i saw this http://t.co/NesDfmCz

13 years, 2 months

1
0
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

13 years, 2 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

13 years, 2 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

13 years, 2 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues October 2011