0 Replies Latest reply on Apr 22, 2011 10:43 AM by Andrew Murphy

    Tip for using JMS and javax.ejb.Timer

    Andrew Murphy Newbie

      Hi all,

       

      I've have implemented a polling service which uses JMS messaging and a javax.ejb.Timer, and thought I'd share my learning experience.

       

      I have an EJB which sends an asynchronous message to a JMS queue. This message is handed off to a MDB which initiates a file download service. The EJB providing this download service is tasked with polling a third-party web service every n seconds until the document sought becomes available, and uses a javax.ejb.Timer for this purpose.

       

      Using Arquillian to test the JMS message sending was relatively straightforward, but in the above use case Arquillian undeploys the test bundle as soon as the MDB has invoked the EJB polling service. Crucially for me, this was before the container had been given the opportunity to trigger the polling timer (this being a container managed service and therefore outside of the control of Arquillian), so I had no way to verify the polling timer was working as expected.

       

      The answer lay in deferring the test bundle undeploy process, which I achieved by obtaining the test Thread and putting it to sleep. In pseudocode this is what I did:

       

      @Test

      public void getCompanyDocument_v1_0Test() {

       

          logger.info("Testing getCompanyDocument");

       

          //Construct JMS message

          documentManagerBean.scheduleDownload(message);

       

          // Defer undeploy process to give container chance to trigger timer

          try {

              Thread.sleep(20000);

              logger.info("Starting undeploy...");

          } catch (InterruptedException ie) { }

       

          //Assert download file exists

      }

       

      It really is that simple!

       

      One word of caution. I have used a non-persistent timer in my polling service which works well in a test environment. If you use persistent timers then be sure to call timer.cancel() before Arquillian starts to undeploy, otherwise you may get multiple persistent timers firing when you start up your next tests.

       

      Cheers, Andrew