Our agent is not receiving an ACK from the ZIS
Although this appears as if the agent is not receiving an ACK from the ZIS, the ZIS has indeed sent the ACK. The problem is that the agent closed its connection to the ZIS after it sent the message to it. Most likely, the agent didn't know that it did this — most of the time, this was a result of a well-known bug in the OpenADK software and/or certain versions of the java SDK that causes the connection to be automatically closed.
The result of this happening is that the OpenADK resends the message as follows:
- If the original message was an "Add" event, the "Add" will be changed to a "Change", the message will be given a new MessageID and the message will be resent
- If the original message was a "Change" event or a "Response", the message would be given a new MessageId and resent
This could be done 10–20 times in a 1 second period.
This can happen in pure java applications that just use older java runtimes. Developers have found that updating those applications to the latest versions of java have been able to fix these issues. To date, nobody has fixed the OpenADK.
Since this issue, coupled with ambiguities in the SIF specification, has been causing so much damage in subscribing application databases and increasing network traffic needlessly, we have had to add code to the ZIS to protect the SIF infrastructure against these bursts of needless "logical duplicate" messages.
The ZIS will therefore accept the first of these messages and reject these "logical duplicates". Most likely, the errant agents will not notice most of the "error ACK" messages because they are in the "tight loop of sending duplicates to the ZIS" and are ignoring return values.