[JBoss JIRA] (ISPN-8410) BoundedOffHeapDataContainer can crash JVM
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8410?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-8410:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.2.0.Beta1
(was: 9.2.0.Beta2)
Resolution: Done
> BoundedOffHeapDataContainer can crash JVM
> -----------------------------------------
>
> Key: ISPN-8410
> URL: https://issues.jboss.org/browse/ISPN-8410
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.1.Final, 9.2.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.2.0.Beta1
>
>
> I have written a test that uses progressively larger values in order to test for fragmentation in the native heap, but it crashes the JVM:
> {noformat}
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000008
> Stack: [0x00007f8456172000,0x00007f8456273000], sp=0x00007f84562709a0, free space=1018k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> J 3123 C1 org.infinispan.container.offheap.BoundedOffHeapDataContainer.entryRemoved(J)V (357 bytes) @ 0x00007f84b9673b23 [0x00007f84b96729a0+0x1183]
> J 3122 C1 org.infinispan.container.offheap.OffHeapDataContainer.performRemove(JLjava/lang/Object;)Lorg/infinispan/container/entries/InternalCacheEntry; (124 bytes) @ 0x00007f84b9780fb4 [0x00007f84b97807c0+0x7f4]
> J 3116 C1 org.infinispan.container.offheap.BoundedOffHeapDataContainer.ensureSize()V (401 bytes) @ 0x00007f84b97483bc [0x00007f84b9746a80+0x193c]
> J 3095 C1 org.infinispan.container.offheap.BoundedOffHeapDataContainer.put(Ljava/lang/Object;Ljava/lang/Object;Lorg/infinispan/metadata/Metadata;)V (14 bytes) @ 0x00007f84b9267f8c [0x00007f84b9267ca0+0x2ec]
> J 3091 C2 org.infinispan.statetransfer.CommitManager.commit(Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/context/Flag;ZLorg/infinispan/context/InvocationContext;)V (146 bytes) @ 0x00007f84b9248aac [0x00007f84b9248260+0x84c]
> J 2655 C1 org.infinispan.interceptors.locking.ClusteringDependentLogic$LocalLogic.commitSingleEntry(Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/commands/FlagAffectedCommand;Lorg/infinispan/context/InvocationContext;Lorg/infinispan/context/Flag;Z)V (129 bytes) @ 0x00007f84b9830d54 [0x00007f84b9830420+0x934]
> J 2628 C1 org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/commands/FlagAffectedCommand;Lorg/infinispan/context/InvocationContext;Lorg/infinispan/context/Flag;Z)V (36 bytes) @ 0x00007f84b9821cfc [0x00007f84b98219a0+0x35c]
> J 2626 C1 org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitEntryIfNeeded(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/FlagAffectedCommand;Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/context/Flag;)Z (53 bytes) @ 0x00007f84b9822e64 [0x00007f84b9822580+0x8e4]
> J 3038 C1 org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntries(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/FlagAffectedCommand;)V (167 bytes) @ 0x00007f84b91970ac [0x00007f84b9195d00+0x13ac]
> J 3033 C2 org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/VisitableCommand;Lorg/infinispan/interceptors/InvocationSuccessAction;)Ljava/lang/Object; (81 bytes) @ 0x00007f84b99a1cec [0x00007f84b99a17c0+0x52c]
> J 3084 C2 org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutKeyValueCommand(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/write/PutKeyValueCommand;)Ljava/lang/Object; (13 bytes) @ 0x00007f84b9111c78 [0x00007f84b9111bc0+0xb8]
> J 2979 C2 org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/write/PutKeyValueCommand;)Ljava/lang/Object; (24 bytes) @ 0x00007f84b99c06b4 [0x00007f84b99bf1a0+0x1514]
> J 3026 C2 org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitPutKeyValueCommand(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/write/PutKeyValueCommand;)Ljava/lang/Object; (7 bytes) @ 0x00007f84b913567c [0x00007f84b9135620+0x5c]
> J 3064 C2 org.infinispan.cache.impl.EncoderCache.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; (27 bytes) @ 0x00007f84b9a3baf4 [0x00007f84b9a3b4a0+0x654]
> j org.infinispan.container.offheap.OffHeapBoundedSingleNodeStressTest.lambda$testLotsOfWrites$0(Ljava/util/Map;)Ljava/lang/Void;+21
> j org.infinispan.container.offheap.OffHeapBoundedSingleNodeStressTest$$Lambda$172.call()Ljava/lang/Object;+8
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 12 months
[JBoss JIRA] (ISPN-8400) Adjust merge policies for JDG Online Services
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8400?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8400:
--------------------------------
Fix Version/s: 9.2.0.Beta2
(was: 9.2.0.Beta1)
> Adjust merge policies for JDG Online Services
> ---------------------------------------------
>
> Key: ISPN-8400
> URL: https://issues.jboss.org/browse/ISPN-8400
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cloud Integrations
> Reporter: Sebastian Łaskawiec
> Assignee: Ryan Emerson
> Fix For: 9.2.0.Beta2
>
>
> Both Shared Memory and Caching Service require custom merge policies.
> In Caching Service we need to clear out all conflicted entries upon split brain. Shared Memory service might be a little bit more tricky and we might want to use some different strategy (but that needs to be checked out).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 12 months
[JBoss JIRA] (ISPN-8356) Embedded distribution names are confusing
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8356?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8356:
--------------------------------
Fix Version/s: 9.2.0.Beta2
(was: 9.2.0.Beta1)
> Embedded distribution names are confusing
> -----------------------------------------
>
> Key: ISPN-8356
> URL: https://issues.jboss.org/browse/ISPN-8356
> Project: Infinispan
> Issue Type: Enhancement
> Components: Build process
> Affects Versions: 9.1.1.Final
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.2.0.Beta2
>
>
> The binary distribution names for embedded libraries are confusing:
> I propose the following names
>
> - infinispan-${version}-all.zip -> infinispan-embedded-${version}-all.zip
> - infinispan-${version}-minimal.zip -> infinispan-embedded-${version}-minimal.zip
> - infinispan-${version}-remote.zip -> infinispan-remote-${version}.zip
> The website labelling needs to be modified accordingly too
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 12 months
[JBoss JIRA] (ISPN-8410) BoundedOffHeapDataContainer can crash JVM
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8410?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8410:
--------------------------------
Fix Version/s: 9.2.0.Beta2
(was: 9.2.0.Beta1)
> BoundedOffHeapDataContainer can crash JVM
> -----------------------------------------
>
> Key: ISPN-8410
> URL: https://issues.jboss.org/browse/ISPN-8410
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.1.Final, 9.2.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.2.0.Beta2
>
>
> I have written a test that uses progressively larger values in order to test for fragmentation in the native heap, but it crashes the JVM:
> {noformat}
> siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000008
> Stack: [0x00007f8456172000,0x00007f8456273000], sp=0x00007f84562709a0, free space=1018k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> J 3123 C1 org.infinispan.container.offheap.BoundedOffHeapDataContainer.entryRemoved(J)V (357 bytes) @ 0x00007f84b9673b23 [0x00007f84b96729a0+0x1183]
> J 3122 C1 org.infinispan.container.offheap.OffHeapDataContainer.performRemove(JLjava/lang/Object;)Lorg/infinispan/container/entries/InternalCacheEntry; (124 bytes) @ 0x00007f84b9780fb4 [0x00007f84b97807c0+0x7f4]
> J 3116 C1 org.infinispan.container.offheap.BoundedOffHeapDataContainer.ensureSize()V (401 bytes) @ 0x00007f84b97483bc [0x00007f84b9746a80+0x193c]
> J 3095 C1 org.infinispan.container.offheap.BoundedOffHeapDataContainer.put(Ljava/lang/Object;Ljava/lang/Object;Lorg/infinispan/metadata/Metadata;)V (14 bytes) @ 0x00007f84b9267f8c [0x00007f84b9267ca0+0x2ec]
> J 3091 C2 org.infinispan.statetransfer.CommitManager.commit(Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/context/Flag;ZLorg/infinispan/context/InvocationContext;)V (146 bytes) @ 0x00007f84b9248aac [0x00007f84b9248260+0x84c]
> J 2655 C1 org.infinispan.interceptors.locking.ClusteringDependentLogic$LocalLogic.commitSingleEntry(Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/commands/FlagAffectedCommand;Lorg/infinispan/context/InvocationContext;Lorg/infinispan/context/Flag;Z)V (129 bytes) @ 0x00007f84b9830d54 [0x00007f84b9830420+0x934]
> J 2628 C1 org.infinispan.interceptors.locking.ClusteringDependentLogic$AbstractClusteringDependentLogic.commitEntry(Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/commands/FlagAffectedCommand;Lorg/infinispan/context/InvocationContext;Lorg/infinispan/context/Flag;Z)V (36 bytes) @ 0x00007f84b9821cfc [0x00007f84b98219a0+0x35c]
> J 2626 C1 org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitEntryIfNeeded(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/FlagAffectedCommand;Lorg/infinispan/container/entries/CacheEntry;Lorg/infinispan/context/Flag;)Z (53 bytes) @ 0x00007f84b9822e64 [0x00007f84b9822580+0x8e4]
> J 3038 C1 org.infinispan.interceptors.impl.EntryWrappingInterceptor.commitContextEntries(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/FlagAffectedCommand;)V (167 bytes) @ 0x00007f84b91970ac [0x00007f84b9195d00+0x13ac]
> J 3033 C2 org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/VisitableCommand;Lorg/infinispan/interceptors/InvocationSuccessAction;)Ljava/lang/Object; (81 bytes) @ 0x00007f84b99a1cec [0x00007f84b99a17c0+0x52c]
> J 3084 C2 org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutKeyValueCommand(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/write/PutKeyValueCommand;)Ljava/lang/Object; (13 bytes) @ 0x00007f84b9111c78 [0x00007f84b9111bc0+0xb8]
> J 2979 C2 org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/write/PutKeyValueCommand;)Ljava/lang/Object; (24 bytes) @ 0x00007f84b99c06b4 [0x00007f84b99bf1a0+0x1514]
> J 3026 C2 org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitPutKeyValueCommand(Lorg/infinispan/context/InvocationContext;Lorg/infinispan/commands/write/PutKeyValueCommand;)Ljava/lang/Object; (7 bytes) @ 0x00007f84b913567c [0x00007f84b9135620+0x5c]
> J 3064 C2 org.infinispan.cache.impl.EncoderCache.put(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; (27 bytes) @ 0x00007f84b9a3baf4 [0x00007f84b9a3b4a0+0x654]
> j org.infinispan.container.offheap.OffHeapBoundedSingleNodeStressTest.lambda$testLotsOfWrites$0(Ljava/util/Map;)Ljava/lang/Void;+21
> j org.infinispan.container.offheap.OffHeapBoundedSingleNodeStressTest$$Lambda$172.call()Ljava/lang/Object;+8
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 12 months
[JBoss JIRA] (ISPN-8487) Global MBean registration happens too soon
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8487?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8487:
--------------------------------
Fix Version/s: 9.2.0.Beta2
(was: 9.2.0.Beta1)
> Global MBean registration happens too soon
> ------------------------------------------
>
> Key: ISPN-8487
> URL: https://issues.jboss.org/browse/ISPN-8487
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Alpha2
> Reporter: Dan Berindei
> Fix For: 9.2.0.Beta2
>
>
> Currently {{DefaultCacheManager}} explicitly starts {{CacheManagerJmxRegistration}} before calling {{ModuleLifecycle#cacheManagerStarting}}, which means MBeans in other modules are not registered in JMX.
> We should start {{CacheManagerJmxRegistration}} only during global component registry start, after the modules have registered their components. If we want to make the cache manager available in JMX before {{DefaultCacheManager.start()}}, we should only register that particular MBean. Conversely, on shutdown, components other than the cache manager should be removed from JMX on {{DefaultCacheManager.stop()}} (as per ISPN-118).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 12 months
[JBoss JIRA] (ISPN-8453) Commit should fail if cache is in degraded mode
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8453?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8453:
--------------------------------
Fix Version/s: 9.2.0.Beta2
(was: 9.2.0.Beta1)
> Commit should fail if cache is in degraded mode
> -----------------------------------------------
>
> Key: ISPN-8453
> URL: https://issues.jboss.org/browse/ISPN-8453
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.1.9.Final, 8.2.8.Final, 9.1.2.Final, 9.2.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.2.0.Beta2
>
>
> When the originator receives a {{CacheNotFoundResponse}} and the cache is in degraded mode, the transaction is marked as partially completed, but the commit completes successfully.
> I believe that is not correct, because the originator could crash after the commit but before the merge, and in that case the transaction will not be applied on all the owners. The transaction manager will ignore any commit exception in {{NON_XA}}/{{useSynchronization}} mode, but at least in {{FULL_XA}}/{{NON_DURABLE_XA}} mode we can signal to the user that the transaction may be lost.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 12 months
[JBoss JIRA] (ISPN-8448) Retried prepare times out while partition is in degraded mode
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8448?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8448:
--------------------------------
Fix Version/s: 9.2.0.Beta2
(was: 9.2.0.Beta1)
> Retried prepare times out while partition is in degraded mode
> -------------------------------------------------------------
>
> Key: ISPN-8448
> URL: https://issues.jboss.org/browse/ISPN-8448
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.1.9.Final, 9.0.3.Final, 8.2.8.Final, 9.1.2.Final, 9.2.0.Alpha2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.1.10.Final, 8.2.9.Final, 9.2.0.Beta2, 9.1.3.Final
>
>
> Since ISPN-5046, prepare commands are retried if one of the prepare targets has left the cluster. However, when the cache enters degraded mode, the prepare targets still include the owners in other partitions, and the prepare command is retried again.
> Each retry automatically waits for cache topology {{<command topology> + 1}}. But the second retry is not really triggered by a topology change, so the retry blocks for {{remoteTimeout}} milliseconds before failing with a {{TimeoutException}}.
> This situation actually happens in {{OptimisticTxPartitionAndMergeDuringPrepareTest}}, but the tests do not fail because it doesn't wait for an {{AvailabilityException}} specifically: they just take 15+ seconds each.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 12 months
[JBoss JIRA] (ISPN-8517) Lazily ressurect ice fromMemory
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8517?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8517:
--------------------------------
Fix Version/s: 9.2.0.Beta2
(was: 9.2.0.Beta1)
> Lazily ressurect ice fromMemory
> -------------------------------
>
> Key: ISPN-8517
> URL: https://issues.jboss.org/browse/ISPN-8517
> Project: Infinispan
> Issue Type: Sub-task
> Components: Off Heap
> Affects Versions: 9.2.0.Alpha2
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 9.2.0.Beta2, 9.1.3.Final
>
>
> Currently many places do
> {code}
> ice = ice = offHeapEntryFactory.fromMemory(address)
> if (wrappedKey.equalsWrappedBytes(ice.getKey()))
> {code}
> In cases where this ends up being a miss, we read the entire value which is wasteful. And the CPU may not have the key in the cache size we read the object into memory. Where as if we do
> {code}
> if (offHeapEntryFactory.equalsKey(address, key))
> ice = ice = offHeapEntryFactory.fromMemory(address)
> {code}
> we know that CPU is reading from the address location twice in a row, which has a very high chance of still being in CPU caches which should hopefully provide better performance. We also then don't have to read the entire ice object in memory unless there was a hit.
> We also should change _performGet_ to return the address instead of the ice. This way callers can use this address for other optimizations such as when doing a _evict_ or _compute_ which have to read the entry first before a remove.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 12 months