[JBoss JIRA] (WFLY-6315) session.invalidate() throw NullPointerException on invalidated session with replication-granularity set to ATTRIBUTE
by Sammy Chu (JIRA)
[ https://issues.jboss.org/browse/WFLY-6315?page=com.atlassian.jira.plugin.... ]
Sammy Chu commented on WFLY-6315:
---------------------------------
Hi [~rhusar] & [~pferraro],
Just tested on Wildfly 10.0.0.Final and the Github master branch (Wildfly 10.1.0.Final-SNAPSHOT) with HA profile (2 nodes in the same machine), the result as below:
# session-invalidate-noreplication.war throwing IllegalStateException with message "UT000021: Session already invalidated: java.lang.IllegalStateException: UT000021: Session already invalidate"
# session-invalidate-replication-session.war, session-invalidate-replication-attribute.war throwing IllegalStateException with message "Transaction DummyTransaction{xid=DummyXid{id=8}, status=3} is not in a valid state to be invoking cache operations on.: java.lang.IllegalStateException: Transaction DummyTransaction{xid=DummyXid{id=8}, status=3} is not in a valid state to be invoking cache operations on."
I think there should still have some issue:
# The exception message in session replication cause is not meaningful.
# Actually I caught the exception in the test code, but the server log still printing such exception
For the above reason, I would like to reopen this issue.
> session.invalidate() throw NullPointerException on invalidated session with replication-granularity set to ATTRIBUTE
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6315
> URL: https://issues.jboss.org/browse/WFLY-6315
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.1.Final
> Environment: Wildfly 8.2.1-Final
> JDK 1.8.0_66-b17
> Windows & Linux
> Reporter: Sammy Chu
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Beta1
>
> Attachments: session-invalidate-noreplication.war, session-invalidate-replication-attribute.war, session-invalidate-replication-session.war
>
>
> We suspected that calling session.invalidate() on an already invalidated session with replication-granularity set to "ATTRIBUTE" will throw a NullPointerException, but from the specification it should throw an IllegalStateException instead.
> Stack trace as below:
> {noformat}
> 13:12:35,554 ERROR [io.undertow.request] (default task-32) UT005023: Exception handling request to /<our system url>: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionFactory$1.invoke(FineSessionFactory.java:103)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionFactory$1.invoke(FineSessionFactory.java:100)
> at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
> at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:87)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionFactory.remove(FineSessionFactory.java:109)
> at org.wildfly.clustering.web.infinispan.session.fine.FineSessionFactory.remove(FineSessionFactory.java:53)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:74)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$SchedulableSession.invalidate(InfinispanSessionManager.java:359)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:140)
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:199) [undertow-servlet-1.1.8.Final.jar:1.1.8.Final]
> ... // our application code, just calling "session.invalidate()"
> {noformat}
> We also enclosed the simplified samples to reproduce this issue (session-invalidate-noreplication.war, session-invalidate-replication-attribute.war, session-invalidate-replication-session.war). In general they are the same except the replication-granularity (in jboss-web.xml => replication-granularity) settings.
> # session-invalidate-noreplication.war and session-invalidate-replication-session.war works correctly as they are throwing IllegalStateException.
> # session-invalidate-replication-attribute.war is buggy because it throw NullPointerException instead.
> For more information, please refer to https://developer.jboss.org/message/947295
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-923) Execution timeout for CLI operations
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFCORE-923?page=com.atlassian.jira.plugin... ]
Filippe Spolti edited comment on WFCORE-923 at 4/27/16 12:51 AM:
-----------------------------------------------------------------
Hi, sometimes I getting this:
{code:shell}
[standalone@localhost:9999 /] /core-service=management/service=management-operations:find-non-progressing-operation
{
"outcome" => "success",
"result" => "-340841891"
}
[standalone@localhost:9999 /] /core-service=management/service=management-operations/active-operation=-340841891:read-resource
{
"outcome" => "success",
"result" => {
"access-mechanism" => "undefined",
"address" => [],
"caller-thread" => "management-handler-thread - 1",
"cancelled" => false,
"exclusive-running-time" => 205574507121L,
"execution-status" => "executing",
"operation" => "composite",
"running-time" => 205575446309L
}
}
{code}
Seems the blocking-timeout does not take effect on those kind of operations, there is a way to terminate long running management operations of any kind?
This behaviour leads the thread in the waiting status:
"main" #1 prio=5 os_prio=0 tid=0x00007f22f0009800 nid=0x78d9 in Object.wait() [0x00007f22f7e19000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
- locked <0x000000079899cba8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
- locked <0x000000079899cba8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
Thanks.
PS, it is EAP 6.4.4
was (Author: filippe.spolti):
Hi, sometimes I getting this:
{code:shell}
[standalone@localhost:9999 /] /core-service=management/service=management-operations:find-non-progressing-operation
{
"outcome" => "success",
"result" => "-340841891"
}
[standalone@localhost:9999 /] /core-service=management/service=management-operations/active-operation=-340841891:read-resource
{
"outcome" => "success",
"result" => {
"access-mechanism" => "undefined",
"address" => [],
"caller-thread" => "management-handler-thread - 1",
"cancelled" => false,
"exclusive-running-time" => 205574507121L,
"execution-status" => "executing",
"operation" => "composite",
"running-time" => 205575446309L
}
}
{code}
Seems the blocking-timeout does not take effect on those kind of operations, there is a way to terminate long running management operations of any kind?
This behaviour leads the thread in the waiting status:
"main" #1 prio=5 os_prio=0 tid=0x00007f22f0009800 nid=0x78d9 in Object.wait() [0x00007f22f7e19000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
- locked <0x000000079899cba8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
- locked <0x000000079899cba8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
Thanks.
PS, it is EAP 6.4.5
> Execution timeout for CLI operations
> ------------------------------------
>
> Key: WFCORE-923
> URL: https://issues.jboss.org/browse/WFCORE-923
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Affects Versions: 2.0.0.Beta4
> Reporter: Lyle Wang
> Assignee: Alexey Loubyansky
> Labels: cli, timeout
>
> It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
> Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
> Currently there is "--timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this timeout with a CLI script file, which has "deploy" inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-923) Execution timeout for CLI operations
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFCORE-923?page=com.atlassian.jira.plugin... ]
Filippe Spolti edited comment on WFCORE-923 at 4/27/16 12:38 AM:
-----------------------------------------------------------------
Hi, sometimes I getting this:
{code:shell}
[standalone@localhost:9999 /] /core-service=management/service=management-operations:find-non-progressing-operation
{
"outcome" => "success",
"result" => "-340841891"
}
[standalone@localhost:9999 /] /core-service=management/service=management-operations/active-operation=-340841891:read-resource
{
"outcome" => "success",
"result" => {
"access-mechanism" => "undefined",
"address" => [],
"caller-thread" => "management-handler-thread - 1",
"cancelled" => false,
"exclusive-running-time" => 205574507121L,
"execution-status" => "executing",
"operation" => "composite",
"running-time" => 205575446309L
}
}
{code}
Seems the blocking-timeout does not take effect on those kind of operations, there is a way to terminate long running management operations of any kind?
This behaviour leads the thread in the waiting status:
"main" #1 prio=5 os_prio=0 tid=0x00007f22f0009800 nid=0x78d9 in Object.wait() [0x00007f22f7e19000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
- locked <0x000000079899cba8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
- locked <0x000000079899cba8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
Thanks.
PS, it is EAP 6.4.5
was (Author: filippe.spolti):
Hi, sometimes I getting this:
{code:shell}
[standalone@localhost:9999 /] /core-service=management/service=management-operations:find-non-progressing-operation
{
"outcome" => "success",
"result" => "-340841891"
}
[standalone@localhost:9999 /] /core-service=management/service=management-operations/active-operation=-340841891:read-resource
{
"outcome" => "success",
"result" => {
"access-mechanism" => "undefined",
"address" => [],
"caller-thread" => "management-handler-thread - 1",
"cancelled" => false,
"exclusive-running-time" => 205574507121L,
"execution-status" => "executing",
"operation" => "composite",
"running-time" => 205575446309L
}
}
{code}
Seems the blocking-timeout does not take effect on those kind of operations, there is a way to terminate long running management operations of any kind?
This behaviour leads the thread in the waiting tatus:
"main" #1 prio=5 os_prio=0 tid=0x00007f22f0009800 nid=0x78d9 in Object.wait() [0x00007f22f7e19000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
- locked <0x000000079899cba8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
- locked <0x000000079899cba8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
Thanks.
PS, it is EAP 6.4.5
> Execution timeout for CLI operations
> ------------------------------------
>
> Key: WFCORE-923
> URL: https://issues.jboss.org/browse/WFCORE-923
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Affects Versions: 2.0.0.Beta4
> Reporter: Lyle Wang
> Assignee: Alexey Loubyansky
> Labels: cli, timeout
>
> It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
> Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
> Currently there is "--timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this timeout with a CLI script file, which has "deploy" inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-923) Execution timeout for CLI operations
by Filippe Spolti (JIRA)
[ https://issues.jboss.org/browse/WFCORE-923?page=com.atlassian.jira.plugin... ]
Filippe Spolti commented on WFCORE-923:
---------------------------------------
Hi, sometimes I getting this:
{code:shell}
[standalone@localhost:9999 /] /core-service=management/service=management-operations:find-non-progressing-operation
{
"outcome" => "success",
"result" => "-340841891"
}
[standalone@localhost:9999 /] /core-service=management/service=management-operations/active-operation=-340841891:read-resource
{
"outcome" => "success",
"result" => {
"access-mechanism" => "undefined",
"address" => [],
"caller-thread" => "management-handler-thread - 1",
"cancelled" => false,
"exclusive-running-time" => 205574507121L,
"execution-status" => "executing",
"operation" => "composite",
"running-time" => 205575446309L
}
}
{code}
Seems the blocking-timeout does not take effect on those kind of operations, there is a way to terminate long running management operations of any kind?
This behaviour leads the thread in the waiting tatus:
"main" #1 prio=5 os_prio=0 tid=0x00007f22f0009800 nid=0x78d9 in Object.wait() [0x00007f22f7e19000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
- locked <0x000000079899cba8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
- locked <0x000000079899cba8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
Thanks.
PS, it is EAP 6.4.5
> Execution timeout for CLI operations
> ------------------------------------
>
> Key: WFCORE-923
> URL: https://issues.jboss.org/browse/WFCORE-923
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Affects Versions: 2.0.0.Beta4
> Reporter: Lyle Wang
> Assignee: Alexey Loubyansky
> Labels: cli, timeout
>
> It will be great if we could have a timeout setting to "stop-the-CLI-execution-after-nnn-seconds" , for all general CLI operations.
> Specifically, during some CLI operations, for example "deploy" or "reload", it is possible that things get stuck and hang-up, CLI cannot get back / return to the user after a long waiting. In this case, if we're able to setup an "execution timeout" and let CLI return with an error message, that would be much better. User should be able to know command execution results by viewing the related logs or checking the status.
> Currently there is "--timeout" setting when running "jboss-cli.sh", but that seems only effective on "connect" operation, tried to use this timeout with a CLI script file, which has "deploy" inside (./jboss-cli.sh --file=test.cli --timeout=xxx), it doesn't work when the deployment takes a long time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-3239) Changing the JNDI bound values in the naming subsystem requires reload.
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3239?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reopened WFLY-3239:
----------------------------------
Assignee: Stuart Douglas (was: Eduardo Martins)
> Changing the JNDI bound values in the naming subsystem requires reload.
> -----------------------------------------------------------------------
>
> Key: WFLY-3239
> URL: https://issues.jboss.org/browse/WFLY-3239
> Project: WildFly
> Issue Type: Feature Request
> Components: Naming
> Affects Versions: 8.1.0.CR1
> Environment: All
> Reporter: Jay SenSharma
> Assignee: Stuart Douglas
>
> - Changing the values which are binded in the naming subsystem shows "reload-required", which it ideally should not. The JNDI naming should follow the "rebind" feature of InitialContext. The values should be rebinded in the JNDI.
> - Ideally the JNDI value should not have required the reload and in the runtime only the JNDI value should have changed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 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 edited comment on WFLY-6561 at 4/26/16 6:14 PM:
-----------------------------------------------------------
This was encountered after upgrading from JBoss 7 Application Server to Wildfly 10
was (Author: kcpublic):
This was started to be encountered after upgrading from JBoss 7 Application Server to Wildfly 10
> 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: EE
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
>
> 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)
10 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:
----------------------------------
The "QuartzWatcherService" is configured to be run every minute. Below is the code for the TimerConfig and verified by watching logs:
{code:java}
ScheduleExpression expression = new ScheduleExpression();
expression.second("0").minute("*").hour("*").start(new Date(System.currentTimeMillis() + 6000));
// Triggers @Timeout method above.
final TimerConfig config = new TimerConfig();
config.setPersistent(false);
timerService.createCalendarTimer(expression, config);
{code}
> 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: EE
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
>
> 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)
10 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 updated WFLY-6561:
-----------------------------
Summary: EJB Timers Intermittently Execute Repeatedly on Server Restart with Error Code WFLYEJB0043 (was: EJB Timers Intermittently Execute Repeatedly on Server Restart)
> 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: EE
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
>
> 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)
10 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:
----------------------------------
This was started to be encountered after upgrading from JBoss 7 Application Server to Wildfly 10
> 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: EE
> Affects Versions: 10.0.0.Final
> Reporter: Kevin Chen
>
> 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)
10 years