SEND IN TIME

[Terry Dennis]

Message: 20
Date: Thu, 22 Oct 2009 08:44:43 +1000
From: Sarah Reichelt <sarah.reichelt at gmail.com>
Subject: Re: SEND IN TIME
To: How to use Revolution <use-revolution at lists.runrev.com>
Message-ID:
<f99b52860910211544r104d64bdj34570ccbfda17094 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

> There is one and only one SEND IN TIME in the app. All the app does is
> re-trigger itself to periodically capture data from the internet. Perhaps
> there's some weird situation where the trigger happens at the same time as
> some external app does its own wait for a response from the internet? I
> doubt it, but I've seen stranger things happen in other environments. 
> Maybe
> because the internet requests are blocking, Revolution gets "stuck" if it
> doesn't get a "proper" response from a GET URL? In that case, the app 
> would
> never get control to SEND the message again.

This sounds like the most probably answer, which is why I suggested
sending the next message at the start of the handler instead of at the
end.

Cheers,
Sarah

**************************

OK, let's try this again.  The app does a SEND IN TIME in response to a 
button click at the top of its execution.  It does that once to start the 
automated process, and then once every time the message sent by the SEND IN 
TIME is received, again at the app entry point.  The "SEND  IN  TIME" is the 
same message that is sent to the automated routine from the button.  The app 
[occasionally] doesn't receive that 2nd SEND IN TIME.

It's like the message got "lost" somewhere.  The app displays a message when 
each iteration is done.  So, I know the app is completing its processing. 
The expected time for the next execution is displayed on the screen.  So, IF 
the app is getting triggered, the screen display of the next expected 
execution would be updated.  The "missed" message still exists in the 
pendingMessages queue.  If I re-trigger the automated procedure it checks to 
see if there is one already scheduled, then cancels it if so, before 
re-starting the automated process.  I get a prompt to cancel the "existing" 
auto processing before it will start another one.

QED: the message is not getting triggered.

Again, I doubt you will be able to fix this particular glitch, but at least 
the development crew will be aware of it in case they get another report of 
something like it in the future.  I even tried putting in code that will 
trigger every nn seconds, then issue another send if the *real* delay that I 
want hasn't been satisfied.  I haven't seen that particular technique fail, 
but like I said before, I haven't figured out what precise conditions cause 
the error.  Whatever, I'm not too excited about what is essentially a 
"background" task getting control frequently throughout the day.

Whatever, subject closed.  However, not "case closed".

Terry