July 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7166) WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC] random failures

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-7166?page=com.atlassian.jira.plugin... ] Dan Berindei updated ISPN-7166: ------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/infinispan/infinispan/pull/4643, https://github.com/infinispan/infinispan/pull/8563 (was: https://github.com/infinispan/infinispan/pull/4643) > WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC] random failures > ------------------------------------------------------------------------------------ > > Key: ISPN-7166 > URL: https://issues.redhat.com/browse/ISPN-7166 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 9.0.0.Beta1 > > > The test requires a key to have a specific primary owner and backup owner, but because is uses the default {{SynchronizedConsistentHashFactory}}, sometimes there's no segment meeting that requirement. > {noformat} > 16:52:02,516 ERROR (testng-WriteSkewConsistencyTest[DIST_SYNC]:[]) [TestSuiteProgress] Test failed: org.infinispan.container.versioning.WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC] > java.lang.IllegalStateException: Could not find any segment owned by Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeB-47455, [Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeA-21455], primary segments: [33, 2, 3, 5, 37, 6, 41, 10, 45, 15, 48, 18, 50, 25, 59, 29], backup segments: {Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeA-21455=[35, 8, 40, 12, 14, 52, 21, 53, 22, 24, 57, 58, 27, 31]} > at org.infinispan.distribution.MagicKey.<init>(MagicKey.java:85) ~[test-classes/:?] > at org.infinispan.distribution.MagicKey.<init>(MagicKey.java:136) ~[test-classes/:?] > at org.infinispan.container.versioning.WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner(WriteSkewConsistencyTest.java:58) ~[test-classes/:?] > {noformat} > The test should either use a fixed key and accept random owners, or use a {{ControlledConsistentHashFactory}} to pin the owners. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7166) WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC] random failures

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-7166?page=com.atlassian.jira.plugin... ] Dan Berindei reopened ISPN-7166: -------------------------------- PR was not actually integrated > WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC] random failures > ------------------------------------------------------------------------------------ > > Key: ISPN-7166 > URL: https://issues.redhat.com/browse/ISPN-7166 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 9.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 9.0.0.Beta1 > > > The test requires a key to have a specific primary owner and backup owner, but because is uses the default {{SynchronizedConsistentHashFactory}}, sometimes there's no segment meeting that requirement. > {noformat} > 16:52:02,516 ERROR (testng-WriteSkewConsistencyTest[DIST_SYNC]:[]) [TestSuiteProgress] Test failed: org.infinispan.container.versioning.WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner[DIST_SYNC] > java.lang.IllegalStateException: Could not find any segment owned by Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeB-47455, [Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeA-21455], primary segments: [33, 2, 3, 5, 37, 6, 41, 10, 45, 15, 48, 18, 50, 25, 59, 29], backup segments: {Cache '___defaultcache'@WriteSkewConsistencyTest[DIST_SYNC]-NodeA-21455=[35, 8, 40, 12, 14, 52, 21, 53, 22, 24, 57, 58, 27, 31]} > at org.infinispan.distribution.MagicKey.<init>(MagicKey.java:85) ~[test-classes/:?] > at org.infinispan.distribution.MagicKey.<init>(MagicKey.java:136) ~[test-classes/:?] > at org.infinispan.container.versioning.WriteSkewConsistencyTest.testValidationOnlyInPrimaryOwner(WriteSkewConsistencyTest.java:58) ~[test-classes/:?] > {noformat} > The test should either use a fixed key and accept random owners, or use a {{ControlledConsistentHashFactory}} to pin the owners. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12126) Performance drop when using auth in REST

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-12126?page=com.atlassian.jira.plugi... ] Work on ISPN-12126 stopped by Gustavo Fernandes. ------------------------------------------------ > Performance drop when using auth in REST > ---------------------------------------- > > Key: ISPN-12126 > URL: https://issues.redhat.com/browse/ISPN-12126 > Project: Infinispan > Issue Type: Bug > Components: REST, Security > Affects Versions: 11.0.1.Final > Reporter: Gustavo Fernandes > Priority: Major > > Currently, the basic auth token is cached on a per-connection basis in the RestHandler. This works fine for HTTP/1 with keep-alive, but not for HTTP/2, because it multiplexes and uses one child-channel per each simultaneous request/response pair (stream). > -One suggestion is to use {{[org.wildfly.security.auth.realm.CachingSecurityRealm|https://wildfly-security.github.io/wildfly-elytron/1.1.x/org/wildfly/security/auth/realm/CachingSecurityRealm.html]}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also improve Hot Rod since the security realms are global- > Regarding digest authentication, due to the existence of the nonce, clients must send different headers any time, so caching the header in the server will not work -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12126) Performance drop when using auth in REST

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-12126?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-12126: ------------------------------------- Description: Currently, the basic auth token is cached on a per-connection basis in the RestHandler. This works fine for HTTP/1 with keep-alive, but not for HTTP/2, because it multiplexes and uses one child-channel per each simultaneous request/response pair (stream). -One suggestion is to use {{[org.wildfly.security.auth.realm.CachingSecurityRealm|https://wildfly-security.github.io/wildfly-elytron/1.1.x/org/wildfly/security/auth/realm/CachingSecurityRealm.html]}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also improve Hot Rod since the security realms are global- Regarding digest authentication, due to the existence of the nonce, clients must send different headers any time, so caching the header in the server will not work was: Currently, the auth token is cached on a per-connection basis in the RestHandler. This works fine for HTTP/1 with keep-alive, but not for HTTP/2, because it multiplexes and uses one child-channel per each simultaneous request/response pair (stream). -One suggestion is to use {{[org.wildfly.security.auth.realm.CachingSecurityRealm|https://wildfly-security.github.io/wildfly-elytron/1.1.x/org/wildfly/security/auth/realm/CachingSecurityRealm.html]}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also improve Hot Rod since the security realms are global- > Performance drop when using auth in REST > ---------------------------------------- > > Key: ISPN-12126 > URL: https://issues.redhat.com/browse/ISPN-12126 > Project: Infinispan > Issue Type: Bug > Components: REST, Security > Affects Versions: 11.0.1.Final > Reporter: Gustavo Fernandes > Priority: Major > > Currently, the basic auth token is cached on a per-connection basis in the RestHandler. This works fine for HTTP/1 with keep-alive, but not for HTTP/2, because it multiplexes and uses one child-channel per each simultaneous request/response pair (stream). > -One suggestion is to use {{[org.wildfly.security.auth.realm.CachingSecurityRealm|https://wildfly-security.github.io/wildfly-elytron/1.1.x/org/wildfly/security/auth/realm/CachingSecurityRealm.html]}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also improve Hot Rod since the security realms are global- > Regarding digest authentication, due to the existence of the nonce, clients must send different headers any time, so caching the header in the server will not work -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12126) Performance drop when using auth in REST

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-12126?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-12126: ------------------------------------- Description: Currently, the auth token is cached on a per-connection basis in the RestHandler. This works fine for HTTP/1 with keep-alive, but not for HTTP/2, because it multiplexes and uses one child-channel per each simultaneous request/response pair (stream). -One suggestion is to use {{[org.wildfly.security.auth.realm.CachingSecurityRealm|https://wildfly-security.github.io/wildfly-elytron/1.1.x/org/wildfly/security/auth/realm/CachingSecurityRealm.html]}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also improve Hot Rod since the security realms are global- was: Currently, the auth token is cached on a per-connection basis in the RestHandler. This works fine for HTTP/1 with keep-alive, but not for HTTP/2, because it multiplexes and uses one child-channel per each simultaneous request/response pair (stream). One suggestion is to use {{[org.wildfly.security.auth.realm.CachingSecurityRealm|https://wildfly-security.github.io/wildfly-elytron/1.1.x/org/wildfly/security/auth/realm/CachingSecurityRealm.html]}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also improve Hot Rod since the security realms are global > Performance drop when using auth in REST > ---------------------------------------- > > Key: ISPN-12126 > URL: https://issues.redhat.com/browse/ISPN-12126 > Project: Infinispan > Issue Type: Bug > Components: REST, Security > Affects Versions: 11.0.1.Final > Reporter: Gustavo Fernandes > Priority: Major > > Currently, the auth token is cached on a per-connection basis in the RestHandler. This works fine for HTTP/1 with keep-alive, but not for HTTP/2, because it multiplexes and uses one child-channel per each simultaneous request/response pair (stream). > -One suggestion is to use {{[org.wildfly.security.auth.realm.CachingSecurityRealm|https://wildfly-security.github.io/wildfly-elytron/1.1.x/org/wildfly/security/auth/realm/CachingSecurityRealm.html]}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also improve Hot Rod since the security realms are global- -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12126) Performance drop when using auth in REST

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-12126?page=com.atlassian.jira.plugi... ] Gustavo Fernandes reassigned ISPN-12126: ---------------------------------------- Assignee: (was: Gustavo Fernandes) > Performance drop when using auth in REST > ---------------------------------------- > > Key: ISPN-12126 > URL: https://issues.redhat.com/browse/ISPN-12126 > Project: Infinispan > Issue Type: Bug > Components: REST, Security > Affects Versions: 11.0.1.Final > Reporter: Gustavo Fernandes > Priority: Major > > Currently, the auth token is cached on a per-connection basis in the RestHandler. This works fine for HTTP/1 with keep-alive, but not for HTTP/2, because it multiplexes and uses one child-channel per each simultaneous request/response pair (stream). > One suggestion is to use {{[org.wildfly.security.auth.realm.CachingSecurityRealm|https://wildfly-security.github.io/wildfly-elytron/1.1.x/org/wildfly/security/auth/realm/CachingSecurityRealm.html]}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also improve Hot Rod since the security realms are global -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12109) TcpConnection.Receiver.run() blocking call

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-12109?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-12109: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/8551, https://github.com/infinispan/infinispan/pull/8562 (was: https://github.com/infinispan/infinispan/pull/8551, https://github.com/infinispan/infinispan/pull/8561) > TcpConnection.Receiver.run() blocking call > ------------------------------------------ > > Key: ISPN-12109 > URL: https://issues.redhat.com/browse/ISPN-12109 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite > Affects Versions: 11.0.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 12.0.0.Final, 11.0.2.Final > > > {noformat} > [TestSuiteProgress] Test failed: org.infinispan.distribution.rehash.WorkDuringJoinTest[DIST_SYNC, tx=false].BlockingChecker > 22:28:37.967 [Connection.Receiver [127.0.0.1:34169 - 127.0.0.1:8001]-8,WorkDuringJoinTest-NodeC] ERROR org.infinispan.commons.test.TestSuiteProgress - Test failed: org.infinispan.distribution.rehash.WorkDuringJoinTest[DIST_SYNC, tx=false].BlockingChecker > java.lang.AssertionError: Blocking call! java.net.SocketInputStream#socketRead0 on thread Thread[Connection.Receiver [127.0.0.1:34169 - 127.0.0.1:8001]-8,WorkDuringJoinTest-NodeC,5,ISPN-non-blocking-thread-group] > at org.infinispan.util.CoreTestBlockHoundIntegration.lambda$applyTo$0(CoreTestBlockHoundIntegration.java:45) ~[test-classes/:?] > at reactor.blockhound.BlockHound$Builder.lambda$install$8(BlockHound.java:383) ~[blockhound-1.0.3.RELEASE.jar:?] > at reactor.blockhound.BlockHoundRuntime.checkBlocking(BlockHoundRuntime.java:89) [?:?] > at java.net.SocketInputStream.socketRead0(SocketInputStream.java) [?:?] > at java.net.SocketInputStream.socketRead(SocketInputStream.java:115) [?:?] > at java.net.SocketInputStream.read(SocketInputStream.java:168) [?:?] > at java.net.SocketInputStream.read(SocketInputStream.java:140) [?:?] > at java.io.BufferedInputStream.fill(BufferedInputStream.java:252) [?:?] > at java.io.BufferedInputStream.read(BufferedInputStream.java:271) [?:?] > at java.io.DataInputStream.readInt(DataInputStream.java:392) [?:?] > at org.jgroups.blocks.cs.TcpConnection$Receiver.run(TcpConnection.java:301) [jgroups-4.2.1.Final.jar:4.2.1.Final] > at java.lang.Thread.run(Thread.java:834) [?:?] > {noformat} > The blocking call doesn't always happen, but it appears to be more common in the unstable CI builds: > https://ci.infinispan.org/job/InfinispanAlternateBuilds/job/InfinispanUns... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11286) compute(...) is not working without any error message if expiration parameter is used

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11286?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11286: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > compute(...) is not working without any error message if expiration parameter is used > ------------------------------------------------------------------------------------- > > Key: ISPN-11286 > URL: https://issues.redhat.com/browse/ISPN-11286 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.1.Final > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Major > Fix For: 9.4.20.Final, 11.0.2.Final, 12.0.0.Dev01 > > Attachments: Book.java, LibraryManager.java > > > If the compute operation is used with expiration parameters the value is not applied without any error message! > compute() without expiration or a put() with expiration will work correctly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11286) compute(...) is not working without any error message if expiration parameter is used

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11286?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11286: ------------------------------- Fix Version/s: 12.0.0.Dev01 (was: 12.0.0.Final) > compute(...) is not working without any error message if expiration parameter is used > ------------------------------------------------------------------------------------- > > Key: ISPN-11286 > URL: https://issues.redhat.com/browse/ISPN-11286 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.1.Final > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Major > Fix For: 9.4.20.Final, 11.0.2.Final, 12.0.0.Dev01 > > Attachments: Book.java, LibraryManager.java > > > If the compute operation is used with expiration parameters the value is not applied without any error message! > compute() without expiration or a put() with expiration will work correctly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11286) compute(...) is not working without any error message if expiration parameter is used

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11286?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11286: ------------------------------- Fix Version/s: 9.4.20.Final > compute(...) is not working without any error message if expiration parameter is used > ------------------------------------------------------------------------------------- > > Key: ISPN-11286 > URL: https://issues.redhat.com/browse/ISPN-11286 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.1.1.Final > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Final, 9.4.20.Final, 11.0.2.Final > > Attachments: Book.java, LibraryManager.java > > > If the compute operation is used with expiration parameters the value is not applied without any error message! > compute() without expiration or a put() with expiration will work correctly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2020