March 2019 - jboss-jira - Jboss List Archives

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

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1687?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1687: ---------------------------------- Fix Version/s: 1.9.0.CR2 (was: 1.9.0.CR1) > Initial WildFly Elytron Performance Enhancments > ----------------------------------------------- > > Key: ELY-1687 > URL: https://issues.jboss.org/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.9.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.12.1#712002)

7 years, 3 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.jboss.org/browse/ELY-1682?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1682: ---------------------------------- Fix Version/s: 1.9.0.CR2 (was: 1.9.0.CR1) > Fallback to another SASL client mechanism when SASL client initialisation fails > ------------------------------------------------------------------------------- > > Key: ELY-1682 > URL: https://issues.jboss.org/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.9.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.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1617) Support SSL Certificate revocation using OCSP

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1617?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1617: ---------------------------------- Fix Version/s: 1.9.0.CR2 (was: 1.9.0.CR1) > Support SSL Certificate revocation using OCSP > --------------------------------------------- > > Key: ELY-1617 > URL: https://issues.jboss.org/browse/ELY-1617 > Project: WildFly Elytron > Issue Type: Task > Components: SSL > Affects Versions: 1.4.0.Final > Reporter: Jan Kalina > Assignee: Martin Mazanek > Priority: Critical > Fix For: 1.9.0.CR2 > > > - Provide undertow's client certificate revocation capability when undertow is used as a load balancer using OCSP. > (CRL capability is provided in the earlier release as part of Elytron SSL Consolidation effort that this JIRA is cloned from) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1525) When SSO is enabled, multipart form and form enconding stop working.

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1525?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1525: ---------------------------------- Fix Version/s: 1.9.0.CR2 (was: 1.9.0.CR1) > When SSO is enabled, multipart form and form enconding stop working. > -------------------------------------------------------------------- > > Key: ELY-1525 > URL: https://issues.jboss.org/browse/ELY-1525 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.6.Final, 1.2.1.Final > Reporter: Estevão Freitas > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.9.0.CR2 > > > I developed a JSF application with "h:inputFile" component and it requires a form with " enctype="multipart/form-data" ". > I use this tutorial for SSO: https://docs.jboss.org/author/display/WFLY/Web+Single+Sign-On . > When I execute the last step: " /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=example-keystore, key-alias=localhost, domain=localhost, credential-reference=clear-text=secret}) ", all commandButtons stop working. > If I remove the "h:inputFile" component and " enctype="multipart/form-data" " from form all buttons works again, but all words with accents are corrupted. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

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

by Darran Lofthouse (Jira)

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

7 years, 3 months

1
0
0 / 0

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

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1735?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1735: ---------------------------------- Fix Version/s: 1.9.0.CR2 (was: 1.9.0.CR1) > Clean up the 'wildfly-elytron-auth-server' module as it currently contains both public and private API > ------------------------------------------------------------------------------------------------------ > > Key: ELY-1735 > URL: https://issues.jboss.org/browse/ELY-1735 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Assignee: Diana Vilkolakova > Priority: Major > Fix For: 1.9.0.CR2, 2.0.0.Alpha2 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1726) Revisit the need for `wildfly-elytron-credential` to depend on `wildfly-elytron-digest`

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1726?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1726: ---------------------------------- Fix Version/s: 1.9.0.CR2 (was: 1.9.0.CR1) > Revisit the need for `wildfly-elytron-credential` to depend on `wildfly-elytron-digest` > --------------------------------------------------------------------------------------- > > Key: ELY-1726 > URL: https://issues.jboss.org/browse/ELY-1726 > Project: WildFly Elytron > Issue Type: Task > Components: Credentials > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.9.0.CR2 > > > This was introduced in the following PR https://github.com/wildfly-security-incubator/wildfly-elytron/pull/54 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1724) Develop an alternative to 'org.wildfly.security.credential.source.OAuth2CredentialSource'

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1724?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1724: ---------------------------------- Fix Version/s: 1.9.0.CR2 (was: 1.9.0.CR1) > Develop an alternative to 'org.wildfly.security.credential.source.OAuth2CredentialSource' > ----------------------------------------------------------------------------------------- > > Key: ELY-1724 > URL: https://issues.jboss.org/browse/ELY-1724 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: Justin Cook > Priority: Critical > Fix For: 1.9.0.CR2, 2.0.0.Alpha2 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1723) Separate auth client parsing from the API.

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1723?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1723: ---------------------------------- Fix Version/s: 1.9.0.CR2 (was: 1.9.0.CR1) > Separate auth client parsing from the API. > ------------------------------------------ > > Key: ELY-1723 > URL: https://issues.jboss.org/browse/ELY-1723 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Justin Cook > Priority: Blocker > Fix For: 1.9.0.CR2, 2.0.0.Alpha2 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1716) Develop an alternative to 'wildfly-elytron-credential-source-deprecated'

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1716?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1716: ---------------------------------- Fix Version/s: 1.9.0.CR2 (was: 1.9.0.CR1) > Develop an alternative to 'wildfly-elytron-credential-source-deprecated' > ------------------------------------------------------------------------ > > Key: ELY-1716 > URL: https://issues.jboss.org/browse/ELY-1716 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: Justin Cook > Priority: Critical > Fix For: 1.9.0.CR2, 2.0.0.Alpha2 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2019