August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9631) "Failed to reinstate timer" warning is shown when creating large number of EJB timers

by Michal Jurc (JIRA)

[ https://issues.jboss.org/browse/WFLY-9631?page=com.atlassian.jira.plugin.... ] Michal Jurc reassigned WFLY-9631: --------------------------------- Assignee: Michal Jurc > "Failed to reinstate timer" warning is shown when creating large number of EJB timers > ------------------------------------------------------------------------------------- > > Key: WFLY-9631 > URL: https://issues.jboss.org/browse/WFLY-9631 > Project: WildFly > Issue Type: Bug > Components: EJB > Environment: EAP 7.0.8.GA > Oracle 12 c > [Configuration of datasources|https://github.com/MarianMacik/timers-testing/blob/c7dde64d27...] - XA Datasource for jBPM - our application - and a separate XA Datasource for EJB Timers in a different schema. > Reporter: Marián Macik > Assignee: Michal Jurc > > Hi, [~manovotn], > as we discussed before, I am creating a JIRA for an issue I experienced when testing EJB Timers with jBPM. > What I did was that I started a large number of processes with jBPM, let's say 10 000 and more. Each process contains a timer which jBPM will create an EJB Timer for. Each timer was configured to fire at exactly the same time, e.g. 12:00 PM. During the test I got this warning displayed about 5 times for each 10 000 timers created: > {code:java} > WARN [org.jboss.as.ejb3] (Timer-1) WFLYEJB0161: Failed to reinstate timer 'kie-server.kie-server.EJBTimerScheduler' (id=09afab21-6b0f-41b0-9338-403b4a12e507) from its persistent state: java.lang.IllegalStateException: WFLYCTL0075: Duplicate resource 09afab21-6b0f-41b0-9338-403b4a12e507 > at org.jboss.as.controller.registry.AbstractModelResource$DefaultResourceProvider.register(AbstractModelResource.java:290) > at org.jboss.as.controller.registry.AbstractModelResource.registerChild(AbstractModelResource.java:169) > at org.jboss.as.ejb3.subsystem.deployment.TimerServiceResource.timerCreated(TimerServiceResource.java:193) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.registerTimerResource(TimerServiceImpl.java:1094) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:767) > at org.jboss.as.ejb3.timerservice.TimerServiceImpl$TimerRefreshListener.timerAdded(TimerServiceImpl.java:1235) > at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence$RefreshTask.run(DatabaseTimerPersistence.java:820) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > {code} > The result of these warnings was that when I had only one EAP instance to fire these timers, it wouldn't fire exactly the timers with ids that were in those warnings, e.g. if it was id=09afab21-6b0f-41b0-9338-403b4a12e507 then this timer wouldn't fire. I had waited for minutes to be sure there is another tick of a refresh interval (configured to 1 min) but nothing happened. But when I started the second EAP instance, they were immediately picked up by that instance and fired. It seems that if there is this warning on a particular instance, the instance won't pick up the timer whatsoever. They will be picked up only by some other instances if there are any. With 2 EAP instances there were warnings too, but all timers fired since I guess affected timers were picked up each time by the other instance. > Another interesting observation is that when I configured a refresh interval to be shorter, e.g. 5 seconds, these warnings were showing up almost every 5 seconds. When I set it to 30 minutes, I didn't get warnings at all, since all timers fired earlier than a refresh occurred. > So I think it has something to do with refresh interval. > Can you please have a look at it? For further configuration details, check the Environment field. > Thank you very much! > Marian Macik -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10923) Server stop indefinitely blocked by DistributableSessionManager after invalidation during async request

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-10923?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-10923: ------------------------------------- Even if that's the case, we can still add a workaround to the wildfly-clustering-web-undertow module by closing the session when detected to be invalid. > Server stop indefinitely blocked by DistributableSessionManager after invalidation during async request > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-10923 > URL: https://issues.jboss.org/browse/WFLY-10923 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 14.0.0.Beta2 > Reporter: Aaron Ogburn > Assignee: Paul Ferraro > Attachments: servlet-async.war > > > After WFLY-10621, a DistributableSessionManager.stop hang can still occur in the following scenario. > 1. async request a starts > 2. sync request b invalidates session > 3. async request a completes > Upon completion, the async request does not unlock and throws following exception: > {code} > 16:04:58,260 ERROR [stderr] (default task-18) Exception in thread "default task-18" java.lang.RuntimeException: java.lang.IllegalStateException: WFLYCLWEBUT0001: Session 8adSKXK1li8Qo15QnaIGrd31DrB6B83jEL4blzq1 is invalid > 16:04:58,260 ERROR [stderr] (default task-18) at io.undertow.servlet.spec.ServletContextImpl.invokeRunnable(ServletContextImpl.java:944) > 16:04:58,260 ERROR [stderr] (default task-18) at io.undertow.servlet.spec.AsyncContextImpl.onAsyncComplete(AsyncContextImpl.java:594) > 16:04:58,260 ERROR [stderr] (default task-18) at io.undertow.servlet.spec.AsyncContextImpl.access$100(AsyncContextImpl.java:71) > 16:04:58,261 ERROR [stderr] (default task-18) at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:315) > 16:04:58,261 ERROR [stderr] (default task-18) at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:473) > 16:04:58,261 ERROR [stderr] (default task-18) at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:584) > 16:04:58,261 ERROR [stderr] (default task-18) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > 16:04:58,261 ERROR [stderr] (default task-18) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > 16:04:58,261 ERROR [stderr] (default task-18) at java.lang.Thread.run(Thread.java:748) > 16:04:58,261 ERROR [stderr] (default task-18) Caused by: java.lang.IllegalStateException: WFLYCLWEBUT0001: Session 8adSKXK1li8Qo15QnaIGrd31DrB6B83jEL4blzq1 is invalid > 16:04:58,261 ERROR [stderr] (default task-18) at org.wildfly.clustering.web.undertow.session.DistributableSession.validate(DistributableSession.java:57) > 16:04:58,261 ERROR [stderr] (default task-18) at org.wildfly.clustering.web.undertow.session.DistributableSession.getAttribute(DistributableSession.java:157) > 16:04:58,261 ERROR [stderr] (default task-18) at io.undertow.servlet.spec.HttpSessionImpl.getAttribute(HttpSessionImpl.java:122) > 16:04:58,261 ERROR [stderr] (default task-18) at org.jboss.weld.context.http.HttpSessionContextImpl.checkBeanIdentifierIndexConsistency(HttpSessionContextImpl.java:98) > 16:04:58,261 ERROR [stderr] (default task-18) at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:47) > 16:04:58,261 ERROR [stderr] (default task-18) at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:23) > 16:04:58,261 ERROR [stderr] (default task-18) at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:237) > 16:04:58,261 ERROR [stderr] (default task-18) at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152) > 16:04:58,261 ERROR [stderr] (default task-18) at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246) > 16:04:58,261 ERROR [stderr] (default task-18) at io.undertow.servlet.spec.AsyncContextImpl.setupRequestContext(AsyncContextImpl.java:678) > 16:04:58,261 ERROR [stderr] (default task-18) at io.undertow.servlet.spec.AsyncContextImpl.access$700(AsyncContextImpl.java:71) > 16:04:58,261 ERROR [stderr] (default task-18) at io.undertow.servlet.spec.AsyncContextImpl$7.run(AsyncContextImpl.java:599) > 16:04:58,261 ERROR [stderr] (default task-18) at io.undertow.servlet.spec.ServletContextImpl$2.call(ServletContextImpl.java:177) > 16:04:58,262 ERROR [stderr] (default task-18) at io.undertow.servlet.spec.ServletContextImpl$2.call(ServletContextImpl.java:174) > 16:04:58,262 ERROR [stderr] (default task-18) at io.undertow.servlet.spec.ServletContextImpl.invokeRunnable(ServletContextImpl.java:942) > 16:04:58,262 ERROR [stderr] (default task-18) ... 8 more > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10784) WeldStartCompletionService failed when optional components not installed

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/WFLY-10784?page=com.atlassian.jira.plugin... ] Matej Novotny edited comment on WFLY-10784 at 8/27/18 8:44 AM: --------------------------------------------------------------- Thanks [~brian.stansberry] I can see where are you headed, but there is one problem. I am probably missing how {{Service}} and {{DeploymentUnit}} with their {{Phase}} play together - inside this new deployment processor, I will need to get hold of [{{WeldBootstrap}}|https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldBootstrap.java] which is stored in [{{WeldBootstrapService}}|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/WeldBootstrapService.java#L64]. Now, with services, you could [inject other services easily|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/...], but I am not sure how to get hold of it with deployment processors in a non-deprecated way? I was trying {{DeploymentPhaseContext.getServiceRegistry().getService(WeldBootstrapService.SERVICE_NAME)}} but that gives me {{ServiceController}} and all the means to get hold of actual service instance seem to be deprecated (e.g. {{getValue()}} and {{getService()}} are deprecated). As a matter of fact, {{DeploymentPhaseContext.getServiceRegistry().getService(WeldBootstrapService.SERVICE_NAME)}} returns {{null}} so it seems that you do not even have access to the service during cleanup? was (Author: manovotn): Thanks [~brian.stansberry] I can see where are you headed, but there is one problem. I am probably missing how {{Service}} and {{DeploymentUnit}} with their {{Phase}} play together - inside this new deployment processor, I will need to get hold of [{{WeldBootstrap}}|https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldBootstrap.java] which is stored in [{{WeldBootstrapService}}|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/WeldBootstrapService.java#L64]. Now, with services, you could [inject other services easily|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/...], but I am not sure how to get hold of it with deployment processors in a non-deprecated way? I was trying {{DeploymentPhaseContext.getServiceRegistry().getService(WeldBootstrapService.SERVICE_NAME)}} but that gives me {{ServiceController}} and all the means to get hold of actual service instance seem to be deprecated (e.g. {{getValue()}} and {{getService()}} are deprecated). > WeldStartCompletionService failed when optional components not installed > ------------------------------------------------------------------------ > > Key: WFLY-10784 > URL: https://issues.jboss.org/browse/WFLY-10784 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 12.0.0.Final, 13.0.0.Final > Reporter: Alexander Kudrevatykh > Assignee: Matej Novotny > Attachments: arq-test.tar.xz > > > WebComponents are optional and fail in initialising it not causes fail of deployment, but when starting EAR application with included WAR fail in deployment since Wildfly 12 because WeldStartCompletionService depends on all components regardless of their type -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10931) Make Galleon feature group names match their file names

by Alexey Loubyansky (JIRA)

Alexey Loubyansky created WFLY-10931: ---------------------------------------- Summary: Make Galleon feature group names match their file names Key: WFLY-10931 URL: https://issues.jboss.org/browse/WFLY-10931 Project: WildFly Issue Type: Bug Components: Build System Reporter: Alexey Loubyansky Assignee: Alexey Loubyansky Priority: Minor This is currently not affecting the build but the next Galleon version is going to be more strict in this regard. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10784) WeldStartCompletionService failed when optional components not installed

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/WFLY-10784?page=com.atlassian.jira.plugin... ] Matej Novotny commented on WFLY-10784: -------------------------------------- Thanks [~brian.stansberry] I can see where are you headed, but there is one problem. I am probably missing how {{Service}} and {{DeploymentUnit}} with their {{Phase}} play together - inside this new deployment processor, I will need to get hold of [{{WeldBootstrap}}|https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldBootstrap.java] which is stored in [{{WeldBootstrapService}}|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/main/java/org/jboss/as/weld/WeldBootstrapService.java#L64]. Now, with services, you could [inject other services easily|https://github.com/wildfly/wildfly/blob/master/weld/subsystem/src/...], but I am not sure how to get hold of it with deployment processors in a non-deprecated way? I was trying {{DeploymentPhaseContext.getServiceRegistry().getService(WeldBootstrapService.SERVICE_NAME)}} but that gives me {{ServiceController}} and all the means to get hold of actual service instance seem to be deprecated (e.g. {{getValue()}} and {{getService()}} are deprecated). > WeldStartCompletionService failed when optional components not installed > ------------------------------------------------------------------------ > > Key: WFLY-10784 > URL: https://issues.jboss.org/browse/WFLY-10784 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 12.0.0.Final, 13.0.0.Final > Reporter: Alexander Kudrevatykh > Assignee: Matej Novotny > Attachments: arq-test.tar.xz > > > WebComponents are optional and fail in initialising it not causes fail of deployment, but when starting EAR application with included WAR fail in deployment since Wildfly 12 because WeldStartCompletionService depends on all components regardless of their type -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10930) Eliminate Wildfly Galleon plugin unnecessary configuration from servlet distribution

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-10930?page=com.atlassian.jira.plugin... ] Yeray Borges updated WFLY-10930: -------------------------------- Description: The Servlet Galleon Pack plugin configuration has meaningless configuration left over after migrating to galleon 2.0.0.Final. This configuration does not affect the server builds, however, should be removed. (was: The Servlet Galleon Pack plugin configuration has meaningless configuration left over after migrating to galleon 2.0.0.GA. This configuration does not affect the server builds, however, should be removed. ) > Eliminate Wildfly Galleon plugin unnecessary configuration from servlet distribution > ------------------------------------------------------------------------------------- > > Key: WFLY-10930 > URL: https://issues.jboss.org/browse/WFLY-10930 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Yeray Borges > Assignee: Yeray Borges > > The Servlet Galleon Pack plugin configuration has meaningless configuration left over after migrating to galleon 2.0.0.Final. This configuration does not affect the server builds, however, should be removed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2916) UX design for the contextual menus

