Smalltalk › Gemtalk › GLASS

How to make Seaside ignore a repeat request

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

GLASS mailing list

How to make Seaside ignore a repeat request

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

GLASS mailing list

Re: How to make Seaside ignore a repeat request

Ciao,

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?

My solution:

When i render the anchor where relative requests may take a long time

i do:

html div with:[

self renderSomeDataToDisplayOn:html. " data user informations "

"A" self renderHiddenBarOn: html.

"B" self renderCommandOn: html

Where:

A) i render a hidden progress "widget"

self renderHiddenBarOn: html.

html div id: 'prgDiv' ; class:'loader'; style:'display: none; margin: 5px auto;'.

2) self renderCommandOn: html

html div id: ( self divReferencePrefix: 'cmdDiv' for: self ); class: 'command'; with:[

html anchor callback:[ | aBlock | ]; onClick: ( self onClickUpdateFor: self on: html); title: 'title; with: 'Anchor for a long time requestA'.

html anchor ............

2A ) the onClickUpdateFor: self on: html

^( html jQuery ajax script: [ :s | s << (( s jQuery class: 'command' ) hide ). s << (( html jQuery: ( 'prgDiv' )) show) ])

When the user click on the anchor the system display a progress bar and hidden all the other command.

The browser appears to be locked until it receives the response from the server.

And what were you looking for?

How much report is a summary, but I think there is everything to try.

Eventually let me know.

Ciao,

Dario

The relative css data are:

.loader {
border: 16px solid #f3f3f3; /* Light grey */
border-top: 16px solid #3498db; /* Blue */
border-radius: 50%;
width: 44px;
height: 44px;
animation: spin 2s linear infinite;
}
@keyframes spin {
0% { transform: rotate(0deg); }
100% { transform: rotate(360deg); }
}
@-webkit-keyframes blinker
{
0% { opacity: 0.3; }
50% { opacity: 1.0; }
100% { opacity: 0.3; }
}
.css3_blink
{
-webkit-animation-name: blinker;
-webkit-animation-iteration-count: infinite;
-webkit-animation-timing-function: cubic-bezier(.5, 0, 1, 1);
-webkit-animation-duration: 1.7s;
color: red;
}
'

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: How to make Seaside ignore a repeat request

In reply to this post by GLASS mailing list

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

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: How to make Seaside ignore a repeat request

On Sat, Nov 3, 2018 at 4:48 AM, Johan Brichau <[hidden email]> 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 <[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

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

GLASS mailing list

Re: How to make Seaside ignore a repeat request

What I do is to disable the element that triggers the ajax call and also hook into the global ajax handler this way:

renderLoadingIndicatorHandlerOn: html

html document addLoadScript: ((html jQuery document)

call: 'ajaxStart'

with: (Javascript.JSStream

on: 'window.onkeydown = function(e){e.preventDefault;return false;};'

, 'window.svxLoadingTimeout = setTimeout(

function(){

'$("#svxLoadingIndicator").hide().fadeIn();}

,500);')

asFunction;

call: 'ajaxError'

with: (Javascript.JSStream

on: 'clearTimeout(window.svxLoadingTimeout); window.onkeydown = null;'

, '$("#svxErrorIndicator").fadeIn();')

asFunction;

call: 'ajaxStop'

with: (Javascript.JSStream

on: 'clearTimeout(window.svxLoadingTimeout);'

, 'window.onkeydown = null; '

, '$("#svxLoadingIndicator").fadeOut();')

asFunction)

So everytime I send an AJAX request I locally disable the element, and do whatever I consider "locally relevant" to the action, then the global AJAX handler is hooked and removes the handler for all keyboard interactions (windows.onkeydown), then if the requests takes more than 500ms of wait I display a modal "loading indicator" that is displayed in front of all the page, and when the ajax stops I fade out that indicator.

If there was an error I display another indicator used to handle ajax errors.

So far this worked very well for interactions that might need to invalidate other elements in the screen after some callback execution (most likely returning an script).

Regards,

Esteban A. Maringolo

El lun., 5 nov. 2018 a las 16:19, Richard Sargent via Glass (<[hidden email]>) escribió:

On Sat, Nov 3, 2018 at 4:48 AM, Johan Brichau <[hidden email]> 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 <[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

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass