[JBoss JIRA] (ISPN-8410) BoundedOffHeapDataContainer can crash JVM
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8410?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-8410:
-------------------------------------
My guess is that this was fixed by ISPN-8454
> 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, 10 months
[JBoss JIRA] (ISPN-8535) Rest API redesign
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8535?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes reassigned ISPN-8535:
---------------------------------------
Assignee: Gustavo Fernandes
> Rest API redesign
> -----------------
>
> Key: ISPN-8535
> URL: https://issues.jboss.org/browse/ISPN-8535
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 9.2.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Fix For: 10.0.0.Final
>
>
> Infinispan REST API deals with only one resource, (the cache) and maps all operations on the cache using HTTP verbs and request parameters. The API assumes the URI is related to the cache making it hard to add new kinds of resources without causing ambiguous references.
> Since we now have other types of entities, such as counters, scripts, templates, etc, and each one of them can involve different operations, we should make the API more "Restful" by using more than one resource and collections of resources, plus HTTP verbs and operations on them. Examples:
> * Create a cache: POST /rest/caches
> * Delete a cache: DELETE /rest/caches/myCache
> * Create a template: POST /rest/templates
> * Delete a template: DELETE /rest/templates/myTemplate
> * Create an entry: POST /rest/caches/myCache/1
> * Create a counter: POST /rest/counters
> * Get a counter value: GET /rest/counters/mycounter
> * Increment a counter: GET /rest/counters/mycounter?action=increment
> * Search a cache: GET /rest/caches/myCache?action=search
> * Create a script: POST /rest/scripts/
> * Get a script source: GET /rest/scritps/myScript
> * Execute a script: GET /rest/scripts/myScript?action=execute¶m1=foo
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (ISPN-8535) Rest API redesign
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-8535:
---------------------------------------
Summary: Rest API redesign
Key: ISPN-8535
URL: https://issues.jboss.org/browse/ISPN-8535
Project: Infinispan
Issue Type: Enhancement
Components: Server
Affects Versions: 9.2.0.Final
Reporter: Gustavo Fernandes
Fix For: 10.0.0.Final
Infinispan REST API deals with only one resource, (the cache) and maps all operations on the cache using HTTP verbs and request parameters. The API assumes the URI is related to the cache making it hard to add new kinds of resources without causing ambiguous references.
Since we now have other types of entities, such as counters, scripts, templates, etc, and each one of them can involve different operations, we should make the API more "Restful" by using more than one resource and collections of resources, plus HTTP verbs and operations on them. Examples:
* Create a cache: POST /rest/caches
* Delete a cache: DELETE /rest/caches/myCache
* Create a template: POST /rest/templates
* Delete a template: DELETE /rest/templates/myTemplate
* Create an entry: POST /rest/caches/myCache/1
* Create a counter: POST /rest/counters
* Get a counter value: GET /rest/counters/mycounter
* Increment a counter: GET /rest/counters/mycounter?action=increment
* Search a cache: GET /rest/caches/myCache?action=search
* Create a script: POST /rest/scripts/
* Get a script source: GET /rest/scritps/myScript
* Execute a script: GET /rest/scripts/myScript?action=execute¶m1=foo
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (ISPN-8396) Add interceptor preventing going out of memory
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8396?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-8396:
-------------------------------------
[~dan.berindei] Yeah I am aware of that, however that is a problem in that by the time I have gotten to the perform, we already sent the remote invocation. Unless this order is different now?
> Add interceptor preventing going out of memory
> ----------------------------------------------
>
> Key: ISPN-8396
> URL: https://issues.jboss.org/browse/ISPN-8396
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cloud Integrations, Core
> Reporter: Sebastian Łaskawiec
> Assignee: William Burns
>
> We need an interceptor which will calculate the amount of required memory for PUT and report an error if that put will cause going out of memory.
> Note that this is strictly connected to eviction mechanism (we might want to evict some entries on write)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (ISPN-8534) Make off heap memory based eviction a better estimation
by William Burns (JIRA)
William Burns created ISPN-8534:
-----------------------------------
Summary: Make off heap memory based eviction a better estimation
Key: ISPN-8534
URL: https://issues.jboss.org/browse/ISPN-8534
Project: Infinispan
Issue Type: Bug
Components: Off Heap
Affects Versions: 9.2.0.Beta1
Reporter: William Burns
Due to how eviction works with off heap the address block is not counted. We should make sure that is included to get a better count.
Also we should make sure to account for at least 8 byte alignment for our various objects as they can vary in any size.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months
[JBoss JIRA] (ISPN-8533) Deadlock in pessimistic transaction
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-8533:
---------------------------------
Summary: Deadlock in pessimistic transaction
Key: ISPN-8533
URL: https://issues.jboss.org/browse/ISPN-8533
Project: Infinispan
Issue Type: Bug
Reporter: Pedro Ruivo
Assignee: Pedro Ruivo
Deadlock can happen (not sure how) during a topology change and pessimistic transaction.
2 transaction can end up in the pending lock manager and they will wait for each other to finish.
{noformat}
Caused by: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on xxxx in behalf of transaction GlobalTx:node-a:3746. Current owner GlobalTx:node-b:3629.
at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:262) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitOn(DefaultPendingLockManager.java:345) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:147) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:166) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:134) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:234) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:41) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
{noformat}
{noformat}
Caused by: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on xxxx in behalf of transaction GlobalTx:node-b:3629. Current
owner GlobalTx:node-a:3746.
at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:262) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitOn(DefaultPendingLockManager.java:345) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:147) ~[infinispan-embedded-9.1.2.Final.
jar:9.1.2.Final]
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:166) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:134) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:234) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:41) ~[infinispan-embedded-9.1.2.Final.jar:9.1.2.Final]
{noformat}
notes: confirm the pending lock manager is cleanup!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 10 months