0

Using wildfly 15 and only JavaEE (no spring) I need to consume messages from a Jms queue, in order and create for every message a new job using Jbatch, in sequence, without job overlap.

For example:

JMS queue: --> msgC --> msgB --> msgA

Jbatch:

  • on receive msgC, create JobC, run jobC
  • wait for JobC to end, watching JMS queue, on receive msgB, create JobB, run JobB
  • wait for JobB to end, watching JMS queue, on receive msgA, create JobA, run JobB

It's possible to achieve this ?

Justin Bertram
  • 29,372
  • 4
  • 21
  • 43
Vokail
  • 630
  • 8
  • 27
  • What causes the various messages (i.e. msgA, msgB, & msgC) to be put on the queue? – Justin Bertram Mar 11 '19 at 16:33
  • A request from a REST services, I must ensure that every request is put on a queue, because actually handled by a (potentially) long job – Vokail Mar 12 '19 at 07:33
  • sounds like you would only call Consumer.receive() AFTER JobC, JobB ended ? – Axel Podehl Mar 12 '19 at 09:51
  • OK, but what triggers the request from the REST services. The link between the messages and the jobs is pretty vague at this point. Clarification would help. – Justin Bertram Mar 12 '19 at 13:11
  • You are right. User request from a webapp trigger REST request, then add request to JMS queue. – Vokail Mar 12 '19 at 13:12
  • This question is hard to help with since it's too high-level and removed from the code to comment on specific coding techniques or component choices, but at the same time there's not enough detail at a purely architectural level (e.g. how much you know about what messages will be put on the queue, in what order and in what volumes) for someone to help from that angle. – Scott Kurz Mar 13 '19 at 21:59

1 Answers1

0

Processing messages in parallel or the right sequence is some standard behaviour in JMS clients and you can simply configure to do it right. That's why you have a queue. Just ensure you have only one message driven bean working on it, which should ensure you have one process and nothing running in parallel.

If you handover the task to the batch API, a different set of threads will process it, and now you need to manually ensure one job terminates before the next can start. So your message driven bean would have to poll and wait until the batch executed.

Why would you do this as it just makes your life more complicated? I believe you could still benefit from the easy orchestration of batch steps, the restart capability or some parallel execution which you would have to cover in your message driven bean yourself.

Queeg
  • 7,748
  • 1
  • 16
  • 42
  • I'm looking for a solution that let my life be more simple, not complicated. What I'm not understading is if there is a "frame" where JMS queue and batch job can work together in a serial way. Note: I've solved this using custom code, but of course I'm interested in a "standard" approach too. – Vokail Nov 02 '20 at 08:17