July 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11304) Allow scaling up without state transfer

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11304?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11304: -------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/7916, https://github.com/infinispan/infinispan/pull/8453, https://github.com/infinispan/infinispan/pull/8559 (was: https://github.com/infinispan/infinispan/pull/7916, https://github.com/infinispan/infinispan/pull/8453) > Allow scaling up without state transfer > --------------------------------------- > > Key: ISPN-11304 > URL: https://issues.redhat.com/browse/ISPN-11304 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 10.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.2.Final > > > We should allow a cache to scale up without performing any state transfer, but without losing the data. > To simplify things, the initial version will support a single owner, and will assume that only one node is being added at a time. > The cache must be accessible remotely, but since information about the location of the keys is not accessible from the client, the client is expected to ignore ownership and use a round-robin access strategy. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 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}} 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 > Assignee: 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)

4 years, 5 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}} 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}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also make Hot Rod better 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 > Assignee: 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}} 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)

4 years, 5 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}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also make Hot Rod better 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 stream (each stream in HTTP/2 is a req/resp pair that can happen simultaneously over the same connection). One suggestion is to use {{org.wildfly.security.auth.realm.CachingSecurityRealm}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also make Hot Rod better 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 > Assignee: 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}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also make Hot Rod better since the security realms are global -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 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-connections 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 stream (each stream in HTTP/2 is a req/resp pair that can happen simultaneously over the same connection). One suggestion is to use {{org.wildfly.security.auth.realm.CachingSecurityRealm}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also make Hot Rod better 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 > Assignee: Gustavo Fernandes > Priority: Major > > Currently, the auth token is cached on a per-connections 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 stream (each stream in HTTP/2 is a req/resp pair that can happen simultaneously over the same connection). > > One suggestion is to use {{org.wildfly.security.auth.realm.CachingSecurityRealm}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also make Hot Rod better since the security realms are global -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 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 stream (each stream in HTTP/2 is a req/resp pair that can happen simultaneously over the same connection). One suggestion is to use {{org.wildfly.security.auth.realm.CachingSecurityRealm}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also make Hot Rod better since the security realms are global was: Currently, the auth token is cached on a per-connections 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 stream (each stream in HTTP/2 is a req/resp pair that can happen simultaneously over the same connection). One suggestion is to use {{org.wildfly.security.auth.realm.CachingSecurityRealm}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also make Hot Rod better 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 > Assignee: 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 stream (each stream in HTTP/2 is a req/resp pair that can happen simultaneously over the same connection). > > One suggestion is to use {{org.wildfly.security.auth.realm.CachingSecurityRealm}} around the supported security realms to cache credentials for a configurable amount of time, or based on the number of credentials. This would also make Hot Rod better since the security realms are global -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

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

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11286?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11286: ------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/8556, https://github.com/infinispan/infinispan/pull/8558 (was: https://github.com/infinispan/infinispan/pull/8556) > 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, 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)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12097) Invalidation Cache with a shared store doesn't work properly after new SPI changes

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-12097?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-12097: ------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/8545, https://github.com/infinispan/infinispan/pull/8558 (was: https://github.com/infinispan/infinispan/pull/8545) > Invalidation Cache with a shared store doesn't work properly after new SPI changes > ---------------------------------------------------------------------------------- > > Key: ISPN-12097 > URL: https://issues.redhat.com/browse/ISPN-12097 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Affects Versions: 11.0.1.Final > Reporter: Paul Ferraro > Assignee: Will Burns > Priority: Blocker > Fix For: 12.0.0.Final, 11.0.2.Final > > Attachments: Test.java > > > There seems to be something amiss with the new NonBlockingStore changes. When a transactional invalidation cache is used with a shared cache store, I've observed the entries published to the removePublisher of the NonBlockStore.batch(...) which should have targeted the writePublisher. This seems to happen when a batch only contains writes, but no removes. > See the attached test to reproduce the issue, which executes two simple cache operations against a transactional vs non-transactional cache using a shared write-through store. The transactional version fails due to unexpected removals triggered by the batch(...) method (which, in the case of the JDBC store delegates to the deleteBatch(...) and bulkUpdate(...) methods. TRACE logging indicates that entries are unexpectedly published to the removePublisher of batch(...) when transactions are enabled causing entries to be removed unexpectedly from the store (as the result of a Cache.put(...)). When tx are disabled, the batch(...) method is, of course, not in play, and everything works correctly via the individual write/delete methods. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

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

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11286?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11286: ------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/8556, https://github.com/infinispan/infinispan/pull/8557 (was: https://github.com/infinispan/infinispan/pull/8556, https://github.com/infinispan/infinispan/pull/8558) > 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, 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)

4 years, 5 months

1
0
0 / 0

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

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11286?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11286: ------------------------------ Status: Open (was: New) > 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 > 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)

4 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2020