May 2010 - 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, 1 month

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, 4 months

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

12 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1582) ExpirationAlgorithm doesn't evict nodes that have been created in a long Tx

by Nicolas Filotto (JIRA)

ExpirationAlgorithm doesn't evict nodes that have been created in a long Tx ---------------------------------------------------------------------------- Key: JBCACHE-1582 URL: https://jira.jboss.org/browse/JBCACHE-1582 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 3.2.5.GA Reporter: Nicolas Filotto Assignee: Manik Surtani Attachments: TestExpirationAlgorithm.java, TestExpirationAlgorithm.java I noticed that I had a memory leak in my application when I use the ExpirationAlgorithm (maybe this bug happens with other algorithms) some nodes were never evicted. After a deeper investigation, I noticed that the no EvictionEntry was created for those nodes since the method getExpiration returns null (which also means that cache.peek(fqn, false) returns null). I finally found the problem, that is because if the Expiration Thread wakes up before that the related Tx is committed, it won't find the node into the cache so it will considered it as removed but in fact it is just because the Tx has not yet been committed. This has for consequence that the node will never be evicted and thus create a memory leak. Please find the related unit test as attached file. -- 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

3
15
0 / 0

[JBoss JIRA] Created: (JBCACHE-1571) ClusteredCacheLoader throws NPE

by Galder Zamarreno (JIRA)

ClusteredCacheLoader throws NPE ------------------------------- Key: JBCACHE-1571 URL: https://jira.jboss.org/jira/browse/JBCACHE-1571 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.2.2.GA Reporter: Galder Zamarreno Assignee: Manik Surtani See attached configuration and test case java.lang.NullPointerException at org.jboss.cache.loader.ClusteredCacheLoader.exists(ClusteredCacheLoader.java:212) at org.jboss.cache.loader.AbstractDelegatingCacheLoader.exists(AbstractDelegatingCacheLoader.java:94) at org.jboss.cache.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:311) at org.jboss.cache.interceptors.CacheLoaderInterceptor.visitGetNodeCommand(CacheLoaderInterceptor.java:176) at org.jboss.cache.commands.read.GetNodeCommand.acceptVisitor(GetNodeCommand.java:76) 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.visitGetNodeCommand(AbstractVisitor.java:115) at org.jboss.cache.commands.read.GetNodeCommand.acceptVisitor(GetNodeCommand.java:76) 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.visitGetNodeCommand(AbstractVisitor.java:115) at org.jboss.cache.commands.read.GetNodeCommand.acceptVisitor(GetNodeCommand.java:76) 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.visitGetNodeCommand(AbstractVisitor.java:115) at org.jboss.cache.commands.read.GetNodeCommand.acceptVisitor(GetNodeCommand.java:76) 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.visitGetNodeCommand(AbstractVisitor.java:115) at org.jboss.cache.commands.read.GetNodeCommand.acceptVisitor(GetNodeCommand.java:76) 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.visitGetNodeCommand(AbstractVisitor.java:115) at org.jboss.cache.commands.read.GetNodeCommand.acceptVisitor(GetNodeCommand.java:76) at org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287) at org.jboss.cache.invocation.CacheInvocationDelegate.getNode(CacheInvocationDelegate.java:494) at org.jboss.cache.invocation.NodeInvocationDelegate.getChild(NodeInvocationDelegate.java:361) at org.jboss.cache.invocation.NodeInvocationDelegate.addChild(NodeInvocationDelegate.java:330) at org.jboss.cache.loader.ClusteredCacheLoader2Test.test000(ClusteredCacheLoader2Test.java:36) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644) at org.testng.internal.Invoker.invokeMethod(Invoker.java:546) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:700) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1002) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:137) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:121) at org.testng.TestRunner.runWorkers(TestRunner.java:908) at org.testng.TestRunner.privateRun(TestRunner.java:617) at org.testng.TestRunner.run(TestRunner.java:498) at org.testng.SuiteRunner.runTest(SuiteRunner.java:329) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:324) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:296) at org.testng.SuiteRunner.run(SuiteRunner.java:201) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:915) at org.testng.TestNG.runSuitesLocally(TestNG.java:879) at org.testng.TestNG.run(TestNG.java:787) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:75) at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:110) -- 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, 8 months

2
8
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

13 years, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1581) Update the JBoss Cache 1.4.x documentation so that OL is not recommended

by Galder Zamarreno (JIRA)

Update the JBoss Cache 1.4.x documentation so that OL is not recommended ------------------------------------------------------------------------ Key: JBCACHE-1581 URL: https://jira.jboss.org/browse/JBCACHE-1581 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Galder Zamarreno Assignee: Manik Surtani Fix For: 1.4.1.SP14 Update the JBoss Cache 1.4.x documentation so that OL is not recommended. See JBCACHE-1544 -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1544) Optimistic locking and eviction

by Mircea Markus (JIRA)

