Knowledge of redelivery

[bill.burke]

Was thinking about the combination of JMS and jbpm today through the enterprise archive and the MDB command service that comes with jbpm.

Looking at the code, there is nothing that takes into account a message redelivery. User code would quite probably want knowledge that a Command was a redelivery.

Maybe a boolean method wasRedelivered() and setRedelivery() on the Command interface would be a good addition? Also, this flag should be set as a transient variable of the process instance by appropriate Command implementations. Thoughts?

[kukeltje]

Bill,

Do you have any usecase? We use jms internally in our company and have never been interested in these kinds of info. It is just like someone that sends a package via DHL/UPS/TNT is not interested in how many times a guy/girl went to the house an no-one was there. You only want to know it did or did not get delivered.

The setRedelivery() could be interesting. Have to give it more thoughts thought.

[bill.burke]

I'll answer your question with a question: Why would a JMS receiver be interested on whether or not a message was redelivered? Maybe a node does not support redelivery of the message. Maybe a node needs to take additional action on a redelivery.

Maybe you are executing a remote service that doesn't support transactions and that may have been executed. So you'll want to transition to a different state that compensates for this.

Since jBPM uses a one size fits all approach for transitioning through JMS you don't have the option of tweaking message delivery semantics on a per node basis.

[genman]

The redelivery flag is not necessarily a useful thing to have access to.

If the JMS provider restarts, it might actually be false even though the message was in the middle of processing earlier. Or, the redelivery flag might actually be set to true even if your MDB.onMessage() was never reached. This could happen if the inflow adapter loses a connection to the JMS provider on another machine.

The spec also says: "If a client receives a message with the redelivered indicator set, it is likely, but not guaranteed, that this message was delivered to the client earlier but the client did not acknowledge its receipt at that earlier time."

JBoss provides a redelivery count as well (I originally wrote this feature) which is persisted, so is a little more reliable. But I wouldn't rely on this for performing transaction compensations.

If a node needs to take additional action on redelivery, for example, then the best thing is to check every time a message is received that that action was or was not performed.

What might be useful to provide are checkpoints that are persisted (not as the MDB transaction context) that indicate some non-transactional resource was used earlier.

[kukeltje]

If a node needs to take additional action on redelivery, for example, then the best thing is to check every time a message is received that that action was or was not performed.

You mean some 'duplicate elimination' on the receiving end? That is exactly what we do (and what e.g. the ebMS specs say as well)

What might be useful to provide are checkpoints that are persisted (not as the MDB transaction context) that indicate some non-transactional resource was used earlier.

and then use e.g. compensating actions? That is at least what we do.