[JBoss JIRA] (ISPN-2995) AtomicHashMap locking issue [optimistic]
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2995?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2995:
--------------------------------
Affects Version/s: (was: 5.2.5.Final)
> AtomicHashMap locking issue [optimistic]
> ----------------------------------------
>
> Key: ISPN-2995
> URL: https://issues.jboss.org/browse/ISPN-2995
> Project: Infinispan
> Issue Type: Bug
> Components: Fine-grained API
> Affects Versions: 5.3.0.Alpha1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: atomic_map, locking
>
> In OptimisticLockingInterceptor, we are collecting the composite keys from ApplyDeltaCommand is the key belongs to the node:
> {code}
> case ApplyDeltaCommand.COMMAND_ID:
> ApplyDeltaCommand command = (ApplyDeltaCommand) wc;
> if (cdl.localNodeIsOwner(command.getKey())) {
> Object[] compositeKeys = command.getCompositeKeys();
> set.addAll(Arrays.asList(compositeKeys));
> }
> break;
> {code}
> However, when we are going to acquire the lock in the node if it is the primary owner:
> {code}
> protected final void lockAndRegisterBackupLock(TxInvocationContext ctx, Object key, long lockTimeout, boolean skipLocking) throws InterruptedException {
> if (cdl.localNodeIsPrimaryOwner(key)) {
> lockKeyAndCheckOwnership(ctx, key, lockTimeout, skipLocking);
> } else if (cdl.localNodeIsOwner(key)) {
> ctx.getCacheTransaction().addBackupLockForKey(key);
> }
> }
> {code}
> The CompositeKey should always acquire the lock.
> This is probably a bug. Add an unit test to verify that locking works as expected for AtomicHashMap.
--
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, 1 month
[JBoss JIRA] (ISPN-2995) AtomicHashMap locking issue [optimistic]
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2995?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2995:
--------------------------------
Fix Version/s: 5.3.0.Beta2
> AtomicHashMap locking issue [optimistic]
> ----------------------------------------
>
> Key: ISPN-2995
> URL: https://issues.jboss.org/browse/ISPN-2995
> Project: Infinispan
> Issue Type: Bug
> Components: Fine-grained API
> Affects Versions: 5.3.0.Alpha1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: atomic_map, locking
> Fix For: 5.3.0.Beta2
>
>
> In OptimisticLockingInterceptor, we are collecting the composite keys from ApplyDeltaCommand is the key belongs to the node:
> {code}
> case ApplyDeltaCommand.COMMAND_ID:
> ApplyDeltaCommand command = (ApplyDeltaCommand) wc;
> if (cdl.localNodeIsOwner(command.getKey())) {
> Object[] compositeKeys = command.getCompositeKeys();
> set.addAll(Arrays.asList(compositeKeys));
> }
> break;
> {code}
> However, when we are going to acquire the lock in the node if it is the primary owner:
> {code}
> protected final void lockAndRegisterBackupLock(TxInvocationContext ctx, Object key, long lockTimeout, boolean skipLocking) throws InterruptedException {
> if (cdl.localNodeIsPrimaryOwner(key)) {
> lockKeyAndCheckOwnership(ctx, key, lockTimeout, skipLocking);
> } else if (cdl.localNodeIsOwner(key)) {
> ctx.getCacheTransaction().addBackupLockForKey(key);
> }
> }
> {code}
> The CompositeKey should always acquire the lock.
> This is probably a bug. Add an unit test to verify that locking works as expected for AtomicHashMap.
--
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, 1 month
[JBoss JIRA] (ISPN-2980) sqlite support
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2980?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2980:
--------------------------------
Assignee: Dan Berindei (was: Mircea Markus)
> sqlite support
> --------------
>
> Key: ISPN-2980
> URL: https://issues.jboss.org/browse/ISPN-2980
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Affects Versions: 5.2.5.Final
> Reporter: Aleksandar Kostadinov
> Assignee: Dan Berindei
> Labels: cache-loader, cache-store, jdbc, sqlite
> Attachments: sqlite-jdbc-3.7.15-SNAPSHOT-f18.jar
>
>
> It would be very nice is we have SQLite support for infinispan. SQLite is a powerful database supporting terabyte sized databases in a file with competitive performance.
> I tried to use it as a JDBC store but the best driver I find in the internet ([xerial sqlite jdbc driver|https://bitbucket.org/xerial/sqlite-jdbc]) does not implement full jdbc specification and trying to use it results in exceptions.
> I think that perhaps using the [non-jdbc wrapper sqlite4java|http://code.google.com/p/sqlite4java/] may make sense for infinispan because:
> 1. it promises better performance
> 2. it allows using the sqlite library from OS (xerial driver uses a customized build of sqlite)
> FYI here is how I setup sqlite for infinispan (unsuccessfully):
> {code}jboss as cli commands:
> /subsystem=datasources/jdbc-driver=sqlite:add(driver-name="sqlite",driver-module-name="org.xerial",driver-class-name=org.sqlite.JDBC)
> data-source add --name=SQLiteDS --connection-url="jdbc:sqlite:${sqlite.database.string}" --jndi-name=java:jboss/datasources/SQLiteDS --driver-name="sqlite"
> /subsystem=datasources/data-source=SQLiteDS/connection-properties=journal_mode:add(value="WAL")
> /subsystem=datasources/data-source=SQLiteDS:enable
> {code}
> {code}JBoss AS module definition (modules/org/xerial/main/module.xml):
> <?xml version="1.0" encoding="UTF-8"?>
> <module xmlns="urn:jboss:module:1.0" name="org.xerial">
> <resources>
> <resource-root path="sqlite-jdbc.jar" />
> </resources>
> <dependencies>
> <module name="javax.api" />
> <module name="javax.transaction.api"/>
> </dependencies>
> </module>
> {code}
> {code}cache store/loader configuration snippet:
> <stringKeyedJdbcStore xmlns="urn:infinispan:config:jdbc:5.2" fetchPersistentState="false" ignoreModifications="false" purgeOnStartup="false" key2StringMapper="com.jboss.datagrid.chunchun.util.TwoWayKey2StringChunchunMapper">
> <dataSource jndiUrl="java:jboss/datasources/SQLiteDS" />
> <stringKeyedTable dropOnExit="false" createOnStart="true" prefix="ispn">
> <idColumn name="ID_COLUMN" type="VARCHAR(255)" />
> <dataColumn name="DATA_COLUMN" type="BLOB" />
> <timestampColumn name="TIMESTAMP_COLUMN" type="BIGINT" />
> </stringKeyedTable>
> </stringKeyedJdbcStore>
> </loaders>
> {code}
> sql driver needs to be copied in the same directory as module.xml
> *UPDATE:* the exception is fixed with latest dev code of xerial jdbc driver, please look at comments to see remaining problems.
> The Exception I'm getting is:{code}
> 12:53:10,683 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (MSC service thread 1-3) ISPN000136: Execution error: org.infinispan.loaders.CacheLoaderException: Error while storing string key to database; key: 'user41', buffer size of value: 4918 bytes
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.storeLockSafe(JdbcStringBasedCacheStore.java:253) [infinispan-cachestore-jdbc-5.2.5.Final.jar:5.2.5.Final]
> ...
> Caused by: java.sql.SQLException: not implemented by SQLite JDBC driver
> at org.sqlite.Unused.unused(Unused.java:29) [sqlite-jdbc-3.7.2.jar:]
> at org.sqlite.Unused.setBinaryStream(Unused.java:60) [sqlite-jdbc-3.7.2.jar:]
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.setBinaryStream(WrappedPreparedStatement.java:871)
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.storeLockSafe(JdbcStringBasedCacheStore.java:247) [infinispan-cachestore-jdbc-5.2.5.Final.jar:5.2.5.Final]
> ... 73 more{code}
> The driver [does not support|http://code.google.com/p/xerial/issues/detail?id=99] setBinaryStream(), only setBytes(). Not sure if there are any other methods required by infinispan but not implemented.
> As a simple comparison between JDBC and direct storage, I tried an app that caches 3000 records of around 5k and 60000 records of around 0.5k (total of less than 60MiB). Bdbje store operation completes in less than a minute. With a local mysql server it takes 10 minutes. And this is on a machine with plenty of CPU and memory over an SSD. Unfortunately bdbje does not work clustered for me (ISPN-2968).
> So my point is that a local disk based, fast, reliable, transactional engine is highly needed.
--
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, 1 month
[JBoss JIRA] (ISPN-2990) L1ManagerImpl doesn't reliably invalidate with async caches
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2990:
--------------------------------
Labels: onboard (was: )
> L1ManagerImpl doesn't reliably invalidate with async caches
> -----------------------------------------------------------
>
> Key: ISPN-2990
> URL: https://issues.jboss.org/browse/ISPN-2990
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.1.Final
> Reporter: Sebastian Tusk
> Assignee: Mircea Markus
> Labels: onboard
>
> B is owner of k,v1
> A has k,v1 in L1
> 1. TX: A puts k,v2
> 2. TX: A sends async PrepareCommand k,v2 to B (one-phase-commit)
> 3. TX: A removes k,v1 from L1
> 4. A putForExternalRead k,v1 and has it in L1 again
> 5. TX: B executes PrepareCommand k,v2 but doesn't send invalidation to origin
> Result: A has k,v1 and B has k,v2
> Solution: For async caches send invalidation to origin too.
> The problem is that the owner updates the cache entry asynchronously. This gives the origin of the transaction time to request the entry. Here an outdated version is received and placed in L1. The owner never invalidates the entry and as result the cache is inconsistent.
--
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, 1 month
[JBoss JIRA] (ISPN-2951) Infinispan try to register again the whole manager on jmx when deleting and recreating a cache
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2951?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2951:
-------------------------------------
decreasing priority as it has a workaround.
> Infinispan try to register again the whole manager on jmx when deleting and recreating a cache
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-2951
> URL: https://issues.jboss.org/browse/ISPN-2951
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.5.Final
> Environment: JDK Oracle 1.6.0_35
> Reporter: Thomas Mortagne
> Assignee: Tristan Tarrant
> Priority: Minor
> Fix For: 5.3.0.Beta2, 5.3.0.Final
>
>
> When I do something like the following:
> {code:java}
> cacheManager.getCache("test");
> cacheManager.removeCache("test");
> cacheManager.getCache("test");
> {code}
> it fails with the following exception (this exception is not exactly with the code above but it's what is happening):
> {noformat}
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.jmx.CacheJmxRegistration.start() on object of type CacheJmxRegistration
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:886)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:657)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:646)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:549)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:217)
> at org.infinispan.CacheImpl.start(CacheImpl.java:582)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:686)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:545)
> at org.xwiki.cache.infinispan.internal.InfinispanCache.<init>(InfinispanCache.java:71)
> at org.xwiki.cache.infinispan.internal.InfinispanCacheFactory.newCache(InfinispanCacheFactory.java:170)
> at org.xwiki.cache.infinispan.InfinispanCacheTest.testRecreateCache(InfinispanCacheTest.java:62)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.jmock.integration.junit4.JUnitRuleMockery$1.evaluate(JUnitRuleMockery.java:49)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=Cache,name="test(local)",manager="DefaultCacheManager"
> at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75)
> at org.infinispan.jmx.CacheJmxRegistration.updateDomain(CacheJmxRegistration.java:153)
> at org.infinispan.jmx.CacheJmxRegistration.buildRegistrar(CacheJmxRegistration.java:145)
> at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59)
> at org.infinispan.jmx.CacheJmxRegistration.start(CacheJmxRegistration.java:83)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> ... 38 more
> {noformat}
> Note: this was working well with 5.1.8.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, 1 month
[JBoss JIRA] (ISPN-2951) Infinispan try to register again the whole manager on jmx when deleting and recreating a cache
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2951?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2951:
--------------------------------
Priority: Minor (was: Major)
> Infinispan try to register again the whole manager on jmx when deleting and recreating a cache
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-2951
> URL: https://issues.jboss.org/browse/ISPN-2951
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.5.Final
> Environment: JDK Oracle 1.6.0_35
> Reporter: Thomas Mortagne
> Assignee: Tristan Tarrant
> Priority: Minor
> Fix For: 5.3.0.Beta2, 5.3.0.Final
>
>
> When I do something like the following:
> {code:java}
> cacheManager.getCache("test");
> cacheManager.removeCache("test");
> cacheManager.getCache("test");
> {code}
> it fails with the following exception (this exception is not exactly with the code above but it's what is happening):
> {noformat}
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.jmx.CacheJmxRegistration.start() on object of type CacheJmxRegistration
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:886)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:657)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:646)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:549)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:217)
> at org.infinispan.CacheImpl.start(CacheImpl.java:582)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:686)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:545)
> at org.xwiki.cache.infinispan.internal.InfinispanCache.<init>(InfinispanCache.java:71)
> at org.xwiki.cache.infinispan.internal.InfinispanCacheFactory.newCache(InfinispanCacheFactory.java:170)
> at org.xwiki.cache.infinispan.InfinispanCacheTest.testRecreateCache(InfinispanCacheTest.java:62)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.jmock.integration.junit4.JUnitRuleMockery$1.evaluate(JUnitRuleMockery.java:49)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=Cache,name="test(local)",manager="DefaultCacheManager"
> at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75)
> at org.infinispan.jmx.CacheJmxRegistration.updateDomain(CacheJmxRegistration.java:153)
> at org.infinispan.jmx.CacheJmxRegistration.buildRegistrar(CacheJmxRegistration.java:145)
> at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59)
> at org.infinispan.jmx.CacheJmxRegistration.start(CacheJmxRegistration.java:83)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> ... 38 more
> {noformat}
> Note: this was working well with 5.1.8.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, 1 month
[JBoss JIRA] (ISPN-2950) In distributed mode cache store data should be read through the main data owner (vs directly from the store)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2950?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2950:
-------------------------------------
[~sannegrinovero]
yes. The ClusterCacheLoader looks the value in the same cache but on a different node on the cluster. This behaviour will be hardcoded once we have this JIRA in place, so I don't see any reason for keeping the ClusterCacheLoader around. Now if you have a use case for it post ISPN-2950 just let me know ;)
> In distributed mode cache store data should be read through the main data owner (vs directly from the store)
> ------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2950
> URL: https://issues.jboss.org/browse/ISPN-2950
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Sanne Grinovero
> Assignee: Mircea Markus
> Priority: Critical
> Labels: onboard
> Fix For: 5.3.0.Beta2, 5.3.0.Final
>
>
> Dist cache with a cache store (shared or not), k owned by \{N1, N2\}. k is read on N3. What currently happens at this stage, if k is not present in N3's memory (likely unless L1 is configured), the N3's cache store is queried and data is loaded from there. This has several drawbacks:
> - the data might already be in the memory of the owner node (N1,N2) so reading it from the disk is highly inefficient. Especially for hot data: data requested from various nodes at the same time (see also mailing list discussion around lucene query performance depending on this)
> - if this is a local cache store, it might contain stale data which would be returned to the user
> - for async configured cache store this would result in dirty reads, given that a change might be in the async store's memory but not in the store at the moment when it is in read by N3. (Note that using async stores still leaves place to inconsistencies when a node leaves, e.g. because of node crashing before managing to flush the async store.)
> This JIRA is about changing the distribution mode: when asked for a specific key, a node would only touch a cache store if it is an owner of that key, otherwise would first go to the main owner of the key to read the value from there. The ClusterCacheLoader should be deprecated 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
11 years, 1 month
[JBoss JIRA] (ISPN-2951) Infinispan try to register again the whole manager on jmx when deleting and recreating a cache
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2951?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2951:
--------------------------------
Assignee: Tristan Tarrant (was: Mircea Markus)
> Infinispan try to register again the whole manager on jmx when deleting and recreating a cache
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-2951
> URL: https://issues.jboss.org/browse/ISPN-2951
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.5.Final
> Environment: JDK Oracle 1.6.0_35
> Reporter: Thomas Mortagne
> Assignee: Tristan Tarrant
> Fix For: 5.3.0.Beta2, 5.3.0.Final
>
>
> When I do something like the following:
> {code:java}
> cacheManager.getCache("test");
> cacheManager.removeCache("test");
> cacheManager.getCache("test");
> {code}
> it fails with the following exception (this exception is not exactly with the code above but it's what is happening):
> {noformat}
> org.infinispan.CacheException: Unable to invoke method public void org.infinispan.jmx.CacheJmxRegistration.start() on object of type CacheJmxRegistration
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:886)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:657)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:646)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:549)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:217)
> at org.infinispan.CacheImpl.start(CacheImpl.java:582)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:686)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:545)
> at org.xwiki.cache.infinispan.internal.InfinispanCache.<init>(InfinispanCache.java:71)
> at org.xwiki.cache.infinispan.internal.InfinispanCacheFactory.newCache(InfinispanCacheFactory.java:170)
> at org.xwiki.cache.infinispan.InfinispanCacheTest.testRecreateCache(InfinispanCacheTest.java:62)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.jmock.integration.junit4.JUnitRuleMockery$1.evaluate(JUnitRuleMockery.java:49)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=Cache,name="test(local)",manager="DefaultCacheManager"
> at org.infinispan.jmx.JmxUtil.buildJmxDomain(JmxUtil.java:75)
> at org.infinispan.jmx.CacheJmxRegistration.updateDomain(CacheJmxRegistration.java:153)
> at org.infinispan.jmx.CacheJmxRegistration.buildRegistrar(CacheJmxRegistration.java:145)
> at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:59)
> at org.infinispan.jmx.CacheJmxRegistration.start(CacheJmxRegistration.java:83)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
> ... 38 more
> {noformat}
> Note: this was working well with 5.1.8.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, 1 month
[JBoss JIRA] (ISPN-2950) In distributed mode cache store data should be read through the main data owner (vs directly from the store)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2950?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2950:
--------------------------------
Labels: onboard (was: )
> In distributed mode cache store data should be read through the main data owner (vs directly from the store)
> ------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-2950
> URL: https://issues.jboss.org/browse/ISPN-2950
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Sanne Grinovero
> Assignee: Mircea Markus
> Priority: Critical
> Labels: onboard
> Fix For: 5.3.0.Beta2, 5.3.0.Final
>
>
> Dist cache with a cache store (shared or not), k owned by \{N1, N2\}. k is read on N3. What currently happens at this stage, if k is not present in N3's memory (likely unless L1 is configured), the N3's cache store is queried and data is loaded from there. This has several drawbacks:
> - the data might already be in the memory of the owner node (N1,N2) so reading it from the disk is highly inefficient. Especially for hot data: data requested from various nodes at the same time (see also mailing list discussion around lucene query performance depending on this)
> - if this is a local cache store, it might contain stale data which would be returned to the user
> - for async configured cache store this would result in dirty reads, given that a change might be in the async store's memory but not in the store at the moment when it is in read by N3. (Note that using async stores still leaves place to inconsistencies when a node leaves, e.g. because of node crashing before managing to flush the async store.)
> This JIRA is about changing the distribution mode: when asked for a specific key, a node would only touch a cache store if it is an owner of that key, otherwise would first go to the main owner of the key to read the value from there. The ClusterCacheLoader should be deprecated 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
11 years, 1 month