April 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1763) Upgrade to Netty 3.3.x

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-1763: -------------------------------------- Summary: Upgrade to Netty 3.3.x Key: ISPN-1763 URL: https://issues.jboss.org/browse/ISPN-1763 Project: Infinispan Issue Type: Component Upgrade Components: Cache Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.FINAL Upgrade to Netty 3.3.0 - http://netty.io/blog/2012/01/19/ This upgrade brings a new websockets implementation, so consider replacing the existing one with the new one in 3.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
3
0 / 0

[JBoss JIRA] (ISPN-1991) Upgrade to Netty 3.4

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-1991: -------------------------------------- Summary: Upgrade to Netty 3.4 Key: ISPN-1991 URL: https://issues.jboss.org/browse/ISPN-1991 Project: Infinispan Issue Type: Component Upgrade Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.FINAL Upgrade to Netty 3.4 and make the necessary changes to servers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
1
0 / 0

[JBoss JIRA] (ISPN-2014) Change default worker thread count for Infinispan servers

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2014: -------------------------------------- Summary: Change default worker thread count for Infinispan servers Key: ISPN-2014 URL: https://issues.jboss.org/browse/ISPN-2014 Project: Infinispan Issue Type: Enhancement Components: Cache Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.4.FINAL Currently this is: 20 * Runtime.getRuntime.availableProcessors() Tests (JBQA-6031) have shown lower worker numbers to work better, and Norman Maurer (netty developer) suggests: 2 * Runtime.getRuntime.availableProcessors() So, let's change default to that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
2
0 / 0

[JBoss JIRA] (ISPN-2012) Add ability to specify lockAcquisitionTimeout on operation basis

by Dmitry Udalov (JIRA)

Dmitry Udalov created ISPN-2012: ----------------------------------- Summary: Add ability to specify lockAcquisitionTimeout on operation basis Key: ISPN-2012 URL: https://issues.jboss.org/browse/ISPN-2012 Project: Infinispan Issue Type: Feature Request Components: Locking and Concurrency Affects Versions: 5.1.2.FINAL Environment: Windows 7 64-bit Reporter: Dmitry Udalov Assignee: Manik Surtani The timeout for cache.getAdvancedCache().lock(Key) is determined by LockAcquisitionTimeout which is set for the entire cache.https://docs.jboss.org/author/display/ISPN/Configuring+cache+progra.... It makes the timeout a property of cached objects and the same across the entire cache. It seems that it would make sense to consider timeout as property of operations performed on the cache objects, not the objects. So it would be up to a caller to specify the timeout, similarly to standard "tryLock(long, TimeUnit)" functionality. I set priority "Major" because a client has one shot only. If it cannot acquire the lock then the entire transaction fails -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
0
0 / 0

[JBoss JIRA] (ISPN-2006) PutMapCommand throws a NullPointerException in Distributed Mode

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-2006: --------------------------------- Summary: PutMapCommand throws a NullPointerException in Distributed Mode Key: ISPN-2006 URL: https://issues.jboss.org/browse/ISPN-2006 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.1.4.CR1 Environment: Infinispan 5.2.0-SNAPSHOT Reporter: Pedro Ruivo Assignee: Manik Surtani I've spotted a bug in PutMapCommand. When the keys in the Command touches in multiple nodes, the remote nodes (nodes that didn't created the command) can throw the exception [1] when executing the perform() method. I'm using a transactional cache. The test case in [2] reproduces the bug. [1] Exception: {code} Caused by: java.lang.NullPointerException at org.infinispan.commands.write.PutMapCommand.perform(PutMapCommand.java:79) at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:83) at org.infinispan.commands.AbstractVisitor.visitPutMapCommand(AbstractVisitor.java:82) at org.infinispan.commands.write.PutMapCommand.acceptVisitor(PutMapCommand.java:67) {code} [2] branch: https://github.com/pruivo/infinispan/tree/issue_2 test case: https://github.com/pruivo/infinispan/blob/issue_2/core/src/test/java/org/... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
5
0 / 0

[JBoss JIRA] (ISPN-2011) Minimise window of stale keys in KeyAffinityService

by Manik Surtani (JIRA)

Manik Surtani created ISPN-2011: ----------------------------------- Summary: Minimise window of stale keys in KeyAffinityService Key: ISPN-2011 URL: https://issues.jboss.org/browse/ISPN-2011 Project: Infinispan Issue Type: Enhancement Components: Distributed Cache Affects Versions: 5.1.3.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.4.FINAL There is a window where requesters retrieve keys from a pool of generated keys and the system flushes the pool during a topology change. This window can be drastically reduced using a slightly coarser grained read lock. This fix also makes the flushing of the pool synchronous with the topology change. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
2
0 / 0

