[JBoss JIRA] (ISPN-7322) Improve triangle algorithm: ordering by segment
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7322?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7322:
------------------------------
Status: Open (was: New)
> Improve triangle algorithm: ordering by segment
> -----------------------------------------------
>
> Key: ISPN-7322
> URL: https://issues.jboss.org/browse/ISPN-7322
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
>
> Current triangle algorithm uses regular message (FIFO ordered) between the primary owner and backup owners of a key. While it ensures that the backup owners receives the stream of updates in the same order, it makes everything slower since it doesn't allow different keys to be handled in parallel.
> "Triangle unordered" solves this problem by sending OOB messages (not ordered) between the primary and backup. To keep the consistency, Infinispan introduces the TriangleOrderManager that orders the updates based on the segment of the key.
> While it is not as perfect as ordering per key, the segments are static; this removes the complexity and avoids handling the cluster topology changes and key adding/removal while improves the performance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (ISPN-7322) Improve triangle algorithm: ordering by segment
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7322?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7322:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4741
> Improve triangle algorithm: ordering by segment
> -----------------------------------------------
>
> Key: ISPN-7322
> URL: https://issues.jboss.org/browse/ISPN-7322
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
>
> Current triangle algorithm uses regular message (FIFO ordered) between the primary owner and backup owners of a key. While it ensures that the backup owners receives the stream of updates in the same order, it makes everything slower since it doesn't allow different keys to be handled in parallel.
> "Triangle unordered" solves this problem by sending OOB messages (not ordered) between the primary and backup. To keep the consistency, Infinispan introduces the TriangleOrderManager that orders the updates based on the segment of the key.
> While it is not as perfect as ordering per key, the segments are static; this removes the complexity and avoids handling the cluster topology changes and key adding/removal while improves the performance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (ISPN-6928) NPE in BoundedEquivalentConcurrentHashMapV8$LIRSEvictionPolicy
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6928?page=com.atlassian.jira.plugin.... ]
William Burns closed ISPN-6928.
-------------------------------
Resolution: Duplicate Issue
This is fixed in ISPN-6998
> NPE in BoundedEquivalentConcurrentHashMapV8$LIRSEvictionPolicy
> --------------------------------------------------------------
>
> Key: ISPN-6928
> URL: https://issues.jboss.org/browse/ISPN-6928
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.2.2.Final
> Reporter: Tim Meagher
>
> Receiving a NullPointerException out of infinispan with the following stack (using 8.2.2 final):
> {noformat}
> java.lang.NullPointerException
> at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8$LIRSEvictionPolicy.findIfEntriesNeedEvicting(BoundedEquivalentConcurrentHashMapV8.java:1531)
> at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8.compute(BoundedEquivalentConcurrentHashMapV8.java:3657)
> at org.infinispan.container.DefaultDataContainer.put(DefaultDataContainer.java:227)
> at org.infinispan.container.entries.ReadCommittedEntry.commit(ReadCommittedEntry.java:168)
> at org.infinispan.statetransfer.CommitManager.commit(CommitManager.java:100)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$LocalLogic.commitSingleEntry(ClusteringDependentLogic.java:299)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(ClusteringDependentLogic.java:115)
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitContextEntry(EntryWrappingInterceptor.java:479)
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitEntryIfNeeded(EntryWrappingInterceptor.java:655)
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitContextEntries(EntryWrappingInterceptor.java:465)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:108)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:176)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:37)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:176)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:100)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:176)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:158)
> at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:145)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:176)
> 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:176)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:112)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:176)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> 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.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:73)
> at org.infinispan.cache.impl.CacheImpl.tryCommit(CacheImpl.java:1722)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1679)
> at org.infinispan.cache.impl.CacheImpl.putInternal(CacheImpl.java:1121)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1111)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1742)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:248)
> {noformat}
> Looks very similar to this issue: https://issues.jboss.org/browse/ISPN-6366
> However, not sure if it's a duplicate as our configuration is nothing like that mentioned & the line number in the stack is one off.
> Not sure what version the other issue was reported against though (and the line number in the stack on the mentioned issue is a null check in 8.2.2 final).
> Configuration for the cache with this problem is included below:
> {noformat}
> <?xml version="1.0" encoding="UTF-8"?>
> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:infinispan:config:8.2 http://www.infinispan.org/schemas/infinispan-config-8.2.xsd
> urn:infinispan:config:store:jdbc:8.0
> http://www.infinispan.org/schemas/infinispan-cachestore-jdbc-config-8.0.xsd"
> xmlns="urn:infinispan:config:8.2">
>
> <cache-container name="default" default-cache="default" statistics="true">
> <serialization>
> <advanced-externalizer class="com.lavastorm.lae.service.element.compile.storage.infinispan.impl.CompiledStorageNodeExternalizer"/>
> <advanced-externalizer class="com.lavastorm.lae.service.element.resolution.storage.infinispan.impl.ResolutionCacheEntryExternalizer"/>
> </serialization>
> <jmx duplicate-domains="true"/>
> <!-- cache configuration for non repository usages -->
> <!-- resolved-element cache -->
> <local-cache-configuration name="resolvedElementConfig">
> <transaction
> transaction-manager-lookup="org.infinispan.transaction.lookup.DummyTransactionManagerLookup"
> locking="PESSIMISTIC" />
>
> <!-- max 2k in memory entries -->
> <eviction thread-policy="DEFAULT" max-entries="2000" strategy="LIRS" />
> <persistence passivation="true">
>
> <!-- max 10k entries on disk -->
> <file-store fetch-state="false" read-only="false" purge="true" path="${ls.home}/data/webapp/cache/infinispan" max-entries="10000"/>
> </persistence>
> </local-cache-configuration>
>
> <local-cache name="resolvedElements" configuration="resolvedElementConfig" statistics="true"/>
>
> </infinispan>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (ISPN-6928) NPE in BoundedEquivalentConcurrentHashMapV8$LIRSEvictionPolicy
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6928?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-6928:
-------------------------------------
[~tmeagher] & [~crogman] I think the issue may still be present. However it is for sure gone with the latest 9.0.Beta1 or newer build as we completely rewrote eviction related code. If however the issue persists and cannot be handled and you need to stay on 8.2, I would suggest using LRU for your eviction algorithm as it will not have this problem.
> NPE in BoundedEquivalentConcurrentHashMapV8$LIRSEvictionPolicy
> --------------------------------------------------------------
>
> Key: ISPN-6928
> URL: https://issues.jboss.org/browse/ISPN-6928
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.2.2.Final
> Reporter: Tim Meagher
>
> Receiving a NullPointerException out of infinispan with the following stack (using 8.2.2 final):
> {noformat}
> java.lang.NullPointerException
> at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8$LIRSEvictionPolicy.findIfEntriesNeedEvicting(BoundedEquivalentConcurrentHashMapV8.java:1531)
> at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8.compute(BoundedEquivalentConcurrentHashMapV8.java:3657)
> at org.infinispan.container.DefaultDataContainer.put(DefaultDataContainer.java:227)
> at org.infinispan.container.entries.ReadCommittedEntry.commit(ReadCommittedEntry.java:168)
> at org.infinispan.statetransfer.CommitManager.commit(CommitManager.java:100)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$LocalLogic.commitSingleEntry(ClusteringDependentLogic.java:299)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(ClusteringDependentLogic.java:115)
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitContextEntry(EntryWrappingInterceptor.java:479)
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitEntryIfNeeded(EntryWrappingInterceptor.java:655)
> at org.infinispan.interceptors.EntryWrappingInterceptor.commitContextEntries(EntryWrappingInterceptor.java:465)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:108)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:176)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:37)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:176)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:100)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:176)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:158)
> at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:145)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:176)
> 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:176)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:112)
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:176)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> 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.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:73)
> at org.infinispan.cache.impl.CacheImpl.tryCommit(CacheImpl.java:1722)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1679)
> at org.infinispan.cache.impl.CacheImpl.putInternal(CacheImpl.java:1121)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1111)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1742)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:248)
> {noformat}
> Looks very similar to this issue: https://issues.jboss.org/browse/ISPN-6366
> However, not sure if it's a duplicate as our configuration is nothing like that mentioned & the line number in the stack is one off.
> Not sure what version the other issue was reported against though (and the line number in the stack on the mentioned issue is a null check in 8.2.2 final).
> Configuration for the cache with this problem is included below:
> {noformat}
> <?xml version="1.0" encoding="UTF-8"?>
> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:infinispan:config:8.2 http://www.infinispan.org/schemas/infinispan-config-8.2.xsd
> urn:infinispan:config:store:jdbc:8.0
> http://www.infinispan.org/schemas/infinispan-cachestore-jdbc-config-8.0.xsd"
> xmlns="urn:infinispan:config:8.2">
>
> <cache-container name="default" default-cache="default" statistics="true">
> <serialization>
> <advanced-externalizer class="com.lavastorm.lae.service.element.compile.storage.infinispan.impl.CompiledStorageNodeExternalizer"/>
> <advanced-externalizer class="com.lavastorm.lae.service.element.resolution.storage.infinispan.impl.ResolutionCacheEntryExternalizer"/>
> </serialization>
> <jmx duplicate-domains="true"/>
> <!-- cache configuration for non repository usages -->
> <!-- resolved-element cache -->
> <local-cache-configuration name="resolvedElementConfig">
> <transaction
> transaction-manager-lookup="org.infinispan.transaction.lookup.DummyTransactionManagerLookup"
> locking="PESSIMISTIC" />
>
> <!-- max 2k in memory entries -->
> <eviction thread-policy="DEFAULT" max-entries="2000" strategy="LIRS" />
> <persistence passivation="true">
>
> <!-- max 10k entries on disk -->
> <file-store fetch-state="false" read-only="false" purge="true" path="${ls.home}/data/webapp/cache/infinispan" max-entries="10000"/>
> </persistence>
> </local-cache-configuration>
>
> <local-cache name="resolvedElements" configuration="resolvedElementConfig" statistics="true"/>
>
> </infinispan>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (ISPN-6366) NPE during startup/initialization of cache from other cluster members in a distributed, synchronized cluster
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6366?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-6366:
-------------------------------------
[~mmr11408] Unfortunately that is a different issue completely unrelated. It looks like someone was shut down the node before it completed startup causing the file channel to be closed. If this is not the case you can log a different JIRA. Thanks!
> NPE during startup/initialization of cache from other cluster members in a distributed, synchronized cluster
> ------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6366
> URL: https://issues.jboss.org/browse/ISPN-6366
> Project: Infinispan
> Issue Type: Bug
> Environment: RH LINUX
> Reporter: Mehdi Rakhshani
> Attachments: btotcrc1.log, jbossDataGridConfiguration.xml, jgroups.xml
>
>
> We have 4 instances of our application that uses Infinispan in a replicated, synchronized cluster. There are multiple independent clusters running in different data centers which share the same DB so the content of the caches is the same everywhere. The instances have been running for weeks with very little activity (the internal client application that comes in via REST API to access these apps has not been brought on live yet).
> Of the 4 cluster members, 2 (app servers) use the cache for read-only, 2 (cache managers) keep the cache up to date from the DB. The app servers keep 20,000 records in the cache and the rest in a file store. The cache managers keep all records in the cache and do not use a file store. All cluster members are configured to get a copy of the cache from others in the cluster during startup.
> Without any changes, when the two tomcat containers hosting the cache mangers were recycled, they stopped coming up. The following exception is thrown in each cache manager in catalina.out.
> The key for this cache ('EdiCache') is a 39 byte string. It is made up of two left-padded strings concatenated together. The key in the exception contains {{\+}} which should be blank instead. When I dump the caches from a cluster that is running in a different data center, I see that the key is {{128738 }} not {{128738+++++++++++++++++++++++++++++++++}}.
> We are using version: 8.1.0.Final
> I can upload catalina.out, my application logs and Infinispan configuration files if needed.
> Any idea what is the cause of this error?
> {noformat}
> 2016-03-09 07:29:02,106 [remote-thread--p2-t4] ERROR org.infinispan.interceptors.InvocationContextInterceptor - ISPN000136: Error executing command PutKeyValueCommand, writing keys [128738+++++++++++++++++++++++++++++++++]
> java.lang.NullPointerException
> at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8$LIRSEvictionPolicy.findIfEntriesNeedEvicting(BoundedEquivalentConcurrentHashMapV8.java:1532)
> at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8.compute(BoundedEquivalentConcurrentHashMapV8.java:3658)
> 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$InvalidationLogic.commitSingleEntry(ClusteringDependentLogic.java:377)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$ReplicationLogic.commitSingleEntry(ClusteringDependentLogic.java:421)
> 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:455)
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:529)
> at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:560)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:198)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:74)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitNonTxDataWriteCommand(AbstractLockingInterceptor.java:93)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitDataWriteCommand(NonTransactionalLockingInterceptor.java:40)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:74)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:352)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:290)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:107)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:74)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:191)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:177)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:74)
> 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.visitPutKeyValueCommand(AbstractVisitor.java:43)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:74)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:43)
> at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34)
> 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)
> 2016-03-09 07:29:02,111 [remote-thread--p2-t4] WARN org.infinispan.remoting.inboundhandler.NonTotalOrderPerCacheInboundInvocationHandler - ISPN000071: Caught exception when handling command SingleRpcCommand{cacheName='EdiCache', command=PutKeyValueCommand{key=128738+++++++++++++++++++++++++++++++++, value=ImBusinessUnitRootEdi [address=128738, qualifier=null, buId=GC00029665M1], flags=[IGNORE_RETURN_VALUES], putIfAbsent=false, valueMatcher=MATCH_ALWAYS, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=null}, successful=true}}
> java.lang.NullPointerException
> at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8$LIRSEvictionPolicy.findIfEntriesNeedEvicting(BoundedEquivalentConcurrentHashMapV8.java:1532)
> at org.infinispan.commons.util.concurrent.jdk8backported.BoundedEquivalentConcurrentHashMapV8.compute(BoundedEquivalentConcurrentHashMapV8.java:3658)
> 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$InvalidationLogic.commitSingleEntry(ClusteringDependentLogic.java:377)
> at org.infinispan.interceptors.locking.ClusteringDependentLogic$ReplicationLogic.commitSingleEntry(ClusteringDependentLogic.java:421)
> 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:455)
> at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:529)
> at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:560)
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:198)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:74)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitNonTxDataWriteCommand(AbstractLockingInterceptor.java:93)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitDataWriteCommand(NonTransactionalLockingInterceptor.java:40)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:62)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:74)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:352)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:290)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:107)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:74)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:191)
> at org.infinispan.interceptors.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:177)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:74)
> 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.visitPutKeyValueCommand(AbstractVisitor.java:43)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:74)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:43)
> at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokePerform(BasePerCacheInboundInvocationHandler.java:92)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:34)
> 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)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 3 months
[JBoss JIRA] (ISPN-7289) Stop applying the DONT_BUNDLE flag to synchronous RPCs
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-7289?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-7289:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Stop applying the DONT_BUNDLE flag to synchronous RPCs
> ------------------------------------------------------
>
> Key: ISPN-7289
> URL: https://issues.jboss.org/browse/ISPN-7289
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.0.Beta2
>
>
> Traditionally Infinispan has been adding the {{DONT_BUNDLE}} flag to synchronous RPCs. Bela has advised removing it for quite a long time, however we have been keeping it because the {{sender-sends-with-timer}} bundler with {{DONT_BUNDLE}} had a performance edge over {{transfer-queue}} without {{DONT_BUNDLE}} (by not doing any bundling).
> With JGroups 4.0 removing {{sender-sends-with-timer}} and focusing even more on message batches, it's time to stop adding {{DONT_BUNDLE}} in Infinispan.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-6803) Precompute a bitset for each flag
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6803?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6803:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Precompute a bitset for each flag
> ---------------------------------
>
> Key: ISPN-6803
> URL: https://issues.jboss.org/browse/ISPN-6803
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.0.Beta2
>
>
> Commands now use keep track of flags as "bitsets" that are actually {{long}}.
> However, flag checks still refer to the {{Flag}} instances themselves, and because the ordinal is not a static field, it cannot be optimized away by HotSpot. We can avoid that by precomputing a bitset for each flag, and making it {{static final}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-7322) Improve triangle algorithm: ordering by segment
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7322?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7322:
------------------------------
Summary: Improve triangle algorithm: ordering by segment (was: Improve triangle algorithm ordering by segment)
> Improve triangle algorithm: ordering by segment
> -----------------------------------------------
>
> Key: ISPN-7322
> URL: https://issues.jboss.org/browse/ISPN-7322
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
>
> Current triangle algorithm uses regular message (FIFO ordered) between the primary owner and backup owners of a key. While it ensures that the backup owners receives the stream of updates in the same order, it makes everything slower since it doesn't allow different keys to be handled in parallel.
> "Triangle unordered" solves this problem by sending OOB messages (not ordered) between the primary and backup. To keep the consistency, Infinispan introduces the TriangleOrderManager that orders the updates based on the segment of the key.
> While it is not as perfect as ordering per key, the segments are static; this removes the complexity and avoids handling the cluster topology changes and key adding/removal while improves the performance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-7322) Improve triangle algorithm ordering by segment
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-7322?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-7322:
------------------------------
Summary: Improve triangle algorithm ordering by segment (was: Improve triangle algorithm by ordering by segment)
> Improve triangle algorithm ordering by segment
> ----------------------------------------------
>
> Key: ISPN-7322
> URL: https://issues.jboss.org/browse/ISPN-7322
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
>
> Current triangle algorithm uses regular message (FIFO ordered) between the primary owner and backup owners of a key. While it ensures that the backup owners receives the stream of updates in the same order, it makes everything slower since it doesn't allow different keys to be handled in parallel.
> "Triangle unordered" solves this problem by sending OOB messages (not ordered) between the primary and backup. To keep the consistency, Infinispan introduces the TriangleOrderManager that orders the updates based on the segment of the key.
> While it is not as perfect as ordering per key, the segments are static; this removes the complexity and avoids handling the cluster topology changes and key adding/removal while improves the performance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-7322) Improve triangle algorithm by ordering by segment
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-7322:
---------------------------------
Summary: Improve triangle algorithm by ordering by segment
Key: ISPN-7322
URL: https://issues.jboss.org/browse/ISPN-7322
Project: Infinispan
Issue Type: Enhancement
Components: Core
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Current triangle algorithm uses regular message (FIFO ordered) between the primary owner and backup owners of a key. While it ensures that the backup owners receives the stream of updates in the same order, it makes everything slower since it doesn't allow different keys to be handled in parallel.
"Triangle unordered" solves this problem by sending OOB messages (not ordered) between the primary and backup. To keep the consistency, Infinispan introduces the TriangleOrderManager that orders the updates based on the segment of the key.
While it is not as perfect as ordering per key, the segments are static; this removes the complexity and avoids handling the cluster topology changes and key adding/removal while improves the performance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months