June 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-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, 8 months

2
7
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-1514) Problems Binding JBoss Cache Instance in JNDI

by Matt Accola (JIRA)

Problems Binding JBoss Cache Instance in JNDI --------------------------------------------- Key: JBCACHE-1514 URL: https://jira.jboss.org/jira/browse/JBCACHE-1514 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.GA Environment: WebSphere 6.1.0.17 Reporter: Matt Accola Assignee: Manik Surtani Attempting to create a JBoss Cache instance and bind to JNDI for use by multiple applications. In WebSphere 6.1 the best way to do this is to create a Custom Service, http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/co.... I have attached a simple Custom Service which creates a new cache instance from an XML configuration file, obtains an InitialContext and attempts to bind the org.jboss.cache.Cache reference. The Custom Service is in the attached JBossCacheCustomService.jar. When I try to start the server I get the following error: com.ibm.ws.naming.util.CannotBindObjectException: Object is not of any type which can be bound. As described in the WebSphere 6.1 Info Center, http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/co... , this is because the object which is being bound is not Serializable. I have also attached the complete log of the server startup. -- 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
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-1516) CacheStoreInterceptor hangs when concurrent access to txStores HashMap

by Takayoshi Kimura (JIRA)

CacheStoreInterceptor hangs when concurrent access to txStores HashMap ---------------------------------------------------------------------- Key: JBCACHE-1516 URL: https://jira.jboss.org/jira/browse/JBCACHE-1516 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.GA, 1.4.0.GA Reporter: Takayoshi Kimura Assignee: Takayoshi Kimura CacheStoreInterceptor has a HashMap txStores instance variable for cache stats. This map is accessed from multiple threads but not synchronized. With Sun JVM, concurrent write operations to a HashMap sometimes hang. See the following bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6484560 This bug affects in all branches, 1.4.x, 2.2.x and 3.x. -- 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
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1517) Possibility of upgrading to JGroups 2.8 ?

by Galder Zamarreno (JIRA)

Possibility of upgrading to JGroups 2.8 ? ----------------------------------------- Key: JBCACHE-1517 URL: https://jira.jboss.org/jira/browse/JBCACHE-1517 Project: JBoss Cache Issue Type: Thirdparty Change Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 3.2.0.GA Reporter: Galder Zamarreno Assignee: Manik Surtani Can we upgrade JBC 3.2 to use JGroups 2.8? Bela said JGroups 2.6 and 2.8 don't have on the wire compatibility, so if JBC 3.2 and JBC 3.1 clusters would not be able to cluster. org.jboss.cache.buddyreplication.NextMemberBuddyLocator is using IpAddress to figure out if candidate and data owner are in the same machine: // assume they're both IpAddresses?? InetAddress inetC = ((IpAddress) candidate).getIpAddress(); InetAddress inetD = ((IpAddress) dataOwner).getIpAddress(); There's also some test classes making use of IpAddress, i.e. CacheJmxWrapperTest and GlobalTransactionTest -- 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

3
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-1518) getChild() returning null

by Galder Zamarreno (JIRA)

getChild() returning null ------------------------- Key: JBCACHE-1518 URL: https://jira.jboss.org/jira/browse/JBCACHE-1518 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.1.0.GA Reporter: Galder Zamarreno Assignee: Manik Surtani Running the following code from the user guide throws an NPE in line 3: 1. Map lotsOfData = generateData(); 2. cache.put("/a/b/c", lotsOfData); 3. cache.getRoot().getChild("/a").setResident(true); 4. cache.getRoot().getChild("/a/b").setResident(true); Needs further investigation... -- 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
7
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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues June 2009