[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-
EDIT: CachingSecurityRealm apparently only caches the credential lookup and not the validation which is very costly.
Regarding DIGEST authentication, due to the existence of the (client) nonce, clients must send different headers every request time, so caching the header in the server will not work.
was:
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-
EDIT: CachingSecurityRealm apparently only cache the credential lookup and not the validation which is very costly.
Regarding DIGEST authentication, due to the existence of the (client) nonce, clients must send different headers every request time, so caching the header in the server will not work.
> 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-
> EDIT: CachingSecurityRealm apparently only caches the credential lookup and not the validation which is very costly.
> Regarding DIGEST authentication, due to the existence of the (client) nonce, clients must send different headers every request time, so caching the header in the server will not work.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (ISPN-12130) RollingUpgradeIT ignoring system properties
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-12130?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-12130:
--------------------------------
Status: Open (was: New)
> RollingUpgradeIT ignoring system properties
> -------------------------------------------
>
> Key: ISPN-12130
> URL: https://issues.redhat.com/browse/ISPN-12130
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 12.0.0.Final, 11.0.1.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 12.0.0.Dev01
>
>
> RollingUpgradeIT manually calls {{InfinispanServerDriver}}, however it passes in a new {{Properties}} object resulting any properties set on the command line, such as the image to be used for the tests, being ignored. Instead {{System.getProperties()}} should be passed to the driver.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[JBoss JIRA] (ISPN-12130) RollingUpgradeIT ignoring system properties
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-12130:
-----------------------------------
Summary: RollingUpgradeIT ignoring system properties
Key: ISPN-12130
URL: https://issues.redhat.com/browse/ISPN-12130
Project: Infinispan
Issue Type: Bug
Components: Test Suite
Affects Versions: 11.0.1.Final, 12.0.0.Final
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 12.0.0.Dev01
RollingUpgradeIT manually calls {{InfinispanServerDriver}}, however it passes in a new {{Properties}} object resulting any properties set on the command line, such as the image to be used for the tests, being ignored. Instead {{System.getProperties()}} should be passed to the driver.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[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-
EDIT: CachingSecurityRealm apparently only cache the credential lookup and not the validation which is very costly.
Regarding DIGEST authentication, due to the existence of the (client) nonce, clients must send different headers every request time, so caching the header in the server will not work.
was:
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 (client) nonce, clients must send different headers every request time, so caching the header in the server will not work.
> 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-
> EDIT: CachingSecurityRealm apparently only cache the credential lookup and not the validation which is very costly.
> Regarding DIGEST authentication, due to the existence of the (client) nonce, clients must send different headers every request time, so caching the header in the server will not work.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[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 (client) nonce, clients must send different headers every request time, so caching the header in the server will not work.
was:
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
> 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 (client) nonce, clients must send different headers every request time, so caching the header in the server will not work.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months
[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:
-------------------------------
Fix Version/s: 11.0.2.Final
12.0.0.Dev01
(was: 9.0.0.Beta1)
> 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: 11.0.2.Final, 12.0.0.Dev01
>
>
> 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)
4 years, 5 months
[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)
4 years, 5 months
[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)
4 years, 5 months