I have a service in Livecycle ES that processes PDF files, via a WatchedFolderEndpoint. When the process is complete the original files are no longer needed. I have the watched folder endpoint configured to only preserve on failure, and that is working correctly. The issue is that the files that are in the stage folder never get deleted, even after they have been processed. I know that the files have been processed because I can see them in the database, which is the last step of the service. The folder is on a remote (to the livecycle server) path, and I don't think its a time issue because there are folders in there from the previous day.
My question is this, Why are the PDFs staying in the stage folder after being processed? The watched folder endpoint is used to pickup documents that have been placed there by scanners and we get around potentially 800~1000 a day, so this issue could eat up a lot large amount of disk space very quickly. Right now its manually being deleted periodically.
Here are the settings for the watched folder endpoint:
Path = \\xxx.xxx.xxx.xxx\SomeFolder\AnotherFolder\
Asynchronous = True
Cron Expression: = 0/20 * * * * ? (Every 20 Secs)
Repeat Count = -1
Throttle = false
Username = SuperAdmin
Domain = DefaultDom
Batch Size = 15
Wait Time = 1000
Include File Pattern = *.pdf
Result Folder = empty
Preserve Folder = empty
Failure Folder = failure/input
Preserve On Failure = true
Overwrite Duplicate Filenames = false
Purge Duration = -1
Solved! Go to Solution.
Views
Replies
Total Likes
We found this same issue where the stage folder filled up to about 29,000+ folders and files and the CPU utilisation went to 100% and never dropped. The server system process was constantly trying to parse the stage directory and as it filled up was thrashing the CPU & disk.
You HAVE to set the result directory parameter in the WatchedFolder Startpoint Endpoint configuration even if you arent using it and set it to purge after 1 day (or anything other than -1 which is never delete). This way the stage folder will self-delete.
Views
Replies
Total Likes
We found this same issue where the stage folder filled up to about 29,000+ folders and files and the CPU utilisation went to 100% and never dropped. The server system process was constantly trying to parse the stage directory and as it filled up was thrashing the CPU & disk.
You HAVE to set the result directory parameter in the WatchedFolder Startpoint Endpoint configuration even if you arent using it and set it to purge after 1 day (or anything other than -1 which is never delete). This way the stage folder will self-delete.
Views
Replies
Total Likes
Yea we figured that out after getting in contact with our support provider. Its a bug with how the watchedfolder endpoints proceses documents. If the result folder is empty it never gets rid of the stage files. Thanks for you help though
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies