[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Kevin Chen (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Kevin Chen commented on WFLY-6561:
----------------------------------
We're not manually creating timers. We're using the JavaEE API with TimerService and @Timeout annotations. I can do the last 2 lines during our EJB startup and timed method execution.
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFCORE-1517) can't start server with configuration file from EAP 6.4.7 (and above)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1517?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1517:
-------------------------------------
Labels: 2.2 (was: )
> can't start server with configuration file from EAP 6.4.7 (and above)
> ---------------------------------------------------------------------
>
> Key: WFCORE-1517
> URL: https://issues.jboss.org/browse/WFCORE-1517
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Priority: Blocker
> Labels: 2.2
> Fix For: 3.0.0.Alpha1
>
>
> When trying to run WildFly 10 with a configuration file from EAP 6.4.7 (i.e. management version 1.8), presumably for migration, the server fails to boot with an error message like this:
> {code}
> 14:44:44,305 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1]
> Message: Unexpected element '{urn:jboss:domain:1.8}server'
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> ... 3 more
> 14:44:44,306 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> This is really because the {{org.jboss.as.controller.parsing.Namespace}} enum doesn't have a constant for management version 1.8. After fixing that, everything seems to work fine (I guess that the rest of the server is fully aware of mgmt version 1.8), so this was hopefully just this single omission.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFCORE-1517) can't start server with configuration file from EAP 6.4.7 (and above)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1517?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1517:
----------------------------------------
Fix Version/s: 3.0.0.Alpha1
Assignee: Ladislav Thon (was: Brian Stansberry)
Resolution: Done
> can't start server with configuration file from EAP 6.4.7 (and above)
> ---------------------------------------------------------------------
>
> Key: WFCORE-1517
> URL: https://issues.jboss.org/browse/WFCORE-1517
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Ladislav Thon
> Priority: Blocker
> Labels: 2.2
> Fix For: 3.0.0.Alpha1
>
>
> When trying to run WildFly 10 with a configuration file from EAP 6.4.7 (i.e. management version 1.8), presumably for migration, the server fails to boot with an error message like this:
> {code}
> 14:44:44,305 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:131) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at org.jboss.as.server.ServerService.boot(ServerService.java:356) [wildfly-server-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:299) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,1]
> Message: Unexpected element '{urn:jboss:domain:1.8}server'
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:108) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.2.0.Final-redhat-1.jar:1.2.0.Final-redhat-1]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123) [wildfly-controller-2.1.2.Final-redhat-1.jar:2.1.2.Final-redhat-1]
> ... 3 more
> 14:44:44,306 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
> This is really because the {{org.jboss.as.controller.parsing.Namespace}} enum doesn't have a constant for management version 1.8. After fixing that, everything seems to work fine (I guess that the rest of the server is fully aware of mgmt version 1.8), so this was hopefully just this single omission.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFLY-6561) EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
by Kevin Chen (JIRA)
[ https://issues.jboss.org/browse/WFLY-6561?page=com.atlassian.jira.plugin.... ]
Kevin Chen commented on WFLY-6561:
----------------------------------
Will add when to a timer method when the class blows up. The one that blew up in particular was considered obsolete and we could delete it but there are other timed classes that are still relevant so would have to add the above lines to all of them.
> EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-6561
> URL: https://issues.jboss.org/browse/WFLY-6561
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
> Assignee: Stuart Douglas
>
> On Wildfly10, we are experiencing intermittent problems where on server startup, an @Timeout annotated method can be executed hundreds of times in a second (log below). Going through the references to the @Timeout methods and the @Scheduled methods, all scheduled methods are set to be non-persistent (ex: timerConfig.setPersistent(false), persistent=false) so we don't know how this could occur. It is not consistent and our only solution has been to kill the Wildfly10 server process and restart.
> 13:47:27,824 WARN [org.jboss.as.ejb3] (EJB default - 6) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 96) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 97) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
> 13:47:27,825 WARN [org.jboss.as.ejb3] (EJB default - 37) [ ] WFLYEJB0043: A previous execution of timer [id=d31eb95a-3f8b-4b7d-882e-f1ff53bc7de8 timedObjectId=synergy.synergy-app-head.QuartzWatcherService auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@dec94c6 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Wed Apr 06 12:10:00 PDT 2016 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Wed Apr 06 13:47:27 PDT 2016.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFLY-6554) Cache configuration are not eagerly defined in Cache Container
by Mathieu Lachance (JIRA)
[ https://issues.jboss.org/browse/WFLY-6554?page=com.atlassian.jira.plugin.... ]
Mathieu Lachance commented on WFLY-6554:
----------------------------------------
I'd like very much to get rid of Spring, though this is not something possible.
Is there a way to changes to change the requisites dependencies to make is start? I guess this is related to the "module" attribute within:
{code}
<cache-container name="hibernate" default-cache="local-query" module="org.hibernate" statistics-enabled="true">
{code}
> Cache configuration are not eagerly defined in Cache Container
> --------------------------------------------------------------
>
> Key: WFLY-6554
> URL: https://issues.jboss.org/browse/WFLY-6554
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final, 10.1.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
>
> In WF8 we used the cache configuration start="EAGER" to force the initialization of the cache configuration.
> In my scenario, we especially used that trick to define all cache configuration (i.e. entity / timestamps / local-query) in the hibernate cache container before any of our war was deployed. Doing so, when wiring the EntityManager programatically (in our application), we were able to depend on the JNDIRegionFactory without getting any NullPointerException/etc.
> This trick has only one bad side effect, which was the creation of unecessary caches.
> Now in WF10, the eager feature is gone and it seems that even if the cache container is available at startup (as discussed in: https://developer.jboss.org/thread/259151) the defined caches are not.
> I do not know if this is a bug or this is by design but this seems wrong to me.
> If we define caches within standalone.xml, I would definitly like to have them defined at the container level. I think it's fair to assume that when pulling the CacheManager all defined caches should have been there.
> I would suggest that when reading all the infinispan subsystem, each cache contained in each cache container be eagerly defined to avoid any issue (and I really meant "defined" and not "started").
> Doing so this would resolve our EntityManager second level cache bootstraping without relying on our application to define the missing cache configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years
[JBoss JIRA] (WFCORE-1516) CLI, some completion issues
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1516?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-1516:
-----------------------------------------
Description:
4 issues with command arguments completion:
1) " " and "=false" shouldn't be proposed for argument without values (that is a regression introduced by the support of implicit true value).
2) arguments without values used to stop completion to operate. For example ls --resolve-expressions should complete to the argument separator " " if no more arguments can be added.
3) "=" character is not appended to argument that has a value (that is a regression introduced by the support of implicit true value).
4) Exception in read-attribute completing the node
read-attribute --node
org.jboss.as.cli.CommandFormatException: Couldn't locate ' --node=' in the line: 'read-attribute --node'
at org.jboss.as.cli.handlers.ReadAttributeHandler.getAddress(ReadAttributeHandler.java:325)
at org.jboss.as.cli.handlers.ReadAttributeHandler$2.canAppearNext(ReadAttributeHandler.java:114)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:257)
at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:73)
at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:126)
at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63)
at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:141)
at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:150)
at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:420)
at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165)
at org.jboss.aesh.console.Console.processInternalOperation(Console.java:735)
at org.jboss.aesh.console.Console.execute(Console.java:718)
at org.jboss.aesh.console.Console.access$900(Console.java:73)
at org.jboss.aesh.console.Console$6.run(Console.java:627)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
was:
3 issues with command arguments completion:
1) " " and "=false" shouldn't be proposed for argument without values (that is a regression introduced by the support of implicit true value).
2) arguments without values used to stop completion to operate. For example ls --resolve-expressions should complete to the argument separator " " if no more arguments can be added.
3) "=" character is not appended to argument that has a value (that is a regression introduced by the support of implicit true value).
> CLI, some completion issues
> ---------------------------
>
> Key: WFCORE-1516
> URL: https://issues.jboss.org/browse/WFCORE-1516
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> 4 issues with command arguments completion:
> 1) " " and "=false" shouldn't be proposed for argument without values (that is a regression introduced by the support of implicit true value).
> 2) arguments without values used to stop completion to operate. For example ls --resolve-expressions should complete to the argument separator " " if no more arguments can be added.
> 3) "=" character is not appended to argument that has a value (that is a regression introduced by the support of implicit true value).
> 4) Exception in read-attribute completing the node
> read-attribute --node
> org.jboss.as.cli.CommandFormatException: Couldn't locate ' --node=' in the line: 'read-attribute --node'
> at org.jboss.as.cli.handlers.ReadAttributeHandler.getAddress(ReadAttributeHandler.java:325)
> at org.jboss.as.cli.handlers.ReadAttributeHandler$2.canAppearNext(ReadAttributeHandler.java:114)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:257)
> at org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:73)
> at org.jboss.as.cli.CommandCompleter.doComplete(CommandCompleter.java:126)
> at org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:63)
> at org.jboss.as.cli.impl.Console$Factory$1$1.complete(Console.java:141)
> at org.jboss.aesh.console.AeshCompletionHandler.complete(AeshCompletionHandler.java:150)
> at org.jboss.aesh.console.AeshInputProcessor.complete(AeshInputProcessor.java:420)
> at org.jboss.aesh.console.AeshInputProcessor.parseOperation(AeshInputProcessor.java:165)
> at org.jboss.aesh.console.Console.processInternalOperation(Console.java:735)
> at org.jboss.aesh.console.Console.execute(Console.java:718)
> at org.jboss.aesh.console.Console.access$900(Console.java:73)
> at org.jboss.aesh.console.Console$6.run(Console.java:627)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years