[kgb-maintainers] Detecting "shadow" notifications

[Damyan Ivanov]

This is about an item in the TODO list about avoiding double or 
"shadow" notifications.

Imagine the following:

client connects to server1 and sends the request. The server recieves 
it, but for some reason the response fails to reach the client. For 
example some network failure between the client and the server.

The client, after timing out, will try with the next server in the 
list. It succeeds, the notification appears in IRC.

However, since the first server recieved the request just fine, it 
process it too, so the notification appears twice on IRC.

This has happened once and it is confusing/annoying, so here's 
a proposal for avoiding "shadow" notifications.

My idea is that servers track notifications as they see them on IRC. 
For example the last 10 notifications or the notifications from the 
last minute (or both: last minute, but no more than 10).

When it recieves a request about a revision that has been seen 
already, it ignores it.

There are a couple of problems here.

 1) there is still chance for doubles, becayse IRC is asynchronous. 
    Both servers may send the IRC message roughtly at the same time.
    There is no much we can do about it. Maybe add a random delay 
    before sending notification, but I am not sure if this is worth 
    the hassle. Also it would worsen the interactive, "snappy" feeling 
    KGB gives now. Not sure if it would also cause re-ordering of 
    notifications (i.e. wait 1s before the first notification and wait 
    0.5s before the second). Not sure how would this interact with 
    throttling (RateLimit).

 2) "revision"+repo-id is something that identifies the commit 
    uniquely. Except for simple, not anntotated tags with Git. These 
    are simple aliases for commits, and therefore share the same SHA1 
    sum. This can be worked around on the client side by adding 
    something to the commit id in order to distinguish the tag change 
    from the commit. Possibly something like "$commit+$tag_name". 
    Something to keep an eye on.

 3) The harderst (for me) part: keeping track. POE is such a worm box 
    that I am not sure where the array/hash/whatever with last 
    notifications shall be kept and how to access that both from the 
    IRC part and the part that handles SOAP requests. Hm, perhaps it 
    only needs to be kept in the IRC part, but still needs to be 
    accessed by the sub that "listens" in the IRC channell and the one 
    that talks to it.


Comments and suggestions welcome.

-- 
dam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/kgb-maintainers/attachments/20091013/a8d639bf/attachment.pgp>