April 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6452) Unable to tune 'default' cache as used by JBossCachedAuthenticationManager leading to valid entries being prematurely evicted.

by Juan AMAT (JIRA)

[ https://issues.jboss.org/browse/WFLY-6452?page=com.atlassian.jira.plugin.... ] Juan AMAT commented on WFLY-6452: --------------------------------- I guess we are talking past each other because for me the cache should not be involved at that stage (and again it was not in JBoss EAP 6.4). I do not think that I can change your mind but I do feel that the current implementation will cause pain to other users that will hit this same issue. Especially people coming from JBoss EAP 6 that will migrate to EAP 7. And it should be documented. > Unable to tune 'default' cache as used by JBossCachedAuthenticationManager leading to valid entries being prematurely evicted. > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-6452 > URL: https://issues.jboss.org/browse/WFLY-6452 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Juan AMAT > Assignee: Darran Lofthouse > > While doing some performance testing of our application on Wildfly 10.0.0.Final we noticed a huge difference in CPU utlization version the same test on JBoss EAP 6.4. > What the test is doing is to run concurrently 2500 clients that log in webapp (FORM bases authentication) and that send a request every 15 seconds on average. > In JBoss EAP 6.4 cpu utilization was about 10% on a 24 cores machine with one 20G JVM. > With wildfly it was 95+%. > Threads dumps showed a lot of threads in the JAAS Login Module. > We are using org.jboss.security.auth.spi.DatabaseServerLoginModule. > This was strange because all the users were already authenticated. > It turns out that in Wildfly JBossCachedAuthenticationManager.isValid is called on every HTTP request. This is not the case in EAP 6.4. > The problem then is that we have configured the security-domain with 'cache-type=default' which will use a cache with 1000 entries less than the number of our clients. > The 'isValid' method will try to find the Principal in the cache, will not find it (most of the time) and will trigger an authentication. > We can workaround this using 'cache-type=infinispan' with a local-cache with more entries. (and this is what I did not set this ticket as blocker). > But this is just a workaround IMO. > Why is 'isValid' called on every request in Wildfly? > On a related note, it would also be nice to be able to configure the number of entries in the cache when using 'cache-type=default' -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6452) Unable to tune 'default' cache as used by JBossCachedAuthenticationManager leading to valid entries being prematurely evicted.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-6452?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-6452: ---------------------------------------- Yes the LoginModule should not be called, we should have been able to identify the corresponding entry in the cache used by JBossCachedAuthenticationManager, > Unable to tune 'default' cache as used by JBossCachedAuthenticationManager leading to valid entries being prematurely evicted. > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-6452 > URL: https://issues.jboss.org/browse/WFLY-6452 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Juan AMAT > Assignee: Darran Lofthouse > > While doing some performance testing of our application on Wildfly 10.0.0.Final we noticed a huge difference in CPU utlization version the same test on JBoss EAP 6.4. > What the test is doing is to run concurrently 2500 clients that log in webapp (FORM bases authentication) and that send a request every 15 seconds on average. > In JBoss EAP 6.4 cpu utilization was about 10% on a 24 cores machine with one 20G JVM. > With wildfly it was 95+%. > Threads dumps showed a lot of threads in the JAAS Login Module. > We are using org.jboss.security.auth.spi.DatabaseServerLoginModule. > This was strange because all the users were already authenticated. > It turns out that in Wildfly JBossCachedAuthenticationManager.isValid is called on every HTTP request. This is not the case in EAP 6.4. > The problem then is that we have configured the security-domain with 'cache-type=default' which will use a cache with 1000 entries less than the number of our clients. > The 'isValid' method will try to find the Principal in the cache, will not find it (most of the time) and will trigger an authentication. > We can workaround this using 'cache-type=infinispan' with a local-cache with more entries. (and this is what I did not set this ticket as blocker). > But this is just a workaround IMO. > Why is 'isValid' called on every request in Wildfly? > On a related note, it would also be nice to be able to configure the number of entries in the cache when using 'cache-type=default' -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6452) Unable to tune 'default' cache as used by JBossCachedAuthenticationManager leading to valid entries being prematurely evicted.

by Juan AMAT (JIRA)

[ https://issues.jboss.org/browse/WFLY-6452?page=com.atlassian.jira.plugin.... ] Juan AMAT commented on WFLY-6452: --------------------------------- OK but once you are authenticated... I still feel the need to configure a cache with some 'random' number of entries counter-intuitive. Worst case we will need to configure a cache with no limit and maybe an expiration time greater that our max session timeout. Hoping that we will not have memory issues. Again that the LoginModule was called again for an already authenticated user is not something that I would expect. IOW either I am authenticated and nothing should be done. Or I am not then a 401 should be returned for the http request or I should be redirected to my login page. > Unable to tune 'default' cache as used by JBossCachedAuthenticationManager leading to valid entries being prematurely evicted. > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-6452 > URL: https://issues.jboss.org/browse/WFLY-6452 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 10.0.0.Final > Reporter: Juan AMAT > Assignee: Darran Lofthouse > > While doing some performance testing of our application on Wildfly 10.0.0.Final we noticed a huge difference in CPU utlization version the same test on JBoss EAP 6.4. > What the test is doing is to run concurrently 2500 clients that log in webapp (FORM bases authentication) and that send a request every 15 seconds on average. > In JBoss EAP 6.4 cpu utilization was about 10% on a 24 cores machine with one 20G JVM. > With wildfly it was 95+%. > Threads dumps showed a lot of threads in the JAAS Login Module. > We are using org.jboss.security.auth.spi.DatabaseServerLoginModule. > This was strange because all the users were already authenticated. > It turns out that in Wildfly JBossCachedAuthenticationManager.isValid is called on every HTTP request. This is not the case in EAP 6.4. > The problem then is that we have configured the security-domain with 'cache-type=default' which will use a cache with 1000 entries less than the number of our clients. > The 'isValid' method will try to find the Principal in the cache, will not find it (most of the time) and will trigger an authentication. > We can workaround this using 'cache-type=infinispan' with a local-cache with more entries. (and this is what I did not set this ticket as blocker). > But this is just a workaround IMO. > Why is 'isValid' called on every request in Wildfly? > On a related note, it would also be nice to be able to configure the number of entries in the cache when using 'cache-type=default' -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6294) Session draining always takes maximum configured timeout

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6294?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-6294: -------------------------------------- Created WFLY-6453 to fix the issue with the session manager too. > Session draining always takes maximum configured timeout > -------------------------------------------------------- > > Key: WFLY-6294 > URL: https://issues.jboss.org/browse/WFLY-6294 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Aaron Ogburn > Assignee: Radoslav Husar > Priority: Minor > > The mod_cluster session drain wait is not ending as expected. mod_cluster adds a session listener to be notified of session destruction. That is fired appropriately, but when the listener is invoked, the infinispan session manager still reports the session as active. Thus, this drain loop doesn't end after the notify because it still sees the active session: > {code} > while ((remainingSessions > 0) && (noTimeout || (timeout > 0))) { > ModClusterLogger.LOGGER.drainSessions(remainingSessions, context.getHost(), context); > listener.wait(noTimeout ? 0 : timeout); > current = System.currentTimeMillis(); > timeout = end - current; > remainingSessions = context.getActiveSessionCount(); > } > {code} > Can the listeners be invoked when the session is fully removed and no longer considered active? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-381) Add ability to provide a transformation to the MechanismAuthenticationFactory factory

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-381?page=com.atlassian.jira.plugin.sy... ] David Lloyd resolved ELY-381. ----------------------------- Fix Version/s: 1.1.0.Beta3 (was: 1.1.0.Beta5) Resolution: Done > Add ability to provide a transformation to the MechanismAuthenticationFactory factory > ------------------------------------------------------------------------------------- > > Key: ELY-381 > URL: https://issues.jboss.org/browse/ELY-381 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI, HTTP, SASL > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta3 > > > Add the ability to provide a {{UnaryOperator}} which transforms the factory used in a mechanism authetication factory before using it to create the mechanism instance. This will necessitate a new type parameter to {{MechanismAuthenticationFactory}} and its derivatives. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6453) InfinispanSessionManager#getLocalSessions should only return sessions with current node locality

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6453?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6453: --------------------------------- Summary: InfinispanSessionManager#getLocalSessions should only return sessions with current node locality (was: InfinispanSessionManager#getLocalSessions should only return sessions with node locality) > InfinispanSessionManager#getLocalSessions should only return sessions with current node locality > ------------------------------------------------------------------------------------------------ > > Key: WFLY-6453 > URL: https://issues.jboss.org/browse/WFLY-6453 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > Stumbled upon while fixing WFLY-6294; modcluster is the only consumer of this at the moment. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6453) InfinispanSessionManager#getLocalSessions should only return sessions with node locality

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6453?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6453: --------------------------------- Description: Stumbled upon while fixing WFLY-6294; modcluster is the only consumer of this at the moment. (was: Stumbled upon while fixing WFLY-6294 which is the only consumer of this at the moment.) > InfinispanSessionManager#getLocalSessions should only return sessions with node locality > ---------------------------------------------------------------------------------------- > > Key: WFLY-6453 > URL: https://issues.jboss.org/browse/WFLY-6453 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Stumbled upon while fixing WFLY-6294; modcluster is the only consumer of this at the moment. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6453) InfinispanSessionManager#getLocalSessions should only return sessions with node locality

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6453?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6453: --------------------------------- Priority: Minor (was: Major) > InfinispanSessionManager#getLocalSessions should only return sessions with node locality > ---------------------------------------------------------------------------------------- > > Key: WFLY-6453 > URL: https://issues.jboss.org/browse/WFLY-6453 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > > Stumbled upon while fixing WFLY-6294; modcluster is the only consumer of this at the moment. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6453) InfinispanSessionManager#getLocalSessions should only return sessions with node locality

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-6453: ------------------------------------ Summary: InfinispanSessionManager#getLocalSessions should only return sessions with node locality Key: WFLY-6453 URL: https://issues.jboss.org/browse/WFLY-6453 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.Final Reporter: Radoslav Husar Assignee: Radoslav Husar -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6453) InfinispanSessionManager#getLocalSessions should only return sessions with node locality

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6453?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-6453: --------------------------------- Description: Stumbled upon while fixing WFLY-6294 which is the only consumer of this at the moment. > InfinispanSessionManager#getLocalSessions should only return sessions with node locality > ---------------------------------------------------------------------------------------- > > Key: WFLY-6453 > URL: https://issues.jboss.org/browse/WFLY-6453 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > Stumbled upon while fixing WFLY-6294 which is the only consumer of this at the moment. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2016