May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13177) ManagedExecutorService: Wrong activeRequestCount at RequestController on RejectedExecutionException

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13177?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13177: --------------------------------- Fix Version/s: 20.0.0.Final (was: 20.0.0.Beta1) > ManagedExecutorService: Wrong activeRequestCount at RequestController on RejectedExecutionException > --------------------------------------------------------------------------------------------------- > > Key: WFLY-13177 > URL: https://issues.redhat.com/browse/WFLY-13177 > Project: WildFly > Issue Type: Bug > Components: Concurrency Utilities > Affects Versions: 13.0.0.Final, 16.0.0.Final > Reporter: Guido Jäkel > Assignee: Eduardo Martins > Priority: Critical > Fix For: 20.0.0.Final > > > On WF-13 and WF-16 we observe a serious bug of the RequestCount of the RequestController while using ManagedExecutorService.submit() or ...execute() in the edge case of a full queue. In this case, the caller gets a RejectedExecutionException, but in the RequestController, the number of active requests is erroneously incremented. > This will lead to a false and monotonously increasing number of active requests. And in case of a limitation configured by the maxRequestCount feature, which is best practice for production environments, over the time this will lead to deadlock of the RequestController and herewith the complete activity of the Wildfly at all. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13150) Create a Galleon layer for distributable web

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13150?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13150: --------------------------------- Fix Version/s: 20.0.0.Final (was: 20.0.0.Beta1) > Create a Galleon layer for distributable web > -------------------------------------------- > > Key: WFLY-13150 > URL: https://issues.redhat.com/browse/WFLY-13150 > Project: WildFly > Issue Type: Feature Request > Components: Clustering, Web (Undertow) > Reporter: Brian Stansberry > Assignee: Paul Ferraro > Priority: Major > Fix For: 20.0.0.Final > > > We have a web-clustering layer that provides the distributable-web subsystem and the related infinispan web session caching resources, configured for multi-server distributed sessions. > We need a variant of this with infinispan configured for local caching. > The WFLY-13099 standalone-microprofile.xml config should have this kind of setup; otherwise session sharing does not work . (A failure in org.jboss.as.test.clustering.cluster.web.shared.SharedSessionTestCase if the server uses a config without it shows this.) For WFLY-13099 I can work around this by adding the needed config stuff without a layer, but as everything else needed for those configs are from layers, it's better to use a layer in WF 20. > Besides it's a good layer to have anyway. :) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13128) Add a Galleon layer for batch-jberet

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13128?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13128: --------------------------------- Fix Version/s: 20.0.0.Final (was: 20.0.0.Beta1) > Add a Galleon layer for batch-jberet > ------------------------------------ > > Key: WFLY-13128 > URL: https://issues.redhat.com/browse/WFLY-13128 > Project: WildFly > Issue Type: Feature Request > Components: Batch > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Fix For: 20.0.0.Final > > > I saw a community request for a Galleon layer for batch-jberet so let's make it first in the set we add to complete coverage of the various subsystems. > Besides the usual layer smoke tests, we can provision a cloud-server+batch-jberet server in testsuite/integration/basic and run most of the batch tests there against it. There are 4 that won't run because they use EJB, Agroal or the org.jboss.remoting3 module, none of which would be provisioned. -- 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: --------------------------------- Fix Version/s: 20.0.0.Final (was: 20.0.0.Beta1) > (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: Major > 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

