[Solved] Custom File.InboundAdapter hangs, when switching to a new mounted folder
Hello Community,
To get to my problem, I need to elaborate a bit. We use an older fixed length format called HCM to transfer data from our SAP-ISH system to the Intersystems server. The data file is generated on a dedicated server and stored in a directory that is mounted to the communication server.
The synchrnoization is done via a lock file, which is exclusively locked in the adapter.
Now this, let's call it HCM server, is to be replaced. The old server is a CentOS 6.4 (Final) (uname -rv: 2.6.32-358.14.1.el6.x86_64 #1 SMP Tue Jul 16 23:51:20 UTC 2013), the new server is a SLES15.5 (uname -rv: 5.14.21-150500.55.7-default #1 SMP PREEMPT_DYNAMIC Mon Jul 10 18:53:13 UTC 2023 (4204a3a))
The transfer directories of old and new HCM server are currently both mounted to the communication server on 2 different directories.
The lock is set in the file adapter's OnTask() Method using a COS line
Open [lockfile]:"WLAS":10
The success is checked afterwards by
if $Test {
set tSC=##super()
} else {
[error code]
}
After successful processing of the data, or in case of an error, the lock is released again with Close [lockfile] in any case.
Close [lockfile]
With the old server mount this procedure works without problems, on the new server mount the 'Open' command does not come back in spite of a set timeout and the service can only be terminated by hard terminating the process on operating system level with kill -9.
The permissions on the lock file used is identical in both directories. It is also possible to create and delete files in the directory on command line as cacheusr. Since I am stuck with my efforts to debug the phenomenon, here is the question:
Has anyone who processes data with file adapter using a lock file for synchroisation observed this behavior and can help with a solution approach?
How can the problem be further narrowed down and debugged?
Thanks for any help and kind regards,
Martin
Comments
The "L" in your Open makes me nervous.
From the description, it seems to hang and wait for unlock not In IRIS but at OS-FileSystem Level.
The description of "L" seems to give some chance for such a conflict.
| L | Locked Exclusive: Use this mode with the “W” (Write) mode to specify exclusive write access to a file. “WL” or “WRL” specifies that the current process has exclusive write access to the file. A file opened with “RL” may still have shared read access. The effects of the “L” mode on concurrent opens are different in Windows and UNIX®. Refer to the “OPEN Mode Locking” section, below, for further details. On UNIX® systems if one process specifies “WL” (or “WRL”) access to a file, other processes requesting read access to that file must specify “RL” so that UNIX® can coordinate file locking. |
suggested testing:
- Check the situation without "L"
- If there is a difference: find out who else may lock at OS level
Thanks to Andreas Schütz and Stephan Mohr - we found out that a blocked firewall port caused the open command to freeze. Timeout settings didn't have any effect, that should not be the case.
Regards,
Martin
Interesting side effects and solution!
Yes, it took a while to find the solution as writing files did not cause problems. It came out, that the port for the lockd process is dynamically negotiated. We configured nfs to use a static port and opend the port in the firewall at the host system and the problems were gone. So you were right with the suggestion to search on OS-level.
Thanks for your help.