Yes - it should be possible - on detecting an error use the msg.toFront option to push the message to the front of the queue in the delay node.so it can be retried. Of course detecting the failure, saving the original msg, how many times to retry need to be considered
1 Like
Also necessary to include the timeout between retries. I think for these situations my guaranteed delivery subflow is the way to go.
1 Like
If you donāt flush and just use toFront then the existing timing is msintained
Oh, I see, use the delay node timeout for that (though then it can't be set to a very large value but that doesn't matter). I think that should work. Still necessary to save the message that is in the pipleline of course, so it still ends up being significantly more complex then using the subflow, which also has the advantage of being configurable via the subflow properties. Also it can save queued messages in persistent context which may be a requirement.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
