publish - subscribe and document loss


I’m still learning broker handling, and I’ve stumbled on a something. Lets say we have a basic pub-sub system, a flow service (iPublish) just to publish a document to the Broker. I have a trigger (iAmTrigger) to watch for the specific doctype (publishMe), and passing over to a handler service (iAmHandler). Basic as it gets.

Thinking forward, i kinda tried what happens when the handler service crashes.I was curious what happens to the document. I noticed, it gets rejected, and so deleted.

Is there a way, to ensure the documents are not lost in these cases?

the documents are not lost in this case. Messages picked up by trigger is not discarded until the invoked service completes execution. you will find more information in pub-sub guide, guaranteed delivery guide, etc.

It depends on what type of Document you are publishing ( volatiel/guaranteed ). Plz go through documentation for more details and to get clarity on this which is a very interesting mechanism in wM.


For better idea and understanding read the pub-sub guide…:slight_smile: Good luck

If you face any issues in implementation please post us back.

well yes…

As I got a better understanding of our original problem … (yeah communication problems are out of the juridiction of this forum I know :slight_smile: ), I have to manage documents, that are causing the handling services to crash.

Nevertheless, with the proper use of pub.flow:throwExceptionForRetry, I managed to retain the documents on the Broker, with Unacked status. Is there a way to resend, or ever better, edit before resend these docs ?

1 Like

You, Can use pub.flow:throwExceptionForRetry and at the same time you have specify number of retries the trigger call the subscription services. Once the maximum retries has reached you can make the trigger to throwAnException (It will tag the document as failed, after that you can resubmit the document via MWS, you can also edit the document). or Suspend and retry later (This has to be followed by a resource monitoring service which will enable the trigger again).

  1. Make the document as Guranteed

  2. You can have a Finally block the handler service and invoke throwExceptionForRetry service

  3. Create a resource monitoring service to check the crashing scenarios and suspend/resume triggers so document are automatically resumed for processing


I would have thought the best solution would have been to find out why the handling service is crashing and fix that.

My 2 Cents…

If the service crahes with an uncaught fatal exception (nontransient error), the document will not remain in the queue. For this case set the logging in the processing service to log on error and save pipeline on error. This gives you the possibility to resubmit and even edit (but use this with care) the processing from wmMonitor.
Standard way for transient errors is alreayd described by Veera. Using a try catch block and the throwing an exceptionForRetry is also good practise.