December 2011 - jbosscache-issues

[JBoss JIRA] (JBCACHE-1609) LegacyRegionManagerImpl#inactivateRegion locks the parent's entire subtree

by Dennis Reed (Created) (JIRA)

LegacyRegionManagerImpl#inactivateRegion locks the parent's entire subtree -------------------------------------------------------------------------- Key: JBCACHE-1609 URL: https://issues.jboss.org/browse/JBCACHE-1609 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.2.8.GA Reporter: Dennis Reed Assignee: Dennis Reed LegacyRegionManagerImpl#inactivateRegion calls lockManager.lockAll on the parent node, so instead of just locking the parent while the region is inactivated, it locks the parent's entire subtree (the entire cache if the region is a child of the root). In combination with JBCACHE-1608, this causes inactivateRegion to lock the parent's entire subtree and never unlock 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, 5 months

2
1
0 / 0

[JBoss JIRA] (JBCACHE-1607) LegacyRegionManagerImpl releases locks from other threads

by Dennis Reed (Created) (JIRA)

LegacyRegionManagerImpl releases locks from other threads --------------------------------------------------------- Key: JBCACHE-1607 URL: https://issues.jboss.org/browse/JBCACHE-1607 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.2.8.GA Reporter: Dennis Reed Assignee: Dennis Reed LegacyRegionManagerImpl calls lockManager.unlockAll(NodeSPI) instead of lockManager.unlockAll(NodeSPI, Owner owner). This will cause it to remove any locks currently held by other threads. Due to JBCACHE- lockManager.unlockAll(NodeSPI) is broken, so the effects are limited to the specific node. -- 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, 5 months

3
2
0 / 0

[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-1610) JDBCCacheLoader doesn't work with Oracle

by Dennis Reed (Created) (JIRA)

JDBCCacheLoader doesn't work with Oracle ---------------------------------------- Key: JBCACHE-1610 URL: https://issues.jboss.org/browse/JBCACHE-1610 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.2.8.GA Reporter: Dennis Reed Assignee: Dennis Reed The Oracle driver throws the exception "java.sql.SQLException: ORA-01461: can bind a LONG value only for insert into a LONG column" when the cacheloader tries to save more than a couple KB of data -- 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

6
10
0 / 0

[JBoss JIRA] (JBCACHE-1612) JBoss Cache NonManagedConnectionFactory will log the password in clear text when an exception occurs

by Tom Fonteyne (Created) (JIRA)

JBoss Cache NonManagedConnectionFactory will log the password in clear text when an exception occurs ---------------------------------------------------------------------------------------------------- Key: JBCACHE-1612 URL: https://issues.jboss.org/browse/JBCACHE-1612 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.2.8.GA Environment: all Reporter: Tom Fonteyne Assignee: Manik Surtani http://anonsvn.jboss.org/repos/jbosscache/core/trunk/src/main/java/org/jb... 088 public Connection getConnection() 089 { ...... 099 catch (SQLException e) 100 { 101 reportAndRethrowError("Failed to get connection for url=" + url + ", user=" + usr + ", password=" + pwd, e); So upon a connection error, the user/password will end up in the logfile in clear text -- 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
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] (JBCACHE-1611) Incompatible Berkeley DB (JE) Version

by wolfgang haefelinger (Created) (JIRA)

Incompatible Berkeley DB (JE) Version ------------------------------------- Key: JBCACHE-1611 URL: https://issues.jboss.org/browse/JBCACHE-1611 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.2.7.GA Environment: $ java -version java version "1.6.0_29" Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) geronimo@lhasa:~/Workspace/nosuchmeth $ uname -a Darwin lhasa 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 Reporter: wolfgang haefelinger Assignee: Manik Surtani Priority: Critical When trying to use Berkeley as cache loader (org.jboss.cache.loader.bdbje.BdbjeCacheLoader), I'm ending up in a "NoSuchMethodError", like shown below. {code} Caused by: java.lang.NoSuchMethodError: com.sleepycat.je.EnvironmentConfig.setAllowCreate(Z)Lcom/sleepycat/je/EnvironmentConfig; at org.jboss.cache.loader.bdbje.BdbjeCacheLoader.start(BdbjeCacheLoader.java:214) at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:464) ... 13 more {code} My code is simple enough, nothing more than getting a cache up and running: {code:java} static public void main(String... args) throws Exception { Cache cache; String cacheconfig = "my-jboss-cache.xml"; System.out.format("creating JBoss cache .."); CacheFactory factory = new DefaultCacheFactory(); /* create and start my cache */ System.out.format("loading cache config from %s",cacheconfig); cache = factory.createCache(cacheconfig); /* throws NoSuchMethod Exception */ System.out.format("creating JBoss cache - done."); } {code} It took me some time to dig into the problem, but here is the catch. The Berkeley engine I'm using is "je-3.2.76.jar". Decompiling class "com.sleepycat.je.EnvironmentConfig" reveals that "setAllowCreate(boolean)"'s signature is {code} $ javap -s -classpath je-3.2.76.jar com.sleepycat.je.EnvironmentConfig | fgrep -A 1 setAllow public void setAllowCreate(boolean); Signature: (Z)V {code} whereas a method returning "com.sleepycat.je.EnvironmentConfig" is expected. To put it in other words, this version of JBossCache has been compiled against a different version of Berkeley DB. Now, which version of Berkeley introduced that change? It appears to be changed from version JE 4.0.71 onwards, according to [1]. The changelog states the following: {quote} All public void setFoo() methods in com.sleepycat.je.*Config have been changed to return this instead of void. This allows multiple set calls to be placed on one line, similar to StringBuffer calls. For example, it is now possible to do the following: EnvironmentConfig envConf = new EnvironmentConfig(); envConf.setAllowCreate(true).setTransactional(true); This will require users to recompile their code. [#17021] {quote} The quote is almost correct. Not must users recompile their code, *frameworks like JBossCache must also clearly mention in their documentation the exact requirements they impose*. References: [1] http://download.oracle.com/otndocs/products/berkeleydb/html/je/je-40117-c... -- 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
0
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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues December 2011