March 2009 - jbosscache-issues - Jboss List Archives

[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-1495) the searchable cache indexes are not updated if there were data manipulation in transaction or batch

by Yan Falken (JIRA)

the searchable cache indexes are not updated if there were data manipulation in transaction or batch ----------------------------------------------------------------------------------------------------- Key: JBCACHE-1495 URL: https://jira.jboss.org/jira/browse/JBCACHE-1495 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: SearchableCache Environment: searchable cache version 1.0.0 GA Reporter: Yan Falken Assignee: Manik Surtani Priority: Blocker // runnable unit test: package problems; import org.hibernate.search.annotations.Field; import org.hibernate.search.annotations.ProvidedId; import org.hibernate.search.annotations.Indexed; import org.hibernate.search.annotations.Store; import org.jboss.cache.*; import org.jboss.cache.loader.jdbm.JdbmCacheLoaderConfig; import org.jboss.cache.config.Configuration; import org.jboss.cache.config.CacheLoaderConfig; import org.jboss.cache.search.SearchableCacheFactory; import org.jboss.cache.search.SearchableCache; import org.testng.annotations.Test; import org.testng.annotations.BeforeMethod; import org.apache.lucene.search.Query; import org.apache.lucene.search.BooleanQuery; import org.apache.lucene.search.TermQuery; import org.apache.lucene.search.BooleanClause; import org.apache.lucene.index.Term; import static org.testng.AssertJUnit.*; import java.util.Properties; import java.io.Serializable; @Test(groups = {"unit"}, sequential = true) public class IndexingInTransaction { private static final Fqn fname = Fqn.fromString("blah"); private Cache coreCache; private SearchableCache searchableCache; Node node; public IndexingInTransaction() { init(); } @BeforeMethod public void init() { CacheFactory factory = new DefaultCacheFactory(); Configuration c = new Configuration(); c.setInvocationBatchingEnabled(true); CacheLoaderConfig clc = new CacheLoaderConfig(); JdbmCacheLoaderConfig jclc = new JdbmCacheLoaderConfig(); jclc.setAsync(false); jclc.setFetchPersistentState(false); jclc.setIgnoreModifications(false); jclc.setPurgeOnStartup(true); jclc.setLocation("/tmp/c1"); clc.addIndividualCacheLoaderConfig(jclc); c.setCacheLoaderConfig(clc); coreCache = factory.createCache(c, false); SearchableCacheFactory f = new SearchableCacheFactory(); Properties p = new Properties(); p.put("hibernate.search.default.indexBase", "/tmp/c1idx"); searchableCache = f.createSearchableCache(coreCache, p, Entity.class); searchableCache.create(); searchableCache.start(); node = searchableCache.getRoot().addChild(fname); } @Test public void testPutEntitiesWithoutTransaction() { for (int i = 1; i <= 10; i++) { Entity e = getEntity(i); System.out.println("caching: " + e); Node c = node.addChild(Fqn.fromString(e.getName())); c.put(""+ e.getId(), e); } assertFalse(searchableCache.createQuery( Entity.searchByName("Name5")).list().isEmpty()); } @Test public void testPutEntitiesWithTransaction() throws Exception { ((CacheSPI)(coreCache)).getTransactionManager().begin(); for (int i = 11; i <= 20; i++) { Entity e = getEntity(i); System.out.println("caching: " + e); Node c = node.addChild(Fqn.fromString(e.getName())); c.put(""+ e.getId(), e); } ((CacheSPI)(coreCache)).getTransactionManager().commit(); assertFalse(searchableCache.createQuery( Entity.searchByName("Name15")).list().isEmpty()); } Entity getEntity(long id) { return new Entity(id, "Name" + id, "Surname" + id, true); } // public static void main(String[] args) { // IndexingInTransaction stb = new IndexingInTransaction(); // stb.init(); // } } @ProvidedId @Indexed class Entity implements Serializable { public static final String IDX_NAME = "name"; public static final String IDX_SURNAME = "surname"; private long id; @Field(store = Store.YES) private String name; @Field (store = Store.YES) private String surname; private boolean dead; Entity(long id, String name, String surname, boolean dead) { this.id = id; this.name = name; this.surname = surname; this.dead = dead; } public long getId() { return id; } public String getName() { return name; } public String getSurname() { return surname; } public boolean isDead() { return dead; } public static Query searchByName(String name) { BooleanQuery query = new BooleanQuery(); query.add(new TermQuery( new Term(Entity.IDX_NAME, name.toLowerCase())), BooleanClause.Occur.MUST); return query; } @Override public String toString() { return "Entity{" + "id=" + id + ", name='" + name + '\'' + ", surname='" + surname + '\'' + ", dead=" + dead + '}'; } } -- 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

