Filepolling in cluster


I’ve searched the forums and the documentation, but I cannot find any information about whether Filepolling ports are cluster safe in 6.5 or not. Does anyone here know?

If you like to have your server logs swamped with errors that file cannot be accessed, then you can call it cluster aware :stuck_out_tongue:
At least that’s what happens to us.

No dupes, but a hell lot of errors when both IS’es try to access the files at the same time.


File polling is officially not cluster-aware in version 6.5. Here’s one SR from Advantage that states this:

  • Percio

I have successfully pointed 2 IS instances (not in an IS cluster–just a load-balancing cluser) at a single shared directory and had them both successfully processing files. As swl noted, you’ll see file not found errors in the logs (if you haven’t changed logging settings from the defaults) but those can be ignored.

Currently we are runnnig the filePolling in an IS cluster, and just as you stated it is not “cluster aware”, we get the same errors as you. It actually seems like it is “cluster safe” though, meaning that the files are synchronized which prevents them from being picked up by more than one node. So I believe just like reamon that we can just ignore the error messages, but I still plan to replace the filePollling port with some custom polling code invoked from a scheduled service (which are cluster aware).

Thanks for all answers.

The reason it works is because the first thing the file poller does is rename the file to move it to the work directory. With the naming scheme, name collisions are avoided which is good.

I did find, however, one caveat. In testing things out, I had 2 Windows boxes each running IS and a file polling. The directory being polled by both was on one of the Windows boxes. This caused problems. I don’t remember the exact error message but there was definitely file access contention.

As long as the directory being polled is not on the same Windows machine as one of the IS instances, things worked just fine.