[JBoss JIRA] (ISPN-9277) Put & Get call is not in sync
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9277?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-9277:
-------------------------------
Comment: was deleted
(was: [~parag2borah], we never really allowed defining two caches with the same name. Previously the second cache definition would silently overwrite (or possibly merge with) the 1st definition, now we signal the error.
Your second problem is that the cache is ASYNC, which means {{cache.put(key, value)}} returns *before* the value was inserted/updated in the cache. In older versions of Infinispan, the cache would update the value on the local node synchronously, before {{cache.put(key, value)}} returns, but we had to change the approach because concurrent writes would cause inconsistencies. In general I would recommend using {{cache.putAsync(key, value)}} instead of making the cache ASYNC, because it's clearer and the behaviour is very similar now.
)
> Put & Get call is not in sync
> -----------------------------
>
> Key: ISPN-9277
> URL: https://issues.jboss.org/browse/ISPN-9277
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.1.Final
> Reporter: paragBorah Borah
> Priority: Blocker
> Attachments: newConfig911.txt, oldConfig722.txt
>
>
> Hello,
> We have upgraded infinispan cache from 7.2.2 to 9.1.1.
> We have configuration (old config file) where we have <local-cache> & <replicated-cache> with same name as “defaultcache”. Where in latest version 9.1.1 we can’t have same name.
> Now my concern is about configuration. In previous configuration when we perform put operation & in some time get operation giving us the latest data from cache.
> But in latest version after put operation & in some time get operation is not giving the latest updated data from cache.
> Could you please help me with the configuration details which can help me to fix this issue.
> Regards
> Parag
>
> [~NadirX]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-375) Enable Hot Rod clients to start transactions
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-375?page=com.atlassian.jira.plugin.s... ]
Pedro Ruivo closed ISPN-375.
----------------------------
Resolution: Done
Support for Hot Rod Transactions added for 9.3
> Enable Hot Rod clients to start transactions
> --------------------------------------------
>
> Key: ISPN-375
> URL: https://issues.jboss.org/browse/ISPN-375
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 9.3.0.Final
>
>
> It might be useful to allow Hot Rod clients to start transactions within Hot Rod servers. The possibility of clients participating in the actual transaction, i.e. being an XAResource, should not be imposed since this might be less than trivial to achieve in non-Java environments. The alternative would be to allow clients to start Hot Rod server local transactions only.
> This would require enhancing Hot Rod spec to have some begin/commit/rollback commands that return a tx id, and for clients to be able to send this id as part of each command that should participate in the transaction.
> Pitfalls to avoid include avoiding a transaction to be propagated over several Hot Rod servers. IOW, to simplify things, if a tx is started in server A, all ops within that tx should be directed to tx. Load balancing could still happen but would need to be tx sticky.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-9061) X-site replication with functional commands throws NullPointerException
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-9061?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-9061:
------------------------------
Sprint: Sprint 9.3.0.Final
> X-site replication with functional commands throws NullPointerException
> -----------------------------------------------------------------------
>
> Key: ISPN-9061
> URL: https://issues.jboss.org/browse/ISPN-9061
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Affects Versions: 9.2.1.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Fix For: 9.3.0.Final
>
>
> {{CacheOperationsTest.testFunctional()}} checks that some keys do not exist in the cache by calling {{evalMany}} on a read-write map, but with a read-only lambda.
> This creates a {{VersionedRepeatableReadEntry(value=null)}} in the tx invocation context, and {{BackupSenderImpl.filterModifications()}} sends that to the remote site as a {{PutKeyValueCommand(value=null)}}. On the remote site this is translated as {{cache.put(key, null)}}, which finally throws a {{NullPointerException}}:
> {noformat}
> 15:18:54,543 WARN (remote-thread-CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeD-p40433-t6:[]) [GlobalInboundInvocationHandler] ISPN000071: Caught exception when handling command SingleXSiteRpcCommand{command=PrepareCommand {modifications=[PutKeyValueCommand{key=MagicKey#k2{1910/3D34DA4D/67@CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeB-4295}, value=null, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=0, version=0}}, successful=true, topologyId=-1}, PutKeyValueCommand{key=MagicKey#k0{190E/360DCEC7/18@CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeA-60870}, value=null, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=0, version=0}}, successful=true, topologyId=-1}, PutKeyValueCommand{key=MagicKey#k1{190F/71AF2073/6@CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeB-4295}, value=null, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=0, version=0}}, successful=true, topologyId=-1}], onePhaseCommit=false, retried=false, gtx=GlobalTx:CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeA-60870:26069, cacheName='___defaultcache', topologyId=-1}}
> java.lang.NullPointerException: Null values are not supported!
> at java.util.Objects.requireNonNull(Objects.java:228) ~[?:1.8.0_152]
> at org.infinispan.cache.impl.CacheImpl.assertValueNotNull(CacheImpl.java:199) ~[classes/:?]
> at org.infinispan.cache.impl.CacheImpl.assertKeyValueNotNull(CacheImpl.java:204) ~[classes/:?]
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1331) ~[classes/:?]
> at org.infinispan.cache.impl.DecoratedCache.put(DecoratedCache.java:654) ~[classes/:?]
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.put(AbstractDelegatingAdvancedCache.java:355) ~[classes/:?]
> at org.infinispan.cache.impl.EncoderCache.put(EncoderCache.java:425) ~[classes/:?]
> at org.infinispan.xsite.BaseBackupReceiver$BackupCacheUpdater.visitPutKeyValueCommand(BaseBackupReceiver.java:110) ~[classes/:?]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67) ~[classes/:?]
> at org.infinispan.xsite.BaseBackupReceiver$BackupCacheUpdater.replayModifications(BaseBackupReceiver.java:259) ~[classes/:?]
> at org.infinispan.xsite.BaseBackupReceiver$BackupCacheUpdater.visitPrepareCommand(BaseBackupReceiver.java:155) ~[classes/:?]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:185) ~[classes/:?]
> at org.infinispan.xsite.BaseBackupReceiver.handleRemoteCommand(BaseBackupReceiver.java:76) ~[classes/:?]
> at org.infinispan.xsite.SingleXSiteRpcCommand.performInLocalSite(SingleXSiteRpcCommand.java:37) ~[classes/:?]
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.runXSiteReplicableCommand(GlobalInboundInvocationHandler.java:126) ~[classes/:?]
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.lambda$handleFromRemoteSite$0(GlobalInboundInvocationHandler.java:95) ~[classes/:?]
> {noformat}
> There's no exception on the local node, maybe because entries with null values are not committed regardless of what their flags say.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-9061) X-site replication with functional commands throws NullPointerException
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-9061?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-9061:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/6051
> X-site replication with functional commands throws NullPointerException
> -----------------------------------------------------------------------
>
> Key: ISPN-9061
> URL: https://issues.jboss.org/browse/ISPN-9061
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Affects Versions: 9.2.1.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Fix For: 9.3.0.Final
>
>
> {{CacheOperationsTest.testFunctional()}} checks that some keys do not exist in the cache by calling {{evalMany}} on a read-write map, but with a read-only lambda.
> This creates a {{VersionedRepeatableReadEntry(value=null)}} in the tx invocation context, and {{BackupSenderImpl.filterModifications()}} sends that to the remote site as a {{PutKeyValueCommand(value=null)}}. On the remote site this is translated as {{cache.put(key, null)}}, which finally throws a {{NullPointerException}}:
> {noformat}
> 15:18:54,543 WARN (remote-thread-CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeD-p40433-t6:[]) [GlobalInboundInvocationHandler] ISPN000071: Caught exception when handling command SingleXSiteRpcCommand{command=PrepareCommand {modifications=[PutKeyValueCommand{key=MagicKey#k2{1910/3D34DA4D/67@CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeB-4295}, value=null, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=0, version=0}}, successful=true, topologyId=-1}, PutKeyValueCommand{key=MagicKey#k0{190E/360DCEC7/18@CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeA-60870}, value=null, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=0, version=0}}, successful=true, topologyId=-1}, PutKeyValueCommand{key=MagicKey#k1{190F/71AF2073/6@CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeB-4295}, value=null, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=0, version=0}}, successful=true, topologyId=-1}], onePhaseCommit=false, retried=false, gtx=GlobalTx:CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeA-60870:26069, cacheName='___defaultcache', topologyId=-1}}
> java.lang.NullPointerException: Null values are not supported!
> at java.util.Objects.requireNonNull(Objects.java:228) ~[?:1.8.0_152]
> at org.infinispan.cache.impl.CacheImpl.assertValueNotNull(CacheImpl.java:199) ~[classes/:?]
> at org.infinispan.cache.impl.CacheImpl.assertKeyValueNotNull(CacheImpl.java:204) ~[classes/:?]
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1331) ~[classes/:?]
> at org.infinispan.cache.impl.DecoratedCache.put(DecoratedCache.java:654) ~[classes/:?]
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.put(AbstractDelegatingAdvancedCache.java:355) ~[classes/:?]
> at org.infinispan.cache.impl.EncoderCache.put(EncoderCache.java:425) ~[classes/:?]
> at org.infinispan.xsite.BaseBackupReceiver$BackupCacheUpdater.visitPutKeyValueCommand(BaseBackupReceiver.java:110) ~[classes/:?]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67) ~[classes/:?]
> at org.infinispan.xsite.BaseBackupReceiver$BackupCacheUpdater.replayModifications(BaseBackupReceiver.java:259) ~[classes/:?]
> at org.infinispan.xsite.BaseBackupReceiver$BackupCacheUpdater.visitPrepareCommand(BaseBackupReceiver.java:155) ~[classes/:?]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:185) ~[classes/:?]
> at org.infinispan.xsite.BaseBackupReceiver.handleRemoteCommand(BaseBackupReceiver.java:76) ~[classes/:?]
> at org.infinispan.xsite.SingleXSiteRpcCommand.performInLocalSite(SingleXSiteRpcCommand.java:37) ~[classes/:?]
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.runXSiteReplicableCommand(GlobalInboundInvocationHandler.java:126) ~[classes/:?]
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.lambda$handleFromRemoteSite$0(GlobalInboundInvocationHandler.java:95) ~[classes/:?]
> {noformat}
> There's no exception on the local node, maybe because entries with null values are not committed regardless of what their flags say.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-9061) X-site replication with functional commands throws NullPointerException
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-9061?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-9061:
------------------------------
Fix Version/s: 9.3.0.Final
> X-site replication with functional commands throws NullPointerException
> -----------------------------------------------------------------------
>
> Key: ISPN-9061
> URL: https://issues.jboss.org/browse/ISPN-9061
> Project: Infinispan
> Issue Type: Bug
> Components: Cross-Site Replication
> Affects Versions: 9.2.1.Final
> Reporter: Dan Berindei
> Assignee: Pedro Ruivo
> Fix For: 9.3.0.Final
>
>
> {{CacheOperationsTest.testFunctional()}} checks that some keys do not exist in the cache by calling {{evalMany}} on a read-write map, but with a read-only lambda.
> This creates a {{VersionedRepeatableReadEntry(value=null)}} in the tx invocation context, and {{BackupSenderImpl.filterModifications()}} sends that to the remote site as a {{PutKeyValueCommand(value=null)}}. On the remote site this is translated as {{cache.put(key, null)}}, which finally throws a {{NullPointerException}}:
> {noformat}
> 15:18:54,543 WARN (remote-thread-CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeD-p40433-t6:[]) [GlobalInboundInvocationHandler] ISPN000071: Caught exception when handling command SingleXSiteRpcCommand{command=PrepareCommand {modifications=[PutKeyValueCommand{key=MagicKey#k2{1910/3D34DA4D/67@CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeB-4295}, value=null, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=0, version=0}}, successful=true, topologyId=-1}, PutKeyValueCommand{key=MagicKey#k0{190E/360DCEC7/18@CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeA-60870}, value=null, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=0, version=0}}, successful=true, topologyId=-1}, PutKeyValueCommand{key=MagicKey#k1{190F/71AF2073/6@CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeB-4295}, value=null, flags=[], commandInvocationId=CommandInvocation:local:0, putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=0, version=0}}, successful=true, topologyId=-1}], onePhaseCommit=false, retried=false, gtx=GlobalTx:CacheOperationsTest[REPL_SYNC, tx=true, lockingMode=OPTIMISTIC, 2PC]-NodeA-60870:26069, cacheName='___defaultcache', topologyId=-1}}
> java.lang.NullPointerException: Null values are not supported!
> at java.util.Objects.requireNonNull(Objects.java:228) ~[?:1.8.0_152]
> at org.infinispan.cache.impl.CacheImpl.assertValueNotNull(CacheImpl.java:199) ~[classes/:?]
> at org.infinispan.cache.impl.CacheImpl.assertKeyValueNotNull(CacheImpl.java:204) ~[classes/:?]
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1331) ~[classes/:?]
> at org.infinispan.cache.impl.DecoratedCache.put(DecoratedCache.java:654) ~[classes/:?]
> at org.infinispan.cache.impl.AbstractDelegatingAdvancedCache.put(AbstractDelegatingAdvancedCache.java:355) ~[classes/:?]
> at org.infinispan.cache.impl.EncoderCache.put(EncoderCache.java:425) ~[classes/:?]
> at org.infinispan.xsite.BaseBackupReceiver$BackupCacheUpdater.visitPutKeyValueCommand(BaseBackupReceiver.java:110) ~[classes/:?]
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67) ~[classes/:?]
> at org.infinispan.xsite.BaseBackupReceiver$BackupCacheUpdater.replayModifications(BaseBackupReceiver.java:259) ~[classes/:?]
> at org.infinispan.xsite.BaseBackupReceiver$BackupCacheUpdater.visitPrepareCommand(BaseBackupReceiver.java:155) ~[classes/:?]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:185) ~[classes/:?]
> at org.infinispan.xsite.BaseBackupReceiver.handleRemoteCommand(BaseBackupReceiver.java:76) ~[classes/:?]
> at org.infinispan.xsite.SingleXSiteRpcCommand.performInLocalSite(SingleXSiteRpcCommand.java:37) ~[classes/:?]
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.runXSiteReplicableCommand(GlobalInboundInvocationHandler.java:126) ~[classes/:?]
> at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler.lambda$handleFromRemoteSite$0(GlobalInboundInvocationHandler.java:95) ~[classes/:?]
> {noformat}
> There's no exception on the local node, maybe because entries with null values are not committed regardless of what their flags say.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-9283) Implement RemoteCache statistics
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-9283:
-------------------------------------
Summary: Implement RemoteCache statistics
Key: ISPN-9283
URL: https://issues.jboss.org/browse/ISPN-9283
Project: Infinispan
Issue Type: Enhancement
Components: Hot Rod
Reporter: Tristan Tarrant
The Hot Rod client does not expose any local statistics (RemoteCacheManager.getStatistics() returns the server-side stats).
We should have the following per-cache stats:
- remote hits and hit avg time
- remote misses and miss avg time
- remote removes and remove avg time
- near cache hits and avg time
- near cache miss and avg time
- near cache size
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-9277) Put & Get call is not in sync
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9277?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-9277:
------------------------------------
[~parag2borah], we never really allowed defining two caches with the same name. Previously the second cache definition would silently overwrite (or possibly merge with) the 1st definition, now we signal the error.
Your second problem is that the cache is ASYNC, which means {{cache.put(key, value)}} returns *before* the value was inserted/updated in the cache. In older versions of Infinispan, the cache would update the value on the local node synchronously, before {{cache.put(key, value)}} returns, but we had to change the approach because concurrent writes would cause inconsistencies. In general I would recommend using {{cache.putAsync(key, value)}} instead of making the cache ASYNC, because it's clearer and the behaviour is very similar now.
> Put & Get call is not in sync
> -----------------------------
>
> Key: ISPN-9277
> URL: https://issues.jboss.org/browse/ISPN-9277
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.1.Final
> Reporter: paragBorah Borah
> Priority: Blocker
> Attachments: newConfig911.txt, oldConfig722.txt
>
>
> Hello,
> We have upgraded infinispan cache from 7.2.2 to 9.1.1.
> We have configuration (old config file) where we have <local-cache> & <replicated-cache> with same name as “defaultcache”. Where in latest version 9.1.1 we can’t have same name.
> Now my concern is about configuration. In previous configuration when we perform put operation & in some time get operation giving us the latest data from cache.
> But in latest version after put operation & in some time get operation is not giving the latest updated data from cache.
> Could you please help me with the configuration details which can help me to fix this issue.
> Regards
> Parag
>
> [~NadirX]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-9277) Put & Get call is not in sync
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-9277?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-9277:
------------------------------------
[~parag2borah], we never really allowed defining two caches with the same name. Previously the second cache definition would silently overwrite (or possibly merge with) the 1st definition, now we signal the error.
Your second problem is that the cache is ASYNC, which means {{cache.put(key, value)}} returns *before* the value was inserted/updated in the cache. In older versions of Infinispan, the cache would update the value on the local node synchronously, before {{cache.put(key, value)}} returns, but we had to change the approach because concurrent writes would cause inconsistencies. In general I would recommend using {{cache.putAsync(key, value)}} instead of making the cache ASYNC, because it's clearer and the behaviour is very similar now.
> Put & Get call is not in sync
> -----------------------------
>
> Key: ISPN-9277
> URL: https://issues.jboss.org/browse/ISPN-9277
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.1.Final
> Reporter: paragBorah Borah
> Priority: Blocker
> Attachments: newConfig911.txt, oldConfig722.txt
>
>
> Hello,
> We have upgraded infinispan cache from 7.2.2 to 9.1.1.
> We have configuration (old config file) where we have <local-cache> & <replicated-cache> with same name as “defaultcache”. Where in latest version 9.1.1 we can’t have same name.
> Now my concern is about configuration. In previous configuration when we perform put operation & in some time get operation giving us the latest data from cache.
> But in latest version after put operation & in some time get operation is not giving the latest updated data from cache.
> Could you please help me with the configuration details which can help me to fix this issue.
> Regards
> Parag
>
> [~NadirX]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-9282) Near-Real-Time indexes lost when server is stopped
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-9282?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-9282:
------------------------------------
Description:
The server does not respect the stop order of the caches dictated by cache manager and tries to stop all caches in random order.
When a cache is indexed and uses the "near-real-time" index manager, it relies on the indexing caches being available during shutdown of the data cache so that it can properly flush the index to persistence storage, and this fails due to one or more index caches being unavailable.
was:
The server does not respect the stop order of the caches dictated by cache manager and tries to stop all caches in random order.
When a cache is indexed and uses the "near-real-time", it relied on the indexing caches being available so that it can properly flush the index to persistence storage, and this fails due to one or more index caches being gone.
> Near-Real-Time indexes lost when server is stopped
> --------------------------------------------------
>
> Key: ISPN-9282
> URL: https://issues.jboss.org/browse/ISPN-9282
> Project: Infinispan
> Issue Type: Bug
> Components: Indexing, Server
> Reporter: Gustavo Fernandes
>
> The server does not respect the stop order of the caches dictated by cache manager and tries to stop all caches in random order.
> When a cache is indexed and uses the "near-real-time" index manager, it relies on the indexing caches being available during shutdown of the data cache so that it can properly flush the index to persistence storage, and this fails due to one or more index caches being unavailable.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (ISPN-9282) Near-Real-Time indexes lost when server is stopped
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-9282:
---------------------------------------
Summary: Near-Real-Time indexes lost when server is stopped
Key: ISPN-9282
URL: https://issues.jboss.org/browse/ISPN-9282
Project: Infinispan
Issue Type: Bug
Components: Indexing, Server
Reporter: Gustavo Fernandes
The server does not respect the stop order of the caches dictated by cache manager and tries to stop all caches in random order.
When a cache is indexed and uses the "near-real-time", it relied on the indexing caches being available so that it can properly flush the index to persistence storage, and this fails due to one or more index caches being gone.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months