May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4962) Add a SecurityMetaData for all deployments

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4962?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4962: -------------------------------- Fix Version/s: 12.0.0.CR1 (was: 12.0.0.Beta4) > Add a SecurityMetaData for all deployments > ------------------------------------------ > > Key: WFCORE-4962 > URL: https://issues.redhat.com/browse/WFCORE-4962 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 12.0.0.CR1 > > > For all deployments we should associate a new class SecurityMetaData with the deployment, initially the purpose of this will be to hold the ServiceName of any Elytron SecurityDomain if one is being used. > At a later point additional security policy information can be added as we move away from the ApplicationSecurityDomain resources. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13514) Huge memory leak in WildFly

by Konrad Bak (Jira)

[ https://issues.redhat.com/browse/WFLY-13514?page=com.atlassian.jira.plugi... ] Konrad Bak commented on WFLY-13514: ----------------------------------- Thank you for your quick reaction! {quote} Konrad Bak funy thing is, I cannot reproduce this manually. If I just try and GET that page from browser (repeatedly OFC), it never goes OOM. {quote} Yeah, I was surprised as well. Because of that, the bug went unnoticed through our staging environment, and we experienced it only in production. I am not sure if you noticed that the binding is crucial here. If we remove {{binding="#\{pageVariable\}"}}, the bug disappears. > Huge memory leak in WildFly > --------------------------- > > Key: WFLY-13514 > URL: https://issues.redhat.com/browse/WFLY-13514 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 18.0.1.Final, 19.1.0.Final, 20.0.0.Beta1 > Reporter: Konrad Bak > Assignee: Matěj Novotný > Priority: Critical > > https://github.com/konbk/bug-report-wildfly-oome > The project shows a huge memory leak introduced in recent WildFly versions that can crash a real-world Java EE application in a matter of hours. > When a JSF page contains any component bound to page variable, all CDI beans (regardless of scope) used on that page stay in memory. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4987) Bump the Elytron subsystem version

by Farah Juma (Jira)

Farah Juma created WFCORE-4987: ---------------------------------- Summary: Bump the Elytron subsystem version Key: WFCORE-4987 URL: https://issues.redhat.com/browse/WFCORE-4987 Project: WildFly Core Issue Type: Task Reporter: Farah Juma Assignee: Farah Juma Fix For: 13.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1974) Correct class names in ProviderFactory

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1974: ------------------------------------- Summary: Correct class names in ProviderFactory Key: ELY-1974 URL: https://issues.redhat.com/browse/ELY-1974 Project: WildFly Elytron Issue Type: Bug Components: API / SPI Affects Versions: 1.12.0.CR4 Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.12.1.CR1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1974) Correct class names in ProviderFactory

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1974?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1974: ---------------------------------- Description: The following use an invalid package: - {code:java} "org.wildfly.security.http.bearer.WildFlyElytronHttpBearerProvider", "org.wildfly.security.http.bearer.WildFlyElytronHttpClientCertProvider", "org.wildfly.security.http.bearer.WildFlyElytronHttpDigestProvider", "org.wildfly.security.http.bearer.WildFlyElytronHttpFormProvider", "org.wildfly.security.http.bearer.WildFlyElytronHttpSpnegoProvider", {code} > Correct class names in ProviderFactory > -------------------------------------- > > Key: ELY-1974 > URL: https://issues.redhat.com/browse/ELY-1974 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Affects Versions: 1.12.0.Final > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.12.1.CR1 > > > The following use an invalid package: - > {code:java} > "org.wildfly.security.http.bearer.WildFlyElytronHttpBearerProvider", > "org.wildfly.security.http.bearer.WildFlyElytronHttpClientCertProvider", > "org.wildfly.security.http.bearer.WildFlyElytronHttpDigestProvider", > "org.wildfly.security.http.bearer.WildFlyElytronHttpFormProvider", > "org.wildfly.security.http.bearer.WildFlyElytronHttpSpnegoProvider", > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (REMJMX-172) Messages in RemotingConnector logging using wrong category

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/REMJMX-172?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on REMJMX-172: ----------------------------------------- Pull request https://github.com/jbossas/remoting-jmx/pull/46 > Messages in RemotingConnector logging using wrong category > ---------------------------------------------------------- > > Key: REMJMX-172 > URL: https://issues.redhat.com/browse/REMJMX-172 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 3.0.5.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (REMJMX-172) Messages in RemotingConnector logging using wrong category

by Darran Lofthouse (Jira)

Darran Lofthouse created REMJMX-172: --------------------------------------- Summary: Messages in RemotingConnector logging using wrong category Key: REMJMX-172 URL: https://issues.redhat.com/browse/REMJMX-172 Project: Remoting JMX Issue Type: Bug Components: Connection Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.5.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (REMJMX-171) Don't disable local authentication for empty username and password

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/REMJMX-171?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on REMJMX-171: ----------------------------------------- Pull request https://github.com/jbossas/remoting-jmx/pull/45 > Don't disable local authentication for empty username and password > ------------------------------------------------------------------ > > Key: REMJMX-171 > URL: https://issues.redhat.com/browse/REMJMX-171 > Project: Remoting JMX > Issue Type: Bug > Components: Connection > Affects Versions: 3.0.4.Final > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 3.0.5.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13514) Huge memory leak in WildFly

by Matěj Novotný (Jira)

[ https://issues.redhat.com/browse/WFLY-13514?page=com.atlassian.jira.plugi... ] Matěj Novotný commented on WFLY-13514: -------------------------------------- [~konbk] funy thing is, I cannot reproduce this manually. If I just try and GET that page from browser (repeatedly OFC), it never goes OOM. And if you monitor the memory usage, it goes up the same way on each request, but once you perform GC, it goes back down. >From Weld perspective, we store req. scoped beans in request's attributes. We do have some caches in place to make things faster, but ultimately it is the request holding them. Once our http listener gets notified about request ending, we proceed to bean destruction (calling pre-destroy callbacks), clearing caches and detaching bean storage so no further context manipulation gets propagated to request. But we don't really seem to remove beans from request at this point (we don't invoke {{HttpServletRequest.removeAttribute(key)}}) - we never did though. I guess we assume the request is deleted by Undertow once it is over which seems reasonable; but it is not what's happening with your reproducer. At least from the heap dump I was seeing that it is still kept as attribute under {{attributes io.undertow.servlet.spec.HttpServletRequestImpl @ 0xf878ef48}} which in turn was in session that was considered active. Maybe someone from Undertow team ([~flavia.rainone]?) would know more about how are requests handled in this case and whether {{HttpServletRequestImpl}} should under some circumstances survive a request ending? > Huge memory leak in WildFly > --------------------------- > > Key: WFLY-13514 > URL: https://issues.redhat.com/browse/WFLY-13514 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, JSF > Affects Versions: 18.0.1.Final, 19.1.0.Final, 20.0.0.Beta1 > Reporter: Konrad Bak > Assignee: Matěj Novotný > Priority: Critical > > https://github.com/konbk/bug-report-wildfly-oome > The project shows a huge memory leak introduced in recent WildFly versions that can crash a real-world Java EE application in a matter of hours. > When a JSF page contains any component bound to page variable, all CDI beans (regardless of scope) used on that page stay in memory. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13357) (Regression) Execution of concurrent batch jobs containg partitioned steps causes deadlock

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13357?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13357: --------------------------------- Priority: Blocker (was: Major) > (Regression) Execution of concurrent batch jobs containg partitioned steps causes deadlock > ------------------------------------------------------------------------------------------ > > Key: WFLY-13357 > URL: https://issues.redhat.com/browse/WFLY-13357 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 19.0.0.Final > Reporter: Felix König > Assignee: Cheng Fang > Priority: Blocker > Fix For: 20.0.0.Final > > > Hello, > the issue described in JBERET-180 seems to have reappeared. I am running Wildfly 16 with jberet-1.3.3. Given that there is a default batch-thread count of 10 I was able to produce a deadlock by starting 10 instances of a partitioned job simultaneously. None of the job runs fast enough to finish before all 10 jobs have been started. All 10 Batch-threads are stuck here: > {code} > "Batch Thread - 1@33537" prio=5 tid=0x109 nid=NA waiting > java.lang.Thread.State: WAITING > at jdk.internal.misc.Unsafe.park(Unknown Source:-1) > at java.util.concurrent.locks.LockSupport.park(Unknown Source:-1) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source:-1) > at java.util.concurrent.ArrayBlockingQueue.take(Unknown Source:-1) > at org.jberet.runtime.runner.StepExecutionRunner.beginPartition(StepExecutionRunner.java:350) > at org.jberet.runtime.runner.StepExecutionRunner.runBatchletOrChunk(StepExecutionRunner.java:222) > at org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:144) > at org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164) > at org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:88) > at org.jberet.runtime.runner.JobExecutionRunner.run(JobExecutionRunner.java:60) > at org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentService$WildFlyBatchEnvironment$1.run(BatchEnvironmentService.java:180) > at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:494) > at org.jberet.spi.JobExecutor$2.run(JobExecutor.java:149) > at org.jberet.spi.JobExecutor$1.run(JobExecutor.java:99) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source:-1) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source:-1) > at java.lang.Thread.run(Unknown Source:-1) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > which is this line of code: > {code:java} > completedPartitionThreads.take(); > {code} > Rarely some threads also get stuck at line 364 instead, which is > {code:java} > final Serializable data = collectorDataQueue.take(); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

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 May 2020