Hi Henrik

Running Version 6.1.8.

We have discovered an issue with a File Trigger being inactivated which is really quite strange. This has actually happened a number of times now and caused us a number of issues with customers.

Server log gives the following:

013-03-21 12:32:43 Err Error watching directory, err: Access is denied
2013-03-21 12:32:43 Err Error watching (ReConnect) directory, err: Error reading the C:\upload\JT directory.
2013-03-21 12:32:53 Err Error watching (ReConnect) directory, err: Error reading the C:\upload\JT directory.

{the 'Reading xxxxxxx directory message above is repeated a number of times}

2013-03-21 12:42:53 Err Trigger error: Access is denied
2013-03-21 12:42:53 Debug Trigger was expired and inactivated

What is strange is that it is failing on a local C: drive folder which shouldn't have any issues with Access.

It also seems quite random, in that there is nothing else happening that may be causing the error.

Have you any ideas what could be causing this?

Cheers

Andy

I am thinking various processes that may block this like;

* antivirus
* backup tools
* other applications

Those are the only things I can think of right now.

---

I'd be interested to know what your App/System Eventlogs look like on that system. It doesn't say what operating system you're running, but I know on some of our older 2003 servers (not VC related) we've had some issues with NonPaged Pool memory usage that can cause any number of issues including locally accessed files not working properly to locking the system up, etc..

Otherwise I agree with Henrik, likely AntiVirus. If its happening often and is fairly repeatable, i'd try setting your AV product to not scan that folder and see if the issue goes away. If it does, i'd talk to that AV vendor and/or consider a different product.

Brian

Thanks Brian - I will certainly look into AV as I know this has caused other conflicts elsewhere before. Our server is actually a managed server so we have bounced back to the hosting company to investigate anything that happened on the day/time the failure occured.

Cheers

Andy

Sorry this is a tardy response . . . . and not a direct answer to those log entries but . . .

We have also had a number of issues with File Triggers to shared folder locations intermittently going inactive (we use Sophos AV).

We never really got to the bottom of it (Shared Folder issue, Network, or Virus Scanner).

Our conclusion (and solution) was that the default trigger settings were way too aggressive by default 5 reconnect attempts 10 seconds apart <basically 1 minute tolerance> for anything but local files. We bumped this to > 10 minute tolerance (5 reconnect attempts but 120 second reconnect interval). This has resolved our issues (we may still get a trigger expired on occasion but it is now more clearly related to some sort of system outage / event).

We now do this on all our file triggers as a matter of course.

This is generally enough time (for us . . . YMMV) to also tolerate server reboots (particularly VMs).

I would suggest you give both those a try to increase your trigger tolerance to short, intermittent interruptions (regardless of cause). . .

We also had a VC Job for a while when we were having problems on the relevant server which Alerted / Emailed on the VisualCron / Trigger Expired event but we have since disabled this as the above changes have settled down our unexplained trigger expired happenings. This might be an idea as it sometimes isn't until the client calls that you realise this has occurred !

EDIT: VC Version 6.1.4 (Upgrade to 6.2.2 is coming soon)

========
We're very thorough in our Adding and Deleting of our jobs and/or triggers when servers are retired, down for maintenance, etc.....

HOWEVER... I would 'love' an option to NEVER disable a trigger vs just limiting the number or retries and interval between retries.

I have a really stupid reason for wanting the trigger to never disable itself in a few occasions. I don't like how i've had to do this, but we have a file-creation trigger looking at a folder that contains a dated variable. This means that the below path will not exist for a while, immediately after midnight and therefor the retries begin.

\\Server\Sharename\folder\{DATEFORMAT(yyyyMMdd)}\trigger.txt

Worse than that, I asked and do not have approval (yet) to have a job that just goes and creates these daily dated folders immediately at Midnight or a few minutes prior. Their system has to do it (likely doesn't, but they don't know for sure what happens if it already exists). SO, this folder gets created by their system the first time someone from that department logs into their app for the day. This might be at 8am, could be at 6am, etc... So i've got an unknown amount of time that I have to allow this trigger (and subsequently VisualCron) to be unhappy about the path not actually existing. I have the reconnect attempts set to 500 and interval set to 60, which gives me a little over 8 hours.

Even with all this, the trigger still disabled itself. Maybe the server/share existing is treated differently than a specific folder not existing in the path specified?

It would just be helpful for (admittedly) stupid, very specific, jobs to have an option to NEVER disable the trigger, ever. There are likely reasons this is not available and i'd love to hear them. I've only got one job like this and do not plan on letting it happen again, but these were the requirements given to me by the Business Unit, I made it happen without realizing the consequences.

Brian

Server log gives the following:

013-03-21 12:32:43 Err Error watching directory, err: Access is denied
2013-03-21 12:32:43 Err Error watching (ReConnect) directory, err: Error reading the C:\upload\JT directory.
2013-03-21 12:32:53 Err Error watching (ReConnect) directory, err: Error reading the C:\upload\JT directory.

We've also noticed these errors on a C:\ drive with VC Server 6.2.0, as well as on network drives with file triggers (create).

We are behind a firewall on a dedicated VC machine, i.e. no antivirus, no backup, no other applications.

Is there any explanation?

Or, as a workaround, is there a 'good' way to handle these errors? They occur frequently but intermittently - so we get lots of notification emails but the job is actually running effectively in between the errors.

Many thanks

As bbusse said you need to increase "On error reconnection Interval and attempts" values. The default number of times that VisualCron try to reconnect (in the event of a network error etc) might be very short time - so try increasing these values.

---