New post
Question
· Aug 28, 2023

[Solved] Custom File.InboundAdapter hangs, when switching to a new mounted folder

#Business Service #ObjectScript #InterSystems IRIS

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

Product version: IRIS 2021.1
$ZV: IRIS for UNIX (SUSE Linux Enterprise Server for x86-64) 2021.1 (Build 215U) Wed Jun 9 2021 09:48:27 EDT
Discussion (4)1
Log in or sign up to continue
Robert Cemper · Aug 28, 2023

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  
1 0
Martin Staudigel · Aug 31, 2023

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.

0 0