[JBoss JIRA] (ISPN-1540) Refactor distribution interceptor
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-1540?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-1540:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2034
> Refactor distribution interceptor
> ---------------------------------
>
> Key: ISPN-1540
> URL: https://issues.jboss.org/browse/ISPN-1540
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache
> Affects Versions: 5.1.0.BETA5
> Reporter: Mircea Markus
> Assignee: William Burns
> Fix For: 6.0.0.CR1
>
>
> DistributionInterceptor, as it looks now is unnecessary complex. Before adding more functionality on top of it (i.e. ISPN-1539) it should be refactored:
> - extract L1 logic into a different interceptor
> - this would require moving the StateTransferLock logic into another interceptor as well
> - now that we have separation between tx and non-tx caches, we can extract the remaining logic into TransactionalDistributionInterceptor and NonTransactional...
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-3516) Remove deprecated API
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3516?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3516:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2073
> Remove deprecated API
> ---------------------
>
> Key: ISPN-3516
> URL: https://issues.jboss.org/browse/ISPN-3516
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 6.0.0.Alpha4
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 6.0.0.Beta1
>
>
> classes:
> * org.infinispan.loaders.remote.wrapper.EntryWrapper
> * org.infinispan.context.FlagContainer
> methods:
> * StreamingMarshaller.startObjectOutput
> * AdvancedCache.getCacheEntry
> * AtomicMapLookup.getAtomicMap
> * DistributionManager.isLocal
> * TxInterceptor.setStatisticsEnabled
> * GridFile.delete
> * ModuleLifecycle.cacheManagerStarting
> * ModuleLifecycle.cacheStarting
> * DeadlockDetectingLockManager.getLocallyInterruptedTransactions
> packages:
> * org.infinispan.config
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-3516) Remove deprecated API
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-3516:
---------------------------------
Summary: Remove deprecated API
Key: ISPN-3516
URL: https://issues.jboss.org/browse/ISPN-3516
Project: Infinispan
Issue Type: Enhancement
Affects Versions: 6.0.0.Alpha4
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Fix For: 6.0.0.Beta1
classes:
* org.infinispan.loaders.remote.wrapper.EntryWrapper
* org.infinispan.context.FlagContainer
methods:
* StreamingMarshaller.startObjectOutput
* AdvancedCache.getCacheEntry
* AtomicMapLookup.getAtomicMap
* DistributionManager.isLocal
* TxInterceptor.setStatisticsEnabled
* GridFile.delete
* ModuleLifecycle.cacheManagerStarting
* ModuleLifecycle.cacheStarting
* DeadlockDetectingLockManager.getLocallyInterruptedTransactions
packages:
* org.infinispan.config
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-3515) Suspicios behaviour for ISPN Directory with Async. JDBC CacheStore
by Anna Manukyan (JIRA)
[ https://issues.jboss.org/browse/ISPN-3515?page=com.atlassian.jira.plugin.... ]
Anna Manukyan updated ISPN-3515:
--------------------------------
Attachment: ClusteredCacheWithAsyncDirTest.java
ClusteredQueryTest.java
async-store-config.xml
> Suspicios behaviour for ISPN Directory with Async. JDBC CacheStore
> ------------------------------------------------------------------
>
> Key: ISPN-3515
> URL: https://issues.jboss.org/browse/ISPN-3515
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Attachments: async-store-config.xml, ClusteredCacheWithAsyncDirTest.java, ClusteredQueryTest.java
>
>
> I've noticed some strange behaviour while test implementation which I was not able to explain.
> I have a infinispan configuration file which contains definition for REPL cache using indexing on Infinispan Directory and using customized caches for ISPN Directory with enabled asynchronous JDBC cachestore (please see attached the configuration).
> The test is extended from the one existing already in the testsuite but works with the newly defined configuration - org.infinispan.query.blackbox.ClusteredCacheTest.
> The issue is that, 2 tests are failing - testClear() and testSearchKeyTransformer() with assertion errors.
> And these failures appear in case if the indexLocalOnly is set to true, even though the ISPN Directory caches are implemented to be clustered in a REPL mode.
> When I'm changing the indexLocalOnly to false, then everything is ok - all tests are passing.
> The failure messages for each method are:
> {code}
> testClear():
> java.lang.AssertionError:
> Expected :0
> Actual :3
> <Click to see difference>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
> at org.infinispan.query.blackbox.ClusteredCacheTest.testClear(ClusteredCacheTest.java:266)
> testSearchKeyTransformer():
> java.lang.AssertionError:
> Expected :2
> Actual :1
> <Click to see difference>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
> at org.infinispan.query.blackbox.ClusteredCacheTest.testSearchKeyTransformer(ClusteredCacheTest.java:362)
> {code}
> You can find attached the test classes.
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-3515) Suspicios behaviour for ISPN Directory with Async. JDBC CacheStore
by Anna Manukyan (JIRA)
Anna Manukyan created ISPN-3515:
-----------------------------------
Summary: Suspicios behaviour for ISPN Directory with Async. JDBC CacheStore
Key: ISPN-3515
URL: https://issues.jboss.org/browse/ISPN-3515
Project: Infinispan
Issue Type: Bug
Components: Querying
Reporter: Anna Manukyan
Assignee: Sanne Grinovero
I've noticed some strange behaviour while test implementation which I was not able to explain.
I have a infinispan configuration file which contains definition for REPL cache using indexing on Infinispan Directory and using customized caches for ISPN Directory with enabled asynchronous JDBC cachestore (please see attached the configuration).
The test is extended from the one existing already in the testsuite but works with the newly defined configuration - org.infinispan.query.blackbox.ClusteredCacheTest.
The issue is that, 2 tests are failing - testClear() and testSearchKeyTransformer() with assertion errors.
And these failures appear in case if the indexLocalOnly is set to true, even though the ISPN Directory caches are implemented to be clustered in a REPL mode.
When I'm changing the indexLocalOnly to false, then everything is ok - all tests are passing.
The failure messages for each method are:
{code}
testClear():
java.lang.AssertionError:
Expected :0
Actual :3
<Click to see difference>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
at org.infinispan.query.blackbox.ClusteredCacheTest.testClear(ClusteredCacheTest.java:266)
testSearchKeyTransformer():
java.lang.AssertionError:
Expected :2
Actual :1
<Click to see difference>
at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:245)
at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252)
at org.infinispan.query.blackbox.ClusteredCacheTest.testSearchKeyTransformer(ClusteredCacheTest.java:362)
{code}
You can find attached the test classes.
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-3478) Polish CS API revamp
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3478?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3478:
------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
all PRs integrated :)
> Polish CS API revamp
> --------------------
>
> Key: ISPN-3478
> URL: https://issues.jboss.org/browse/ISPN-3478
> Project: Infinispan
> Issue Type: Feature Request
> Affects Versions: 6.0.0.Alpha4
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Fix For: 6.0.0.Beta1
>
>
> Still some TODOs:
> * 3.4 name consistently
> * Make ClusterStore configuration match the name (ClusterLoader)
> * 3.5 - move the params from init to an instance named InitializationContext that contains context info (is singleton etc, and also marshaller etc)
> * 4 - push pull request
> * 5 - remove all the "store" references from the code
> * 6 - don't use "bulk" in the name of them methods ...
> * 7 - make CacheLoaderException runtime
> * 8 - rename EntryFactory in ContextEntryFactory and MVCCEntry in ContextEntry
> * 9 - make StoreConfiguration aware of purging etc
> * 10 - add removed test to the compatibility module: ConfigurationCompatibilityTest.testModeShapeStoreConfiguration
> * - FileCacheStoreTest
> * 11 - remove EHCache2InfinispanTransformerTest and other product migration tests in general + user manual entries
> * 12 - Config: loaders/shared should be configured on a per cache basis.
> * - action - lockAcquisitionTimeout (moved to bucket), concurrencyLevel (mode to bucket),
> * purgerThreads & purgeSynchronously(removed as purging is async anyway)
> * - purge on startup should be renamed to clean on startup as purging, as a term, is already used for cleaning
> * up expired entries
> * 13 - add test to show that notification happens for purged entries
> * 14 - add interruption support in the code that invokes the CacheLoaderTask
> * 15 - allow the number of map/reduce threads that iterate over the store to be configured
> * 16 - Make ByteBuffer an interface and add a factory for it. Also consider adding a factory for MarshalledEntry
> * 17 - rename org.infinispan.loader -> o.i.persistence
> * 18 - remote gets should not serialize the entries but operate on bytebuffers directly
> * 19 - make sure cachestore string is not present int he source base
> * 20 - https://community.jboss.org/thread/232195
> * 21 - remove DataManipulationHelper
> * 22 - move Sleepycat Berkeley DB Java Edition license to the right place
> * 23 removed 5.2 and 5.3 config files from the test resource dir
> * 24 make the name consistent in the other modules as well
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-2903:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] from VERIFIED to CLOSED
> Manual eviction should not delete entry from cache store
> --------------------------------------------------------
>
> Key: ISPN-2903
> URL: https://issues.jboss.org/browse/ISPN-2903
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.2.3.Final
> Reporter: Paul Ferraro
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 5.2.x, jdg6
> Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final
>
> Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log
>
>
> Here's the scenario:
> Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7).
> 1. Create cache entry containing atomic map with 2 map entries on node1.
> 2. Passivate that cache entry on node2 via manual evict.
> 3. Modify 1 of the atomic map entries within the cache entry on node1.
> 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost.
> It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls.
--
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
12 years, 7 months
[JBoss JIRA] (ISPN-3330) Hotrod clients getWithMetadata doesn't work when locking isolation != NONE
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-3330?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-3330:
-------------------------------------
Besides isolation level validation (which is ok) this PR also tries to validate key and value equivalence by constraining them to be able to compare byte[]. This is wrong for all caches that are not supposed to be accessed remotely, for example metadata caches spawned by query. These (especially if infinispan directory is used) do not have byte[] keys and values so the validation is not meaningful to them. Since we cannot know at this moment which caches are going to be accessed remotely I will remove this validation.
> Hotrod clients getWithMetadata doesn't work when locking isolation != NONE
> --------------------------------------------------------------------------
>
> Key: ISPN-3330
> URL: https://issues.jboss.org/browse/ISPN-3330
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.3.0.Final, 6.0.0.Alpha4
> Reporter: Jakub Markos
> Assignee: Galder Zamarreño
> Priority: Minor
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
>
> I have a cluster of 2 infinispan servers with this configuration:
> {code:xml}<subsystem xmlns="urn:infinispan:server:core:5.3">
> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener">
> <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/>
> <distributed-cache name="default" start="EAGER" mode="SYNC" segments="1" owners="2" batching="false" l1-lifespan="0" remote-timeout="60000">
> <locking isolation="REPEATABLE_READ"/>
> </distributed-cache>
> </cache-container>
> </subsystem>{code}
> Running this code:
> {code}remoteCache.put("k1", "v1", 10000000, TimeUnit.MICROSECONDS); // setting only lifespan
> MetadataValue<String> k1 = remoteCache.getWithMetadata("k1");
> assertTrue(k1.getValue().equals("v1"));
> // microseconds converted to seconds
> assertTrue(k1.getLifespan() == 10);
> assertTrue(k1.getMaxIdle() == -1);{code}
> fails with:
> {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[5] returned server error (status=0x85): java.lang.ClassCastException: org.infinispan.container.entries.RepeatableReadEntry can
> not be cast to org.infinispan.container.entries.InternalCacheEntry
> at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143)
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:52)
> at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:35)
> at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:23)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.getWithMetadata(RemoteCacheImpl.java:145){code}
> Works with isolation="READ_COMMITED"/"NONE" or with no <locking> at all.
--
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
12 years, 7 months