February 2009 - jbosscache-issues

[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] Created: (JBCACHE-1434) Fix UnitTestCacheFactory extractTestName method

by Dominik Pospisil (JIRA)

Fix UnitTestCacheFactory extractTestName method ----------------------------------------------- Key: JBCACHE-1434 URL: https://jira.jboss.org/jira/browse/JBCACHE-1434 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Dominik Pospisil Assignee: Dominik Pospisil UnitTestCacheFactory uses stack trace introspection to retreive executed test class name. It does not work if the factory method is called from a seperclass of test class. Find other way around to retrieve test class. -- 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, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1461) Possible problems with SQL metacharacters in JDBCCacheLoader

by Krzysztof Sobolewski (JIRA)

Possible problems with SQL metacharacters in JDBCCacheLoader ------------------------------------------------------------ Key: JBCACHE-1461 URL: https://jira.jboss.org/jira/browse/JBCACHE-1461 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.0.2.CR1, 2.2.1.CR1 Reporter: Krzysztof Sobolewski Assignee: Manik Surtani JDBCCacheLoader uses queries with LIKE operator, but passes search patterns constructed from query parameters without concern for metacharacters like '%' and '_'. A quick test can show the problem: add /a/b/c add /a/d/c remove /a/_/c find the cache is empty. Fortunately the problem is apparently limited to deleteNodeSql and recursiveChildrenSql, both in JDBCCacheLoaderConfig (and not in AdjListJDBCCacheLoaderConfig). -- 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

15 years, 4 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1432) Cache corrupted by 64bit windows member

by Bill Middleton (JIRA)

Cache corrupted by 64bit windows member --------------------------------------- Key: JBCACHE-1432 URL: https://jira.jboss.org/jira/browse/JBCACHE-1432 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.2.1.CR1 Environment: Windows 64bit OS with either 32 or 64bit jvm in cluster with any linux OS (32 or 64bit) with any linux jvm. Reporter: Bill Middleton Assignee: Manik Surtani Fix For: 3.1.0 Hello. We've run into some trouble in attempting to bring a 64bit windows machine into an existing cluster. The cluster has (had) two 64bit linux members and was running fine when we attempted to insert a 64bit windows machine into the cluster. Anytime the 64bit windows machine wrote a node, the node was thereafter unreadable by either of the original cluster members. Exceptions of the following form were thrown by the other members (will attach stacktrace as comment) I attempted to get help on this issue in the user forum, but it seems that nobody else is running 64bit windows as a cluster member with other OS's in the cluster. I hope perhaps someone can at least confirm this now formally? -- 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

15 years, 5 months

3
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-1476) TransactionLog generates spurious ERROR logs on read-only transactions

by Krzysztof Sobolewski (JIRA)

TransactionLog generates spurious ERROR logs on read-only transactions ---------------------------------------------------------------------- Key: JBCACHE-1476 URL: https://jira.jboss.org/jira/browse/JBCACHE-1476 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Transactions Affects Versions: 3.0.2.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani Attachments: TransactionLogTest.patch We're testing our internal component with JBoss Cache 3.x and we noticed lots of ERROR logs from TransactionLog like this one: 2009-02-11 13:47:49,773 ERROR [org.jboss.cache.transaction.TransactionLog] (main) Could not find matching prepare for commit: GlobalTransaction:<192.168.1.18:7900>:3 It turns out that these logs are harmless and happen only on transactions that are committed without doing any writes (i.e. read-only transactions). Even though it's mostly harmless, it's annoying, hence this bug. I'm going to attach a patch with a test case, which modifies the log4j configuration and adds a "deadly" appender to TransactionLog's logger to demonstrate the issue (it's a little bit funny...) -- 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

15 years, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-1483) TreeCache's findNode Method Throws NPE When findInternal Returns Null

by Jimmy Wilson (JIRA)

TreeCache's findNode Method Throws NPE When findInternal Returns Null --------------------------------------------------------------------- Key: JBCACHE-1483 URL: https://jira.jboss.org/jira/browse/JBCACHE-1483 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP11, 1.4.1.SP10, 1.4.1.SP9, 1.4.1.SP8 Reporter: Jimmy Wilson Assignee: Jimmy Wilson Fix For: 1.4.X findNode does not correctly handle cases where findInternal returns null. -- 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

15 years, 7 months

1
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-1449) Small lock confusion in CacheLoaderInterceptor

by Krzysztof Sobolewski (JIRA)

Small lock confusion in CacheLoaderInterceptor ---------------------------------------------- Key: JBCACHE-1449 URL: https://jira.jboss.org/jira/browse/JBCACHE-1449 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.2.1.CR1 Reporter: Krzysztof Sobolewski Assignee: Manik Surtani I was doing another torture-test of one of my components based on JBoss Cache and noticed mysterious "can't lock node" exceptions. The test is very simple: 5 threads are trying to retrieve one node's key, 5 other threads try to delete it. Long story short, I think the result is one the smallest fixed I've ever seen :) Index: src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java =================================================================== --- src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java (revision 6986) +++ src/main/java/org/jboss/cache/interceptors/CacheLoaderInterceptor.java (working copy) @@ -245,7 +245,7 @@ { NodeSPI n = dataContainer.peek(fqn, true, true); Object lockOwner = lockManager.getLockOwner(ctx); - boolean needLock = n != null && !lockManager.ownsLock(fqn, lockOwner); + boolean needLock = n != null && !lockManager.ownsLock(n, lockOwner); boolean mustLoad = false; try { It seems that when the node (n) is deleted, the lockManager checks some different nodes map, when it uses the node's FQN, than is later checked on line 252, where it tries to read-lock the node (and fails, because it's already locked by pessimistic locking interceptor). -- 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

15 years, 9 months

