April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1687) Initial WildFly Elytron Performance Enhancments

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1687?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1687: ---------------------------------- Fix Version/s: 1.12.0.CR2 (was: 1.12.0.CR1) > Initial WildFly Elytron Performance Enhancments > ----------------------------------------------- > > Key: ELY-1687 > URL: https://issues.redhat.com/browse/ELY-1687 > Project: WildFly Elytron > Issue Type: Task > Affects Versions: 1.7.0.CR2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.12.0.CR2 > > Attachments: BASIC_Auth_Load.jmx, Flight.tgz > > > Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues. > After that we will perform the initial metric test again and close the issue. > A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test. > The first test is to test HTTP Basic authentication backed by WildFly Elytron. > * Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate. > Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes. > h2. Initial Issues > h3. WildFlyElytronProvider Locking > Total block time 8.393s via calls to java.security.Provider.getServices(); > Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance. > h3. Memory 2.42G of char[] > e.g. > {noformat} > void java.nio.HeapCharBuffer.<init>(int, int) 13037 > CharBuffer java.nio.CharBuffer.allocate(int) 9148 > CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148 > CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148 > void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148 > {noformat} > Is there any option to re-use these as they can be cleared instead of leaving to GC. > HeapByteBuffer and HeapCharBuffer are also quite prominent. > h3. Memory 1.78G of Callback[] > Using the CallbackHandler API the use of the array is inevitable. > * Could we extend the API to avoid the array? > * Could we re-use the array? Could consider null termination. > {noformat} > boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222 > void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222 > {noformat} > h3. Memory 1.41G of HttpAuthenticator$Builder > {noformat} > HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699 > boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699 > {noformat} > Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use? > h3. Memory 1.3G of SecurityContextImpl > {noformat} > SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247 > SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673 > {noformat} > Also instances of HttpAuthenticator > {noformat} > HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624 > {noformat} > And instances of HttpAuthenticator$AuthenticationExchange. > {noformat} > boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423 > {noformat} > As with HttpAuthenticator$Builder is there any way to consider re-use? > h3. Memory 1.21G of java.util.ArrayList > {noformat} > boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911 > {noformat} > Can check the use and see if an alternative is possible. > _If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._ > _This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._ > https://issues.jboss.org/browse/ELY-1689 > h3. Memory ServerAuthenticationContext States > Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states. > Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance? > h3. Memory SecurityIdentity > As an immutable object we can end up with intermediate throw away instances, can we optimise create once? > {noformat} > SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454 > ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454 > {noformat} > h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator > These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages. > Could a static Base64 conversion clean up a lot of this? > h1. Done > h3. Method Profiling - new HttpString > A lot of time spend creating new HttpString (Package is no3 in the top list) > {noformat} > void io.undertow.util.HttpString.<init>(String) 4 > void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4 > {noformat} > Could we re-use the HttpString for common header types? > Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25 > h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[] > {noformat} > FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091 > FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091 > void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091 > {noformat} > This test did not use forms at all, is this something that can be delayed until we know it is needed? > _It may be possible for the FormParserFactory to be a single static reference, the parser it self is created on a per-request basis as needed._ > https://issues.jboss.org/browse/ELYWEB-27 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1682?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1682: ---------------------------------- Fix Version/s: 1.12.0.CR2 (was: 1.12.0.CR1) > Fallback to another SASL client mechanism when SASL client initialisation fails > ------------------------------------------------------------------------------- > > Key: ELY-1682 > URL: https://issues.redhat.com/browse/ELY-1682 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.7.0.CR1 > Reporter: Martin Choma > Priority: Major > Fix For: 1.12.0.CR2 > > Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt > > > {code:title=HipChat conversation} > Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential. > But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok. > I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for? > Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected > Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case). > In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved. > Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting > though for that one as that is where that loop happens but start with an ELY issue > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1440) FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1440?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1440: ---------------------------------- Fix Version/s: 1.12.0.CR2 (was: 1.12.0.CR1) > FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself. > ---------------------------------------------------------------------------------------------- > > Key: ELY-1440 > URL: https://issues.redhat.com/browse/ELY-1440 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.12.0.CR2 > > > This API was introduced to cover the case where authentication happens late in a request, generally that is quite a rare event. > Even though the API may be popular it would likely happen once for a session and all future requests for that session the identity would be known in advance. > At the moment by not running as the existing identity we are loosing all automatic identity outflow opportunities as calls pass from the servlet container to the EJB container. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1778) Enhanced Audit Logging - Feature parity with legacy audit logging

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1778?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1778: ---------------------------------- Fix Version/s: 1.12.0.CR2 (was: 1.12.0.CR1) > Enhanced Audit Logging - Feature parity with legacy audit logging > ----------------------------------------------------------------- > > Key: ELY-1778 > URL: https://issues.redhat.com/browse/ELY-1778 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Audit > Reporter: Justin Cook > Priority: Major > Fix For: 1.12.0.CR2 > > > This RFE for Enhanced Audit Logging in WildFly Elytron is for feature parity with legacy audit logging via: > * Additional audit events > * An "Audit" annotation -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1765) Review authentication client dependencies on credential sources

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1765?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1765: ---------------------------------- Fix Version/s: 1.12.0.CR2 (was: 1.12.0.CR1) > Review authentication client dependencies on credential sources > --------------------------------------------------------------- > > Key: ELY-1765 > URL: https://issues.redhat.com/browse/ELY-1765 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.12.0.CR2 > > > Could these credential sources be discoverable from java.security.Provider with a more generic configuration API? This could help break any dependency from authentication client to the implementation. > _In the opposite direction I think it is Ok for the impl to depend on the client._ -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1749) Code review of WildFlyElytronProvider

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1749?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1749: ---------------------------------- Fix Version/s: 1.12.0.CR2 (was: 1.12.0.CR1) > Code review of WildFlyElytronProvider > ------------------------------------- > > Key: ELY-1749 > URL: https://issues.redhat.com/browse/ELY-1749 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.12.0.CR2 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1745) The AvailableRealmsCallback should not result in a NPE if there is no mechanism configuration.

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1745?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1745: ---------------------------------- Fix Version/s: 1.12.0.CR2 (was: 1.12.0.CR1) > The AvailableRealmsCallback should not result in a NPE if there is no mechanism configuration. > ---------------------------------------------------------------------------------------------- > > Key: ELY-1745 > URL: https://issues.redhat.com/browse/ELY-1745 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.12.0.CR2 > > > The NPE is due to the following code: - > {noformat} > } else if (callback instanceof AvailableRealmsCallback) { > Collection<String> names = stateRef.get().getMechanismConfiguration().getMechanismRealmNames(); > if (log.isTraceEnabled()) { > log.tracef("Handling AvailableRealmsCallback: realms = [%s]", String.join(", ", names)); > } > if (! names.isEmpty()) { > ((AvailableRealmsCallback) callback).setRealmNames(names.toArray(new String[names.size()])); > } > handleOne(callbacks, idx + 1); > {noformat} > If mechanism configuration is mandatory this should report an appropriate error, if not it should fallback to specifying an empty list. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1744) Remove use of java.security.acl APIs

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1744?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1744: ---------------------------------- Fix Version/s: 1.12.0.CR2 (was: 1.12.0.CR1) > Remove use of java.security.acl APIs > ------------------------------------ > > Key: ELY-1744 > URL: https://issues.redhat.com/browse/ELY-1744 > Project: WildFly Elytron > Issue Type: Task > Components: Realms > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.12.0.CR2 > > > The 'java.security.acls' packages has been deprecated and flagged for removal, this will be removed in Java 13 > https://bugs.openjdk.java.net/browse/JDK-8191138 > Within WildFly Elytron we only seem to use it in the JAAS security realm which I don't believe is used although likely is public API. I believe the use was to mirror some PicketBox behaviour. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1742) Clean up the 'wildfly-elytron-x500-cert' module as it currently contains both public and private API

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1742?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1742: ---------------------------------- Fix Version/s: 1.12.0.CR2 (was: 1.12.0.CR1) > Clean up the 'wildfly-elytron-x500-cert' module as it currently contains both public and private API > ---------------------------------------------------------------------------------------------------- > > Key: ELY-1742 > URL: https://issues.redhat.com/browse/ELY-1742 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.12.0.CR2 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1741) Clean up the 'wildfly-elytron-x500' module as it currently contains both public and private API

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1741?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1741: ---------------------------------- Fix Version/s: 1.12.0.CR2 (was: 1.12.0.CR1) > Clean up the 'wildfly-elytron-x500' module as it currently contains both public and private API > ----------------------------------------------------------------------------------------------- > > Key: ELY-1741 > URL: https://issues.redhat.com/browse/ELY-1741 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.12.0.CR2 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020