March 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11510) Convert detection of blocking or non blocking threads

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11510?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11510: ------------------------------ Status: Open (was: New) > Convert detection of blocking or non blocking threads > ----------------------------------------------------- > > Key: ISPN-11510 > URL: https://issues.redhat.com/browse/ISPN-11510 > Project: Infinispan > Issue Type: Sub-task > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Dev04 > > > Unfortunately detecting a blocking thread by name is very fragile as a user can change the name of the threads. > Also a non blocking thread is detected by checking the implementation of the thread. This will not work for Java 15 with loom as we may not have a thread but rather a fiber. > We should detect these instead by using a thread group which will work for both and be more explicit. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11510) Convert detection of blocking or non blocking threads

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11510?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11510: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8101 > Convert detection of blocking or non blocking threads > ----------------------------------------------------- > > Key: ISPN-11510 > URL: https://issues.redhat.com/browse/ISPN-11510 > Project: Infinispan > Issue Type: Sub-task > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Dev04 > > > Unfortunately detecting a blocking thread by name is very fragile as a user can change the name of the threads. > Also a non blocking thread is detected by checking the implementation of the thread. This will not work for Java 15 with loom as we may not have a thread but rather a fiber. > We should detect these instead by using a thread group which will work for both and be more explicit. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11510) Convert detection of blocking or non blocking threads

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11510?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11510: ------------------------------ Fix Version/s: 11.0.0.Dev04 > Convert detection of blocking or non blocking threads > ----------------------------------------------------- > > Key: ISPN-11510 > URL: https://issues.redhat.com/browse/ISPN-11510 > Project: Infinispan > Issue Type: Sub-task > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Dev04 > > > Unfortunately detecting a blocking thread by name is very fragile as a user can change the name of the threads. > Also a non blocking thread is detected by checking the implementation of the thread. This will not work for Java 15 with loom as we may not have a thread but rather a fiber. > We should detect these instead by using a thread group which will work for both and be more explicit. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11518) IndexingDuringStateTransferTest random failures

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11518?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11518: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > IndexingDuringStateTransferTest random failures > ----------------------------------------------- > > Key: ISPN-11518 > URL: https://issues.redhat.com/browse/ISPN-11518 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Test Suite > Affects Versions: 11.0.0.Dev03 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 11.0.0.Dev04 > > > {{IndexingDuringStateTransferTest.test}} blocks {{StateResponseCommand}} so that state transfer doesn't finish during the test. Since state transfer is now non-blocking, blocking the thread that's trying to send the {{StateResponseCommand}} also prevents it from sending the response to the {{StateTransferStartCommand}}. > Because the {{StateTransferStartCommand}} is blocked, the requestor can't complete the transaction data future in {{StateTransferLockImpl}}, and the test can't proceed to unblock the {{StateResumeCommand}}. > The {{RpcManager}} wrapper is supposed to send the command anyway, but it doesn't catch {{AssertionError}}, so the command isn't sent and the rebalance hangs. > Eventually the put times out, and the next test also fails because it can't add a new manager: > {noformat} > java.lang.RuntimeException: java.util.concurrent.TimeoutException > at org.infinispan.query.blackbox.IndexingDuringStateTransferTest.test(IndexingDuringStateTransferTest.java:189) > at org.infinispan.query.blackbox.IndexingDuringStateTransferTest.testPut(IndexingDuringStateTransferTest.java:78) > at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: java.util.concurrent.TimeoutException > {noformat} > {noformat} > org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Initial state transfer timed out for cache defaultcache on IndexingDuringStateTransferTest-NodeF > at org.infinispan.manager.DefaultCacheManager.internalStart(DefaultCacheManager.java:746) > at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:712) > at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:268) > at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:232) > at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:225) > at org.infinispan.query.blackbox.IndexingDuringStateTransferTest.test(IndexingDuringStateTransferTest.java:144) > at org.infinispan.query.blackbox.IndexingDuringStateTransferTest.testPutIgnoreReturnValue(IndexingDuringStateTransferTest.java:82) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11529) Clustered Locks allows numOwners=1 and DENY_READ_WRITES

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-11529?page=com.atlassian.jira.plugi... ] Ryan Emerson updated ISPN-11529: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8100 > Clustered Locks allows numOwners=1 and DENY_READ_WRITES > ------------------------------------------------------- > > Key: ISPN-11529 > URL: https://issues.redhat.com/browse/ISPN-11529 > Project: Infinispan > Issue Type: Bug > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > > If the user configures a clustered lock to utilise numOwners=1 and Reliability.CONSISTENT, this will result in the partion handling strategy being set to DENY_READ_WRITES which will result in the cluster becoming degraded in the event of a single node leaving the cluster. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11529) Clustered Locks allows numOwners=1 and DENY_READ_WRITES

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-11529?page=com.atlassian.jira.plugi... ] Ryan Emerson updated ISPN-11529: -------------------------------- Status: Open (was: New) > Clustered Locks allows numOwners=1 and DENY_READ_WRITES > ------------------------------------------------------- > > Key: ISPN-11529 > URL: https://issues.redhat.com/browse/ISPN-11529 > Project: Infinispan > Issue Type: Bug > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > > If the user configures a clustered lock to utilise numOwners=1 and Reliability.CONSISTENT, this will result in the partion handling strategy being set to DENY_READ_WRITES which will result in the cluster becoming degraded in the event of a single node leaving the cluster. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11530) Only allow numOwners=1 and ALLOW_READ_WRITES strategy

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-11530?page=com.atlassian.jira.plugi... ] Ryan Emerson updated ISPN-11530: -------------------------------- Status: Open (was: New) > Only allow numOwners=1 and ALLOW_READ_WRITES strategy > ----------------------------------------------------- > > Key: ISPN-11530 > URL: https://issues.redhat.com/browse/ISPN-11530 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Core > Affects Versions: 11.0.0.Dev03 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 11.0.0.Dev04 > > > DENY_READ_WRITES or ALLOW_READS results in the cluster becoming degraded in the event of a single node leaving the cluster, therefore we should throw an exception and explain that ALLOW_READ_WRITES should be used with numOwners=1. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11530) Only allow numOwners=1 and ALLOW_READ_WRITES strategy

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-11530?page=com.atlassian.jira.plugi... ] Ryan Emerson updated ISPN-11530: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8100 > Only allow numOwners=1 and ALLOW_READ_WRITES strategy > ----------------------------------------------------- > > Key: ISPN-11530 > URL: https://issues.redhat.com/browse/ISPN-11530 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Core > Affects Versions: 11.0.0.Dev03 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 11.0.0.Dev04 > > > DENY_READ_WRITES or ALLOW_READS results in the cluster becoming degraded in the event of a single node leaving the cluster, therefore we should throw an exception and explain that ALLOW_READ_WRITES should be used with numOwners=1. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11530) Only allow numOwners=1 and ALLOW_READ_WRITES strategy

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-11530?page=com.atlassian.jira.plugi... ] Ryan Emerson updated ISPN-11530: -------------------------------- Summary: Only allow numOwners=1 and ALLOW_READ_WRITES strategy (was: Only allow numOwners=1 and ALLOW_READ_WRITES configuration) > Only allow numOwners=1 and ALLOW_READ_WRITES strategy > ----------------------------------------------------- > > Key: ISPN-11530 > URL: https://issues.redhat.com/browse/ISPN-11530 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Core > Affects Versions: 11.0.0.Dev03 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 11.0.0.Dev04 > > > DENY_READ_WRITES or ALLOW_READS results in the cluster becoming degraded in the event of a single node leaving the cluster, therefore we should throw an exception and explain that ALLOW_READ_WRITES should be used with numOwners=1. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11530) Only allow numOwners=1 and ALLOW_READ_WRITES configuration

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-11530?page=com.atlassian.jira.plugi... ] Ryan Emerson updated ISPN-11530: -------------------------------- Summary: Only allow numOwners=1 and ALLOW_READ_WRITES configuration (was: Prevent numOwners=1 and DENY_READ_WRITES configuration) > Only allow numOwners=1 and ALLOW_READ_WRITES configuration > ---------------------------------------------------------- > > Key: ISPN-11530 > URL: https://issues.redhat.com/browse/ISPN-11530 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Core > Affects Versions: 11.0.0.Dev03 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 11.0.0.Dev04 > > > This configuration results in the cluster becoming degraded in the event of a single node leaving the cluster, therefore we should throw an exception and explain that ALLOW_READ_WRITES should be used with numOwners=1. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2020