Firebug Red POST (from button click), showing as "Aborted" Status

[Stu]

Hi Folks,

Clarion 8 (last), Nettalk 7.25.

I've got a form with a button and a browse on it.

When clicked, the button calls a function which processes away, adding records to a memory file.

After it's finished, the browse is refreshed.

The processing is not simple, but it's not uber-hard either.

Sometimes (but not always) the button will "stay gray", and the browse is not refreshed.

Usually that means, in my experience, badly coded xhtml (not compliant).

But firing up Firebug showed me a different story.

(images attached)

Basically the POST goes red with the status of "Aborted". Not "200 Aborted", just "Aborted".

Can't find anything too helpful on google/SO, except maybe this (http://stackoverflow.com/questions/12116641/how-to-solve-firebugs-aborted-messages-upon-ajax-requests).

I know there's something wrong, because the button stays gray and the refresh etc doesn't happen.

BUT it cannot be 100% replicated. Sometimes it works okay. Sometimes not.

As the screen shows, it's 271ms in this instance. Could there be a time-out issue?

[Edit #1]

This behaviour happens in a browser that is run directly on the server, and on browsers inside the network, and browsers outside the network (ie, from anywhere).

[attachment deleted by admin]

[Stu]

[Edit #2]

Okay.

So the "Aborted" status is what the post seems to be primed with (the "Net" tab of firebug shows this while the post is first running, it's marked as "Aborted").

Seems like a timeout issue.

Will have a look at:

1. Putting in some p_web.Noop() calls.

2. Breaking up the function into multiple functions.

[Stu]

Unfortunately p_web.Noop()'s didn't solve the issue.

[Bruce]

it would need to take longer than 30 seconds for it to be a timeout issue. Are we talking about a process that takes that sort of time?

[Stu]

Absolutely. Couple of minutes.

But there are other things in play. Our IT guys have been doing things on the servers, and I'm _positive_ there has been some kind of decrease in cpu power .. these processes used to be shorter, say 20-30 seconds, now taking 3-5 minutes, sometimes more.

So. Basically. It may be a combination of a few things, which is normal I guess for doing webserver stuff!

[Bruce]

3 to 5 minutes is a long time for a user to wait for a browse refresh. Even 20-30 seconds is a long time. Perhaps think about an interface (maybe a progress bar) which allows the user to continue in the meantime?

cheers
Bruce

[Stu]

They have the wait timer, which is what tells them it's progressing.

But yeah okay. A progress bar. That might be good. Thanks Bruce.

[Stu]

Hey Bruce,

What do you mean by

Perhaps think about an interface (maybe a progress bar) which allows the user to continue in the meantime?

?

Am finding this happening in a few places where I do very intensive calculating of things that must appear on the screen afterward (ie, running matching logic on thousands of people and then displaying them in a list for the user to do something with).

I'm guessing you are saying use a progress bar to indicate how the progress of the calculating is going.

BUT just wondering what you mean by "continue in the meantime"?

[Bruce]

It depends completely on the context I guess. Here are some possible scenarios;

a) I'm searching on Google. I type in a request. It thinks about it for some time (ok, not a lot, but imagine it was say 15 seconds) and then replies. Clearly I'm waiting because I want the result of that request before I can move on.

contrast this to

b) I'm doing my year end accounts for ClarionShop. I need about 12 reports. So I start each one and immediately continue with other things. Once the reports are ready they appear as a download link, or in another tab, or whatever.

In the first case the user is performing a synchronous task. In the second they're starting multiple asynchronous tasks and carrying on.

It sounds to me like you're more in example a than b.

So, given the times involved, I'd break the process into 3 parts;
a) get the request from the user
b) send the user to a "waiting" page, which shows a progress bar
c) when the result is ready replace the waiting page with the result.

For quick operations you basically go from a to c, but for long operations the interim step b keeps the user interested, and explains what is going on.

cheers
bruce

[Stu]

Hey Bruce,

Okay, thanks very much for the info / advice.

Am re-engineering both the form and function of my LONG wait-time elements.

Have discovered some of the problem (wait time) has been interface. So moving a browse to a popup from the form where the calcs are done, instead of refreshing after the calcs are done, has made a big difference.

But am also looking at the function of the code. Needs to be quicker if it can be.

Thanks again.