2
10
0 / 0

[JBoss JIRA] Created: (JBCACHE-1402) Memcached server based on JBoss Cache

by Manik Surtani (JIRA)

Memcached server based on JBoss Cache ------------------------------------- Key: JBCACHE-1402 URL: https://jira.jboss.org/jira/browse/JBCACHE-1402 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.0.0.GA This is to create a simple server daemon (similar to a TcpCacheServer) that uses memcached's binary and RESTful protocols, which proxy requests to the cache. Simply called CacheServer? A CacheClient could also be created, which implements Cache and uses the memcached protocol to speak to CacheServer. Consistent hashing could be used to select the server picked, server topology could be piggybacked with responses back to the CacheClient. This would allow us to: 1. Use CacheClient with memcached backends 2. Use memcached front-ends (Java, Python, Perl, C) to speak to JBoss Cache backends 3. Allow for a heterogenous mix of backends. In future the TcpCacheServer could simply be replaced with CacheServer and the TcpCacheLoader updated to use the CacheClient. -- 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

15 years, 9 months

1
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1418) Expose locality of data for partitioned caches

by Manik Surtani (JIRA)

Expose locality of data for partitioned caches ---------------------------------------------- Key: JBCACHE-1418 URL: https://jira.jboss.org/jira/browse/JBCACHE-1418 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Replication Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.2.0 After we implement a distributed cache based on partitioning, JBCACHE-61, we should also expose a mechanism to locate data within a cluster, to help compute grid products like FishFarm (https://fishfarm.dev.java.net/) and GridGain (http://www.gridgain.org). Perhaps something like: DataLocator dl = Cache.getDataLocator(); // return a null if not using a partitioned cache? Or a specialized DataLocator that statically assumes a fully replicated cache or a local cache depending on cache mode? List<Address> addresses = dl.locate(myFqn); // locate single fqns. Return a list of addresses since it may exist on > 1 node Map<Fqn, List<Address>> as = dl.locate(fqn1, fqn2, fqn3); // locate multiple fqns -- 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

15 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1416) Allow to put jboss cache and log4j libs in the WEB-INF/lib dir. The Cache#shutdown and Cache#stop methods are not blocking an provok errors when undeploying a webapp.

by Laurent Mimoun (JIRA)

Allow to put jboss cache and log4j libs in the WEB-INF/lib dir. The Cache#shutdown and Cache#stop methods are not blocking an provok errors when undeploying a webapp. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBCACHE-1416 URL: https://jira.jboss.org/jira/browse/JBCACHE-1416 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 2.2.0.GA Environment: tomcat6 Reporter: Laurent Mimoun Assignee: Manik Surtani Priority: Critical When undeploying the webapp, here is the errors in the logs : Sep 25, 2008 7:50:36 PM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive ROOT.war Sep 25, 2008 7:55:33 PM org.apache.catalina.startup.HostConfig checkResources INFO: Undeploying context [] Sep 25, 2008 7:55:33 PM org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive ROOT.war Sep 25, 2008 7:55:34 PM org.apache.catalina.loader.WebappClassLoader loadClass INFO: Illegal access: this web application instance has been stopped already. Could not load java.io.PrintWriter. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact. java.lang.IllegalStateException at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1246) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1206) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.apache.log4j.spi.LoggingEvent.<init>(LoggingEvent.java:154) at org.apache.log4j.Category.forcedLog(Category.java:388) at org.apache.log4j.Category.log(Category.java:853) at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193) at org.jgroups.protocols.MPING.run(MPING.java:362) at java.lang.Thread.run(Thread.java:619) Sep 25, 2008 7:55:34 PM org.apache.catalina.loader.WebappClassLoader loadClass INFO: Illegal access: this web application instance has been stopped already. Could not load org.apache.log4j.spi.VectorWriter. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact. java.lang.IllegalStateException at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1246) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1206) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.apache.log4j.spi.LoggingEvent.<init>(LoggingEvent.java:154) at org.apache.log4j.Category.forcedLog(Category.java:388) at org.apache.log4j.Category.log(Category.java:853) at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193) at org.jgroups.protocols.MPING.run(MPING.java:362) at java.lang.Thread.run(Thread.java:619) Sep 25, 2008 7:55:34 PM org.apache.catalina.loader.WebappClassLoader loadClass INFO: Illegal access: this web application instance has been stopped already. Could not load org.apache.log4j.spi.VectorWriter. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact. java.lang.IllegalStateException at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1246) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1206) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at org.apache.log4j.spi.LoggingEvent.<init>(LoggingEvent.java:154) at org.apache.log4j.Category.forcedLog(Category.java:388) at org.apache.log4j.Category.log(Category.java:853) at org.apache.commons.logging.impl.Log4JLogger.error(Log4JLogger.java:193) at org.jgroups.protocols.Discovery$PingSenderTask$1.run(Discovery.java:389) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) Sep 25, 2008 7:55:36 PM org.apache.catalina.loader.WebappClassLoader loadClass INFO: Illegal access: this web application instance has been stopped already. Could not load org.apache.log4j.spi.VectorWriter. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact. After a closer analysis, the reason is quite simple, in the destroy method of the servlet of my webapp, the method Cache#stop is called but this method doesn't wait that the jgroups thread to finish. So the destroy method returns but there are still jgroups thread in the jvm. These threads sometimes use the log4j api (that is in the war too) to log message but the classloader of the webapp is no more avalaible to load the log4j classes because the webapp has been undeployed, that's why an "could not load class ...log4j" happens. To fix the problem, I think the lifecycle methods of jboss cache must be blocking is the case of using jgroups threads. This way the jboss cache and log4j will be able to be packaged in a single war file that is very a good thing in terms of maintenance developpement and so on. -- 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

15 years, 9 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues February 2009