13 Replies Latest reply on Mar 24, 2017 4:12 AM by Rohan Emmanuel

    timer is not invoked

    nimo stephan Master

      I use jboss as 6 m4

       

      I have this within my stateless ejbbean:

       


      @Schedule(hour="*", minute="*", second="5", persistent=true)
      public void mySchedule()

      {       
         System.out.println("Timer " + new Date() + " for bean " + this.getClass().getSimpleName()); 

      }

       

      @Timeout 
      private void onTimeout(Timer timer)

              System.out.println("Timeout method invoked at " + new Date() + " for bean " + this.getClass().getSimpleName());
      }

       

       

      So you see, onTimeout should be triggered every 5 seconds - but onTimeout is not called.

       

      I have red http://jaitechwriteups.blogspot.com/2010/07/ejb31-timerservice-in-jboss-as-600m4.html that jboss as 6 milestone 4 supports timer.


      Why is my timer not working?

       

       

      Do I need to trigger mySchedule-Method for the first time to enable my timer?

       

      something like:

       

      public void initMyTimer(){


      this.mySchedule();

      }

        • 1. Re: timer is not invoked
          jaikiran pai Master

          Do you have a ejb-jar.xml? What does it's xsd  declaration look like? Also, can you post the entire EJB bean code (I'm interested in seeing the class name and annotations associated with it).

          • 2. Re: timer is not invoked
            jaikiran pai Master

            nimo stephan wrote:

             

             

             

            I have this within my stateless ejbbean:

             


            @Schedule(hour="*", minute="*", second="5", persistent=true)
            public void mySchedule()

            {       
               System.out.println("Timer " + new Date() + " for bean " + this.getClass().getSimpleName()); 

            }

             

            @Timeout 
            private void onTimeout(Timer timer)

                    System.out.println("Timeout method invoked at " + new Date() + " for bean " + this.getClass().getSimpleName());
            }

             

             

            So you see, onTimeout should be triggered every 5 seconds - but onTimeout is not called.

             

            Note that you have annotated mySchedule() as the auto-timeout method. So it's the mySchedule() which will be invoked and not the onTimeout().

             

            Also, the schedule expression hour="*", minute="*", second = "5" doesn't mean every 5 seconds. It means, the timer is scheduled to run every hour, every minute at the second = 5. For example 1:12:05 and then 1:13:05 (where 1 is 1 AM, 12 and 13 are minutes).

            • 3. Re: timer is not invoked
              nimo stephan Master

              I have a ejb-jar.xml under WEB-INF-directory packaged as WAR:

               

              <ejb-jar xmlns = "http://java.sun.com/xml/ns/javaee"
                       version = "3.1"
                       xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
                       xsi:schemaLocation = "http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd">
                 <enterprise-beans>


                  ..
                 </enterprise-beans>
              </ejb-jar>

               

               

              MyBean with Timer:

               

              @Stateless
              public class MyBean implements MyBeanLocal, MyBeanWebService{


                 
                  @Inject Logger log;
                  @PersistenceContext EntityManager entityManager;
                 
                  @Resource
                  private SessionContext context;


              @Schedule(second="5", persistent=true)
              public void mySchedule()

              {       
                 System.out.println("Timer " + new Date() + " for bean " + this.getClass().getSimpleName());

              }


              @Timeout 
              private void onTimeout(Timer timer)

                      System.out.println("Timeout method invoked at " + new Date() + " for bean " + this.getClass().getSimpleName());
              }

              }

               

               

              I changed my timer to @Schedule(second="5", persistent=true) but it does not work.

               

               

              {quote}Note that you have annotated mySchedule() as the auto-timeout method. So  it's the mySchedule() which will be invoked and not the onTimeout().{quote}

               

              Got it. But mySchedule is not invoked every 5 seconds. Strange..(maybe I have to de-annotate onTimeout-method?)

              • 4. Re: timer is not invoked
                jaikiran pai Master

                nimo stephan wrote:

                 


                 

                 

                I changed my timer to @Schedule(second="5", persistent=true) but it does not work.

                 

                 

                ...

                But mySchedule is not invoked every 5 seconds. Strange..

                It won't. Since as per your new expression the hour and minute is now (by default) 0. Which means the schedule is expected to fire at 00:00:05.

                 

                If you want it to fire every 5 seconds then use this schedule:

                 

                @Schedule(second = "*/5", minute = "*", hour = "*")
                public void blah(Timer timer)
                {
                ...
                }
                • 5. Re: timer is not invoked
                  nimo stephan Master

                  thanks, indeed, my schedule expression was wrong. However, it does not work:

                   

                  This is my SessionBean:

                   

                  @Stateless
                  public class MyBean implements MyBeanLocal, MyBeanWebService{


                     
                      @Inject Logger log;
                      @PersistenceContext EntityManager entityManager;
                     
                      @Resource
                      private SessionContext context;



                      @PostConstruct
                      public void initialize()
                      {
                          log.info("@PostConstruct");
                          log.info("{} was created.", this.getClass().getSimpleName());

                      }
                     
                     
                      @PreDestroy
                      public void preDestroy()
                      {


                          log.info("@PreDestroy");       
                          log.info("{} was destroyed.", this.getClass().getSimpleName());
                      }


                    @Schedule(second="*/5", minute = "*", hour = "*")
                    public void mySchedule()

                    {       
                     System.out.println("Timer " + new Date() + " for bean " + this.getClass().getSimpleName());

                    }


                  }

                   

                   

                  I invoke my SessionBean by weld-injection:

                   

                  @SessionScoped @Named
                  public class MyClient implements Serializable{


                      private static final long serialVersionUID = -555775799974135650L;


                      @Inject MyBeanLocal myBean;

                  ..

                  }

                   

                   

                  My SessionBean is invoked as I can see the PostConstruct-Message in my console:

                   

                  09:02:50,710 INFO  [com.MyBean] @PostConstruct
                  09:02:50,710 INFO  [com.MyBean] MyBean was created.

                   

                  However, mySchedule is not invoked ! I wait and wait and wait..my Timer is not working.

                   

                   

                  I dont know, if this is relevant to my timer-problem.

                  When deploying my WAR-File, I always get this error. But however, I can run my war-application:

                   

                  08:52:30,808 WARN  [org.jboss.ejb3.interceptor.InterceptorInfoRepository] EJBTHREE-1852: InterceptorInfoRepository is deprecated
                  08:52:31,011 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Real: name=vfs:///D:/workspaces/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_6.0_Runtime_Server1282552650255/deploy/MyWAR.war state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying MyWAR.war: Error creating ejb container MyEJB: Container jboss.j2ee:jar=MyWAR.war,name=MyEJB,service=EJB3,VMID=15859851ccbc6adb:695c7b51:12b1429ca97:-7fc5 + is already registered
                      at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189) [:6.0.0.20100721-M4]
                      at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:59) [:6.0.0.20100721-M4]
                      at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56) [:2.2.0.Alpha6]
                      at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.Alpha6]
                      at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.Alpha6]
                      at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha6]
                      at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.Alpha6]
                      at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.Alpha6]
                      at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.Alpha6]
                      at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.Alpha6]
                      at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.Alpha6]
                      at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.Alpha6]
                      at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.20100721-M4]
                      at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:130) [:0.1.0.Alpha1]
                      at org.jboss.profileservice.dependency.ProfileDeployAction.deploy(ProfileDeployAction.java:148) [:0.1.0.Alpha1]
                      at org.jboss.profileservice.dependency.ProfileDeployAction.installActionInternal(ProfileDeployAction.java:94) [:0.1.0.Alpha1]
                      at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54) [jboss-kernel.jar:2.2.0.Alpha10]
                      at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42) [jboss-kernel.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.Alpha10]
                      at org.jboss.profileservice.dependency.ProfileServiceController.activate(ProfileServiceController.java:188) [:0.1.0.Alpha1]
                      at org.jboss.profileservice.AbstractProfileService.activateProfile(AbstractProfileService.java:170) [:0.1.0.Alpha1]
                      at org.jboss.system.tools.ProfileServiceToolsFacade.addURI(ProfileServiceToolsFacade.java:217) [:6.0.0.20100721-M4]
                      at org.jboss.system.tools.LegacyDeploymentScannerAdapter.addURL(LegacyDeploymentScannerAdapter.java:131) [:6.0.0.20100721-M4]
                      at org.jboss.system.tools.DeploymentScanner.addURL(DeploymentScanner.java:91) [:6.0.0.20100721-M4]
                      at org.jboss.system.tools.DeploymentScanner.addURL(DeploymentScanner.java:83) [:6.0.0.20100721-M4]
                      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_21]
                      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_21]
                      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_21]
                      at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_21]
                      at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.Beta5]
                      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.Beta5]
                      at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.Beta5]
                      at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.Beta5]
                      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.Beta5]
                      at org.jboss.system.server.jmx.MBeanServerWrapper.invoke(MBeanServerWrapper.java:138) [:6.0.0.20100721-M4 (Build SVNTag:JBoss_6.0.0.20100721-M4 date: 20100723)]
                      at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1427) [:1.6.0_21]
                      at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:72) [:1.6.0_21]
                      at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1265) [:1.6.0_21]
                      at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1360) [:1.6.0_21]
                      at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:788) [:1.6.0_21]
                      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_21]
                      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_21]
                      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_21]
                      at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_21]
                      at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305) [:1.6.0_21]
                      at sun.rmi.transport.Transport$1.run(Transport.java:159) [:1.6.0_21]
                      at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_21]
                      at sun.rmi.transport.Transport.serviceCall(Transport.java:155) [:1.6.0_21]
                      at sun.rmi.transport.tcp.TCPTransport.handleMyWARsages(TCPTransport.java:535) [:1.6.0_21]
                      at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790) [:1.6.0_21]
                      at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649) [:1.6.0_21]
                      at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_21]
                      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_21]
                      at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]
                  Caused by: org.jboss.deployers.spi.DeploymentException: Error creating ejb container MyEJB: Container jboss.j2ee:jar=MyWAR.war,name=MyEJB,service=EJB3,VMID=15859851ccbc6adb:695c7b51:12b1429ca97:-7fc5 + is already registered
                      at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:751) [:1.5.0-alpha-4]
                      at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:688) [:1.5.0-alpha-4]
                      at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:670) [:1.5.0-alpha-4]
                      at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:633) [:1.5.0-alpha-4]
                      at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:510) [:1.5.0-alpha-4]
                      at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:175) [:6.0.0.20100721-M4]
                      ... 71 more
                  Caused by: java.lang.IllegalStateException: Container jboss.j2ee:jar=MyWAR.war,name=MyEJB,service=EJB3,VMID=15859851ccbc6adb:695c7b51:12b1429ca97:-7fc5 + is already registered
                      at org.jboss.ejb3.Ejb3Registry.register(Ejb3Registry.java:128) [:1.5.0-alpha-4]
                      at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:747) [:1.5.0-alpha-4]
                      ... 76 more

                  • 6. Re: timer is not invoked
                    jaikiran pai Master

                    nimo stephan wrote:

                     


                      @Schedule(second="5", persistent=true)
                      public void mySchedule()

                      {       
                       System.out.println("Timer " + new Date() + " for bean " + this.getClass().getSimpleName());

                      }

                     

                    }

                     

                    You still are using the wrong expression

                     

                    nimo stephan wrote:

                     


                    I dont know, if this is relevant to my timer-problem.

                    When deploying my WAR-File, I always get this error. But however, I can run my war-application:

                     

                    08:52:31,011 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Real: name=vfs:///D:/workspaces/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_6.0_Runtime_Server1282552650255/deploy/MyWAR.war state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Error deploying MyWAR.war: Error creating ejb container MyEJB: Container jboss.j2ee:jar=MyWAR.war,name=MyEJB,service=EJB3,VMID=15859851ccbc6adb:695c7b51:12b1429ca97:-7fc5 + is already registered
                        at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189) [:6.0.0.20100721-M4]
                        at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:59) [:6.0.0.20100721-M4]
                        at org.jboss.deployers.vfs.spi.deployer.AbstractSimpleVFSRealDeployer.deploy(AbstractSimpleVFSRealDeployer.java:56) [:2.2.0.Alpha6]
                        at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.Alpha6]
                        at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.Alpha6]
                        at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha6]
                        at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.Alpha6]
                        at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.Alpha6]
                        at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.Alpha6]
                        at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
                    ...
                    Caused by: org.jboss.deployers.spi.DeploymentException: Error creating ejb container MyEJB: Container jboss.j2ee:jar=MyWAR.war,name=MyEJB,service=EJB3,VMID=15859851ccbc6adb:695c7b51:12b1429ca97:-7fc5 + is already registered
                        at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:751) [:1.5.0-alpha-4]
                        at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:688) [:1.5.0-alpha-4]
                        at org.jboss.ejb3.Ejb3Deployment.deployUrl(Ejb3Deployment.java:670) [:1.5.0-alpha-4]
                        at org.jboss.ejb3.Ejb3Deployment.deploy(Ejb3Deployment.java:633) [:1.5.0-alpha-4]
                        at org.jboss.ejb3.Ejb3Deployment.create(Ejb3Deployment.java:510) [:1.5.0-alpha-4]
                        at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:175) [:6.0.0.20100721-M4]
                        ... 71 more
                    Caused by: java.lang.IllegalStateException: Container jboss.j2ee:jar=MyWAR.war,name=MyEJB,service=EJB3,VMID=15859851ccbc6adb:695c7b51:12b1429ca97:-7fc5 + is already registered
                        at org.jboss.ejb3.Ejb3Registry.register(Ejb3Registry.java:128) [:1.5.0-alpha-4]
                        at org.jboss.ejb3.Ejb3Deployment.deployElement(Ejb3Deployment.java:747) [:1.5.0-alpha-4]
                        ... 76 more

                    That looks like a problem. Does it happen on redeploy of the application? What is MyEJB? Is it a @Singleton bean?

                    • 7. Re: timer is not invoked
                      nimo stephan Master

                      I guess, I found the error!

                       

                       

                      Look:

                       

                      {quote}You still are using the wrong expression{quote}

                       

                      No, I am using this in my Stateless bean MyEJB:


                      @Schedule(second="*/20", minute = "*", hour = "*", persistent=true)
                      public void scheduleReport()
                      {

                      System.out.println("Timer " + new Date() + " for bean " + this.getClass().getSimpleName());

                      }

                       

                      {quote}That looks like a problem. Does it happen on redeploy of the application? What is MyEJB? Is it a @Singleton bean?{quote}

                       

                      I do not use hot-deploy. Everytime, I have a new version of MyWAR.war, I stop the server, delete the (exploded) war-file from the deploy-directory and put a new version in it. Then I start the server again, which results this error. How can I solve that?

                       

                      MyEJB is not a Singleton bean:

                       

                      @Stateless
                      public class MyEJB implements MyEJBLocal{

                      ...

                      }

                       

                       

                      The odd thing is:

                       

                       

                      I make a new try with a additional bean which is a @Singleton:

                       

                      @Singleton
                      @Startup
                      public class MySingleton{

                       

                      // the timer-object is stored in a database per default

                      @Schedule(second="*/5", minute = "*", hour = "*", persistent=true)
                          public void scheduleReport()
                          {


                            for (Object obj:timerService.getTimers()){
                                  Timer timer = (Timer) obj;

                       

                                  log.info("timer.getInfo {}", timer.getInfo());
                                  log.info("timer.getSchedule {}", timer.getSchedule().getSecond());
                                  log.info("timer.getSchedule {}", timer.getHandle());
                             }

                       

                             
                              System.out.println("Timer " + new Date() + " for bean " + this.getClass().getSimpleName() +" invoked!");

                      }

                      }

                       

                       

                      And indeed, the timer of my Singleton-Bean is invoked every 5 seconds. So this works. But the timer of my Stateless-Bean does not work.

                       

                      When I change the ScheduleExpression of scheduleReport of MySingleton to this:

                       

                      @Schedule(second="*/20", minute = "*", hour = "*", persistent=true)

                       

                      and make a new redeploy (server-stop, delete old-war file, put new war-file, start server), then the container does not consider the updated expression. The timer is still invoked every 5 seconds altought I changed it to 20 seconds. So I guess, I need to reset the timer. But how?

                       

                      You know, my stateless-bean had at first another (wrong) schedule-expression and I changed it to the right, but the container does not update my timer to the new ScheduleExpression. So this is the problem, internally the container assumes the old (the first) scheduleExpression. So why does the container not update the stored TimerObject? I know, the stored timer alives server-restarts - but however, it should consider updated scheduledExpression.

                       

                       

                      The other thing is, when I rename the method of my MySingleton-Bean "scheduleReport()" to "scheduleReport_1()", then the container complains that it cannot find the method "scheduleReport()". In this case, the timer does not work anymore(, as the container has the timer stored with the old reference to scheduleReport()).

                       

                       

                      How can I solve that?

                      • 8. Re: timer is not invoked
                        nimo stephan Master

                        I deleted all stored timer-objects of jboss-hsql via the following command:

                         

                         

                        DELETE FROM PUBLIC.CALENDAR_TIMER


                        DELETE FROM PUBLIC.TIMEOUT_METHOD


                        DELETE FROM PUBLIC.TIMER

                         

                         

                        I have found that there were OLD entries in the hsql-database which are not updated correctly by the container.

                         

                        To retrace this problem:

                         

                        1. Make a stateless EJB with a method annotated with @Schedule (AutoTimer):

                         

                        package org.mybeans;

                         

                        @Stateless
                        public class MyEJB implements MyEJBLocal{


                        @Schedule(second="*/5", minute = "*", hour = "*", persistent=true)
                        public void firstSchedule()
                        {

                        System.out.println("Timer " + new Date() + " for bean " + this.getClass().getSimpleName() +" invoked!");

                        }


                        }

                         

                         

                        2. Deploy this bean within a war

                         

                        3. The timer works - firstSchedule gets invoked every 5 seconds.

                         

                        4. Now, lets change the ScheduleExpression:

                         

                        @Stateless
                        public class MyEJB implements MyEJBLocal{

                         

                        @Schedule(second="*/20", minute = "*", hour = "*", persistent=true)
                        public void firstSchedule()
                        {

                        System.out.println("Timer " + new Date() + " for bean " + this.getClass().getSimpleName() +" invoked!");

                        }

                        }

                         

                         

                        5. Deploy these changes (stop the server->update the old war->start the server)

                         

                        6. You will see, that the Timer is invoked every 5 seconds instead of every 20 seconds. Hence, the Container does not care about changed Schedule-Expressions. Is this a bug?

                         

                        7. Now lets change the name of "firstSchedule()" to "secondSchedule()" and deploy it again.

                         

                        8. You will see that a deployment-error is thrown with the message that the method "firstSchedule" (which is needed for the old timer) can not be found. Is this a bug?

                         

                         

                         

                        This is the log for the Timers after changing the ScheduleExpression of my Method "firstSchedule":


                        // I only updated the first Timer, so I expect 1 Timer instead of 2

                        16:00:32,113 INFO  [org.mybeans.MyEJB] timerService.getTimers().size() 2
                        16:00:32,113 INFO  [org.mybeans.MyEJB] timer.getInfo
                        16:00:32,113 INFO  [org.mybeans.MyEJB] timer.getSchedule */20  // the updated Schedule of my Timer - it is never invoked by the container
                        16:00:32,113 INFO  [org.mybeans.MyEJB] timer.getHandle() org.jboss.ejb3.timerservice.mk2.TimerHandleImpl@f870215c
                        16:00:32,113 INFO  [org.mybeans.MyEJB] -------------------
                        16:00:32,113 INFO  [org.mybeans.MyEJB] timer.getInfo
                        16:00:32,113 INFO  [org.mybeans.MyEJB] timer.getSchedule */10// the old Schedule of my Timer - it is invoked by the container
                        16:00:32,113 INFO  [org.mybeans.MyEJB] timer.getHandle() org.jboss.ejb3.timerservice.mk2.TimerHandleImpl@bc32ef40
                        16:00:32,113 INFO  [org.mybeans.MyEJB] -------------------

                         

                         

                         

                        To sum up:

                        Normally, I expect that the timer with "timer.getSchedule */10" will be replaced by "timer.getSchedule */20" instead of creating a new one. It is not replaced and a changed timer is registered as a new one but the new one will never be invoked by the container, only the old one.

                         

                         

                        I am using Jboss as 6 milestone 4.

                        • 9. Re: timer is not invoked
                          jaikiran pai Master

                          Wow, a lot of questions in one post Let me answer one by one.

                           

                          nimo stephan wrote:

                           

                          I have found that there were OLD entries in the hsql-database which are not updated correctly by the container.

                          nimo stephan wrote:

                           


                           

                          To retrace this problem:

                           

                          1. Make a stateless EJB with a method annotated with @Schedule (AutoTimer):

                           

                          package org.mybeans;

                           

                          @Stateless
                          public class MyEJB implements MyEJBLocal{


                          @Schedule(second="*/5", minute = "*", hour = "*", persistent=true)
                          public void firstSchedule()
                          {

                          System.out.println("Timer " + new Date() + " for bean " + this.getClass().getSimpleName() +" invoked!");

                          }


                          }

                           

                           

                          2. Deploy this bean within a war

                           

                          3. The timer works - firstSchedule gets invoked every 5 seconds.

                           

                          4. Now, lets change the ScheduleExpression:

                           

                          @Stateless
                          public class MyEJB implements MyEJBLocal{

                           

                          @Schedule(second="*/20", minute = "*", hour = "*", persistent=true)
                          public void firstSchedule()
                          {

                          System.out.println("Timer " + new Date() + " for bean " + this.getClass().getSimpleName() +" invoked!");

                          }

                          }

                           

                           

                          5. Deploy these changes (stop the server->update the old war->start the server)

                           

                          6. You will see, that the Timer is invoked every 5 seconds instead of every 20 seconds. Hence, the Container does not care about changed Schedule-Expressions. Is this a bug?

                          Since in step#1 you created a *persistent* auto timer to fire every 5 seconds, the timer is going to stay there in the DB. Chaning the schedule expression on the same method and deploying the app is going to create a *new* persistent auto timer. The previous one will continue to exist in the DB and will be fired every 5 seconds. I have been thinking about this scenario with persistent auto timers ever since it was implemented, but haven't completely decided on what to do with it. The idea I had was to compare the previous peristent auto timer for all the attributes including schedule expression and method while deploying and decide whether a new auto timer has to be created or not. I'll think a bit more on this and get it done by 6.0 CR1. In short, yes it's a problem right now if you change the schedule expression during redeploys. A workaround is to mark the auto-timer as non-persistent.

                          • 10. Re: timer is not invoked
                            nimo stephan Master
                            {quote}The previous one will continue to exist...I have been thinking about this scenario with persistent auto timers ever  since it was implemented, but haven't completely decided on what to do  with it. The idea I had was to compare the previous peristent auto timer  for all the attributes including schedule expression and method while  deploying and decide whether a new auto timer has to be created or not.  I'll think a bit more on this and get it done by 6.0 CR1. In short, yes  it's a problem right now if you change the schedule expression during  redeploys. A workaround is to mark the auto-timer as non-persistent.{quote}

                             

                            Maybe I can help you with your decision:

                             

                            1.

                            You know, "persistent=true" is the default setting. If I change a schedule of method x then this change is registered as a new schedule.The new schedule should get the flag "autofired=true" in the database where all previous schedule(s) of method x should get the flag "autofired=false" -> LIFO (last in first out).

                             

                            2.

                            One thing is definitly not good: If I rename the method x to method y than I get a runtime-exception because of the registered schedule ("Method x not found"). It should be possible to rename or delete methods which has a registered schedule with persistent=true.

                             

                            3.

                            The other thing is a lack of administration of schedules while application is running: It should be possible to view (or maybe stop) schedules while the application is running. Where can I find a kind of timer-administration in my JBOSS JMX-Console or in the admin-console ? I have to go to jboss hsql-database and make selects for traceablitlity or appropriate updates for stopping timers - this is not comfortable. It should be possible to view and clear timer-histories, to view and stop schedules in front of a Admin-GUI.

                            • 11. Re: timer is not invoked
                              jaikiran pai Master

                              nimo stephan wrote:

                               


                              Maybe I can help you with your decision:

                               

                              Sure.

                               

                               

                              nimo stephan wrote:


                              1.

                              You know, "persistent=true" is the default setting. If I change a schedule of method x then this change is registered as a new schedule.The new schedule get the flag "autofired=true" in the database where all previous schedule(s) of method x get the flag "autofired=false" -> LIFO (last in first out).

                              I understand what you are saying. But IMO, the previous timer no longer makes sense and should be completely removed (ofcourse by JBoss EJB3 implementation and not the user)

                               

                              nimo stephan wrote:


                               

                              2.

                              One thing is definitly not good: If I rename the method x to method y than I get a runtime-exception because of the registered schedule ("Method x not found"). It should be possible to rename or delete methods which has a registered schedule with persistent=true.

                               

                              Thinking more about it, I guess while creating the auto-timers during deployment, it would probably be a good idea to cleanup all existing autotimers for that bean from the DB. That way we won't have any stale irrelevant auto-timers. One thing to take into account while doing this would be how to deal with timeout events which happended when the server was down, of the previously persisted autotimers.

                               

                              nimo stephan wrote:

                               


                              3.

                              The other thing is a lack of administration of schedules while application is running: It should be possible to view (or maybe stop) schedules while the application is running. Where can I find a kind of timer-administration in my JBOSS JMX-Console or in the admin-console ? I have to go to jboss hsql-database and make selects for traceablitlity or appropriate updates for stopping timers - this is not comfortable.

                               

                              One of the goals of the new timerservice implementation is to provide exactly this functionality of monitoring timers from a console. The first step was to get a working implementation in AS6 so that users can start using the EJB3.1 functionality. Now the next step is to come up with the console. We'll be working on that pretty soon.

                              • 12. Re: timer is not invoked
                                nimo stephan Master
                                {quote}the previous timer no longer makes sense and should be completely removed{quote}

                                 

                                Indeed, this is best solution!

                                 

                                {quote}it would probably be a good idea to cleanup all existing autotimers for that bean from the DB{quote}

                                 

                                Yes, that is good!

                                 

                                {quote}One thing to take into account while doing this would be how to deal with timeout events which happended when the server was down{quote}

                                 

                                For my money, delete these timeout events as I am no more interested for all my stale timers. But this should definitly noticed in the documentation.

                                 

                                {quote}to provide exactly this functionality of monitoring timers from a console.{quote}

                                 

                                Thats fine.

                                 

                                 

                                Thanke you!

                                • 13. Re: timer is not invoked
                                  Rohan Emmanuel Newbie

                                  Hi Jaikiran Pai,

                                  This has been resolved?    i still noticed that  old persistent timers was still getting tirggered when i undeploy and redeploy the timer with new schedule in wildfly 10.0.0.Final.