June 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (HIBERNATE-164) Hibernate Criteria SQL select with order by causes in DB2 big performance impact

by Petr Hariprasad Hajič (Jira)

Petr Hariprasad Hajič created HIBERNATE-164: ----------------------------------------------- Summary: Hibernate Criteria SQL select with order by causes in DB2 big performance impact Key: HIBERNATE-164 URL: https://issues.jboss.org/browse/HIBERNATE-164 Project: Hibernate Integration Issue Type: Bug Environment: Oracle Java 7, Hibernate 3.6.10.Final, Tomcat 7.0, IBM DB2 9, 10 (not tested on the last version). Reporter: Petr Hariprasad Hajič Assignee: Steve Ebersole Using detached criteria with ordering clause produces inefficient SQL (simplified). ?? DetachedCriteria crit = DetachedCriteria.forClass(Log.class); ... crit.addOrder(org.hibernate.criterion.Order.asc("dateTime"); ?? Catched hibernate QUERY in console (simplified and replaced ? with values): ??select temp.* from ( select row_number() over(order by a.dateTime asc) as rownumber, a.dateTime, a.* from T_LOG a order by a.dateTime asc) as temp where rownumber <= 75;?? Cost of this SQL is about 2*10^6 - very pure (index was used). Slightly improved SQL gives good performance: ??select temp.* from ( select row_number() over(order by a.dateTime asc) as rownumber, a.dateTime, a.* from T_LOG a) as temp where rownumber <= 75;?? Cost is about 75 (i.e. nearly milion times better), of course index was used also! But I don´t know how to modify criteria to omit But I dont know how to modify Criteria to exclude second wrong order by. Is there solution or workaround? -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

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

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1617?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1617: ---------------------------- Issue Type: Feature Request (was: Task) > Support SSL Certificate revocation using OCSP > --------------------------------------------- > > Key: ELY-1617 > URL: https://issues.jboss.org/browse/ELY-1617 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SSL > Affects Versions: 1.4.0.Final > Reporter: Jan Kalina > Assignee: Martin Mazanek > Priority: Critical > Fix For: 1.10.0.CR1 > > > - 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)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4529) Upgrade Elytron Web to 1.6.0.CR1

by Farah Juma (Jira)

Farah Juma created WFCORE-4529: ---------------------------------- Summary: Upgrade Elytron Web to 1.6.0.CR1 Key: WFCORE-4529 URL: https://issues.jboss.org/browse/WFCORE-4529 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4529) Upgrade Elytron Web to 1.6.0.CR1

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/WFCORE-4529?page=com.atlassian.jira.plugi... ] Farah Juma updated WFCORE-4529: ------------------------------- Fix Version/s: 10.0.0.Beta1 > Upgrade Elytron Web to 1.6.0.CR1 > -------------------------------- > > Key: WFCORE-4529 > URL: https://issues.jboss.org/browse/WFCORE-4529 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 10.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4528) Upgrade WildFly Elytron to 1.10.0.CR1

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/WFCORE-4528?page=com.atlassian.jira.plugi... ] Farah Juma updated WFCORE-4528: ------------------------------- Fix Version/s: 10.0.0.Beta1 > Upgrade WildFly Elytron to 1.10.0.CR1 > ------------------------------------- > > Key: WFCORE-4528 > URL: https://issues.jboss.org/browse/WFCORE-4528 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 10.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4528) Upgrade WildFly Elytron to 1.10.0.CR1

by Farah Juma (Jira)

Farah Juma created WFCORE-4528: ---------------------------------- Summary: Upgrade WildFly Elytron to 1.10.0.CR1 Key: WFCORE-4528 URL: https://issues.jboss.org/browse/WFCORE-4528 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1689) Rewrite HttpAuthenticator$AuthenticationExchange.authenticate() to use a recursive call.

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1689?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1689: ---------------------------- Fix Version/s: 1.10.0.CR2 (was: 1.10.0.CR1) > Rewrite HttpAuthenticator$AuthenticationExchange.authenticate() to use a recursive call. > ---------------------------------------------------------------------------------------- > > Key: ELY-1689 > URL: https://issues.jboss.org/browse/ELY-1689 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.10.0.CR2 > > > By switching to a recursive call we can eliminate the intermediate ArrayList which is required to hold the responders. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

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

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1687?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1687: ---------------------------- Fix Version/s: 1.10.0.CR2 (was: 1.10.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.10.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)

6 years, 11 months

1
0
0 / 0

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

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1682?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1682: ---------------------------- Fix Version/s: 1.10.0.CR2 (was: 1.10.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.10.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)

6 years, 11 months

1
0
0 / 0

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

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1525?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1525: ---------------------------- Fix Version/s: 1.10.0.CR2 (was: 1.10.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.10.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)

6 years, 11 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 June 2019