June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3268) Equivalence classes are API and should live in a separate package

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-3268: ------------------------------------- Summary: Equivalence classes are API and should live in a separate package Key: ISPN-3268 URL: https://issues.jboss.org/browse/ISPN-3268 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.3.0.CR2 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.3.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3243) Inconsistent behaviour of operations HotRod.clear vs Memcached.flushAll wrt CacheStore

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-3243?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-3243: -------------------------------- Status: Pull Request Sent (was: Pull Request Sent) > Inconsistent behaviour of operations HotRod.clear vs Memcached.flushAll wrt CacheStore > -------------------------------------------------------------------------------------- > > Key: ISPN-3243 > URL: https://issues.jboss.org/browse/ISPN-3243 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.6.Final, 5.3.0.Final > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > Affecting 5.3.0-SNAPSHOT and 5.2.x branch > When using hot rod client the clear() operation deletes all entries also in the cache store > When using memcached client the flush_all operation deletes entries only in the memory > hotrod behaviour: > https://github.com/infinispan/infinispan/blob/5.3.x/server/hotrod/src/mai... > memcached behaviour: > https://github.com/infinispan/infinispan/blob/5.3.x/server/memcached/src/... > shouldn't they be consistent ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3243) Inconsistent behaviour of operations HotRod.clear vs Memcached.flushAll wrt CacheStore

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-3243?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-3243: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Inconsistent behaviour of operations HotRod.clear vs Memcached.flushAll wrt CacheStore > -------------------------------------------------------------------------------------- > > Key: ISPN-3243 > URL: https://issues.jboss.org/browse/ISPN-3243 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.6.Final, 5.3.0.Final > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > Affecting 5.3.0-SNAPSHOT and 5.2.x branch > When using hot rod client the clear() operation deletes all entries also in the cache store > When using memcached client the flush_all operation deletes entries only in the memory > hotrod behaviour: > https://github.com/infinispan/infinispan/blob/5.3.x/server/hotrod/src/mai... > memcached behaviour: > https://github.com/infinispan/infinispan/blob/5.3.x/server/memcached/src/... > shouldn't they be consistent ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3264) Deprecate ByteArrayKey

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-3264?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-3264: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Deprecate ByteArrayKey > ---------------------- > > Key: ISPN-3264 > URL: https://issues.jboss.org/browse/ISPN-3264 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.3.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Blocker > Fix For: 5.3.0.Final > > > Since the work gone into the equivalence API, the ByteArrayKey class should be deprecated and removed in 6.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3232) ClassCastException in LevelDBCacheStore

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3232?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3232: ----------------------------------- Fix Version/s: 5.3.0.Final > ClassCastException in LevelDBCacheStore > --------------------------------------- > > Key: ISPN-3232 > URL: https://issues.jboss.org/browse/ISPN-3232 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.3.0.CR1 > Reporter: Michal Linhard > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > The test org/infinispan/loaders/leveldb/LevelDBCacheStoreTest.java shows this error in the log: > {code} > 2013-06-14 15:20:13,136 ERROR [AbstractCacheStore] (main) ISPN000045: Problems encountered while purging expired > org.infinispan.loaders.CacheLoaderException: org.infinispan.loaders.CacheLoaderException: java.lang.ClassCastException: [B cannot be cast to java.lang.Long > at org.infinispan.loaders.leveldb.LevelDBCacheStore.purgeInternal(LevelDBCacheStore.java:412) > at org.infinispan.loaders.AbstractCacheStore$2.run(AbstractCacheStore.java:111) > at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:44) > at org.infinispan.loaders.AbstractCacheStore.purgeExpired(AbstractCacheStore.java:107) > at org.infinispan.loaders.BaseCacheStoreTest.purgeExpired(BaseCacheStoreTest.java:214) > at org.infinispan.loaders.BaseCacheStoreTest.testLoadAndStoreWithIdle(BaseCacheStoreTest.java:202) > 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:601) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:335) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:330) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) > at org.testng.SuiteRunner.run(SuiteRunner.java:240) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) > at org.testng.TestNG.run(TestNG.java:1057) > at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:111) > at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:204) > at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:175) > Caused by: org.infinispan.loaders.CacheLoaderException: java.lang.ClassCastException: [B cannot be cast to java.lang.Long > at org.infinispan.loaders.leveldb.LevelDBCacheStore.purgeInternal(LevelDBCacheStore.java:403) > ... 29 more > Caused by: java.lang.ClassCastException: [B cannot be cast to java.lang.Long > at org.infinispan.loaders.leveldb.LevelDBCacheStore.purgeInternal(LevelDBCacheStore.java:367) > ... 29 more > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3267) Support all LevelDB options

