Sorry if that is the wrong place for this question.
We have a test that should send a message to MQ-server, then the MDB listener invokes EJB service method, and then I should wait for a message to be processed. Only after that I should assert tables in the database. So far, the only solution I've found is to put the thread that invokes the test method to sleep for some random time, but that's definitely not the right way to do it. We also use Groovy throughout our batch tests. So maybe some scripting would help. I think there should be some elegant solution to this problem. Maybe I could use jdb to connect to remote VM?
Would appreciate any help.
I try and avoid randomness in my tests. One technique is to have a loop where you sleep for X milliseconds/seconds and retry 3-5 times. Then fail the test if you don't get a message back. X varies based on your expected time to process and put the message back on the queue.
Thanks for the reply, Jeanne.
Unfortunately in my case a message is immediately removed from a queue after processing. Though I can check the lock variable (which is set in the database when the process is started and should be removed when it's finished), I think that might be expensive. The best case scenario would be to intercept MessageListener onMessage method, but I'm not sure how to implement it without Spring or AspectJ. Still I'm thinking about attaching jdb to remote process, although I understand that it's not a nice approach.
Actually, I was wrong, when I wrote that process leaves a lock flag in the database. Another thing that I tried was to send a badly-formatted message to MQ server right after the correct one. I expected that it would be taken from queue, right after the first message is processed (so if we check that queue is empty, then we're good to go). But I was wrong here again (I'm not sure how it works, but seems that the processing of messages might be done in separate threads.
And then I recalled that the whole processing method was wrapped into one transaction, so my final decision was to check whether the table is empty. It might be not reliable, but at least it works for now