[JBoss JIRA] (ISPN-11129) High Availability for non-shared indexes on DIST caches
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-11129?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-11129:
-------------------------------------
Description:
'Non-shared indexes' is a setup when each node has a local index backed by the file system, using either the near-real-time or the FS index managers.
For REPL caches, a full copy of the index is kept in each node. As long as at least on node is up the queries hit the local index which represents the full index of the data.
But non-shared indexes have some drawbacks for DIST caches: each node only indexes data that the node is the primary owner. If a node goes down, there is no redundancy. This issue aims to solve this issue at two levels:
* Indexing: replicated entries should be indexed for redundancy purposes. If a primary owner goes down, the entry is indexed in the backup owner. This should follow exactly the data distribution on the cache in terms of number of replicas and rebalancing
* Querying: query broadcast is currently used for non-shared indexes. If replicated entries start to be indexed, a mechanism will have to be used to avoid retuning repeated results, since currently the broadcast simply queries all the entries in each node and join the result.
was:
'Non-shared indexes' is a setup when each node has a local index backed by the file system, using either the near-real-time or the FS index managers.
For REPL caches, a full copy of the index is kept in each node. As long as at least on node is up the queries hit the local index which represents the full index of the data.
But non-shared indexes has some drawbacks for DIST caches: each node only indexes data that the node is the primary owner. If a node goes down, there is no redundancy. This issue aims to solve this issue at two levels:
* Indexing: replicated entries should be indexed for redundancy purposes. If a primary owner goes down, the entry is indexed in the backup owner. This should follow exactly the data distribution on the cache in terms of number of replicas and rebalancing
* Querying: query broadcast is currently used for non-shared indexes. If replicated entries start to be indexed, a mechanism will have to be used to avoid retuning repeated results, since currently the broadcast simply queries all the entries in each node and join the result.
> High Availability for non-shared indexes on DIST caches
> -------------------------------------------------------
>
> Key: ISPN-11129
> URL: https://issues.redhat.com/browse/ISPN-11129
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 9.4.17.Final, 10.1.1.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 10.1.2.Final, 11.0.0.Final
>
>
> 'Non-shared indexes' is a setup when each node has a local index backed by the file system, using either the near-real-time or the FS index managers.
> For REPL caches, a full copy of the index is kept in each node. As long as at least on node is up the queries hit the local index which represents the full index of the data.
> But non-shared indexes have some drawbacks for DIST caches: each node only indexes data that the node is the primary owner. If a node goes down, there is no redundancy. This issue aims to solve this issue at two levels:
> * Indexing: replicated entries should be indexed for redundancy purposes. If a primary owner goes down, the entry is indexed in the backup owner. This should follow exactly the data distribution on the cache in terms of number of replicas and rebalancing
> * Querying: query broadcast is currently used for non-shared indexes. If replicated entries start to be indexed, a mechanism will have to be used to avoid retuning repeated results, since currently the broadcast simply queries all the entries in each node and join the result.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (ISPN-11257) Indexed queries should automatically be broadcast when needed
by Gustavo Fernandes (Jira)
Gustavo Fernandes created ISPN-11257:
----------------------------------------
Summary: Indexed queries should automatically be broadcast when needed
Key: ISPN-11257
URL: https://issues.redhat.com/browse/ISPN-11257
Project: Infinispan
Issue Type: Bug
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
Currently there is a parameter IndexedQueryMode with the values FETCH (local) or BROADCAST (clustered) for queries. When omitted, Infinispan should automatically detect if the query should be local or not based on the configuration
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (ISPN-11256) Context entries should always be MvccEntries
by Dan Berindei (Jira)
Dan Berindei created ISPN-11256:
-----------------------------------
Summary: Context entries should always be MvccEntries
Key: ISPN-11256
URL: https://issues.redhat.com/browse/ISPN-11256
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 10.1.1.Final
Reporter: Dan Berindei
Fix For: 11.0.0.Final
We optimize reads by storing {{InternalCacheEntry}} instances directly in the {{InvocationContext}}, instead of creating a {{ReadCommittedEntry}} or a {{RepeatableReadEntry}}.
This helps {{READ_COMMITTED}} behave like users expect it to, at least in local mode with OBJECT storage: since the context has a reference to the entry in the data container, the transaction sees external updates automatically. I also see this as a negative, though, becase it's practically impossible to extend it to work with distributed caches or with off-heap storage.
The downside is that reading from the entry in the context is racy, so we need {{synchronized}} blocks everywhere, and me may even be missing {{synchronized}} in some places.
It also means that things like {{ReadCommittedEntry.isLoaded()}} don't if the command that triggered the load from the store was a read, because there is no {{ReadCommittedEntry}}.
I suggest always wrapping the entry in a {{MvccEntry}}, and making {{READ_COMMITTED}} caches re-fetch the entry on every read to see external updates (maybe guarded by a flag/configuration attribute). {{SingleKeyNonTxInvocationContext}} may avoid the extra allocation by implementing {{MvccEntry}} itself.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (ISPN-6763) NPE when trying to remove entry from cache store (SingleFileStore)
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-6763?page=com.atlassian.jira.plugin... ]
Dan Berindei closed ISPN-6763.
------------------------------
Resolution: Out of Date
{{SingleFileStore.process()}} was removed in 9.3.0.
> NPE when trying to remove entry from cache store (SingleFileStore)
> ------------------------------------------------------------------
>
> Key: ISPN-6763
> URL: https://issues.redhat.com/browse/ISPN-6763
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 8.1.2.Final
> Reporter: Bogdan Sikora
> Priority: Major
>
> NPE in failover ( via kill ) test
> {noformat}
> 2016-06-08 06:13:33,567 ERROR [stderr] (persistence-thread--p23-t4) Exception in thread "persistence-thread--p23-t4" java.lang.NullPointerException
> 2016-06-08 06:13:33,568 ERROR [stderr] (persistence-thread--p23-t4) at org.infinispan.persistence.file.SingleFileStore.process(SingleFileStore.java:506)
> 2016-06-08 06:13:33,568 ERROR [stderr] (persistence-thread--p23-t4) at org.infinispan.persistence.manager.PersistenceManagerImpl.processOnAllStores(PersistenceManagerImpl.java:447)
> 2016-06-08 06:13:33,568 ERROR [stderr] (persistence-thread--p23-t4) at org.infinispan.persistence.manager.PersistenceManagerImpl.processOnAllStores(PersistenceManagerImpl.java:432)
> 2016-06-08 06:13:33,570 ERROR [stderr] (persistence-thread--p23-t4) at org.infinispan.persistence.util.PersistenceManagerCloseableSupplier.lambda$get$273(PersistenceManagerCloseableSupplier.java:115)
> 2016-06-08 06:13:33,570 ERROR [stderr] (persistence-thread--p23-t4) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 2016-06-08 06:13:33,570 ERROR [stderr] (persistence-thread--p23-t4) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 2016-06-08 06:13:33,570 ERROR [stderr] (persistence-thread--p23-t4) at org.jboss.as.clustering.infinispan.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:48)
> 2016-06-08 06:13:33,571 ERROR [stderr] (persistence-thread--p23-t4) at java.lang.Thread.run(Thread.java:745)
> {noformat}
> {noformat}
> 2016-06-08 06:13:34,344 WARN [org.infinispan.eviction.impl.ActivationManagerImpl] (default task-4) ISPN000214: Unable to remove entry under L_UafEeYdUurQTuPNaDBPDUwqWuH39gYSa6SW3eq from cache store after activation: org.infinispan.persistence.spi.PersistenceException: java.lang.NullPointerException
> at org.infinispan.persistence.file.SingleFileStore.delete(SingleFileStore.java:432)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.deleteFromAllStores(PersistenceManagerImpl.java:415)
> at org.infinispan.eviction.impl.ActivationManagerImpl.onUpdate(ActivationManagerImpl.java:65)
> at org.infinispan.container.DefaultDataContainer.lambda$put$224(DefaultDataContainer.java:227)
> at org.infinispan.commons.util.concurrent.jdk8backported.EquivalentConcurrentHashMapV8.compute(EquivalentConcurrentHashMapV8.java:1873)
> at org.infinispan.container.DefaultDataContainer.put(DefaultDataContainer.java:226)
> at org.infinispan.container.entries.ReadCommittedEntry.commit(ReadCommittedEntry.java:168)
> at org.infinispan.statetransfer.CommitManager.commit(CommitManager.java:98)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$DistributionLogic.commitSingleEntry(ClusteringDependentLogic.java:544)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(ClusteringDependentLogic.java:114)
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitContextEntry(EntryWrappingInterceptor.java:478)
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitEntryIfNeeded(EntryWrappingInterceptor.java:654)
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitContextEntries(EntryWrappingInterceptor.java:464)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:107)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:173)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:112)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:173)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:173)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:90)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:99)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:173)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:157)
> at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:144)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:173)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:112)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:173)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:228)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:86)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:173)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:112)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:173)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:112)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:173)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:157)
> at org.infinispan.transaction.xa.TransactionXaAdapter.commit(TransactionXaAdapter.java:114)
> at org.infinispan.transaction.tm.DummyTransaction.finishResource(DummyTransaction.java:401)
> at org.infinispan.transaction.tm.DummyTransaction.commitResources(DummyTransaction.java:448)
> at org.infinispan.transaction.tm.DummyTransaction.runCommit(DummyTransaction.java:321)
> at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:108)
> at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:71)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:76)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:768)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:565)
> at io.undertow.servlet.spec.HttpServletResponseImpl.doErrorDispatch(HttpServletResponseImpl.java:170)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:320)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.infinispan.persistence.file.SingleFileStore.delete(SingleFileStore.java:428)
> ... 68 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (ISPN-7157) NPE possible in cache eviction 'HIR_NONRESIDENT'
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-7157?page=com.atlassian.jira.plugin... ]
Dan Berindei closed ISPN-7157.
------------------------------
Resolution: Out of Date
LIRS support was removed in 9.0
> NPE possible in cache eviction 'HIR_NONRESIDENT'
> ------------------------------------------------
>
> Key: ISPN-7157
> URL: https://issues.redhat.com/browse/ISPN-7157
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.2.Final
> Reporter: Elias Ross
> Priority: Major
>
> Observed the following:
> java.lang.NullPointerException: null
> at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8$LIRSEvictionPolicy.findIfEntriesNeedEvicting(BoundedEquivalentConcurrentHashMapV8.java:1531) ~[org.infinispan-infinispan-commons-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8.compute(BoundedEquivalentConcurrentHashMapV8.java:3657) ~[org.infinispan-infinispan-commons-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.container.DefaultDataContainer.put(DefaultDataContainer.java:227) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.container.entries.ReadCommittedEntry.commit(ReadCommittedEntry.java:168) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.statetransfer.CommitManager.commit(CommitManager.java:100) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$LocalLogic.commitSingleEntry(ClusteringDependentLogic.java:299) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(ClusteringDependentLogic.java:115) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitContextEntry(EntryWrappingInterceptor.java:479) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitEntryIfNeeded(EntryWrappingInterceptor.java:655) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitContextEntries(EntryWrappingInterceptor.java:456) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:530) ~[org.infinispan-infinispan-core-8.2.2.Final.jar:8.2.2.Final]
> ...
> I think the cause is this code:
> } else if (evict.state == Recency.HIR_NONRESIDENT) {
> Node<K, V> node = f.find(hash, evict.getKey());
> V prevValue = node.val;
> ^^^ node can be null here
> if (prevValue != NULL_VALUE) {
> node.val = (V) NULL_VALUE;
> map.addCount(-1, -1);
>
> This is 8.2.2
> In 8.2.x the code is:
> } else if (evict.state == Recency.HIR_NONRESIDENT) {
> BoundedEquivalentConcurrentHashMapV8.Node<K, V> node = f.find(hash, evict.getKey());
> V prevValue = node.val;
> ^^^ node can be null here
> if (prevValue != BoundedEquivalentConcurrentHashMapV8.NULL_VALUE) {
> node.val = (V) BoundedEquivalentConcurrentHashMapV8.NULL_VALUE;
> Solution would be to check for null values here.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months
[JBoss JIRA] (ISPN-11253) Add task name to hotrod access log
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-11253?page=com.atlassian.jira.plugi... ]
Pedro Ruivo updated ISPN-11253:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.4.18.Final
Resolution: Done
> Add task name to hotrod access log
> ----------------------------------
>
> Key: ISPN-11253
> URL: https://issues.redhat.com/browse/ISPN-11253
> Project: Infinispan
> Issue Type: Task
> Components: Server
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 9.4.18.Final, 11.0.0.Alpha1
>
>
> The access log shows an EXEC operation, but unfortunately it doesn't say what the actual task was that was executed. We should be able to put this in the key field of the access log to provide better visibility.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 10 months