Not long ago one of my customers complained that his file adapter was randomly producing errors for failed file deletion after it has created a message out of it and then after a while it successfully processed the file and the message. At first sight this was pretty complex problem because it appeared only from time to time and the problem was not persistent since usually on the next turn the file adapter successfully processed the file and delivered the message.
Shortly after that I had my first hypothesis and it was that this was due to simultaneous file access. However this was very difficult to prove and related Java file manipulation classes (boolean File.delete()) do not reveal the real reason for this failure (permission problem or something else). Since the environment was entirely Microsoft based I decided to use the Process Monitor tool. The Process Monitor is very powerful tool which can monitor all kind of process activities like file access and registry access.
So, we set up Process Monitor on the system where the file adapter was running and to avoid unnecessary load we enabled only file access related events since everything else was not necessary at the moment:
One could also set filter for messages coming only fromjlaunch.exe and thus avoid huge number of unrelated messages.
The file adapter was reading a file on a network share which was written there beforehand by ERP running on the same system where the share was. Therefore in order to get the complete picture we set up process monitor there as well and waited for some time until the problem appeared again.
Once we had the first error message in the audit log we stopped both process monitors and investigated the logs.
The problematic file was: INSAR19300900368791006171629.xml so we looked for such entries in the log. And soon we found the following:
4:29:55.3200749 PM,,jlaunch.exe,,2040,, CreateFile,,
which shows that the real reason for this behavior was sharing violation. So far so good, what we also needed was to identify who was those process which was keeping the file open. Then we had a look on the logs from ERP system and there we found one process which had the following command line:
cmd /c copy
so this process was triggered shortly before that at 4:29:48 PM and lasted until 4:30:13 PM and in between it put a lock on our file \\10.0.0.191\SAP-XI\193\INV_TO_H\INSAR19300900368791006171629.xml and no one could delete it.