If you inside a doAfterCommit lambda initiate a new message using the default initiator, it seemingly ends up using the ProcessContext of the stage processor it just exited. This is probably due to not having cleared the ThreadLocal keeping the context.
So, it seems to do the db.commit() and jms.commit() just fine, and then probably run the doAfterCommit lambdas, and then clears the ThreadLocal process contexts. If this is the case, the doAfterCommit must be moved outside. Or possibly be run by a separate thread - which is a hack to fix this now (start a new thread inside the doAfterCommit lambda).
If you inside a doAfterCommit lambda initiate a new message using the default initiator, it seemingly ends up using the ProcessContext of the stage processor it just exited. This is probably due to not having cleared the ThreadLocal keeping the context.
So, it seems to do the db.commit() and jms.commit() just fine, and then probably run the doAfterCommit lambdas, and then clears the ThreadLocal process contexts. If this is the case, the doAfterCommit must be moved outside. Or possibly be run by a separate thread - which is a hack to fix this now (start a new thread inside the doAfterCommit lambda).