[JBoss JIRA] (AG-140) Connection leak caused by failed transaction integration
by Dmitry Telegin (Jira)
[ https://issues.redhat.com/browse/AG-140?page=com.atlassian.jira.plugin.sy... ]
Dmitry Telegin updated AG-140:
------------------------------
Attachment: agroal-connection-leak-poc.log
> Connection leak caused by failed transaction integration
> --------------------------------------------------------
>
> Key: AG-140
> URL: https://issues.redhat.com/browse/AG-140
> Project: Agroal
> Issue Type: Bug
> Components: narayana, pool
> Affects Versions: 1.8
> Reporter: Dmitry Telegin
> Assignee: Luis Barreiro
> Priority: Major
> Attachments: agroal-connection-leak-poc.log
>
>
> If the following conditions are met:
> - transaction integration is installed;
> - connection checkout has been successful;
> - {{transactionIntegration.associate(...)}} (ConnectionPool.java:222) throws an exception,
> then the code that called {{getConnection()}} will have no reference to the connection object, hence no ability to close it and return to the pool. The connection won't be reaped or GCed, thus staying in the checked-out state forever, which in turn can lead to connection pool exhaustion.
> The following snippet demonstrates the issue (assuming that Hibernate uses Agroal+Narayana and the transaction is active):
> {code:java}
> Foo foo = new Foo();
> try {
> em.merge(foo); // org.hibernate.id.IdentifierGenerationException due to missing ID, transaction aborted
> } catch (Exception e) {
> // suppress exception
> LOG.log(Level.WARNING, "merge", e);
> }
>
> // continue using the same EntityManager
> em.find(Foo.class, 0L); // java.sql.SQLException: Exception in association of connection to existing transaction, connection leaked
> {code}
> Obviously, the usage pattern is invalid (must handle the exception properly and must not use EntityManager afterwards), but it shouldn't lead to connection leaks either.
> The compete PoC: https://github.com/dteleguin/agroal-connection-leak-poc
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13471) Fail the ws deployment packaged with JAXP implementation
by Jim Ma (Jira)
[ https://issues.redhat.com/browse/WFLY-13471?page=com.atlassian.jira.plugi... ]
Jim Ma updated WFLY-13471:
--------------------------
Summary: Fail the ws deployment packaged with JAXP implementation (was: Fail the ws deployment packaged with JAXP implementation jar)
> Fail the ws deployment packaged with JAXP implementation
> --------------------------------------------------------
>
> Key: WFLY-13471
> URL: https://issues.redhat.com/browse/WFLY-13471
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 19.1.0.Final
> Reporter: Jim Ma
> Assignee: Jim Ma
> Priority: Major
> Fix For: 20.0.0.Beta1
>
>
> Deploy JAXWS application that packages an older JAXP implementation.
> Try to get the wsdl: wget http://localhost:8080/helloWorld?wsdl
> When the container is performing operations, it should use the container's JAXP implementation, else it could fail if the application is packaging a version that is not compatible.
> 19:28:42,560 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.3.0.GA (WildFly Core 10.1.2.Final-redhat-00001) started in 4091ms - Started 426 of 652 services (374 services are lazy, passive or on-demand)
> 19:28:45,537 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /helloWorld: java.lang.AbstractMethodError: org.apache.xerces.dom.DeferredDocumentImpl.setXmlStandalone(Z)V
> at org.apache.cxf.frontend.WSDLGetUtils.updateDoc(WSDLGetUtils.java:332)
> at org.apache.cxf.frontend.WSDLGetUtils.writeWSDLDocument(WSDLGetUtils.java:708)
> at org.apache.cxf.frontend.WSDLGetUtils.getDocument(WSDLGetUtils.java:151)
> at org.apache.cxf.frontend.WSDLGetInterceptor.getDocument(WSDLGetInterceptor.java:129)
> at org.apache.cxf.frontend.WSDLGetInterceptor.handleMessage(WSDLGetInterceptor.java:77)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:110)
> at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:225)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:503)
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
> ...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13471) Fail the ws deployment packaged with JAXP implementation jar
by Jim Ma (Jira)
[ https://issues.redhat.com/browse/WFLY-13471?page=com.atlassian.jira.plugi... ]
Jim Ma updated WFLY-13471:
--------------------------
Summary: Fail the ws deployment packaged with JAXP implementation jar (was: Fail the ws deployment packed with JAXP implementation jar)
> Fail the ws deployment packaged with JAXP implementation jar
> ------------------------------------------------------------
>
> Key: WFLY-13471
> URL: https://issues.redhat.com/browse/WFLY-13471
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 19.1.0.Final
> Reporter: Jim Ma
> Assignee: Jim Ma
> Priority: Major
> Fix For: 20.0.0.Beta1
>
>
> Deploy JAXWS application that packages an older JAXP implementation.
> Try to get the wsdl: wget http://localhost:8080/helloWorld?wsdl
> When the container is performing operations, it should use the container's JAXP implementation, else it could fail if the application is packaging a version that is not compatible.
> 19:28:42,560 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.3.0.GA (WildFly Core 10.1.2.Final-redhat-00001) started in 4091ms - Started 426 of 652 services (374 services are lazy, passive or on-demand)
> 19:28:45,537 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /helloWorld: java.lang.AbstractMethodError: org.apache.xerces.dom.DeferredDocumentImpl.setXmlStandalone(Z)V
> at org.apache.cxf.frontend.WSDLGetUtils.updateDoc(WSDLGetUtils.java:332)
> at org.apache.cxf.frontend.WSDLGetUtils.writeWSDLDocument(WSDLGetUtils.java:708)
> at org.apache.cxf.frontend.WSDLGetUtils.getDocument(WSDLGetUtils.java:151)
> at org.apache.cxf.frontend.WSDLGetInterceptor.getDocument(WSDLGetInterceptor.java:129)
> at org.apache.cxf.frontend.WSDLGetInterceptor.handleMessage(WSDLGetInterceptor.java:77)
> at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
> at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:110)
> at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134)
> at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
> at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:225)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:503)
> at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
> at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
> ...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13471) Fail the ws deployment packed with JAXP implementation jar
by Jim Ma (Jira)
Jim Ma created WFLY-13471:
-----------------------------
Summary: Fail the ws deployment packed with JAXP implementation jar
Key: WFLY-13471
URL: https://issues.redhat.com/browse/WFLY-13471
Project: WildFly
Issue Type: Bug
Components: Web Services
Affects Versions: 19.1.0.Final
Reporter: Jim Ma
Assignee: Jim Ma
Fix For: 20.0.0.Beta1
Deploy JAXWS application that packages an older JAXP implementation.
Try to get the wsdl: wget http://localhost:8080/helloWorld?wsdl
When the container is performing operations, it should use the container's JAXP implementation, else it could fail if the application is packaging a version that is not compatible.
19:28:42,560 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.3.0.GA (WildFly Core 10.1.2.Final-redhat-00001) started in 4091ms - Started 426 of 652 services (374 services are lazy, passive or on-demand)
19:28:45,537 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /helloWorld: java.lang.AbstractMethodError: org.apache.xerces.dom.DeferredDocumentImpl.setXmlStandalone(Z)V
at org.apache.cxf.frontend.WSDLGetUtils.updateDoc(WSDLGetUtils.java:332)
at org.apache.cxf.frontend.WSDLGetUtils.writeWSDLDocument(WSDLGetUtils.java:708)
at org.apache.cxf.frontend.WSDLGetUtils.getDocument(WSDLGetUtils.java:151)
at org.apache.cxf.frontend.WSDLGetInterceptor.getDocument(WSDLGetInterceptor.java:129)
at org.apache.cxf.frontend.WSDLGetInterceptor.handleMessage(WSDLGetInterceptor.java:77)
at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:110)
at org.jboss.wsf.stack.cxf.transport.ServletHelper.callRequestHandler(ServletHelper.java:134)
at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:88)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:225)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:503)
at org.jboss.wsf.stack.cxf.CXFServletExt.service(CXFServletExt.java:136)
at org.jboss.wsf.spi.deployment.WSFServlet.service(WSFServlet.java:140)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFCORE-4967) RequestController drops queued tasks randomly during server start.
by P K (Jira)
[ https://issues.redhat.com/browse/WFCORE-4967?page=com.atlassian.jira.plug... ]
P K commented on WFCORE-4967:
-----------------------------
yes, please see linked PullRequest
> RequestController drops queued tasks randomly during server start.
> ------------------------------------------------------------------
>
> Key: WFCORE-4967
> URL: https://issues.redhat.com/browse/WFCORE-4967
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 11.0.0.Final
> Reporter: P K
> Assignee: Jeff Mesnil
> Priority: Major
>
> Our deployment is quite complex, EAR app containing several modules.
> After move to different data-center some of EJB timers will not be triggered at all after server restart (randomly).
> There was no change to wildfly server version and application itself.
> Only hardware/network changed and issue started occurring.
> Classified as : WEIRDO and some race conditions was assumed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[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 commented on ELY-1687:
---------------------------------------
Just marking as unassigned, this will be a good activity to pick up again but I am not working on it at the moment so if anyone else wanted to try some performance tests to identify some bottle necks that would also be great.
> 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
> Priority: Major
> 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)
6 years, 2 months
[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 reassigned ELY-1687:
-------------------------------------
Assignee: (was: Darran Lofthouse)
> 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
> Priority: Major
> 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)
6 years, 2 months