June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13542) Container does not enforce bean-managed concurrency for timeout methods

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13542?page=com.atlassian.jira.plugi... ] Cheng Fang commented on WFLY-13542: ----------------------------------- I don't think this is a bug. See related issue AS7-3119 for detailed discussion. When multiple executions of the same timer overlaps while the first exection is still running, WildFly drops other overlapping executions of the same timer, to prevent over-flooding the bean instance and also to avoid confusing users. After all, the purpose of a specific timer is to do something at a certain time, which is already fulfilled by running the first execution. > Container does not enforce bean-managed concurrency for timeout methods > ----------------------------------------------------------------------- > > Key: WFLY-13542 > URL: https://issues.redhat.com/browse/WFLY-13542 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.1.0.Final > Reporter: Fábio Silva > Assignee: Cheng Fang > Priority: Major > > Bean-managed concurrency for @Singleton EJBs is not enforced for timeout methods annotated with @Schedule. When a timeout is fired while the previous one is still running, the timeout method is not called. Instead, WildFly logs a warning like the following: > {code:java} > 20:58:54,000 WARN [org.jboss.as.ejb3.timer] (EJB default - 2) WFLYEJB0043: A previous execution of timer [id=aa716284-ef7b-4bb3-a356-a8ca187255c4 timedObjectId=myweb.myweb.MySingleton auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@303bd2d5 previousRun=Sun May 31 20:57:10 BRT 2020 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sun May 31 20:58:54 BRT 2020 timerState=IN_TIMEOUT info=null] ScheduleExpression [second=0/1;minute=*;hour=*;dayOfMonth=*;month=*;dayOfWeek=*;year=*;timezoneID=null;start=null;end=null] is still in progress, skipping this overlapping scheduled execution at: Sun May 31 20:58:54 BRT 2020. > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13540) Ensure DefaultJMSConnection factory is first in the list to avoid null jndi bindings

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13540?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13540: ----------------------------------------- [~luck3y] Is the plan for resolving this to resolve it with a fix version of whatever wildfly s2i release will incorporate the wildfly-cekit-modules change? > Ensure DefaultJMSConnection factory is first in the list to avoid null jndi bindings > ------------------------------------------------------------------------------------ > > Key: WFLY-13540 > URL: https://issues.redhat.com/browse/WFLY-13540 > Project: WildFly > Issue Type: Bug > Reporter: Ken Wills > Assignee: Ken Wills > Priority: Critical > > See: WFLY-13424 for underlying cause. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4972) LayersTest doesn't follow module aliases

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4972?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-4972: ------------------------------------- Summary: LayersTest doesn't follow module aliases (was: LatersTest doesn't follow module aliases) > LayersTest doesn't follow module aliases > ---------------------------------------- > > Key: WFCORE-4972 > URL: https://issues.redhat.com/browse/WFCORE-4972 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Jean Francois Denise > Assignee: Jean Francois Denise > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4926) Upgrade WildFly Elytron from 1.11.3.Final to 1.11.4.Final

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4926?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-4926: ------------------------------------- Security: (was: Red Hat Internal) > Upgrade WildFly Elytron from 1.11.3.Final to 1.11.4.Final > --------------------------------------------------------- > > Key: WFCORE-4926 > URL: https://issues.redhat.com/browse/WFCORE-4926 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Ilia Vassilev > Assignee: Darran Lofthouse > Priority: Major > Labels: downstream_dependency > Fix For: 12.0.0.Beta3 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4928) Upgrade WildFly Elytron Web from 1.7.0.Final to 1.7.1.Final

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4928?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-4928: ------------------------------------- Security: (was: Red Hat Internal) > Upgrade WildFly Elytron Web from 1.7.0.Final to 1.7.1.Final > ----------------------------------------------------------- > > Key: WFCORE-4928 > URL: https://issues.redhat.com/browse/WFCORE-4928 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Ilia Vassilev > Assignee: Darran Lofthouse > Priority: Major > Labels: downstream_dependency > Fix For: 12.0.0.Beta2 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4959) Feature for checking module installation in JBoss

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4959?page=com.atlassian.jira.plug... ] Brian Stansberry reassigned WFCORE-4959: ---------------------------------------- Assignee: (was: Brian Stansberry) > Feature for checking module installation in JBoss > ------------------------------------------------- > > Key: WFCORE-4959 > URL: https://issues.redhat.com/browse/WFCORE-4959 > Project: WildFly Core > Issue Type: Feature Request > Components: Management > Reporter: Joao Paulo Goncalves > Priority: Major > Labels: domain-mode > > Using CLI tool or Administrative Console is not possible at this moment to check if a custom added module was added correctly, especially in domain mode. The only alternative available is to add host per host. This approach takes time, and for unused users there isn't some visual (GUI) to help them. > JBoss CLI approach: > module --add --source=jar1,jar2 --target=/path-of-module --host=your-host OR module --add --source=jar1,jar2 --target=/path-of-module --host=all (deploy the module in all hosts that belongs to the domain) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4959) Feature for checking module installation in JBoss

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4959?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-4959: ------------------------------------- Component/s: Management > Feature for checking module installation in JBoss > ------------------------------------------------- > > Key: WFCORE-4959 > URL: https://issues.redhat.com/browse/WFCORE-4959 > Project: WildFly Core > Issue Type: Feature Request > Components: Management > Reporter: Joao Paulo Goncalves > Assignee: Brian Stansberry > Priority: Major > Labels: domain-mode > > Using CLI tool or Administrative Console is not possible at this moment to check if a custom added module was added correctly, especially in domain mode. The only alternative available is to add host per host. This approach takes time, and for unused users there isn't some visual (GUI) to help them. > JBoss CLI approach: > module --add --source=jar1,jar2 --target=/path-of-module --host=your-host OR module --add --source=jar1,jar2 --target=/path-of-module --host=all (deploy the module in all hosts that belongs to the domain) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4959) Feature for checking module installation in JBoss

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-4959?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-4959: ------------------------------------- Labels: domain-mode (was: ) > Feature for checking module installation in JBoss > ------------------------------------------------- > > Key: WFCORE-4959 > URL: https://issues.redhat.com/browse/WFCORE-4959 > Project: WildFly Core > Issue Type: Feature Request > Reporter: Joao Paulo Goncalves > Assignee: Brian Stansberry > Priority: Major > Labels: domain-mode > > Using CLI tool or Administrative Console is not possible at this moment to check if a custom added module was added correctly, especially in domain mode. The only alternative available is to add host per host. This approach takes time, and for unused users there isn't some visual (GUI) to help them. > JBoss CLI approach: > module --add --source=jar1,jar2 --target=/path-of-module --host=your-host OR module --add --source=jar1,jar2 --target=/path-of-module --host=all (deploy the module in all hosts that belongs to the domain) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13051) provide setRemoveOnCancelPolicy on ManagedScheduledExecutorService

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-13051?page=com.atlassian.jira.plugi... ] Eduardo Martins commented on WFLY-13051: ---------------------------------------- [~nimo22] That method and feature is specific to the ScheduledThreadPoolExecutor, not the ScheduledExecutorService interface it implements. > provide setRemoveOnCancelPolicy on ManagedScheduledExecutorService > ------------------------------------------------------------------ > > Key: WFLY-13051 > URL: https://issues.redhat.com/browse/WFLY-13051 > Project: WildFly > Issue Type: Enhancement > Components: Concurrency Utilities > Affects Versions: 19.0.0.Beta1 > Reporter: nimo stephan > Assignee: Eduardo Martins > Priority: Major > > Using > {code:java} > @Resource > private ManagedScheduledExecutorService executor; > {code} > provides no possiblity to setRemoveOnCancelPolicy to true. > A casting within a method: > {code:java} > ((ScheduledThreadPoolExecutor) executor).setRemoveOnCancelPolicy(true); > {code} > throws the error: > {code:java} > Caused by: javax.ejb.EJBException: java.lang.ClassCastException: class org.glassfish.enterprise.concurrent.ManagedScheduledExecutorServiceAdapter cannot be cast to class java.util.concurrent.ScheduledThreadPoolExecutor (org.glassfish.enterprise.concurrent.ManagedScheduledExecutorServiceAdapter is in unnamed module of loader 'org.glassfish.javax.enterprise.concurrent' @a93b7af; java.util.concurrent.ScheduledThreadPoolExecutor is in module java.base of loader 'bootstrap') > at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:246) > at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:388) > at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:68) > {code} > Please provide option to cast or if not possible to add the property > {code:java} > setRemoveOnCancelPolicy() > {code} > within the object ManagedScheduledExecutorService. Because without it, we cannot remove a task from the queue with "future.cancel(false)". -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13051) provide setRemoveOnCancelPolicy on ManagedScheduledExecutorService