[JBoss JIRA] (WFLY-13356) Add a Galleon layer for Webservices

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13356?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13356: --------------------------------- Fix Version/s: 20.0.0.Final (was: 20.0.0.Beta1) > Add a Galleon layer for Webservices > ----------------------------------- > > Key: WFLY-13356 > URL: https://issues.redhat.com/browse/WFLY-13356 > Project: WildFly > Issue Type: Feature Request > Components: Build System, Web Services > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Fix For: 20.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13353) Add a Galleon layer for the POJO subsystem

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13353?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13353: --------------------------------- Fix Version/s: 20.0.0.Final (was: 20.0.0.Beta1) > Add a Galleon layer for the POJO subsystem > ------------------------------------------ > > Key: WFLY-13353 > URL: https://issues.redhat.com/browse/WFLY-13353 > Project: WildFly > Issue Type: Feature Request > Components: Build System, POJO > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Optional > Fix For: 20.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13352) Add a Galleon layer for the sar subsystem

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13352?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13352: --------------------------------- Fix Version/s: 20.0.0.Final (was: 20.0.0.Beta1) > Add a Galleon layer for the sar subsystem > ----------------------------------------- > > Key: WFLY-13352 > URL: https://issues.redhat.com/browse/WFLY-13352 > Project: WildFly > Issue Type: Feature Request > Components: Build System, JMX > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 20.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13350) Add a Galleon layer for JSF

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13350?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13350: --------------------------------- Fix Version/s: 20.0.0.Final (was: 20.0.0.Beta1) > Add a Galleon layer for JSF > --------------------------- > > Key: WFLY-13350 > URL: https://issues.redhat.com/browse/WFLY-13350 > Project: WildFly > Issue Type: Feature Request > Components: Build System, JSF > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Fix For: 20.0.0.Final > > > Create a Galleon layer to provision the JSF subsystem. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13351) Add a Galleon layer for the Mail subsystem

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13351?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13351: --------------------------------- Fix Version/s: 20.0.0.Final (was: 20.0.0.Beta1) > Add a Galleon layer for the Mail subsystem > ------------------------------------------ > > Key: WFLY-13351 > URL: https://issues.redhat.com/browse/WFLY-13351 > Project: WildFly > Issue Type: Feature Request > Components: Build System, Mail > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Major > Fix For: 20.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13319) Wildfly 19 MP-JWT & EJB Integration

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13319?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-13319: --------------------------------- Fix Version/s: 20.0.0.Final (was: 20.0.0.Beta1) > Wildfly 19 MP-JWT & EJB Integration > ----------------------------------- > > Key: WFLY-13319 > URL: https://issues.redhat.com/browse/WFLY-13319 > Project: WildFly > Issue Type: Enhancement > Components: EJB, MP JWT, Test Suite > Affects Versions: 19.0.0.Final > Reporter: Radu Cimpean > Assignee: Darran Lofthouse > Priority: Major > Fix For: 20.0.0.Final > > Attachments: server-cli.txt, web.xml > > > ===Previous configuration & situation=== > As written https://groups.google.com/forum/#!topic/wildfly/L1BxATschCU, > We were running wildfly 18 and used jwt for securing the application. We did this via a series of cli commands (see server-cli.txt) to configure the server, as well as referencing the created domains in the web.xml. > Under jboss-web.xml we are referencing the "ejb-domain" created in the CLIs. The web.xml (see attachments) protects the resource wit the role referenced in the CLIs (role present in the token) > All our jax-rs resources are annotated with @Stateless and are calling EJBs which in turn are @Statless and declare allowed roles. > ===Current situation=== > We've upgraded to wildfly 19 in hopes of using microprofile jwt. To do this, we've annotated the Application class with > @LoginConfig(authMethod = "MP-JWT", realmName = "MP-JWT-REALM"), removed the login-config from the web.xml, and removed the security-domain from jboss-web.xml (since otherwise I would receive an error: ELY01148: A SecurityDomain has already been associated with the specified ClassLoader"). > After also removing the security-constraint tag from the web.xml I was able to get to the resource and noticed that the JWTToken was properly injected (all claims and entries are there), and the SecurityContext injected in the resource also contained the jwt specific values. From what I can tell, in the context of the jax-rs classloader, I am authenticated. > I would, however, always receive a "Invocation on method... is not allowed" the second the resource would try calling a bean, even if the role matched. Upon checking the logs, and what the injected SessionContext contained, I noticed the principal was anonymous and had no roles allowed. > I therefore believe that the credentials are somehow not being properly passed. > Is there a documented way of properly integrating jax-rs&ejb with microprofile jwt? -- 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