Trigger Task Option

[ndayalani21]

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?

[stephenknilans]

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.