Overview

Although this appears as if the agent is not receiv­ing an ACK from the ZIS, the ZIS has indeed sent the ACK. The prob­lem is that the agent closed its con­nec­tion to the ZIS after it sent the mes­sage to it. Most like­ly, the agent didn't know that it did this — most of the time, this was a result of a well-known bug in the Ope­nADK soft­ware and/or cer­tain ver­sions of the java SDK that caus­es the con­nec­tion to be auto­mat­i­cal­ly closed.

What Happens

The result of this hap­pen­ing is that the Ope­nADK resends the mes­sage as fol­lows:

• If the orig­i­nal mes­sage was an "Add" event, the "Add" will be changed to a "Change", the mes­sage will be giv­en a new Mes­sageID and the mes­sage will be resent
• If the orig­i­nal mes­sage was a "Change" event or a "Response", the mes­sage would be giv­en a new Mes­sageId and resent

This could be done 10–20 times in a 1 sec­ond peri­od.

This can hap­pen in pure java appli­ca­tions that just use old­er java run­times. Devel­op­ers have found that updat­ing those appli­ca­tions to the lat­est ver­sions of java have been able to fix these issues. To date, nobody has fixed the Ope­nADK.

Result

Since this issue, cou­pled with ambi­gu­i­ties in the SIF spec­i­fi­ca­tion, has been caus­ing so much dam­age in sub­scrib­ing appli­ca­tion data­bas­es and increas­ing net­work traf­fic need­less­ly, we have had to add code to the ZIS to pro­tect the SIF infra­struc­ture against these bursts of need­less "log­i­cal dupli­cate" mes­sages.

The ZIS will there­fore accept the first of these mes­sages and reject these "log­i­cal dupli­cates". Most like­ly, the errant agents will not notice most of the "error ACK" mes­sages because they are in the "tight loop of send­ing dupli­cates to the ZIS" and are ignor­ing return val­ues.