Hi Richard,

In case of  xml-http-requests (aka ajax requests), you could use client-side javascript code to control the request. It would require to standardise the use of ajax calls throughout the entire seaside application code, though. Using custom tags (subclasses of WATag), you could create some abstractions.

In the case of full-page requests (triggered by page links), returning a 204 is indeed an interesting thought. I have never experimented with it but it should be straightforward to change the response code in that case. I’ll respond in your other email.

What we (Yesplan) do in production to limit the number of such ’session locked’ retries from happening is making the session sticky to the gem. Since Seaside wants to process requests sequentially, we queue them in the load-balancer. See  http://jbrichau.github.io/blog/when-to-use-http-session-affinity-in-glass

Cheers,

Johan

On 1 Nov 2018, at 01:25, Richard Sargent via Glass <[hidden email]> wrote:

I have a situation where some requests may take a long time, resulting in the
user getting impatient and triggering the request again. If the second
request cannot get the lock while the first is processing, the request
processing loop retries for a total of 10 attempts before giving up.
(This is especially critical when the default #retryDelays of 23.31 seconds
is too long and have been shortened.)

Short of fixing the thing that takes a ridiculously long time, what can I do
to prevent or ignore the user triggering the request a second time and
perhaps getting back a /Too many retries: 11/ response instead of what was
requested?

Is there a way to disable the UI while a request is being processed?
Is there a way to produce a "null response" that won't try to update the
display in the browser?


Thanks,
Richard



--
Sent from: http://forum.world.st/GLASS-f1460844.html
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass