Graceful shutdown and chained MDB's

[michaelhansenonecom]

We are having a problem with MDB's getting lost during graceful shutdown.

The problem is that we have MDB's that creates other MDB's, and it appears that sometimes the last running MDB during the shutdown is neither allowed to add a new MDB, nor is it allowed to end up in the DLQ.

The MDB's are created this way for several reasons:

- To handle each external system asynchronous from each other, so one service being down not causing problems for the whole chain.

- To handle large imports, that takes too long to process in a single transaction (one MDB spawns a new identical MDB, just with fewer records to import).

Is there a configuration that would allow us to continue using the current chained MDB, without loosing the MDB's during shutdown?

Setup: is 2 Wildfly 10.1 servers in a cluster, where only the front-end is clustered.

Thanks in advance for any input.

[mnovak]

Hi Michael,

I'm not sure what is meant by chained MDB. Could you provide example?

Thanks,

Mirek

[michaelhansenonecom]

Hi Mirek

I basically means one MDB that starts one or more other MDBs.

One example is that we have some large file imports, where each line requires some processing. So what we do is we import the file, and do minimal parsing, then adds all the lines to a message to a MDB. The MDB then handles a number of the lines (f.x. 200), and then create a new (identical) MDB with the rest of the lines. In this case a file with 1000 lines would result in 5 MDB's running one after another before the processing has finished.

Another example is for some orders we need to contact several external services (both in-house, and really external system). The basic order is then handled, and it then creates a MDB for each step that might result in calling an external service. Then if one service is down it just rollbacks the single step, and the service then is retried until it goes through (or the message ends up in the Dead Letter Queue).

Regards

Michael

[mnovak]

Thanks Michael for patience but I'm still fighting with your naming convention. I'm confused by "...MDB creates MDB...". It's not possible (or at least it's anti-pattern) to create MDB from MDB. Probably what you wanted to say is that you create a message with 1000 lines and send to queue. MDB consumes this message and processes 200 lines from it. Takes the remaining 800 lines and creates a new message and sends to the same queue. The same MDB (but another session of the MDB) consumes this message and processes another 200 lines. Is my understanding correct or "...MDB creates MDB..." means something else.

Mirek

[michaelhansenonecom]

You are correct, the MDB does not create a new MDB, the code called by the MDB creates new messages for same (or in case 2 another) queue.

My problem is that apparently during shutdown when the message is handled on the queue, it is not able to add new messages to queues, nor does it end up back in its own queue or the dead letter queue.

Regards

Michael

[mnovak]

Great, now I understand :-) afaik if WF10 is cleanly shutdown then it waits for all XA transactions to be finished. Thus I would suggest to annotate your MDB by (or modify ejb-jar.xml deployment descriptor):

@TransactionManagement(value = TransactionManagementType.CONTAINER)

@TransactionAttribute(TransactionAttributeType.REQUIRED)

Then consumption of messages by MDB (calling onMesasge(message) method) and sending new message to queue will be done in XA transaction and server will wait for it to finish. Also if it happens that processing would be forcibly interrupted, for example server crashed or is killed then after restart, all XA transaction will be recovered (either rolled back or committed).

Here make sure that you're using "java:/JmsXA" pooled connection factory for sending message to queue from MDB.

This should reliably handle both the use cases you've described above.

Now the 2nd thing: "Setup: is 2 Wildfly 10.1 servers in a cluster, where only the front-end is clustered."

Do you think that there are 2 WF10 servers in Artemis cluster? What is the front-end here?