[JBoss JIRA] (ISPN-2010) Cache lookup of known instances in REST servlet

by Manik Surtani (JIRA)

Manik Surtani created ISPN-2010: ----------------------------------- Summary: Cache lookup of known instances in REST servlet Key: ISPN-2010 URL: https://issues.jboss.org/browse/ISPN-2010 Project: Infinispan Issue Type: Enhancement Components: Cache Server Affects Versions: 5.1.3.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.4.FINAL Similar to the fix applied for the Hot Rod endpoint, we shouldn't call cacheManager.getCacheNames().contains() all the time as this is expensive and generates a lot of garbage. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-1418) FileCacheStore throws an IllegalMonitorStateException in FileCacheVamTest

by Dan Berindei (JIRA)

FileCacheStore throws an IllegalMonitorStateException in FileCacheVamTest ------------------------------------------------------------------------- Key: ISPN-1418 URL: https://issues.jboss.org/browse/ISPN-1418 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 5.1.0.ALPHA2 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Minor Fix For: 5.1.0.BETA1 If there are no expired elements the bucket will not be modified and the lock doesn't need to be acquired. We were still releasing the lock though, leading to IllegalMonitorStateExceptions in FileCacheStoreVamTest: 2011-09-25 11:54:46,000 ERROR (testng-FileCacheStoreVamTest) [org.infinispan.test.fwk.UnitTestTestNGListener] Method testLoadAndStoreWithLifespan(org.infinispan.loaders.file.FileCacheStoreVamTest) threw an exception java.lang.IllegalMonitorStateException at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:398) at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1340) at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:778) at org.infinispan.util.concurrent.locks.StripedLock.releaseLock(StripedLock.java:135) at org.infinispan.loaders.LockSupportCacheStore.unlock(LockSupportCacheStore.java:87) at org.infinispan.loaders.file.FileCacheStore.purgeInternal(FileCacheStore.java:244) at org.infinispan.loaders.AbstractCacheStore$2.run(AbstractCacheStore.java:106) at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:48) at org.infinispan.loaders.AbstractCacheStore.purgeExpired(AbstractCacheStore.java:103) at org.infinispan.loaders.BaseCacheStoreTest.purgeExpired(BaseCacheStoreTest.java:198) at org.infinispan.loaders.BaseCacheStoreTest.testLoadAndStoreWithLifespan(BaseCacheStoreTest.java:151) 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:909) at org.testng.TestRunner.privateRun(TestRunner.java:618) at org.testng.TestRunner.run(TestRunner.java:499) at org.testng.SuiteRunner.runTest(SuiteRunner.java:332) at org.testng.SuiteRunner.access$000(SuiteRunner.java:33) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:358) at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:142) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

6
9
0 / 0

[JBoss JIRA] Created: (ISPN-1417) Inefficient and unnecessary clearing of looked up entries when a context is reset

by Manik Surtani (JIRA)

Inefficient and unnecessary clearing of looked up entries when a context is reset --------------------------------------------------------------------------------- Key: ISPN-1417 URL: https://issues.jboss.org/browse/ISPN-1417 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.0.1.FINAL Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.FINAL When a context is reset, some implementations call clear() on the looked up entries map. This can be inefficient in microbenchmarks if a large number of entries have been looked up. Contexts should simply nullify looked up entries and let the collection be gc'd. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-1378) Log Infinispan version only once

by Michal Linhard (JIRA)

Log Infinispan version only once -------------------------------- Key: ISPN-1378 URL: https://issues.jboss.org/browse/ISPN-1378 Project: Infinispan Issue Type: Enhancement Affects Versions: 5.0.0.FINAL Reporter: Michal Linhard Assignee: Manik Surtani The log message with version {code} 16:13:15,245 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-3) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0-SNAPSHOT 16:13:15,750 INFO [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-2) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0-SNAPSHOT 16:13:16,302 INFO [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-4) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0-SNAPSHOT 16:13:16,359 INFO [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-3) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0-SNAPSHOT 16:13:16,705 INFO [org.infinispan.factories.ComponentRegistry] (MSC service thread 1-1) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.0-SNAPSHOT {code} is logged in AbstractComponentRegistry and therefore it's logged for each configured cache. Wouldn't one such message suffice for one CacheManager instance ? e.g. log it at the end of GlobalComponentRegistry.start() -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2012