[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski commented on WFLY-10280:
-------------------------------------------
Possibly it is just silently ignored. Thing is that during configuration of clustering, some config providers ignore cache name ( passivation ) and default to "client-mappings" mappings for instance.
btw, it does not explode with workaround I call it a good workaround.
> Can't enable stateful EJB passivation when EJB remote service is removed
> ------------------------------------------------------------------------
>
> Key: WFLY-10280
> URL: https://issues.jboss.org/browse/WFLY-10280
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 12.0.0.Final
> Reporter: Ladislav Thon
> Assignee: Bartosz Baranowski
> Priority: Minor
> Attachments: tinyEjbPassivation.war
>
>
> In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
> What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
> When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
> {code}
> 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService]
> service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START]
> service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService]
> service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager]
> service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2262) "Frozen" coordinator causes the whole cluster to hang
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2262?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2262:
--------------------------------
FYI, I just released 3.6.16.Final
> "Frozen" coordinator causes the whole cluster to hang
> -----------------------------------------------------
>
> Key: JGRP-2262
> URL: https://issues.jboss.org/browse/JGRP-2262
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.7
> Reporter: Pietro Paolini
> Assignee: Bela Ban
> Fix For: 4.0.12, 3.6.16
>
> Attachments: jdbc_test.xml, jgroup.zip
>
>
> This is the result of an investigation I carried out for a problem we have experienced within our
> application, the scenario it has been re-created by pausing the JVM using a debugger.
> The discovery mechanism is JDBC_PING.
> If the coordinator's JVM gets fronzen (for whatever reason) before the coordinator sets itself as the cluster coordinator and another node is started after that it will be unable to join the cluster and it will hang indefinitely.
> This seems to be caused by the "continue" statement at
> https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...
> I have prepared a simple application which can help in replicating the problem.
> To replicate the problem :
> 1) Make sure the JGROUPSPING is empty
> 2) Run the application using an IDE and attaching a debugger to cause the JVM to
> be paused at line Main.java:67, wait for it.
> 3) Run the application in non debug mode or with gradle using "gradle run" and it will
> hang indefinitely
> Depending on the UUID/IP Address being used generated/assigned this may not happen all the time but it happened quite often in my local tests.
>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10585) BanTransitiveDependencies enforcer violations while building wildfly-galleon-pack module on IBM jdk
by Jan Blizňák (JIRA)
[ https://issues.jboss.org/browse/WFLY-10585?page=com.atlassian.jira.plugin... ]
Jan Blizňák commented on WFLY-10585:
------------------------------------
I suppose this is the cause https://github.com/apache/cxf/blob/master/parent/pom.xml#L2789-L2826
We could add explicit exclude on WF side..
> BanTransitiveDependencies enforcer violations while building wildfly-galleon-pack module on IBM jdk
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-10585
> URL: https://issues.jboss.org/browse/WFLY-10585
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Web Services
> Reporter: Petr Kremensky
> Assignee: Alessio Soldano
>
> Building WildFly: Full Galleon Pack using IBM jdk fails with enforcer BanTransitiveDependencies violation.
> *reproduce*
> {noformat}
> wildfly] $ mvn package -pl galleon-pack
> ...
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (ban-transitive-deps) @ wildfly-galleon-pack ---
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanTransitiveDependencies failed with message:
> org.wildfly:wildfly-galleon-pack:pom:14.0.0.Beta1-SNAPSHOT
> org.apache.cxf:cxf-rt-features-logging:jar:3.2.4-jbossorg-1:compile has transitive dependencies:
> xalan:xalan:jar:2.7.1.jbossorg-4:compile
> xalan:serializer:jar:2.7.1.jbossorg-4:compile
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 21.949 s
> [INFO] Finished at: 2018-06-18T13:30:17+02:00
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce (ban-transitive-deps) on project wildfly-galleon-pack: Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed. -> [Help 1]
> {noformat}
> *workaround*
> Skip enforcer by adding {{-Denforcer.skip=true}} property
> *environment*
> {noformat}
> $ mvn -version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> Maven home: /usr/lib/maven
> Java version: 1.8.0_171, vendor: IBM Corporation
> Java home: /usr/lib/java/ibm-java-8.0-5.16/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.16.15-300.fc28.x86_64", arch: "amd64", family: "unix"
> $ git rev-parse --short HEAD
> 4eff06230b
> {noformat}
> *ibm jdk download*
> https://developer.ibm.com/javasdk/downloads/sdk8/
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-9727) WildFly Randomly Terminates after 5-10 minutes
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-9727?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-9727:
--------------------------------
Description:
I've been experiencing an odd intermittent issue on my WildFly server that has been running on my local system. Every other day or so my server will shutdown, without warning, after running for five to ten minutes from launch. The WildFly server logs contain no errors but the Eclipse logs output these two stack identical stack traces every time:
{code}
Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)
Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)
{code}
This issue will occur on every server start for an entire day and then the next day it won't happen at all. However, when it happens it makes debugging the software I write that runs of the server near impossible. Does anyone have any ideas what could be causing this issue? Let me know if you need more details, thanks!
was:
I've been experiencing an odd intermittent issue on my WildFly server that has been running on my local system. Every other day or so my server will shutdown, without warning, after running for five to ten minutes from launch. The WildFly server logs contain no errors but the Eclipse logs output these two stack identical stack traces every time:
{{Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)
Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)}}
This issue will occur on every server start for an entire day and then the next day it won't happen at all. However, when it happens it makes debugging the software I write that runs of the server near impossible. Does anyone have any ideas what could be causing this issue? Let me know if you need more details, thanks!
> WildFly Randomly Terminates after 5-10 minutes
> ----------------------------------------------
>
> Key: WFLY-9727
> URL: https://issues.jboss.org/browse/WFLY-9727
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.0.Final
> Environment: Running WildFly 10.x from within Eclipse Oxygen (4.7.2) on 2015 MacBook Pro running OS X El Capitan (10.11.6)
> Reporter: Daniel Wiseman
> Assignee: Jason Greene
> Priority: Critical
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> I've been experiencing an odd intermittent issue on my WildFly server that has been running on my local system. Every other day or so my server will shutdown, without warning, after running for five to ten minutes from launch. The WildFly server logs contain no errors but the Eclipse logs output these two stack identical stack traces every time:
> {code}
> Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
> at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
> at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
> at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
> at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
> at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
> at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)
> Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
> at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
> at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
> at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
> at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
> at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
> at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)
> {code}
> This issue will occur on every server start for an entire day and then the next day it won't happen at all. However, when it happens it makes debugging the software I write that runs of the server near impossible. Does anyone have any ideas what could be causing this issue? Let me know if you need more details, thanks!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10585) BanTransitiveDependencies enforcer violations while building wildfly-galleon-pack module on IBM jdk
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-10585?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-10585:
---------------------------------------
Component/s: Web Services
Assignee: Alessio Soldano (was: Jason Greene)
I put the Web Services component on this and assigned to Alessio because AFAICT from the description the issue seems to be coming from CXF.
> BanTransitiveDependencies enforcer violations while building wildfly-galleon-pack module on IBM jdk
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-10585
> URL: https://issues.jboss.org/browse/WFLY-10585
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Web Services
> Reporter: Petr Kremensky
> Assignee: Alessio Soldano
>
> Building WildFly: Full Galleon Pack using IBM jdk fails with enforcer BanTransitiveDependencies violation.
> *reproduce*
> {noformat}
> wildfly] $ mvn package -pl galleon-pack
> ...
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (ban-transitive-deps) @ wildfly-galleon-pack ---
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BanTransitiveDependencies failed with message:
> org.wildfly:wildfly-galleon-pack:pom:14.0.0.Beta1-SNAPSHOT
> org.apache.cxf:cxf-rt-features-logging:jar:3.2.4-jbossorg-1:compile has transitive dependencies:
> xalan:xalan:jar:2.7.1.jbossorg-4:compile
> xalan:serializer:jar:2.7.1.jbossorg-4:compile
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 21.949 s
> [INFO] Finished at: 2018-06-18T13:30:17+02:00
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce (ban-transitive-deps) on project wildfly-galleon-pack: Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed. -> [Help 1]
> {noformat}
> *workaround*
> Skip enforcer by adding {{-Denforcer.skip=true}} property
> *environment*
> {noformat}
> $ mvn -version
> Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T20:49:05+01:00)
> Maven home: /usr/lib/maven
> Java version: 1.8.0_171, vendor: IBM Corporation
> Java home: /usr/lib/java/ibm-java-8.0-5.16/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.16.15-300.fc28.x86_64", arch: "amd64", family: "unix"
> $ git rev-parse --short HEAD
> 4eff06230b
> {noformat}
> *ibm jdk download*
> https://developer.ibm.com/javasdk/downloads/sdk8/
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10106) Problem with @Schedule and daylight-saving time
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-10106?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10106:
---------------------------------
Steps to Reproduce:
1. Deploy this little Bean to a Wildfly 12:
{code:java}
import java.util.logging.LogManager;
import java.util.logging.Logger;
import javax.ejb.Schedule;
import javax.ejb.Singleton;
import javax.ejb.Startup;
@Startup
@Singleton
public class TestBean {
private static final Logger logger = LogManager.getLogManager().getLogger(TestBean.class.getName());
@Schedule(second = "*/10", minute = "*", hour = "*", persistent = false)
void scheduledUpdate() {
logger.info("Time is up!");
}
}
{code}
2. Set your system date time to 24.03.2018 23:59:00
3. Start your Wildfly 12
What you now should see is something like the following output in the log:
{code}
...
2018-03-24 23:59:17,173 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
2018-03-24 23:59:17,173 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
2018-03-24 23:59:17,173 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 12.0.0.Final (WildFly Core 4.0.0.Final) started in 3392ms - Started 435 of 625 services (314 services are lazy, passive or on-demand)
2018-03-24 23:59:20,013 INFO [TestBean] (EJB default - 1) Time is up!
2018-03-24 23:59:30,008 INFO [TestBean] (EJB default - 2) Time is up!
2018-03-24 23:59:40,010 INFO [TestBean] (EJB default - 3) Time is up!
2018-03-24 23:59:50,010 INFO [TestBean] (EJB default - 4) Time is up!
2018-03-24 23:59:50,010 WARN [org.jboss.as.ejb3.timer] (EJB default - 5) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:00:00 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,012 WARN [org.jboss.as.ejb3.timer] (EJB default - 7) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:00:20 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,013 INFO [TestBean] (EJB default - 6) Time is up!
2018-03-24 23:59:50,014 WARN [org.jboss.as.ejb3.timer] (EJB default - 9) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:00:40 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,014 INFO [TestBean] (EJB default - 8) Time is up!
2018-03-24 23:59:50,014 WARN [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:01:00 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,014 INFO [TestBean] (EJB default - 10) Time is up!
2018-03-24 23:59:50,014 WARN [org.jboss.as.ejb3.timer] (EJB default - 2) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:01:10 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,014 WARN [org.jboss.as.ejb3.timer] (EJB default - 5) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:01:30 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,014 INFO [TestBean] (EJB default - 3) Time is up!
2018-03-24 23:59:50,014 WARN [org.jboss.as.ejb3.timer] (EJB default - 4) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:01:40 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,014 WARN [org.jboss.as.ejb3.timer] (EJB default - 6) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:02:00 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,014 INFO [TestBean] (EJB default - 7) Time is up!
...
{code}
was:
1. Deploy this little Bean to a Wildfly 12:
import java.util.logging.LogManager;
import java.util.logging.Logger;
import javax.ejb.Schedule;
import javax.ejb.Singleton;
import javax.ejb.Startup;
@Startup
@Singleton
public class TestBean {
private static final Logger logger = LogManager.getLogManager().getLogger(TestBean.class.getName());
@Schedule(second = "*/10", minute = "*", hour = "*", persistent = false)
void scheduledUpdate() {
logger.info("Time is up!");
}
}
2. Set your system date time to 24.03.2018 23:59:00
3. Start your Wildfly 12
What you now should see is something like the following output in the log:
...
2018-03-24 23:59:17,173 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
2018-03-24 23:59:17,173 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
2018-03-24 23:59:17,173 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 12.0.0.Final (WildFly Core 4.0.0.Final) started in 3392ms - Started 435 of 625 services (314 services are lazy, passive or on-demand)
2018-03-24 23:59:20,013 INFO [TestBean] (EJB default - 1) Time is up!
2018-03-24 23:59:30,008 INFO [TestBean] (EJB default - 2) Time is up!
2018-03-24 23:59:40,010 INFO [TestBean] (EJB default - 3) Time is up!
2018-03-24 23:59:50,010 INFO [TestBean] (EJB default - 4) Time is up!
2018-03-24 23:59:50,010 WARN [org.jboss.as.ejb3.timer] (EJB default - 5) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:00:00 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,012 WARN [org.jboss.as.ejb3.timer] (EJB default - 7) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:00:20 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,013 INFO [TestBean] (EJB default - 6) Time is up!
2018-03-24 23:59:50,014 WARN [org.jboss.as.ejb3.timer] (EJB default - 9) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:00:40 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,014 INFO [TestBean] (EJB default - 8) Time is up!
2018-03-24 23:59:50,014 WARN [org.jboss.as.ejb3.timer] (EJB default - 1) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:01:00 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,014 INFO [TestBean] (EJB default - 10) Time is up!
2018-03-24 23:59:50,014 WARN [org.jboss.as.ejb3.timer] (EJB default - 2) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:01:10 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,014 WARN [org.jboss.as.ejb3.timer] (EJB default - 5) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:01:30 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,014 INFO [TestBean] (EJB default - 3) Time is up!
2018-03-24 23:59:50,014 WARN [org.jboss.as.ejb3.timer] (EJB default - 4) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:01:40 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,014 WARN [org.jboss.as.ejb3.timer] (EJB default - 6) WFLYEJB0043: A previous execution of timer [id=2cb6b3c6-fdc8-468a-806c-a0699237db21 timedObjectId=TestWeb.TestWeb.TestBean auto-timer?:true persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@2cd27b36 initialExpiration=null intervalDuration(in milli sec)=0 nextExpiration=Sat Mar 24 23:02:00 CET 2018 timerState=IN_TIMEOUT info=null] is still in progress, skipping this overlapping scheduled execution at: Sat Mar 24 23:59:50 CET 2018.
2018-03-24 23:59:50,014 INFO [TestBean] (EJB default - 7) Time is up!
...
> Problem with @Schedule and daylight-saving time
> -----------------------------------------------
>
> Key: WFLY-10106
> URL: https://issues.jboss.org/browse/WFLY-10106
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 12.0.0.Final
> Reporter: Christoph Erni
> Assignee: Yeray Borges
> Priority: Critical
> Fix For: 14.0.0.CR1
>
>
> The method anotated with @Schedule is executed repeatedly just before entering the day of daylight-saving time.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10417) Security API - Soteria - Jaspic - Error getting ServerAuthContext
by Alessandro Moscatelli (JIRA)
[ https://issues.jboss.org/browse/WFLY-10417?page=com.atlassian.jira.plugin... ]
Alessandro Moscatelli reopened WFLY-10417:
------------------------------------------
some related issues are still open, it seems
> Security API - Soteria - Jaspic - Error getting ServerAuthContext
> -----------------------------------------------------------------
>
> Key: WFLY-10417
> URL: https://issues.jboss.org/browse/WFLY-10417
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 13.0.0.Beta1
> Environment: Wildfly 13.0.0.Beta1 and an EAR Application using JavaEE 8 Security API
> Reporter: Alessandro Moscatelli
> Assignee: Ilia Vassilev
> Priority: Critical
> Fix For: 14.0.0.CR1
>
> Attachments: image-2018-05-24-13-41-05-322.png, soteria.zip
>
>
> I am testing the new Wildfly release and the new Java EE8 Security API.
> I noticed this serious (I truly believe) bug, and it also accours almost randomly.
>
> The deployed application is an EAR.
>
> If I deploy the EAR with a started Wildfly 13.0.0.Beta1 everything is fine.
> Then if I stop and start / restart the application server, I can see the startup and the EAR is redeployed but sometimes (like 50% of time) the bug/error accours.
> Usually after a couple of times (stop/start/restart) I can reproduce the issue.
> Before the bug accours every call to pages and APIs works correctly. After the bug accours every call triggers the AuthException.
> After the bug accours, if I redeploy the SAME EAR everything is fine again 100% of times.
> This seems like Wildfly does something different when redeploying an application on startup and when being already startup up and then processing an application deploy.
>
> I can provide my EAR if you want, but I would prefer not to if this is not necessary.
> The security domain as defined as suggested :
> {code:xml}
> <security-domain name="auth" cache-type="default">
> <authentication-jaspi>
> <login-module-stack name="dummy">
> <login-module code="Dummy" flag="optional"/>
> </login-module-stack>
> <auth-module code="Dummy"/>
> </authentication-jaspi>
> </security-domain>
> {code}
>
> META-INF/jboss-app.xml inside the EAR :
>
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-app>
> <security-domain>auth</security-domain>
> </jboss-app>
> {code}
>
> META-INF/jboss-web.xml inside the WAR inside the EAR :
>
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>auth</security-domain>
> </jboss-web>
> {code}
>
> Log :
> {code}
> 17:04:18,556 ERROR [org.jboss.security] (default task-1) PBOX00374: Error getting ServerAuthContext for authContextId default-host /optoplus-services-web and security domain auth: javax.security.auth.message.AuthException
> at org.jboss.security.auth.message.config.JBossServerAuthConfig.getAuthContext(JBossServerAuthConfig.java:187)
> at org.jboss.security.plugins.auth.JASPIServerAuthenticationManager.isValid(JASPIServerAuthenticationManager.java:99)
> at org.wildfly.extension.undertow.security.jaspi.JASPICAuthenticationMechanism.authenticate(JASPICAuthenticationMechanism.java:123)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jaspi.JASPICSecureResponseHandler.handleRequest(JASPICSecureResponseHandler.java:48)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> UPDATE !!
> Now I finally got WHY it was random !!
> The problem is related to EAR containing multiple WAR registering different contexts :
> {code}
> 13:29:37,661 INFO [org.glassfish.soteria.servlet.SamRegistrationInstaller] (ServerService Thread Pool -- 80) Initializing Soteria 1.0 for context '/soteria-web2'
> 13:29:37,661 INFO [org.glassfish.soteria.servlet.SamRegistrationInstaller] (ServerService Thread Pool -- 76) Initializing Soteria 1.0 for context '/soteria-web'
> 13:29:37,738 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 80) WFLYUT0021: Registered web context: '/soteria-web2' for server 'default-server'
> 13:29:37,745 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 76) WFLYUT0021: Registered web context: '/soteria-web' for server 'default-server'
> 13:29:37,781 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "soteria-ear-1.0.0.ear" (runtime-name : "soteria-ear-1.0.0.ear")
> 13:29:37,908 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://0.0.0.0:9990/management
> 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://0.0.0.0:9990
> 13:29:37,910 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 13.0.0.Beta1 (WildFly Core 5.0.0.Beta3) started in 10500ms - Started 707 of 931 services (430 services are lazy, passive or on-demand)
> 13:30:09,195 ERROR [org.jboss.security] (default task-1) PBOX00374: Error getting ServerAuthContext for authContextId default-host /soteria-web and security domain auth: javax.security.auth.message.AuthException
> {code}
> *+In case of a reboot (or stop and start) of Wildfly, only ONE of the TWO contexts manages to get the ServerAuthContext !+*
> I attached an example project you can use to reproduce and detailed steps !
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month