October 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2575) KeyTransformer registration is required on all nodes of the cluster, in case of custom keys

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2575: -------------------------------- Assignee: Adrian Nistor (was: Sanne Grinovero) > KeyTransformer registration is required on all nodes of the cluster, in case of custom keys > ------------------------------------------------------------------------------------------- > > Key: ISPN-2575 > URL: https://issues.jboss.org/browse/ISPN-2575 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Affects Versions: 5.2.0.Beta5 > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Attachments: ClusteredCacheTest.java > > > The case is the following: > I have a clustered cache on which I want to perform a search. I'm doing the following: > I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception: > java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer > When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager. > The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

5 days, 14 hours

2
1
0 / 0

[Red Hat JIRA] (ISPN-12429) Upgrade and release SB starter with 11.0.4.Final

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12429?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12429: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade and release SB starter with 11.0.4.Final > ------------------------------------------------- > > Key: ISPN-12429 > URL: https://issues.redhat.com/browse/ISPN-12429 > Project: Infinispan > Issue Type: Component Upgrade > Components: Spring Integration > Affects Versions: 11.0.4.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > > Upgrade the starter to 11.0.4.Final > SB 2.3.4.RELEASE > Upgrade to latests Junit 5 and Testcontainers -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[Red Hat JIRA] (ISPN-12430) AsyncNonBlockingStore can have many more modifications than modification queue size

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-12430?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-12430: ------------------------------ Status: Open (was: New) > AsyncNonBlockingStore can have many more modifications than modification queue size > ----------------------------------------------------------------------------------- > > Key: ISPN-12430 > URL: https://issues.redhat.com/browse/ISPN-12430 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Will Burns > Priority: Major > > The AsyncNonBlockingStore is known to allow for concurrent writes more than modification queue size. Unfortunately, due to how synchronized Publisher works it can be much much more if a given thread is delayed as other threads can sneak in. For example in the stress test with 1024 modification queue size I could get 6K entries in a given queue. The problem is that the concurrent publisher would add the value to its own queue which was only processed on the first thread, which means many could sneak in as no changes were actually populated in the map. > We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[Red Hat JIRA] (ISPN-12430) AsyncNonBlockingStore can have many more modifications than modification queue size

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-12430?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-12430: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8783 > AsyncNonBlockingStore can have many more modifications than modification queue size > ----------------------------------------------------------------------------------- > > Key: ISPN-12430 > URL: https://issues.redhat.com/browse/ISPN-12430 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Will Burns > Priority: Major > > The AsyncNonBlockingStore is known to allow for concurrent writes more than modification queue size. Unfortunately, due to how synchronized Publisher works it can be much much more if a given thread is delayed as other threads can sneak in. For example in the stress test with 1024 modification queue size I could get 6K entries in a given queue. The problem is that the concurrent publisher would add the value to its own queue which was only processed on the first thread, which means many could sneak in as no changes were actually populated in the map. > We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[Red Hat JIRA] (ISPN-12430) AsyncNonBlockingStore can have many more modifications than modification queue size

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-12430?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-12430: ------------------------------ Fix Version/s: 12.0.0.Dev05 > AsyncNonBlockingStore can have many more modifications than modification queue size > ----------------------------------------------------------------------------------- > > Key: ISPN-12430 > URL: https://issues.redhat.com/browse/ISPN-12430 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Dev05 > > > The AsyncNonBlockingStore is known to allow for concurrent writes more than modification queue size. Unfortunately, due to how synchronized Publisher works it can be much much more if a given thread is delayed as other threads can sneak in. For example in the stress test with 1024 modification queue size I could get 6K entries in a given queue. The problem is that the concurrent publisher would add the value to its own queue which was only processed on the first thread, which means many could sneak in as no changes were actually populated in the map. https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/r... > > We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[Red Hat JIRA] (ISPN-12430) AsyncNonBlockingStore can have many more modifications than modification queue size

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-12430?page=com.atlassian.jira.plugi... ] Will Burns reassigned ISPN-12430: --------------------------------- Assignee: Will Burns > AsyncNonBlockingStore can have many more modifications than modification queue size > ----------------------------------------------------------------------------------- > > Key: ISPN-12430 > URL: https://issues.redhat.com/browse/ISPN-12430 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > > The AsyncNonBlockingStore is known to allow for concurrent writes more than modification queue size. Unfortunately, due to how synchronized Publisher works it can be much much more if a given thread is delayed as other threads can sneak in. For example in the stress test with 1024 modification queue size I could get 6K entries in a given queue. The problem is that the concurrent publisher would add the value to its own queue which was only processed on the first thread, which means many could sneak in as no changes were actually populated in the map. > We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[Red Hat JIRA] (ISPN-12430) AsyncNonBlockingStore can have many more modifications than modification queue size

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-12430?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-12430: ------------------------------ Description: The AsyncNonBlockingStore is known to allow for concurrent writes more than modification queue size. Unfortunately, due to how synchronized Publisher works it can be much much more if a given thread is delayed as other threads can sneak in. For example in the stress test with 1024 modification queue size I could get 6K entries in a given queue. The problem is that the concurrent publisher would add the value to its own queue which was only processed on the first thread, which means many could sneak in as no changes were actually populated in the map. https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/r... We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications. was: The AsyncNonBlockingStore is known to allow for concurrent writes more than modification queue size. Unfortunately, due to how synchronized Publisher works it can be much much more if a given thread is delayed as other threads can sneak in. For example in the stress test with 1024 modification queue size I could get 6K entries in a given queue. The problem is that the concurrent publisher would add the value to its own queue which was only processed on the first thread, which means many could sneak in as no changes were actually populated in the map. We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications. > AsyncNonBlockingStore can have many more modifications than modification queue size > ----------------------------------------------------------------------------------- > > Key: ISPN-12430 > URL: https://issues.redhat.com/browse/ISPN-12430 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > > The AsyncNonBlockingStore is known to allow for concurrent writes more than modification queue size. Unfortunately, due to how synchronized Publisher works it can be much much more if a given thread is delayed as other threads can sneak in. For example in the stress test with 1024 modification queue size I could get 6K entries in a given queue. The problem is that the concurrent publisher would add the value to its own queue which was only processed on the first thread, which means many could sneak in as no changes were actually populated in the map. https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/r... > > We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[Red Hat JIRA] (ISPN-12430) AsyncNonBlockingStore can have many more modifications than modification queue size