by Takayoshi Kimura (JIRA)

[ https://issues.jboss.org/browse/ISPN-3267?page=com.atlassian.jira.plugin.... ] Takayoshi Kimura updated ISPN-3267: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1926 > Support all LevelDB options > --------------------------- > > Key: ISPN-3267 > URL: https://issues.jboss.org/browse/ISPN-3267 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Affects Versions: 5.3.0.CR2 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > > The current LevelDB cache store lacks some LevelDB configuration parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3267) Support all LevelDB options

by Takayoshi Kimura (JIRA)

[ https://issues.jboss.org/browse/ISPN-3267?page=com.atlassian.jira.plugin.... ] Takayoshi Kimura updated ISPN-3267: ----------------------------------- Description: The current LevelDB cache store lacks some LevelDB options. (was: The current LevelDB cache store lacks some LevelDB configuration parameters.) > Support all LevelDB options > --------------------------- > > Key: ISPN-3267 > URL: https://issues.jboss.org/browse/ISPN-3267 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Affects Versions: 5.3.0.CR2 > Reporter: Takayoshi Kimura > Assignee: Takayoshi Kimura > > The current LevelDB cache store lacks some LevelDB options. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3267) Support all LevelDB options

by Takayoshi Kimura (JIRA)

Takayoshi Kimura created ISPN-3267: -------------------------------------- Summary: Support all LevelDB options Key: ISPN-3267 URL: https://issues.jboss.org/browse/ISPN-3267 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Affects Versions: 5.3.0.CR2 Reporter: Takayoshi Kimura Assignee: Takayoshi Kimura The current LevelDB cache store lacks some LevelDB configuration parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3266) Pessimistic Force Write Lock doesn't acquire remote lock

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3266: -------------------------------- Attachment: DistSyncL1PessimisticFuncTest.java Attached test file that should work once pessimistic locking is fixed, where it acquires lock in another thread blocked after doing so. > Pessimistic Force Write Lock doesn't acquire remote lock > -------------------------------------------------------- > > Key: ISPN-3266 > URL: https://issues.jboss.org/browse/ISPN-3266 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, Locking and Concurrency > Reporter: William Burns > Assignee: Mircea Markus > Attachments: DistSyncL1PessimisticFuncTest.java > > > Looking into FORCE_WRITE_LOCK it appears it only acquires a local lock in PessimisticLockingInterceptor. Thinking about this, it seems this should acquire only a remote lock on the primary node. Currently this isn't going to block writes at all. I am guessing this was just an oversight when redoing the locking mechanism. > This causes other issues such as L1 inconsistencies which is how I ran into this and the locking should only occur on the remote node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3266) Pessimistic Force Write Lock doesn't acquire remote lock

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3266?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3266: ------------------------------------- This is as simple as the following: however this wouldn't be in a test since the write lock should block the put causing the test to not complete, will attach a real test {code} String key = "some-key"; String value = "some-value"; String otherValue = "some-new-value"; final Cache<Object, String> nonOwner = getFirstNonOwner(key); Cache<Object, String> owner = getFirstOwner(key); owner.put(key, value); // Get put in L1 nonOwner.get(key); assertIsInL1(nonOwner, key); TransactionManager mgr = TestingUtil.getTransactionManager(nonOwner); mgr.begin(); try { nonOwner.getAdvancedCache().withFlags(Flag.FORCE_WRITE_LOCK).get(key); // Owner now does a write owner.put(key, otherValue); } finally { mgr.commit(); } assertIsNotInL1(nonOwner, key); {code} > Pessimistic Force Write Lock doesn't acquire remote lock > -------------------------------------------------------- > > Key: ISPN-3266 > URL: https://issues.jboss.org/browse/ISPN-3266 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, Locking and Concurrency > Reporter: William Burns > Assignee: Mircea Markus > > Looking into FORCE_WRITE_LOCK it appears it only acquires a local lock in PessimisticLockingInterceptor. Thinking about this, it seems this should acquire only a remote lock on the primary node. Currently this isn't going to block writes at all. I am guessing this was just an oversight when redoing the locking mechanism. > This causes other issues such as L1 inconsistencies which is how I ran into this and the locking should only occur on the remote node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2013