MICROS RES 3700: IFS error status -21 / IFS_ADAPTER_ERROR

[JimFromCanada]

This is related (but not identical) to a previous post about IFS error -20 (timeout).

The IFS timeout in the link above was resolved by turning off the "Log Transactions" option.

The same system (5.7.8) now hits an IFS_ADAPTER_ERROR instead.

This error will appear roughly 10 seconds after a SIM event is fired and it is waiting in a loop. The SIM script makes a TX/RX every second or so then sleeps. It does this TX/RX/sleep pattern in a loop until it receives an answer it can act upon (quit or continue processing).

The timing of failures is not consistent. It may error out after 3 seconds or it may last up to 10 seconds before failing.

There is no indication of failures in the event log, nor is there anything relevant in the 3700d.log other than the error itself:
[tt]Sun Jul 99 99:99:99 2024 | UWS01 | OPS | 0 | IFS error [IFS_ADAPTER_ERROR] |[/tt]

There are no search results that I can find for any specific IFS-type errors. I'm surprised that something this "blocking" in nature hasn't been hit enough to have search results associated with it in a search engine, but that's really just par for the course as far as my luck is concerned.

TL;DR: IFS_ADAPTER_ERROR is received in OPS after a period of time and SIM processing will halt. There is no indication of what the error is, nor is there any error being thrown by the SIM server. It just halts.

Potentially relevant information:
RES 5.7.8 / MR8
DB: 6337
Windows Server 2022 on a new machine that is quite substantial in resources

My main question: how can one begin to diagnose this if there is no information provided in the logs, windows event logs, online, etc? It seems like basic debugging of the environment is out of the question because there are no traces of something going wrong.

 

[JimFromCanada]

For posterity, the error codes line up with the index of the string in MDSIFSProxy.cpp
[tt]01: IFS_INVALID_CONFIG
02: IFS_SERVER_NAME_SIZE_ERROR
03: IFS_INTERFACE_NAME_SIZE_ERROR
04: IFS_NO_TX_DATA
05: IFS_DATA_SIZE_ERROR
06: IFS_BIND_ERROR
07: IFS_ID_SIZE_ERROR
08: IFS_NOT_REGISTERED
09: IFS_INVALID_RX_BUFFER
10: IFS_INTERFACE_NOT_ACTIVE
11: IFS_SERVER_NOT_ACTIVE
12: IFS_RESOURCE_ERROR
13: IFS_OS_RESOURCE_ERROR
14: IFS_RX_TERMINATED
15: IFS_INTERNAL_ERROR_2
16: IFS_INTERNAL_ERROR_3
17: IFS_RECEIVE_TIMEOUT
18: IFS_RPC_ERROR
19: IFS_NO_INTERFACE_NAME
20: IFS_PROXY_ERROR
21: IFS_ADAPTER_ERROR
22: IFS_ADAPTER_CLIENT_NOT_FOUND[/tt]

We've encountered "-20" and "-21" so far.

There is nothing notable in the MDS HTTP logs other than this one happening every five seconds:
[tt]ReadRequestData failed[/tt]

And these two happening several times a second:
[tt]Bad connection - Inactivity Time [1]
Connection is bad. Marking it for deletion.[/tt]

 

[JimFromCanada]

This issue mysteriously resolved itself.

The resolution may have been a combination of checking the network gear / cables / firewalls / etc. The very odd thing was that _some_ connections were being sustained while others would die but there was no pattern to it--it could fail on any and all of the workstations.

The database itself be suspect as well but with the IFS server co-operating for the time being, the mystery issue is unfortunately going to remain a mystery.

 

[JimFromCanada]

As a follow-up, this specific pattern is observed:
When the IFS service is restarted, the IFS server will immediately connect to the configured interfaces.
The IFS service maintains a connection on its own and sends pings every 5 minutes.
The workstations also connect to the SIM server when the IFS service restarts and they will also ping every 5 minutes. Their connections are also maintained until the IFS service restarts (or the SIM server does).

If the SIM server is restarted it may take up to 5 minutes (max) for the connections to be re-established. The connections will also be reestablished if any transmission is made to that SIM interface. The IFS service and all workstations will effectively "come online" with a client connection if a TX is made before the 5 minute window of PING's has elapsed.