Hi,

I held off posting this earlier in case someone had something more
useful to say, but if you're using PeriodicalExecuter to fire off ajax
requests, I think you're opening yourself to some chaotic effects,
since you've got a timed event firing off an event that takes
unpredictable time (the ajax request).

If you just want to update your chat display, I'd use a chained
`setTimeout` instead. Conceptually:

    var chatCheckTimer = 0,
        chatCheckPaused = false;
    function chatCheck() {
        chatCheckTimer = 0;
        if (!chatCheckPaused) {
            new Ajax.Request("your url", {
                // ...
                onComplete: scheduleChatCheck
            });
        }
    }
    function scheduleChatCheck() {
        if (!chatCheckPaused && chatCheckTimer === 0) {
            chatCheckTimer = setTimeout(chatCheck,
CHECK_CHAT_INTERVAL);
        }
    }
    function enableChatCheck(flag) {
        chatCheckPaused = !flag;
        if (flag) {
            // Enabled
            if (chatChecktimer === 0) {
                chatCheck();
            }
        }
        else {
            // Disabled
            if (chatCheckTimer !== 0) {
                cancelTimeout(chatCheckTimer);
                chatCheckTimer = 0;
            }
        }
    }

Kick the process off with a call to either `chatCheck` or
`scheduleChatCheck`, whatever makes more sense for your page.

Doing it that way, you *know* there will never be more than one
outstanding chat check ajax call; chaos is reigned in.

You might also implement your own timeout; if an ajax call lasts
longer than X seconds, assume a timeout, try to abort it (possible on
some browsers), and even if it completes, ignore the result. (You do
this with an ever-increasing call ID; you make your `onSuccess`
function a closure over the ID [a copy of it local to the `chatCheck`
function, not the global one] and have it check that the local and
global IDs match when `onSuccess` is called, disregarding the result
if not.)

FWIW,
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com

On May 6, 9:26 am, Julien Lenne <tyrsen...@gmail.com> wrote:
> Hi !
>
> As nobody seems to be looking or have an idea, here is the source code
> of the page :
>
> http://kraml.fr/lib/js/chat.js
>
> It seems that when being @home with 2 computers (on an Internet box)
> on the website, it "crashes" more often.
>
> Here are my ideas of what is being happening, if it reminds someone of
> anything :
> - Network problem, the call doesn't get to the host but gives no error
> (fiber connection)
> - Server problem (OS), that wouldn't accept too many connections from
> the same IP (seems strange to me)
> - Server problem (Apache), for the same reason, but it seems less
> strange in this case
>
> Please let me know if you have an idea about this,
>
> Regards,
> Julien.
>
> On 4 mai, 09:40, Julien Lenne <tyrsen...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Hi there again !
>
> > New debugs showed me that the php file wasn't even called.
> > I heard there could be limits on the number of concurrent ajax calls,
> > is it true ?
>
> > I think that to test it, I'm going to stop my periodicalupdater before
> > an request and restart it right after, but it seems to me a bit weird.
>
> > Has Prototype.js an existing process to prevent this ?
>
> > Thanks in advance,
>
> > Regards,
> > Me.
>
> > On 3 mai, 10:04, Julien Lenne <tyrsen...@gmail.com> wrote:
>
> > > Hello there !
>
> > > It's been a (little) year since I've started using prototype.js. It's
> > > really great and it simplifies my dev life a lot !
>
> > > I use it to develop a chat application (www.kraml.fr) and I use the
> > > PeriodicalUpdater to retrieve the new events.
>
> > > But, somehow, it happens that the call never retrieves the answer from
> > > the server, even if in Apache log I see that the page has been called
> > > by that user.
>
> > > For now, I try to escape the problem by putting a timeout on the call
> > > (from a script found on the web), but to avoid loosing information, I
> > > have to send a receipt, which is slowing my app, and is not really
> > > reliable as it can "pend" as the periodical call.
>
> > > I don't think it comes from the prototype library, but I thought
> > > people could have had an idea or even had the same problem. I'm
> > > looking actually at the PHP sessions, but am not really sure it has
> > > something to do with it.
>
> > > Thanks in advance,
>
> > > Regards,
> > > Julien. (tyrsensei onwww.kraml.frifyouwant to test on live)

-- 
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.

Reply via email to