8

I am trying to test the @Schedule annotation with the following code: 

import javax.ejb.Schedule;
import javax.ejb.Singleton;
import javax.ejb.Startup;

@Singleton
@Startup
public class TimerTest {

    public TimerTest() {

    }

    @Schedule(second = "*", minute = "*", hour = "*")
    public void sayHello() {
        System.out.println("Hello");
    }

}

However, when I deploy it to the standalone instance of wildfly 8.1.0 (final) I am getting the following error messages in the logs:

2014-09-23 08:38:03,076 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."test-server.war".component.TimerTest.ejb3.timerService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test-server.war".component.TimerTest.ejb3.timerService: Failed to start service
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
    at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
Caused by: java.lang.NullPointerException
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.doesTimeoutMethodMatch(TimerServiceImpl.java:959)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:710)
    at org.jboss.as.ejb3.timerservice.TimerServiceImpl.start(TimerServiceImpl.java:202)
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
    ... 3 more

2014-09-23 08:38:07,098 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "test-server.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"test-server.war\".component.TimerTest.ejb3.timerService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"test-server.war\".component.TimerTest.ejb3.timerService: Failed to start service
    Caused by: java.lang.NullPointerException"}}

2014-09-23 08:38:07,145 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
JBAS014777:   Services which failed to start:      service jboss.deployment.unit."test-server.war".component.TimerTest.ejb3.timerService: org.jboss.msc.service.StartException in service jboss.deployment.unit."test-server.war".component.TimerTest.ejb3.timerService: Failed to start service

JBAS014777:   Services which failed to start:      service jboss.deployment.unit."test-server.war".component.TimerTest.ejb3.timerService

Any ideas as to what could be causing this?

cardori
  • 235
  • 1
  • 5
  • 13
  • 2
    Application servers shouldn't ever throw NullPointerException like that, so you should probably report this as a bug to JBoss. Based on the `doesTimeoutMethodMatch`, I might guess that the server is trying to ensure that your `@Schedule` has not changed since it was first created in a persistent database. Perhaps try cleaning up the timer database tables (or whatever), and then try redeploying the application? – Brett Kail Sep 23 '14 at 14:26
  • 3
    I did some research and the timers are stored in the standalone\data\timer-service-data folder. Removing the timer located here and deploying again did indeed fix the issue. Thanks for highlighting that (I've been struggling with this for a while) – cardori Sep 23 '14 at 14:53
  • 1
    I would probably still report the issue to JBoss. Regardless of the contents of that file, that NPE should not occur. – Brett Kail Sep 23 '14 at 19:19

1 Answers1

15

I've seen this before. In your WildFly directory, asuming you did a standalone deployment, there will be a directory standalone/data/timer-service-data. There is probably some old timerService data in that directory. Shut down the server, delete this data and try again.

This is probably data from a test run that did not complete before the server shut down. Remember that the timerService is persistent. So if there are pending tasks when you shut down the server, it will try to pick up those tasks first. If you updated your war those timer processes will probably not match the processes in the war anymore.

Martijn Burger
  • 7,315
  • 8
  • 54
  • 94