by nimo stephan (Jira)

[ https://issues.redhat.com/browse/WFLY-13051?page=com.atlassian.jira.plugi... ] nimo stephan edited comment on WFLY-13051 at 6/1/20 2:52 PM: ------------------------------------------------------------- I thought that the _ManagedScheduledExecutorServiceAdapter_ can be casted to {code:java} ((ScheduledThreadPoolExecutor) executor).setRemoveOnCancelPolicy(true); {code} because of {code:java} public interface ManagedScheduledExecutorService extends ManagedExecutorService, ScheduledExecutorService {code} {code:java} public class ScheduledThreadPoolExecutor extends ThreadPoolExecutor implements ScheduledExecutorService { {code} I see no reason why the user is not allowed to use _setRemoveOnCancelPolicy()_ on jee containers. Is there a way to make it possible to use "setRemoveOnCancelPolicy(true)" on the injected _ManagedScheduledExecutorService_ instance? was (Author: nimo22): I thought that the _ManagedScheduledExecutorServiceAdapter_ can be casted to {code:java} ((ScheduledThreadPoolExecutor) executor).setRemoveOnCancelPolicy(true); {code} because of {code:java} public interface ManagedScheduledExecutorService extends ManagedExecutorService, ScheduledExecutorService {code} I see no reason why the user is not allowed to use _setRemoveOnCancelPolicy()_ on jee containers. Is there a way to make it possible to use "setRemoveOnCancelPolicy(true)" on the injected _ManagedScheduledExecutorService_ instance? > provide setRemoveOnCancelPolicy on ManagedScheduledExecutorService > ------------------------------------------------------------------ > > Key: WFLY-13051 > URL: https://issues.redhat.com/browse/WFLY-13051 > Project: WildFly > Issue Type: Enhancement > Components: Concurrency Utilities > Affects Versions: 19.0.0.Beta1 > Reporter: nimo stephan > Assignee: Eduardo Martins > Priority: Major > > Using > {code:java} > @Resource > private ManagedScheduledExecutorService executor; > {code} > provides no possiblity to setRemoveOnCancelPolicy to true. > A casting within a method: > {code:java} > ((ScheduledThreadPoolExecutor) executor).setRemoveOnCancelPolicy(true); > {code} > throws the error: > {code:java} > Caused by: javax.ejb.EJBException: java.lang.ClassCastException: class org.glassfish.enterprise.concurrent.ManagedScheduledExecutorServiceAdapter cannot be cast to class java.util.concurrent.ScheduledThreadPoolExecutor (org.glassfish.enterprise.concurrent.ManagedScheduledExecutorServiceAdapter is in unnamed module of loader 'org.glassfish.javax.enterprise.concurrent' @a93b7af; java.util.concurrent.ScheduledThreadPoolExecutor is in module java.base of loader 'bootstrap') > at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:246) > at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:388) > at org.jboss.as.ejb3@17.0.1.Final//org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:68) > {code} > Please provide option to cast or if not possible to add the property > {code:java} > setRemoveOnCancelPolicy() > {code} > within the object ManagedScheduledExecutorService. Because without it, we cannot remove a task from the queue with "future.cancel(false)". -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2020