Optimistic locking and eviction ------------------------------- Key: JBCACHE-1544 URL: https://jira.jboss.org/jira/browse/JBCACHE-1544 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mircea Markus Assignee: Manik Surtani Since eviction is done per node, it is easy to get the cache into a bad state. For example, a 2-node cluster, OPTIMISTIC, REPL_SYNC, 60 second eviction: On Node A: cache.put ( "/foo", 0, 0 ); // this could be from any node for ( ;; ) { Thread.sleep ( 30000 ); // wait 30 seconds cache.get ( "/foo", 0 ); // refresh the eviction timer so the node will never be evicted on A } --------- This is just using the default JBC versioning, and direct cache access. No hibernate. There's no special configuration for the cache except what I listed (OPTIMISTIC, REPL_SYNC, 60 second eviction). No code hitting the cache except what I listed below. By the way, this is EAP 4.3 CP05 (JBC 1.4.1.SP13). On Node B: // wait at least 60 seconds after the original put for the node to be evicted on B cache.put ( "/foo", 0, 0 ); // will always fail during replication to A: org.jboss.cache.optimistic.DataVersioningException: DataNode [/foo] version Ver=2 is newer than workspace node Ver=1 -- 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, 11 months

4
15
0 / 0

[JBoss JIRA] Created: (JBCACHE-1580) Type safety problem with dead member buddy backup region

by Brian Stansberry (JIRA)

Type safety problem with dead member buddy backup region -------------------------------------------------------- Key: JBCACHE-1580 URL: https://jira.jboss.org/jira/browse/JBCACHE-1580 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Buddy Replication, Cache loaders Affects Versions: 3.2.4.GA Reporter: Brian Stansberry Assignee: Manik Surtani Priority: Critical I'm seeing problems with data gravitation when testing JBC 3.2.4 against JBoss AS trunk and the current EAP branch. I think the problem I describe here goes back a long way; nothing new in 3.2.4, but for some reason it's popping up now.[1] The problem is that when a :DEAD member region is created, it gets a child node whose name is of type Integer. There is code in JBC that assumes names for all children of these :DEAD nodes will be of type Integer. But CacheLoaders, particularly FileCacheLoader, cannot make such a guarantee. If the attempt to determine the children of the :DEAD node results in a call to CacheLoader.getChildrenNames(), there are type safety problems, e.g. this failure when a cache get() for a non-existent Fqn is invoked: java.lang.ArrayStoreException: java.lang.String at java.util.AbstractCollection.toArray(AbstractCollection.java:171) at org.jboss.cache.commands.read.GravitateDataCommand.perform(GravitateDataCommand.java:135) at org.jboss.cache.interceptors.CallInterceptor.invokeCommand(CallInterceptor.java:108) at org.jboss.cache.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:99) at org.jboss.cache.commands.AbstractVisitor.visitGravitateDataCommand(AbstractVisitor.java:135) You can see the problem in this snippet from GravitateDataCommand.perform(): if (buddyFqnTransformer.isDeadBackupRoot(backupRoot)) { Set<Integer> deadChildNames = new TreeSet<Integer>(spi.getChildrenNames(backupRoot)); Integer[] elems = deadChildNames.toArray(new Integer[deadChildNames.size()]); spi.getChildrenNames() is not guaranteed to return a Set<Integer>, and definitely will not if it calls FileCacheLoader.getChildrenNames(). I've also seen ClassCastException in that same area in a compareTo() method being invoked by TreeSet. I'll attach a patch that makes the problem go away (i.e. allows the failing AS test to pass.) Basically adds a utility method to BuddyFqnTransformer that does a conversion of the return value from CacheLoader.getChildrenNames() to Set<Integer>. Then changes the 3 places that use the contents of the CacheLoader.getChildrenNames() to have them use this utility method. Another approach would be to change the return type of FileCacheLoader.getChildrenNames() to Set<?> (same as the interface) and call the new BuddyFqnTransformer utility method from there. But that changes the API of FileCacheLoader, plus requires injecting BuddyFqnTransformer into FileCacheLoader. Sorry; I don't have a proper unit test for this. :-( I thought this was an AS bug (there was a related one -- JBCLUSTER-269) and used all my time trying to fix it at the wrong level. [1] I only saw the problem when I started testing AS + 3.2.4 + JGroups 2.6.15. With 2.6.13 it didn't happen. I think the JGroups change must have for some reason resulted in :DEAD member regions being created that weren't before; the test that's failing involves stopping and starting caches. Perhaps a timing thing. There was a flaw in an AS class that should have resulted in the test failing if :DEAD member regions were being created before, so the fact that the test has been passing tells me they weren't. -- 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, 11 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1578) ExpirationAlgorithm doesn't seem to work properly when same fqn are modified and removed in parallel

by Nicolas Filotto (JIRA)

ExpirationAlgorithm doesn't seem to work properly when same fqn are modified and removed in parallel ---------------------------------------------------------------------------------------------------- Key: JBCACHE-1578 URL: https://jira.jboss.org/jira/browse/JBCACHE-1578 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.2.3.CR1, 3.2.3.GA Reporter: Nicolas Filotto Assignee: Manik Surtani Fix For: 3.2.3.CR1 Attachments: TestExpirationAlgorithm.java I have a memory leak in my application that uses the ExpirationAlgorithm, after a deeper investigation it seems that some nodes are never evicted so after a certain period of time I get OutOffMemoryError. I attached a UnitTest. -- 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, 12 months

3
10
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues May 2010