by Will Burns (Jira)

Will Burns created ISPN-12430: --------------------------------- Summary: AsyncNonBlockingStore can have many more modifications than modification queue size Key: ISPN-12430 URL: https://issues.redhat.com/browse/ISPN-12430 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Reporter: Will Burns The AsyncNonBlockingStore is known to allow for concurrent writes more than modification queue size. Unfortunately, due to how synchronized Publisher works it can be much much more if a given thread is delayed as other threads can sneak in. For example in the stress test with 1024 modification queue size I could get 6K entries in a given queue. The problem is that the concurrent publisher would add the value to its own queue which was only processed on the first thread, which means many could sneak in as no changes were actually populated in the map. We should change this to be a bit more strict and limit the writes to only queue + # of threads with concurrent modifications. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[Red Hat JIRA] (ISPN-12423) Infispan thread freezing (STUCK) - dead lock occured

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-12423?page=com.atlassian.jira.plugi... ] Will Burns commented on ISPN-12423: ----------------------------------- A stack trace of it hung and the log together would show the best picture. Just make sure your log format includes the thread name :) > Infispan thread freezing (STUCK) - dead lock occured > ---------------------------------------------------- > > Key: ISPN-12423 > URL: https://issues.redhat.com/browse/ISPN-12423 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 11.0.4.Final > Reporter: Evgenii Balakhonov > Priority: Major > Attachments: Thread dump - heap storage.txt, Thread dump sync.txt, Thread dump.txt, cache-configuration-jdbc.xml, cache-configuration-jdbc.xml > > > During huge load some threads hangs on > java.lang.Thread.State: WAITING (parking) > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000005d2e654a8> (a java.util.concurrent.locks.StampedLock) > at java.util.concurrent.locks.StampedLock.acquireRead(StampedLock.java:1215) > at java.util.concurrent.locks.StampedLock.readLock(StampedLock.java:428) > at org.infinispan.container.offheap.OffHeapConcurrentMap.peekOrGet(OffHeapConcurrentMap.java:615) > at org.infinispan.container.offheap.OffHeapConcurrentMap.peek(OffHeapConcurrentMap.java:682) > I attached Infinispan configuration and three thread dumps: > * off heap storage enabled (Thread dump.txt) > * heap storage enabled (Thread dump - heap storage.txt) > * off heap storage enabled and replicated cache mode="SYNC" (thread dump sync.txt) > Under high load, Infinspan freezes 100% of the cases. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[Red Hat JIRA] (ISPN-12423) Infispan thread freezing (STUCK) - dead lock occured

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-12423?page=com.atlassian.jira.plugi... ] Will Burns commented on ISPN-12423: ----------------------------------- Just add {code} <Logger name="org.infinispan" level="TRACE"/> {code} to your loggers. > Infispan thread freezing (STUCK) - dead lock occured > ---------------------------------------------------- > > Key: ISPN-12423 > URL: https://issues.redhat.com/browse/ISPN-12423 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 11.0.4.Final > Reporter: Evgenii Balakhonov > Priority: Major > Attachments: Thread dump - heap storage.txt, Thread dump sync.txt, Thread dump.txt, cache-configuration-jdbc.xml, cache-configuration-jdbc.xml > > > During huge load some threads hangs on > java.lang.Thread.State: WAITING (parking) > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x00000005d2e654a8> (a java.util.concurrent.locks.StampedLock) > at java.util.concurrent.locks.StampedLock.acquireRead(StampedLock.java:1215) > at java.util.concurrent.locks.StampedLock.readLock(StampedLock.java:428) > at org.infinispan.container.offheap.OffHeapConcurrentMap.peekOrGet(OffHeapConcurrentMap.java:615) > at org.infinispan.container.offheap.OffHeapConcurrentMap.peek(OffHeapConcurrentMap.java:682) > I attached Infinispan configuration and three thread dumps: > * off heap storage enabled (Thread dump.txt) > * heap storage enabled (Thread dump - heap storage.txt) > * off heap storage enabled and replicated cache mode="SYNC" (thread dump sync.txt) > Under high load, Infinspan freezes 100% of the cases. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2020