by Liz Clayton (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2916?page=com.atlassian.jira.plugi... ] Liz Clayton commented on DROOLS-2916: ------------------------------------- [~danielezonca] [~gabriolo] Actually, it checking the last wireframes, it seems that we did offer "empty" Given/Expect columns to start: https://redhat.invisionapp.com/share/BVKORFBUJ24#/screens/302476083 > UX design for the contextual menus > ---------------------------------- > > Key: DROOLS-2916 > URL: https://issues.jboss.org/browse/DROOLS-2916 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing, Test Scenarios Editor > Reporter: Liz Clayton > Assignee: Liz Clayton > Labels: UX, UXTeam > Attachments: Screen Shot 2018-08-23 at 12.34.13 PM.png > > > Provide the labels for the different contextual menus retrieved on right clicking the grid: > 1) click on a "header" cell > 2) click on the first cell of a row > 3) click on any other cell of a row -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10930) Eliminate Wildfly Galleon plugin unnecessary configuration from servlet distribution

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-10930?page=com.atlassian.jira.plugin... ] Yeray Borges updated WFLY-10930: -------------------------------- Component/s: Build System > Eliminate Wildfly Galleon plugin unnecessary configuration from servlet distribution > ------------------------------------------------------------------------------------- > > Key: WFLY-10930 > URL: https://issues.jboss.org/browse/WFLY-10930 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Yeray Borges > Assignee: Yeray Borges > > The Servlet Galleon Pack plugin configuration has meaningless configuration left over after migrating to galleon 2.0.0.GA. This configuration does not affect the server builds, however, should be removed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10930) Eliminate Wildfly Galleon plugin unnecessary configuration from servlet distribution

by Yeray Borges (JIRA)

Yeray Borges created WFLY-10930: ----------------------------------- Summary: Eliminate Wildfly Galleon plugin unnecessary configuration from servlet distribution Key: WFLY-10930 URL: https://issues.jboss.org/browse/WFLY-10930 Project: WildFly Issue Type: Task Reporter: Yeray Borges Assignee: Yeray Borges The Servlet Galleon Pack plugin configuration has meaningless configuration left over after migrating to galleon 2.0.0.GA. This configuration does not affect the server builds, however, should be removed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-390) Update python-ui-test-pr job to run tests in parallel

by Filip Brychta (JIRA)

Filip Brychta created SWSQE-390: ----------------------------------- Summary: Update python-ui-test-pr job to run tests in parallel Key: SWSQE-390 URL: https://issues.jboss.org/browse/SWSQE-390 Project: Kiali QE Issue Type: Bug Reporter: Filip Brychta Assignee: Michael Foley http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/view/kiali/job/pytho... job runs UI test sequentially. We need to update it to run it in parallel as well like http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/python-ui-tests-... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 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 August 2018