January 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, 2 months

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

13 years, 9 months

3
3
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, 12 months

4
15
0 / 0

[JBoss JIRA] Created: (JBCACHE-1511) NullPointerException in invalidateRegion

by Dennis Reed (JIRA)

NullPointerException in invalidateRegion ---------------------------------------- Key: JBCACHE-1511 URL: https://jira.jboss.org/jira/browse/JBCACHE-1511 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP9 Reporter: Dennis Reed Assignee: Dennis Reed (1.4.1.SP9 stack trace) Caused by: java.lang.NullPointerException at org.jboss.cache.TreeCache.inactivateRegion(TreeCache.java:2363) inactivateRegion uses marshaller_ without checking to see whether it is null. marshaller_ is only set if registerClassLoader() or unregisterClassLoader() is called on the cache before inactivateRegion is. -- 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

2
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-1545) remove does not remove node when using optimistic locking and called on an instance which does not contain the node.

by Dennis Reed (JIRA)

remove does not remove node when using optimistic locking and called on an instance which does not contain the node. -------------------------------------------------------------------------------------------------------------------- Key: JBCACHE-1545 URL: https://jira.jboss.org/jira/browse/JBCACHE-1545 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Replication Affects Versions: 1.4.1.SP13 Reporter: Dennis Reed Assignee: Manik Surtani With optimistic locking, remove ( String fqn ), and remove ( String fgn, Object key ) do not remove from other cluster members if the node does not exist in the local cache. This can happen when using invalidation, or when the node has been evicted. -- 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

3
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1565) Locking doesn't work when replication is used

by tbech (JIRA)

Locking doesn't work when replication is used --------------------------------------------- Key: JBCACHE-1565 URL: https://jira.jboss.org/jira/browse/JBCACHE-1565 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.2.1.GA Environment: Linux, Sun Java 5.0 Reporter: tbech Assignee: Manik Surtani Priority: Critical Attachments: exc.txt During performance tests of JBossCache, I've tried to test transactions with cache.getInvocationContext().getOptionOverrides().setForceWriteLock operation ('select-for-update'). I've used standard jbosscache benchmark from svn. I've created new product jbosscache3.2.1 based on 3.1.0 and new test. Basicaly it did: try { long startTime = System.nanoTime(); if (concurrentWrites) { cacheWrapper.startTransaction(); cacheWrapper.setForceWriteLock(true); } ObjectInCache o = (ObjectInCache) cacheWrapper.get(path, key); o = new ObjectInCache(Integer.valueOf(o.getVal().intValue() + 1), randStr[taskNumber%randStr.length]); cacheWrapper.put(path, key, o); if (concurrentWrites) { cacheWrapper.endTransaction(true); } long statValue = (System.nanoTime() - startTime); descriptiveStatistics.addValue(statValue); } catch (Throwable e) { log.error("Error appeared whilst writing to cache:" + e.getMessage(), e); try { if (concurrentWrites) { cacheWrapper.endTransaction(false); } } finally { } } finally { logRunCount(taskNumber); } concurrentWrites was set to true. This tests passes nicely in one node (local mode). However in 2,3,4 nodes it fails after first usage of the same object by different node with exception: org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn [/concurrent/Intermediate-0/Node 0] after [240000] milliseconds for requestor [GlobalTransaction:<10.118.236.212:40325>:0]! Lock held by [GlobalTransaction:<10.118.236.211:8112>:40] at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:159) It looks like, in replication the node is not beeing releases after transaction commit. -- 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, 1 month

4
10
0 / 0

[JBoss JIRA] Created: (JBCACHE-1567) Parent nodes not being evicted

by Galder Zamarreno (JIRA)

Parent nodes not being evicted ------------------------------ Key: JBCACHE-1567 URL: https://jira.jboss.org/jira/browse/JBCACHE-1567 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 3.2.2.GA, 3.1.0.GA, 3.0.3.GA Reporter: Galder Zamarreno Assignee: Galder Zamarreno It appears that parent nodes are sometimes not being evicted, leading to potential memory leaks. See attached failing test. Needs further investigation to find the cause root. -- 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, 2 months

2
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-1549) Buddy pool tracking when 2nd to last member leaves group

by Brian Stansberry (JIRA)

Buddy pool tracking when 2nd to last member leaves group -------------------------------------------------------- Key: JBCACHE-1549 URL: https://jira.jboss.org/jira/browse/JBCACHE-1549 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Buddy Replication Affects Versions: 3.2.1.GA Reporter: Brian Stansberry Assignee: Manik Surtani Priority: Critical If you have a 2 node cluster with buddy replication, and you restart one node, that node does not receive a state transfer. See forum thread for details of the exact symptoms. Problem is this in BuddyManager$AsyncViewHandlerThread.handleEnqueuedViewChange(): // there is a strange case where JGroups issues view changes and just includes self in new views, and then // quickly corrects it. Happens intermittently on some unit tests. If this is such a case, please ignore. if (members.newMembers.size() == 1 && members.newMembers.get(0).equals(cache.getLocalAddress())) { log.info("Ignoring membership change event since it only contains self."); return; } Problem is the if condition is always true when the 2nd to last member leaves the group, but returning leaves the last member in a state where it thinks the next to last member is still a buddy. When that node restarts and rejoins the group, the reassign buddies logic sees that the new member is already a buddy and returns without pushing state. -- 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, 3 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 January 2010