how big are your files?
its only going to write to the GDS when it exceed the max inline size. otherwise its done in memory.
if you reduce the max inline size + increase your doc disposal, you should be able to see it before the system cleans up..
i wouldn't recommend reducing the max inline size in prod however since it may make your overall performance worse (if your inline is very small and everything is written to GDS, your performance is going to be impacted due to high I/O vs. doing 90% of it in memory.
Our pdf-files is about the size of 130 kb.
With the current configuration we have set the document max-inline-size to 512 kb. Now the FileNotFoundException to the GDS has disapeared. But i still wonder why this error was shown when we used the GDS instead on the memory.....
Could it be problem with Synchronizing clock times in our cluster..?
Now and then we have another FileNotFoundException ERROR in the tmp-directory. In what way are LC using this directory..?
2014-09-18 23:33:58,067 ERROR [com.adobe.idp.Document] DOCS001: Unexpected exception. While doing first time passivation for a document..
com.adobe.idp.DocumentError: java.io.FileNotFoundException: /tmp/AdobeDocumentStorage/local/docm1411075483830/c694140f75dc873cf6c26afd8e73f57e (No such file or directory)
at org.jacorb.orb.ORB$HandlerWrapper._invoke(Unknown Source)
at org.jacorb.poa.RequestProcessor.invokeOperation(Unknown Source)
at org.jacorb.poa.RequestProcessor.process(Unknown Source)
at org.jacorb.poa.RequestProcessor.run(Unknown Source)
Caused by: java.io.FileNotFoundException: /tmp/AdobeDocumentStorage/local/docm1411075483830/c694140f75dc873cf6c26afd8e73f57e (No such file or directory)
at java.io.FileInputStream.open(Native Method)
... 8 more
im not too sure about the synch clocks being the cause of the 1st issue. where is your GDS? is it on 1 of the nodes of the cluster? we have our independent on a HA file system.
As for the 2nd issue , passivate. We get this also. when i talk to my tam he indicates the pdf file is corrupt. we cant' verify since the pdfs come from external sources. We have not been able to replicate in our dev env. Are you saying you can cause this in a controlled env?
im not too sure how the tmp folder is used but looking at mine, it looks like the gds, except specific to the node. if you look in it, you'll see files that you can rename with a .pdf ext and see what it is. mine also has a file ext like this: <filename>.expiresOn<timestamp>.
the only thing i can think of permissions. im assuming your LC svc is running as a service under a service account? Does your LC service have read/write permissions to the LC subfolders?
As i mentioned earlier our problem has only been seen when testing performance. And if i rerun the tests that failed everything works fine..so permission could not be the issue.
Does your server have virus or file scanning software that might be examining your files.
I have seen situations where the scanning software does not release a newly created file soon enough, and the LC process that was expecting it fails on a 'file not found' error.
If you encounter the error, immediately look for the file manually. If it is there, this might be the cause.
Usually the delay is sub-second, but that can be enough.
I usually suppress scanning of GDS and TEMP locations, as all files read from there are proprietary format generated by the LC server.