ajaxSubmit results sometimes get lost

[William Wilson]

Hello all,
I'm experiencing an issue with ajaxSubmit callbacks that take a long time.  The function in question usually takes about 500msec, but right after startup it takes much longer (the first time invoked after a restart, when it must load many classes, set up DB connections, etc, it can take up to ten seconds).  Because the response time is fairly short at all times except on startup, I don't think it's worth it to do this with Comet.  I could just do some priming thing, but it appears to be a correctness issue.

If the callback function passed to ajaxSubmit takes longer than the ajaxPostTimeout, the result of the callback gets lost.  Instead, it appears (to my not entirely trained eye) that the browser attempts to retry.  Upon retry, all the callbacks for all the defined form elements get called except the one for ajaxSubmit (which is still executing from before).

After all this happens, the result from the first ajaxSubmit call disappears.  Since there's no second invocation of the ajaxSubmit callback, there's no opportunity to return a result on the retry.  The browser is just left hanging.

I'm not sure what I should do to prevent this from happening.  I'm not sure if oneShot or callOnce would even help here, since the problem isn't multiple invocations, but rather disappearing results.

[David Pollak]

The two easiest ways to deal with this issue are:

1 - warm up your app before it serves any pages... do this in boot

2 - extend the Ajax timeout

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

--

Telegram, Simply Beautiful CMS https://telegr.am

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[David Whittaker]

Is the fact that the ajaxSubmit is not invoked on retry by design?  This sounds similar to the problem I was having recently.   I ended up disabling retries at which point I started getting timeout alerts in the browser.  Before that there was no indication that anything had gone wrong, like William said, it just seemed like the response got lost.

[David Pollak]

On Thu, Jul 5, 2012 at 5:53 PM, David Whittaker <da...@iradix.com> wrote:

Is the fact that the ajaxSubmit is not invoked on retry by design?  This sounds similar to the problem I was having recently.   I ended up disabling retries at which point I started getting timeout alerts in the browser.  Before that there was no indication that anything had gone wrong, like William said, it just seemed like the response got lost.

The response doesn't get lost, the retry re-invokes the method which probably doesn't have anything to say the second time around.

[David Whittaker]

I don't mean to apply that it actually does get lost, but because the timeout alert is never triggered it appears that way.  I've followed the Posts with Wireshark and I can see that a response initially does comes back, but the timeout has elapsed so it's ignored.  In my case the ajaxSubmit is not invoked the second time though.  I just re-enabled retries in my app and here is the post body for a first attempt that times out:

F951457564254DQXY3G=US&F951457564255TE2ARA=&F951457564256VRCL4Q=100&F951457564257TJGPQO=100&F951457564258WRNFRZ=0&F951457564258WRNFRZ=1&F951457564258WRNFRZ=2&F951457564258WRNFRZ=3&F9514575642592NXT1H=100&F951457564260AJYMGB=0&F951457564260AJYMGB=1&zF951457564261CZ2EKL=_

And here is the body for the retry:

F951457564254DQXY3G=US&F951457564255TE2ARA=&F951457564256VRCL4Q=100&F951457564257TJGPQO=100&F951457564258WRNFRZ=0&F951457564258WRNFRZ=1&F951457564258WRNFRZ=2&F951457564258WRNFRZ=3&F9514575642592NXT1H=100&F951457564260AJYMGB=0&F951457564260AJYMGB=1

The guid that was assigned to the ajaxSubmit, zF951457564261CZ2EKL, isn't included the second time around.  This is what it looks like in the page markup.

<input onclick="liftAjax.lift_uriSuffix = 'zF951457564261CZ2EKL=_'; return true;" class="submit small" name="zF951457564261CZ2EKL" type="submit" value="Filter">

 I understand why you're skeptical, I've looked at the js and I don't understand what would cause it, nonetheless that's what I'm seeing.  I'll try to put together a test case.

-Dave

[David Whittaker]

Ok, I've got a reproducible test on github here: https://github.com/davewhittaker/retry_fail

Just

1) ./sbt

2) container:start

3) load http://localhost:8080

4) type something into the "name" field and click submit

The app is set for 1 retry after a 1 second timeout and the submit action sleeps the thread for 2 seconds.  There are println statements that are fired when both the SHtml.text and SHtml.ajaxSubmit callbacks are triggered.  You'll see on the console that the SHtml.text and SHtml.ajaxSubmit statements will print for the first try, then on the second post it's just the SHtml.text that gets printed.  The JsCmds.Alert that the SHtml.ajaxSubmit responds with is never displayed, nor is there any error message in the browser.

[Antonio Salazar Cardozo]

I bet this is an issue to do with the lift_uriSuffix. I think even though it's set initially when the first request goes out, it's cleared by the time the request is retried. This may actually also explain a particularly nasty bug we'd been trying to track down for a while.

I might try and look at this sometime today or tomorrow.

Thanks,

Antonio

[David Whittaker]

Antonio,

Good call, lift_uriSuffix is set onclick, then it seems to be cleared before the first attempt is made.  It's appended to the data being sent, but not to the version stored for retry.  Modifying the code block below so that aboutToSend.theData = theData after the string is appended should fix it,   I think.

var theData = aboutToSend.theData;

if (liftAjax.lift_uriSuffix) {

  theData += '&' + liftAjax.lift_uriSuffix;

  liftAjax.lift_uriSuffix = undefined;

}

liftAjax.lift_actualAjaxCall(theData, successFunc, failureFunc);

[Antonio Salazar Cardozo]

Cool, let's do it!

[David Whittaker]

Ok, ticket created and fix is up for review.  I've verified that it fixes the issue with my test case.  https://github.com/lift/framework/pull/1290.