[JBoss JIRA] (WFLY-13259) Memory leak in Hibernate pending-puts cache when L2 cache is enabled
by Sorin Potra (Jira)
[ https://issues.redhat.com/browse/WFLY-13259?page=com.atlassian.jira.plugi... ]
Sorin Potra commented on WFLY-13259:
------------------------------------
I want to bring to your attention another aspect that might help in finding the root cause of this issue. In WildFly 13 (EE7 profile) the leak is less severe. If you run the test client, you will notice that memory usage is high immediately after running the first 3500 transactions. But then, if you leave the client running and wait for a few minutes you will notice that memory usage will decrease significantly. What seems to happen is that in WildFly 13, subsequent transactions do not touch the old pending-puts entries so these will expire after 60s and will be removed by the reaping thread. So basically in WildFly 13 the leak only affects the transactions from the last few minutes. This makes it less severe but it can still be a problem if a large number of transactions are executed in a short period of time.
If you switch WildFly 13 to EE8 profile (<property name="ee8.preview.mode" value="true"/>) then you will reproduce the issue as in WildFly 19.
> Memory leak in Hibernate pending-puts cache when L2 cache is enabled
> --------------------------------------------------------------------
>
> Key: WFLY-13259
> URL: https://issues.redhat.com/browse/WFLY-13259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 18.0.1.Final, 19.0.0.Final
> Reporter: Sorin Potra
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: PathToGCRoots_strong_refs.PNG, afterOOM.hprof.zip, beforeOOM.hprof.zip, pending-puts-leak.PNG, simple-hibernate-war-client.zip, simple-hibernate-war-client.zip.2020-03-25, simple-hibernate-war.war, simple-hibernate-war.war.2020-03-25, simple-hibernate-war.zip, simple-hibernate-war.zip.2020-03-25
>
>
> Under certain conditions, described below, WildFly / Hibernate can leak memory into the pending-puts cache eventually causing an OutOfMemoryError. Attached you can find a web application and a standalone client that can be used to reproduce the problem. The web app defines two entities: a Parent and a Child. There is a bidirectional one-to-many relationship between the Parent and the Child. JPA L2 cache is enabled (Infinispan is the cache provider).
> Repeatedly executing a transaction that creates a new Child and adds it to the list of children in the Parent will cause the memory usage to increase steadily until OOM is encountered. If the execution of these transactions is stopped before reaching OOM, the memory will be reclaimed after a few minutes of inactivity.
> Attached you can find the following:
> - simple-hibernate-war.war - the web app that can be deployed in WildFly to reproduce the issue.
> - simple-hibernate-war.zip - the source code for the above web app. The servlet that is invoked by the client to create and persist a new Child is com.microfocus.sa.web.AddChildServlet
> - simple-hibernate-war-client.zip - the standalone client that can be used to invoke the AddChildServlet. After unzipping the archive, the client can be run with the following command from the client folder:
>
> java -cp bin com.microfocus.sa.client.AddChildClient
>
> If you need to run the client multiple times, you have to restart WildFly in between the runs, to start from a fresh state (the web app uses the h2 in memory databasewhich is reset at each restart).
> - pending-puts-leak.PNG - a screeshot from Memory Analyzer showing a leaked SessionImpl instance
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (ELY-1948) wildfly-elytron HTTP JWT Bearer realm CORS
by Jan Bárta (Jira)
Jan Bárta created ELY-1948:
------------------------------
Summary: wildfly-elytron HTTP JWT Bearer realm CORS
Key: ELY-1948
URL: https://issues.redhat.com/browse/ELY-1948
Project: WildFly Elytron
Issue Type: Bug
Reporter: Jan Bárta
Assignee: Darran Lofthouse
Hi,
i found possible problem with HTTP Bearer JWT.
If you need create dynamically CORS by +own policy JAXRS filter+, then it will be problem with expired/invalid (any other problem) JWT token. You will see CORS exception on expired/invalid JWT because wildfly-elytron refuse request before own policy JAXRS filters (as e.g. @PreMatching ContainerRequestFilter, ContainerResponseFilter).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Guillaume Smet (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Guillaume Smet commented on WFLY-11566:
---------------------------------------
[~tomekadamski] I finally found the time to backport this to 6.0 as I don't think we want to upgrade HV in the old versions: https://github.com/hibernate/hibernate-validator/pull/1074 .
Could you try this PR and report back?
Once you acked it, I will release a 6.0.19.Final.
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.redhat.com/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Labels: downstream_dependency
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13276) Galleon provisioning is failing intermittently on s390
by Yeray Borges Santana (Jira)
[ https://issues.redhat.com/browse/WFLY-13276?page=com.atlassian.jira.plugi... ]
Yeray Borges Santana updated WFLY-13276:
----------------------------------------
Attachment: provisioning-error.log
> Galleon provisioning is failing intermittently on s390
> ------------------------------------------------------
>
> Key: WFLY-13276
> URL: https://issues.redhat.com/browse/WFLY-13276
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: Yeray Borges Santana
> Assignee: Yeray Borges Santana
> Priority: Major
> Attachments: provisioning-error.log
>
>
> It seems to be randomly between build and dist modules, but in s390 environment the builds fail with the following error:
> {noformat}
> org.jboss.galleon.ProvisioningException: Failed to generate host.xml on {
> [Step 3/4] "operation" => "composite",
> [Step 3/4] "address" => [],
> [Step 3/4] "rollback-on-runtime-failure" => true,
> [Step 3/4] "steps" => [
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"}
> [Step 3/4] ],
> [Step 3/4] "disallowed-providers" => ["OracleUcrypto"],
> [Step 3/4] "final-providers" => "combined-providers"
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"provider-loader" => "elytron"}
> [Step 3/4] ],
> [Step 3/4] "module" => "org.wildfly.security.elytron"
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"provider-loader" => "openssl"}
> [Step 3/4] ],
> [Step 3/4] "module" => "org.wildfly.openssl"
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"aggregate-providers" => "combined-providers"}
> [Step 3/4] ],
> [Step 3/4] "providers" => [
> [Step 3/4] "elytron",
> [Step 3/4] "openssl"
> [Step 3/4] ]
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"identity-realm" => "local"}
> [Step 3/4] ],
> [Step 3/4] "identity" => "$local"
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"file-audit-log" => "local-audit"}
> [Step 3/4] ],
> [Step 3/4] "format" => "JSON",
> [Step 3/4] "path" => "audit.log",
> [Step 3/4] "relative-to" => "jboss.domain.log.dir"
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"constant-realm-mapper" => "local"}
> [Step 3/4] ],
> [Step 3/4] "realm-name" => "local"
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"provider-http-server-mechanism-factory" => "global"}
> [Step 3/4] ]
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"simple-permission-mapper" => "default-permission-mapper"}
> [Step 3/4] ],
> [Step 3/4] "mapping-mode" => "first",
> [Step 3/4] "permission-mappings" => [
> [Step 3/4] {
> [Step 3/4] "principals" => ["anonymous"],
> [Step 3/4] "permission-sets" => [{"permission-set" => "default-permissions"}]
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "match-all" => "true",
> [Step 3/4] "permission-sets" => [
> [Step 3/4] {"permission-set" => "login-permission"},
> [Step 3/4] {"permission-set" => "default-permissions"}
> [Step 3/4] ]
> [Step 3/4] }
> [Step 3/4] ]
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"simple-role-decoder" => "groups-to-roles"}
> [Step 3/4] ],
> [Step 3/4] "attribute" => "groups"
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"provider-sasl-server-factory" => "global"}
> [Step 3/4] ]
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"mechanism-provider-filtering-sasl-server-factory" => "elytron"}
> [Step 3/4] ],
> [Step 3/4] "filters" => [{"provider-name" => "WildFlyElytron"}],
> [Step 3/4] "sasl-server-factory" => "global"
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"configurable-sasl-server-factory" => "configured"}
> [Step 3/4] ],
> [Step 3/4] "properties" => {"wildfly.sasl.local-user.default-user" => "$local"},
> [Step 3/4] "sasl-server-factory" => "elytron"
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"constant-role-mapper" => "super-user-mapper"}
> [Step 3/4] ],
> [Step 3/4] "roles" => ["SuperUser"]
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"permission-set" => "login-permission"}
> [Step 3/4] ],
> [Step 3/4] "permissions" => [{"class-name" => "org.wildfly.security.auth.permission.LoginPermission"}]
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"permission-set" => "default-permissions"}
> [Step 3/4] ],
> [Step 3/4] "permissions" => []
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"properties-realm" => "ManagementRealm"}
> [Step 3/4] ],
> [Step 3/4] "users-properties" => {
> [Step 3/4] "path" => "mgmt-users.properties",
> [Step 3/4] "relative-to" => "jboss.domain.config.dir",
> [Step 3/4] "digest-realm-name" => "ManagementRealm"
> [Step 3/4] }
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "write-attribute",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"properties-realm" => "ManagementRealm"}
> [Step 3/4] ],
> [Step 3/4] "name" => "groups-properties",
> [Step 3/4] "value" => {
> [Step 3/4] "path" => "mgmt-groups.properties",
> [Step 3/4] "relative-to" => "jboss.domain.config.dir"
> [Step 3/4] }
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"security-domain" => "ManagementDomain"}
> [Step 3/4] ],
> [Step 3/4] "default-realm" => "ManagementRealm",
> [Step 3/4] "permission-mapper" => "default-permission-mapper",
> [Step 3/4] "realms" => [
> [Step 3/4] {
> [Step 3/4] "realm" => "ManagementRealm",
> [Step 3/4] "role-decoder" => "groups-to-roles"
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "realm" => "local",
> [Step 3/4] "role-mapper" => "super-user-mapper"
> [Step 3/4] }
> [Step 3/4] ]
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"sasl-authentication-factory" => "management-sasl-authentication"}
> [Step 3/4] ],
> [Step 3/4] "mechanism-configurations" => [
> [Step 3/4] {
> [Step 3/4] "mechanism-name" => "JBOSS-LOCAL-USER",
> [Step 3/4] "realm-mapper" => "local"
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "mechanism-name" => "DIGEST-MD5",
> [Step 3/4] "mechanism-realm-configurations" => [{"realm-name" => "ManagementRealm"}]
> [Step 3/4] }
> [Step 3/4] ],
> [Step 3/4] "sasl-server-factory" => "configured",
> [Step 3/4] "security-domain" => "ManagementDomain"
> [Step 3/4] },
> [Step 3/4] {
> [Step 3/4] "operation" => "add",
> [Step 3/4] "address" => [
> [Step 3/4] {"host" => "master"},
> [Step 3/4] {"subsystem" => "elytron"},
> [Step 3/4] {"http-authentication-factory" => "management-http-authentication"}
> [Step 3/4] ],
> [Step 3/4] "http-server-mechanism-factory" => "global",
> [Step 3/4] "mechanism-configurations" => [{
> [Step 3/4] "mechanism-name" => "BASIC",
> [Step 3/4] "mechanism-realm-configurations" => [{"realm-name" => "Management Realm"}]
> [Step 3/4] }],
> [Step 3/4] "security-domain" => "ManagementDomain"
> [Step 3/4] }
> [Step 3/4] ]
> [Step 3/4] }: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {
> [Step 3/4] "WFLYCTL0412: Required services that are not installed:" => ["elytron.security-properties"],
> [Step 3/4] "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.providers.elytron is missing [elytron.security-properties]"]
> [Step 3/4] }}}
> [Step 3/4] at org.wildfly.galleon.plugin.config.generator.WfConfigGenerator.doHandle(WfConfigGenerator.java:356)
> [Step 3/4] at org.wildfly.galleon.plugin.config.generator.WfConfigGenerator.endBatch(WfConfigGenerator.java:272)
> [Step 3/4] at org.wildfly.galleon.plugin.config.generator.WfConfigGenerator.executeScript(WfConfigGenerator.java:494)
> [Step 3/4] at org.wildfly.galleon.plugin.config.generator.WfConfigGenerator.forkedForEmbedded(WfConfigGenerator.java:471)
> [Step 3/4] at org.wildfly.galleon.plugin.server.ForkedEmbeddedUtil.main(ForkedEmbeddedUtil.java:208)
> [Step 3/4] [INFO] Overall Galleon provisioning took 27.115 seconds
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFCORE-4870) Improve add-user handling to allow custom dictionary/keyboard
by Bartosz Baranowski (Jira)
[ https://issues.redhat.com/browse/WFCORE-4870?page=com.atlassian.jira.plug... ]
Bartosz Baranowski updated WFCORE-4870:
---------------------------------------
Description:
As is:
- default Keyboard is properties based setup, it is locked to default EN keyboard layout, properties file, that it reads are locked in management-domain jar
- default Dictionary is properties based setup, it is locked with few example word definitions, properties file, that it reads are locked in management-domain jar
- SimplePasswordStrengthChecker - default implementation of password check algorithm. Sadly with private fields, so it is not extendable( seems like oversight )
- bin/add-user.properties - config file with properties that allow change how SimplePasswordStrengthChecker or other implementation behaves. It allows to load custom implementation of PasswordStrengthChecker
Ideally, user should be able to:
- configure layout/dictionary content
- configure implementation of keyboard/dictionary
- extend SimplePasswordStrengthChecker to change keyboard/dictionary, implement more checks.
was:As is. There is no way to provide custom dictionary/keyboard. Also, right now, property files files that feed keyboard layout and dictionary are embedded in domain-management jar.
> Improve add-user handling to allow custom dictionary/keyboard
> -------------------------------------------------------------
>
> Key: WFCORE-4870
> URL: https://issues.redhat.com/browse/WFCORE-4870
> Project: WildFly Core
> Issue Type: Enhancement
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Priority: Minor
>
> As is:
> - default Keyboard is properties based setup, it is locked to default EN keyboard layout, properties file, that it reads are locked in management-domain jar
> - default Dictionary is properties based setup, it is locked with few example word definitions, properties file, that it reads are locked in management-domain jar
> - SimplePasswordStrengthChecker - default implementation of password check algorithm. Sadly with private fields, so it is not extendable( seems like oversight )
> - bin/add-user.properties - config file with properties that allow change how SimplePasswordStrengthChecker or other implementation behaves. It allows to load custom implementation of PasswordStrengthChecker
> Ideally, user should be able to:
> - configure layout/dictionary content
> - configure implementation of keyboard/dictionary
> - extend SimplePasswordStrengthChecker to change keyboard/dictionary, implement more checks.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13259) Memory leak in Hibernate pending-puts cache when L2 cache is enabled
by Sorin Potra (Jira)
[ https://issues.redhat.com/browse/WFLY-13259?page=com.atlassian.jira.plugi... ]
Sorin Potra commented on WFLY-13259:
------------------------------------
I modified the web app to call EntityManager.close() in all servlets and the context listener (the only servlet used in the scenario tested is AddChildServlet). This has a beneficial effect on memory usage as the size of the SessionImpl instances has decreased. But the memory leak is still there. I modified the client to execute 3500 transactions before slowing down (initially it was executing 1400 transactions). I kept -Xmx to the default value of 512M. The Child pending-puts cache has a retained heap size of about 180MB after executing 3500 transactions. Please find attached the new web-app and its client (simple-hibernate-war.war.2020-03-25, simple-hibernate-war.zip.2020-03-25, simple-hibernate-war-client.zip.2020-03-25).
The scenario in our production app is a bit different as the entry point is an EJB, not a servlet as in the test app and the production app uses container managed transactions and entity managers. Bur the pending-puts leak is present in both scenarios.
> Memory leak in Hibernate pending-puts cache when L2 cache is enabled
> --------------------------------------------------------------------
>
> Key: WFLY-13259
> URL: https://issues.redhat.com/browse/WFLY-13259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 18.0.1.Final, 19.0.0.Final
> Reporter: Sorin Potra
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: PathToGCRoots_strong_refs.PNG, afterOOM.hprof.zip, beforeOOM.hprof.zip, pending-puts-leak.PNG, simple-hibernate-war-client.zip, simple-hibernate-war-client.zip.2020-03-25, simple-hibernate-war.war, simple-hibernate-war.war.2020-03-25, simple-hibernate-war.zip, simple-hibernate-war.zip.2020-03-25
>
>
> Under certain conditions, described below, WildFly / Hibernate can leak memory into the pending-puts cache eventually causing an OutOfMemoryError. Attached you can find a web application and a standalone client that can be used to reproduce the problem. The web app defines two entities: a Parent and a Child. There is a bidirectional one-to-many relationship between the Parent and the Child. JPA L2 cache is enabled (Infinispan is the cache provider).
> Repeatedly executing a transaction that creates a new Child and adds it to the list of children in the Parent will cause the memory usage to increase steadily until OOM is encountered. If the execution of these transactions is stopped before reaching OOM, the memory will be reclaimed after a few minutes of inactivity.
> Attached you can find the following:
> - simple-hibernate-war.war - the web app that can be deployed in WildFly to reproduce the issue.
> - simple-hibernate-war.zip - the source code for the above web app. The servlet that is invoked by the client to create and persist a new Child is com.microfocus.sa.web.AddChildServlet
> - simple-hibernate-war-client.zip - the standalone client that can be used to invoke the AddChildServlet. After unzipping the archive, the client can be run with the following command from the client folder:
>
> java -cp bin com.microfocus.sa.client.AddChildClient
>
> If you need to run the client multiple times, you have to restart WildFly in between the runs, to start from a fresh state (the web app uses the h2 in memory databasewhich is reset at each restart).
> - pending-puts-leak.PNG - a screeshot from Memory Analyzer showing a leaked SessionImpl instance
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13259) Memory leak in Hibernate pending-puts cache when L2 cache is enabled
by Sorin Potra (Jira)
[ https://issues.redhat.com/browse/WFLY-13259?page=com.atlassian.jira.plugi... ]
Sorin Potra updated WFLY-13259:
-------------------------------
Attachment: simple-hibernate-war.war.2020-03-25
> Memory leak in Hibernate pending-puts cache when L2 cache is enabled
> --------------------------------------------------------------------
>
> Key: WFLY-13259
> URL: https://issues.redhat.com/browse/WFLY-13259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 18.0.1.Final, 19.0.0.Final
> Reporter: Sorin Potra
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: PathToGCRoots_strong_refs.PNG, afterOOM.hprof.zip, beforeOOM.hprof.zip, pending-puts-leak.PNG, simple-hibernate-war-client.zip, simple-hibernate-war-client.zip.2020-03-25, simple-hibernate-war.war, simple-hibernate-war.war.2020-03-25, simple-hibernate-war.zip, simple-hibernate-war.zip.2020-03-25
>
>
> Under certain conditions, described below, WildFly / Hibernate can leak memory into the pending-puts cache eventually causing an OutOfMemoryError. Attached you can find a web application and a standalone client that can be used to reproduce the problem. The web app defines two entities: a Parent and a Child. There is a bidirectional one-to-many relationship between the Parent and the Child. JPA L2 cache is enabled (Infinispan is the cache provider).
> Repeatedly executing a transaction that creates a new Child and adds it to the list of children in the Parent will cause the memory usage to increase steadily until OOM is encountered. If the execution of these transactions is stopped before reaching OOM, the memory will be reclaimed after a few minutes of inactivity.
> Attached you can find the following:
> - simple-hibernate-war.war - the web app that can be deployed in WildFly to reproduce the issue.
> - simple-hibernate-war.zip - the source code for the above web app. The servlet that is invoked by the client to create and persist a new Child is com.microfocus.sa.web.AddChildServlet
> - simple-hibernate-war-client.zip - the standalone client that can be used to invoke the AddChildServlet. After unzipping the archive, the client can be run with the following command from the client folder:
>
> java -cp bin com.microfocus.sa.client.AddChildClient
>
> If you need to run the client multiple times, you have to restart WildFly in between the runs, to start from a fresh state (the web app uses the h2 in memory databasewhich is reset at each restart).
> - pending-puts-leak.PNG - a screeshot from Memory Analyzer showing a leaked SessionImpl instance
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-13259) Memory leak in Hibernate pending-puts cache when L2 cache is enabled
by Sorin Potra (Jira)
[ https://issues.redhat.com/browse/WFLY-13259?page=com.atlassian.jira.plugi... ]
Sorin Potra updated WFLY-13259:
-------------------------------
Attachment: simple-hibernate-war.zip.2020-03-25
> Memory leak in Hibernate pending-puts cache when L2 cache is enabled
> --------------------------------------------------------------------
>
> Key: WFLY-13259
> URL: https://issues.redhat.com/browse/WFLY-13259
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 18.0.1.Final, 19.0.0.Final
> Reporter: Sorin Potra
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: PathToGCRoots_strong_refs.PNG, afterOOM.hprof.zip, beforeOOM.hprof.zip, pending-puts-leak.PNG, simple-hibernate-war-client.zip, simple-hibernate-war-client.zip.2020-03-25, simple-hibernate-war.war, simple-hibernate-war.war.2020-03-25, simple-hibernate-war.zip, simple-hibernate-war.zip.2020-03-25
>
>
> Under certain conditions, described below, WildFly / Hibernate can leak memory into the pending-puts cache eventually causing an OutOfMemoryError. Attached you can find a web application and a standalone client that can be used to reproduce the problem. The web app defines two entities: a Parent and a Child. There is a bidirectional one-to-many relationship between the Parent and the Child. JPA L2 cache is enabled (Infinispan is the cache provider).
> Repeatedly executing a transaction that creates a new Child and adds it to the list of children in the Parent will cause the memory usage to increase steadily until OOM is encountered. If the execution of these transactions is stopped before reaching OOM, the memory will be reclaimed after a few minutes of inactivity.
> Attached you can find the following:
> - simple-hibernate-war.war - the web app that can be deployed in WildFly to reproduce the issue.
> - simple-hibernate-war.zip - the source code for the above web app. The servlet that is invoked by the client to create and persist a new Child is com.microfocus.sa.web.AddChildServlet
> - simple-hibernate-war-client.zip - the standalone client that can be used to invoke the AddChildServlet. After unzipping the archive, the client can be run with the following command from the client folder:
>
> java -cp bin com.microfocus.sa.client.AddChildClient
>
> If you need to run the client multiple times, you have to restart WildFly in between the runs, to start from a fresh state (the web app uses the h2 in memory databasewhich is reset at each restart).
> - pending-puts-leak.PNG - a screeshot from Memory Analyzer showing a leaked SessionImpl instance
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month