Trigger Task Option

Question

In the Trigger Task; there is an Option Do not start a new execution if one is already active
In the Documentation this option Do not start a new execution if one is already active allows you prevent a Pipeline from running again if a previous execution of that Pipeline is already running.
Does this option ignore the second request if it is sent at the same time or does it queue it up?

tlikarish · Answer

If the option is enabled and concurrent requests are made, then it is possible for both requests to start a pipeline executing. The feature was originally only for tasks that were scheduled, which is why this only prevents another one from starting if there is already one running.
Although, we’ve heard some feedback about changing the behavior such that only one trigger task could start even if there are multiple requests made simultaneously, so might be looking into that soon.

ndayalani21 · Answer

So if this option is enabled and concurrent request are made; will it ignore the second request or does it queue it up?

tlikarish · Answer

If the requests are made close enough together, then both requests will queue up and start executing.

cstewart · Answer

If it is essential to ensure that only one runs at a time, you could use the public API to find out if one is already running, or use some other method to gate execution.

stephenknilans · Answer

The problem with that, is that people generally don’t care if one is running.  They just don’t want two to be running at the same time.  So the ONLY place the logic can go is in the acceptance of the api command.
The logic should be OK,  got a trigger, NO OTHER TRIGGER SHOULD BE ACCEPTED UNTIL COMPLETION OR FAILURE.  And if you do have a queue up feature, it should do the same thing in the same place, except that the trigger should be remembered for after the current one finishes.  There probably should be some consideration for a failure in there.
I always figured this is for the problem ALL schedulers have in that nobody knows when something will finish, like the time a DBA kept incorrectly recreating a table I needed, and making it take almost 150 times as long!  My task that generally took 30 minutes took about 3 DAYS after he recreated the table.  Had two processes started at once, it could have taken substantially longer and/or potentially corrupted the table’s data.  Someone also could have been looking at the table, which could have delayed it substantially.
I was even at a place where they thought their network ran 45 times the speed that it did.  It wasn’t until we NEEDED that speed that the question was raised and, evidence in hand, we confronted the one guy that could tell us the truth.  The BUILDING had the throughput we were told, and we were allocated only a small part of THAT.
One place I was at had two complimentary systems, to backup.  They figured that if A impersonated B and B did the same with A, that there would be no problem.  If they had a complete failure of a system, maybe it might have worked.  A took over for B which took over for A which took over for B, etc……   Everything came to a screeching halt.  We never found out what started it, but once started, those systems were just trying to boot until a person came in and STOPPED it!
One place even got a certain product.  I don’t know if they ever fixed the bug or whatever.  The manager had to crash the system every morning and reboot.  It was so slow that he couldn’t do it properly, and the garbage collection in that software obviously had problems.
So yeah, sometimes it is a good idea to have some sort of safety device.

Forum Discussion

Trigger Task Option

5 Replies

Recent Discussions

Google Sheets Subscribe questions

Basic string transformations not working

Can we generate XML file in pretty print format using native snapLogic snaps?

Multipart Reader failure - 'content-type' was not found

Unable to write sldb file to file system