14 years, 5 months

3
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-1500) RegionManager.createRegion allows duplicate region names

by Dennis Reed (JIRA)

RegionManager.createRegion allows duplicate region names -------------------------------------------------------- Key: JBCACHE-1500 URL: https://jira.jboss.org/jira/browse/JBCACHE-1500 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 1.4.1.SP9 Reporter: Dennis Reed Assignee: Manik Surtani RegionManager.createRegion does not check for duplicate region names. If two calls to RegionManager.createRegion for the same Fqn create regions A (first) and B (second): - all future cache operations will happen on B - EvictionTimerTask will only watch A, causing no evictions on B, and B's eviction queue will fill up. -- 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

2
3
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-1497) When adding node, CacheLoaderInterceptor locks child node before MVCCLockingInterceptor locks parent

by Krzysztof Sobolewski (JIRA)

When adding node, CacheLoaderInterceptor locks child node before MVCCLockingInterceptor locks parent ---------------------------------------------------------------------------------------------------- Key: JBCACHE-1497 URL: https://jira.jboss.org/jira/browse/JBCACHE-1497 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders, Locking Affects Versions: 3.0.3.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani Attachments: AddRemoveNodeDeadlockTest.java I finally got to the root cause of those deadlocks I mentioned in this forum thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=152123 It really is this issue of inverted locking order, but somewhere else than I originally looked. Turns out this only happen with cache loader configured: it's the CacheLoaderInterceptor that locks the child before locking parent, as is evident in these two stack traces: The child was locked first with this stack: java.lang.Exception: TRACE PREV at org.jboss.cache.lock.MVCCLockManager.lockAndRecord(MVCCLockManager.java:132) at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:155) at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:241) at org.jboss.cache.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:300) at org.jboss.cache.interceptors.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:165) at org.jboss.cache.interceptors.ActivationInterceptor.visitGetKeyValueCommand(ActivationInterceptor.java:132) at org.jboss.cache.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:97) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131) at org.jboss.cache.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:110) at org.jboss.cache.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:97) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301) at org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283) at org.jboss.cache.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:110) at org.jboss.cache.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:97) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:77) at org.jboss.cache.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:97) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178) at org.jboss.cache.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:130) at org.jboss.cache.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:110) at org.jboss.cache.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:97) at org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287) at org.jboss.cache.invocation.CacheInvocationDelegate.get(CacheInvocationDelegate.java:444) Then, the parent: ava.lang.Exception: TRACE at org.jboss.cache.lock.MVCCLockManager.lockAndRecord(MVCCLockManager.java:132) at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:155) at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:223) at org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutKeyValueCommand(MVCCLockingInterceptor.java:101) at org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutKeyValueCommand(PrePostProcessingCommandInterceptor.java:88) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.CacheLoaderInterceptor.visitPutKeyValueCommand(CacheLoaderInterceptor.java:137) at org.jboss.cache.interceptors.ActivationInterceptor.visitPutKeyValueCommand(ActivationInterceptor.java:146) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131) at org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301) at org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283) at org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:119) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178) at org.jboss.cache.interceptors.InvocationContextInterceptor.visitPutKeyValueCommand(InvocationContextInterceptor.java:82) at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100) at org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287) at org.jboss.cache.invocation.CacheInvocationDelegate.put(CacheInvocationDelegate.java:555) Cache loader and lockParentForChildInsertRemove are prerequisites for this to happen. But the test case (attached, might be a little hard to follow :) ) shows that the deadlock occurs only when adding a node, not when removing. -- 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
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1499) Race condition in RegionManager.createRegion

by Dennis Reed (JIRA)

Race condition in RegionManager.createRegion -------------------------------------------- Key: JBCACHE-1499 URL: https://jira.jboss.org/jira/browse/JBCACHE-1499 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 1.4.X Reporter: Dennis Reed Assignee: Manik Surtani There is a race condition in RegionManager.createRegion. If two calls to create a region with the same FQN come in at the same time, they may both succeed. The last one to be added will win in the RegionManager (stored in a ConcurrentHashMap), while the first will win in the EvictionTimerTask (stored in a HashSet). This will cause the Region to not be monitored for evictions, and allow the eviction queue to fill up. -- 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
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues March 2009