Hi All,
One of my IS trigger has Max number of concurrent threads = 4 and its also set to Retry on error. Subscribing service is sending record to two different systems based on some value (which we can’t set at trigger filter). Incase any system failure, I rethrow an exception and then it will be retried after 15 min interval (as specified in Trigger Retry settings). If there are 4 docs already failed in one system and piled up in the queue for retry, now any subsequent docs (after queue size reach 4 which is equal to Max concurrent thread) published to broker are getting queued and not being processed, which may be for different system that is up and running.
It seems me when each thread processed one doc and failed then it will be blocked for retry and can’t process any other doc. If anyone knows about this please confirm me the same.
Also would be great if anybody can provides an idea how can I keep processing all the docs which are being placed in trigger queue even after the Max execution thread number of docs (4 in this case) failed and retried. I don’t want to hold one system’s data due to other system is down.
Thanks,
Joy
Hi Joy,
you are correct the trigger is preserving the document order so until the first one to error goes through the others will not. The larger issue here is your subscribing service. It should only handle the update to one system. You need another trigger + service to handle the other type of update. This is a 1 to many subscription pattern. Since you are willing to perform the update on the other system even the your other system is failing, it shows the decoupled relationship between the two.