Hi

We have a Remote file trigger with the below settings (connection is removed). Expiration is not enabled:


Last week the remote site had an error rendering the connection unusable a day or so. The trigger responded as follows (according to the VC server log):

• When the connection problem started a retry was perfomed every 30 seconds
  
• The connection was tried 61 times totally (the first error and 60 retries I presume) and ended after 30 minutes (60*30 seconds obviously).
  
• After the 30 minutes the trigger was inactivated! Here is the final logging:
  

  Err Unhandled exception occured in Remote file Trigger: SFTP component not connected
  Err Trigger error: SFTP component not connected
  Debug Trigger was expired and inactivated

  
  

Questions:

1. Why is the trigger inactivated when no expiry is set? This seems like a non robust architechture: because of external problems we have to enable the trigger again manually! Or am I missing something?
   
2. Why is the log reporting retries every 30 seconds when reconnect interval is set to 10? This is not a serious problem but still strange.
   

Thank you.

Server: 8.3.4 (I have not created a test case for 8.3.5)

1. Expiry is not related to this. What is related is the number of retry time and retry interval. We might add a "infinite" retries later but kept this so we at least have some control over it
2. this sounds strange. We don't see any trace of 30 second interval in the code. We only used the values specified in the Trigger. We will try to reproduce this later when we have more time over.

---

Thank you for the answer.

Why would you want a trigger to disable itself by default? I mean notifications about nonworking triggers are great, but if I create a trigger IMHO it should never disable - unless of course I specify it explicitly eg. setting an expiration policy. Now I have to explicitly specify a very high number of retries to make sure that the job survives an outage from an external partner lasting several days (not to say months). After all the less we need to interfere with VisualCron the higher the value of the product. Automation is the goal here also concerning surviving suboptimal conditions. Put another way: when would I want a trigger to disable automatically? My answer: Only if VisualCron somhow could infer that the connection would never come up again - which is rather unlikely.

The reason why you may want to disable is that you might create a Trigger with wrong settings and then you will not know as it will try to forever get things right with retries when the problem is not really on server but settings related.

---

But if you upgrade you have the "No limit" option in the File trigger and it will wait forever.

---