My apologies for the long-winded-ness of this post.

My issue is that Timeout settings seem to be ignored on Remote Execute tasks.... explanation of how we use the task and task configuration follows.

We use the Remote Execute tasks across 2 domains. The PARENT here is VisualCron running on 1 domain and does the Remote Execute call to the CHILD which is a domain controller on a 2nd domain. This overall works well except when it doesn't.

The remote tasks are pretty simple. We are simply calling CMD.EXE with some parameters on the CHILD from VisualCron...which in turns runs batch files to do the work... The task cycles through a list of new "people" performing tasks on the CHILD for each one in a loop. Some tasks create folders in the proper places... One creates the user account... another changes security settings. We run this job once per hour.

VistualCron doesn't seem very capable of reliably detecting failures of the Remote Execute tasks.. or even if they launch at all... Sometimes the Remote Tasks don't seem to even run but VisualCron sits and waits for it to complete ... and sometimes the tasks errors out and closes on the CHILD and Cron does not recognize it as the case. These aren't issues as we've developed work arounds to this... We simply don't mark the item any item that fails as complete and the next run (1 hr) will pick it up and try again.

However, to combat this lack of detection we implement timeouts to keep the loop flowing... in the event of success our item is marked completed and never touched again.. failure it's not marked and repeats all steps in the next run of the job as I said above...

The problem is that the TIMEOUT period never expires. Each Remote Execute task is set to time out in 30 seconds. Successful calls normally take 3 seconds. In the event of failure the timeout simply never occurs.. and the task will wait a far longer duration before failing.. and sometimes it NEVER fails at all and just waits forever.

Our last 2 failures took 12 mins 50 seconds and 12 minutes 53 seconds before reporting failure. In this case, the tasks on the CHILD never actually started. I can see that no instances of CMD are being run on the CHILD. Both results returned error code 77777 with "No output" for the Output (standard) and the Output (error) returns "Exception in Task: The remove procedure call failed. (Exception from HRESULT: 0x800706BE) Exception in Task: Non zero exit code".. Success simply returns "Process with Id: XXXX was completed successfully." Additionally I verified that the work the tasks were supposed to perform was not completed.

The HRESULT code seems to come back to a "driver error" as I'm sure that's related something with the RPC driver in windows... but I'm not interested in fighting that.. as we have a resolution that handles retries.

I am interested in FORCING the TIMEOUT to actually time out. If the task does not complete in 30 seconds it has failed. I do not want to wait 12+ minutes for the task to complete... or in the rare happening I have to manually stop the job because the task waits forever... In these cases I am forced to restart the entire visualcron service... clicking on stop task or stop job has no effect. I use the "Server [On/Off]" option inside Visual Cron and restart the client before the task shows as stopped.

Waiting 12 minutes on failures for more than 5 runs of the loop would mean that the job is overlapping start times.... when instead it should never run more than about 5 minutes if every single RPC failed at timeout.

Is this lack of timeout a bug or as I missing something important?
It seems to be a bug since I can't even force the task/job to stop without restarting the service...

Another note: we use the "wait for completion" option on Remote Execute... since our documentation doesn't have any information about this option on remote execute we assume that it means do not run the task asynchronously... and we do want to wait since we don't want the loop to try and run all of these task in a loop bogging down our domain controller with work. Complete one and move to the next is our proper workflow. However, we do want the timeout to actually have an effect. Does this cause the task to ignore the timeout? If so this seems odd as it lets me set both of them without issue.

Which version are you using?

---

Which version are you using?

8.1.2 build 36464

Ok, please upgrade as we have fixed this issue.

---

Ok, please upgrade as we have fixed this issue.

We upgraded. Whether or not it fixes the problem is yet to be determined but upgrading should not be the solution to things like this. The reason? Because upgrading broke 3 other tasks that have been running reliably for some time. In some cases it appears that it added additional flow events to my tasks.

For instance:
JOB X:
Task1:
On Error, Goto Tasks ERROR
On Success, If output not equal '0' (Int64) - Goto Task DATA COLLECTION
On Complete, Stop Task

It seems that the upgrade added an additional On Success flow that said Continue with next task... which caused tasks to run that should not have alerting to error conditions when none existed... so even if the 1st success didn't jump the 2nd success caused the on complete to not stop the flow.. and downstream tasks continued to fire.

We removed the 2nd On Success and ran the job succesfully. I opened it back up a few minutes later and the second On Success had returned.

This is not the first time an upgrade has broken tasks for us... and "upgrade" will no longer be accepted as a solution.

I think we are talking about different things. Remote execute - wait for complete is one thing and Flow->On complete is another thing.

Regarding Flow you must have, at the moment, one One Success that leads to something directly (without conditions). If it is not there we will add it.

---

I think we are talking about different things. Remote execute - wait for complete is one thing and Flow->On complete is another thing.

Regarding Flow you must have, at the moment, one One Success that leads to something directly (without conditions). If it is not there we will add it.

Flow and remote execute are not the same thing, true, but the solution to upgrade to "fix" it caused more issues that we fixed which is what I was explaining.

If this application is going to make changes to our processes for no reason then I feel the need to see out a different solution. These newly broken tasks were working 100% of the time without intervention...and the upgrade broke them.. and you're telling me that this is by design. This is NOT acceptable.

I think we are talking about different things. Remote execute - wait for complete is one thing and Flow->On complete is another thing.

Regarding Flow you must have, at the moment, one One Success that leads to something directly (without conditions). If it is not there we will add it.

Flow and remote execute are not the same thing, true, but the solution to upgrade to "fix" it caused more issues that we fixed which is what I was explaining.

If this application is going to make changes to our processes for no reason then I feel the need to see out a different solution. These newly broken tasks were working 100% of the time without intervention...and the upgrade broke them.. and you're telling me that this is by design. This is NOT acceptable.

I think, to resolve this, we need the original Job exported to us and a description of the scenario (based on current flows) to be able to reproduce this. Please send it to support@visualcron.com - it just sounded like something was missing from your initial flows (even though they worked before) - but we need an example to confirm this.

---