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