[Glass] How to make Seaside ignore a repeat request

[Richard Sargent via Glass]

On Sat, Nov 3, 2018 at 4:48 AM, Johan Brichau <johan at yesplan.be> wrote:

> 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.
>

Thanks for the answers, Johan. The 204 status worked out to be more trouble
than benefit. At this point, it looks like the best option is the UI
overlay which prevents anything else getting clicked while the first
request is running.

For those who were interested, it does appear that the second request
terminates the first. So, the first request's response gets "delivered" to
a closed socket, since the 204 response was sent back "long before" the
response to the first request was constructed, and that 204 response
completed the request/response sequence.



> 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 <
> glass at lists.gemtalksystems.com> 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
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20181105/a06c0200/attachment.html>