Re: athena duplicate messages issue

Jean-Paul Calderone <[email protected]> Fri, 12 Jan 2007 09:21:35 -0500
Newsgroups gmane.comp.python.quotient.dev
Message-ID <20070112142135.11447.1077207812.divmod.quotient.14231@ohm>
On Fri, 12 Jan 2007 09:42:37 +0000, Michael Graz <[email protected]> wrote:
>I had been having problems with the "athena transport received duplicate
>messages" error.  Most of the time it has been harmless message but in some
>instances it causes everything to lock-up.  So after a bit of investigation
>I see that it is caused by the following sequence:
>- server invokes callRemote to run a javascript method in the client
>- athena.js in client sends back a response to the server for every
>callRemote
>- but the responses that get sent back (client to server) are not cleaned up
>(in the client) so they linger for the next wave of server callRemote and
>client send response
>
>A fix for this was to add the following line after "var outgoingMessages =
>self.messages;"
>    self.messages = [];
>This is in function flushMessages in athena.js.  The result is that outgoing
>messages which are flushed are discarded and not kept, which seems to be the
>goal anyway.

This defeats the purpose of all of the reliable message delivery code. :)
If the HTTP request which is made later in that same function fails, all
of those messages will be permanently lost.

It would be useful if you could share a short program which demonstrates
this problem.  

>
>I'm not sure of the complete ramifications here but everything is now
>working cleanly for me.  That is, when the server code issues one or more
>callRemotes, then the browser code acknowledges each with one and only one
>response.  So passing this along for the group.  Does anyone have any
>insights into the problem ("duplicate messages") and/or the fix ("messages =
>[]")?

There is probably an improvement which can be made here, but it is likely
along the lines of being smarter about recognizing when a set of messages
_must_ have been received and trimming the message queue then.  This may
be possible with the existing acknowledgement code (I haven't looked closely)
or it may require the addition of some new messages at certain times.

Jean-Paul