[JBoss JIRA] (ISPN-2974) DeltaAware based fine-grained replication corrupts cache data, if eviction is enabled
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2974?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2974:
-------------------------------------
AtomicHashMap is also affected by this bug with eviction.
> DeltaAware based fine-grained replication corrupts cache data, if eviction is enabled
> -------------------------------------------------------------------------------------
>
> Key: ISPN-2974
> URL: https://issues.jboss.org/browse/ISPN-2974
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.1.Final, 5.2.5.Final
> Reporter: Horia Chiorean
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 5.3.0.Alpha1
>
>
> When using a custom {{DeltaAware}} implementation in a cluster with 2 replicated nodes with eviction enabled, data transferred from one node (the writer) to the another (the reader) causes data stored on this node and evicted at the time of the change, to be rewritten with whatever the partial latest delta was.
> In more detail:
> * configure 2 nodes in replicated mode, with eviction enabled
> * consider NodeA the writer and NodeB the reader
> * NodeA inserts some data (custom entries) into the cache
> * NodeB correctly receives via state transfer the initial data
> * NodeA loads & partially updates some information about an entry which was not in the cache - was evicted previously
> * NodeB receives the partial delta with the changes from NodeA, but *instead of merging* with whatever is stored in the persistent store, *replaces the entire entry in the cache*, leaving it in effect with "partial/corrupt information"
> If eviction is not enabled, everything works as expected.
--
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-2991) Management of DistExec / Map Reduce jobs
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-2991:
-------------------------------------
Summary: Management of DistExec / Map Reduce jobs
Key: ISPN-2991
URL: https://issues.jboss.org/browse/ISPN-2991
Project: Infinispan
Issue Type: Feature Request
Components: Distributed Execution and Map/Reduce, JMX, reporting and management
Reporter: Tristan Tarrant
Assignee: Vladimir Blagojevic
Fix For: 5.3.0.Final
We should expose a management interface for both DistExec and Map/reduce jobs so that at the very least we can:
- list running jobs with starting time and duration
- list recently terminated jobs
- allow cancelling running jobs
--
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 Aleksandar Kostadinov (JIRA)
[ https://issues.jboss.org/browse/ISPN-2980?page=com.atlassian.jira.plugin.... ]
Aleksandar Kostadinov commented on ISPN-2980:
---------------------------------------------
FYI the workload I'm talking about is not only write but also a lot of read accesses. Running as async loader does not make a big difference.
Replicating same data to another server (all servers running on localhost) though takes only 20-30 seconds. I guess the lack of too many read accesses is the main reason for that difference.
I think that a local efficient transactional storage would be unbeatable. For example a single EC2 lagre instance has 850GB ephemeral storage so one can easily build a reasonable size data grid on a couple of these if there is a way to efficiently access that amount disk space.
> 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: Mircea Markus
> Labels: cache-loader, cache-store, jdbc, sqlite
>
> 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: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_STRING_TABLE">
> <idColumn name="ID_COLUMN" type="VARCHAR(255)" />
> <dataColumn name="DATA_COLUMN" type="BINARY" />
> <timestampColumn name="TIMESTAMP_COLUMN" type="BIGINT" />
> </stringKeyedTable>
> </stringKeyedJdbcStore>
> </loaders>
> {code}
> sql driver needs to be copied in the same directory as module.xml
> 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]
> at org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.storeLockSafe(JdbcStringBasedCacheStore.java:87) [infinispan-cachestore-jdbc-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.loaders.LockSupportCacheStore.store(LockSupportCacheStore.java:213) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.loaders.AbstractCacheStore.applyModifications(AbstractCacheStore.java:126) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.loaders.AbstractCacheStore.commit(AbstractCacheStore.java:163) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.CacheStoreInterceptor.commitCommand(CacheStoreInterceptor.java:164) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.CacheStoreInterceptor.visitCommitCommand(CacheStoreInterceptor.java:146) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:60) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.AbstractVisitor.visitCommitCommand(AbstractVisitor.java:136) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:60) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitCommitCommand(EntryWrappingInterceptor.java:116) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:60) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.AbstractVisitor.visitCommitCommand(AbstractVisitor.java:136) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.visitCommitCommand(AbstractTxLockingInterceptor.java:101) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:60) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.NotificationInterceptor.visitCommitCommand(NotificationInterceptor.java:65) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:60) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.TxInterceptor.visitCommitCommand(TxInterceptor.java:153) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:60) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.AbstractVisitor.visitCommitCommand(AbstractVisitor.java:136) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitCommitCommand(TransactionSynchronizerInterceptor.java:73) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:60) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:216) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:189) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.statetransfer.StateTransferInterceptor.visitCommitCommand(StateTransferInterceptor.java:121) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:60) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.AbstractVisitor.visitCommitCommand(AbstractVisitor.java:136) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:60) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.AbstractVisitor.visitCommitCommand(AbstractVisitor.java:136) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.commands.tx.CommitCommand.acceptVisitor(CommitCommand.java:60) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:182) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:81) [infinispan-core-5.2.5.Final.jar:5.2.5.Final]
> at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:402)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:103)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:167)
> at com.jboss.datagrid.chunchun.jsf.InitializeCache.startup(InitializeCache.java:125) [classes:]
> at com.jboss.datagrid.chunchun.jsf.InitializeCache.processEvent(InitializeCache.java:76) [classes:]
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) [jboss-jsf-api_2.1_spec-2.0.7.Final-redhat-1.jar:2.0.7.Final-redhat-1]
> at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2169) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1]
> at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2145) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1]
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1]
> at org.jboss.as.weld.webtier.jsf.ForwardingApplication.publishEvent(ForwardingApplication.java:288) [jboss-as-weld-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> at com.sun.faces.config.ConfigManager.publishPostConfigEvent(ConfigManager.java:602) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:371) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:223) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1]
> at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3392) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3850) [jbossweb-7.0.17.Final-redhat-1.jar:]
> at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:89) [jboss-as-web-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
> 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 Sebastian Tusk (JIRA)
[ https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin.... ]
Sebastian Tusk edited comment on ISPN-2990 at 4/3/13 11:24 AM:
---------------------------------------------------------------
Actually sending the invalidation to origin isn't enough.
B is owner of k,v1
A has k,v1 in L1
1. A calls remove(k)
2. A removes k
3. A starts retrieval of k
4. B sends k to A
5. B removes k
6. B sends invalidation to A
7. A puts k into L1
was (Author: sebastiantusk):
Actually sending the invalidation to origin isn't enough.
B is owner of k,v1
A has k,v1 in L1
1. A calls remove(k)
2. A starts retrieval of k
3. B sends k to A
4. B removes k
5. B sends invalidation to A
6. A removes k
7. A puts k into L1
> 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
>
> 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-2990) L1ManagerImpl doesn't reliably invalidate with async caches
by Sebastian Tusk (JIRA)
[ https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin.... ]
Sebastian Tusk commented on ISPN-2990:
--------------------------------------
Actually sending the invalidation to origin isn't enough.
B is owner of k,v1
A has k,v1 in L1
1. A calls remove(k)
2. A starts retrieval of k
3. B sends k to A
4. B removes k
5. B sends invalidation to A
6. A removes k
7. A puts k into L1
> 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
>
> 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