How to produce an HTTP 204 response

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

How to produce an HTTP 204 response

GLASS mailing list
I want to experiment with modifying Seaside under GemStone so that if/when
GRGemStonePlatform>>#seasideProcessRequest:adaptor:resultBlock: runs out of
retries, it produces (or causes to be produced from a high level) an HTTP
204 (No Content) response, rather than an Internal Server Error "Too many
retries" page.

Can anyone offer advice on how to do this?


In this scenario, each iteration throws a WASessionLockNotAcquiredException
because another web server gem is holding the session lock for a long
running request. This only occurs when running multiple web server gems
behind a HA Proxy (or any other load balancing mechanism, I expect) and an
impatient user clicks the link/button again.


Bonus points for anyone who can definitively tell me whether the 204
response from the second gem would or would not prevent the user's browser
from showing the results from the first request/first gem when it finally
completes. With the current implementation, the Internal Server Error "Too
many retries" seems to prevent the display of the results from the original
request when it finally completes.


Thanks everyone!




--
Sent from: http://forum.world.st/GLASS-f1460844.html
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: How to produce an HTTP 204 response

GLASS mailing list
GLASS mailing list wrote
> I want to experiment with modifying Seaside under GemStone so that if/when
> GRGemStonePlatform>>#seasideProcessRequest:adaptor:resultBlock: runs out
> of
> retries, it produces (or causes to be produced from a high level) an HTTP
> 204 (No Content) response, rather than an Internal Server Error "Too many
> retries" page.
>
> Can anyone offer advice on how to do this?

in tODE you can run the command:

find source `retries`

and it will give a list of the method definitions where you could look for
where the too many retries response is being created/sent.  

The specific code to generate the response you want depends on which server
adaptor you're using.  

see the implementors of #internalServerErrorMessage: for ideas about that




> In this scenario, each iteration throws a
> WASessionLockNotAcquiredException
> because another web server gem is holding the session lock for a long
> running request. This only occurs when running multiple web server gems
> behind a HA Proxy (or any other load balancing mechanism, I expect) and an
> impatient user clicks the link/button again.

You could cover the page with a throbber or disable the buttons while the
first request is being processed to undermine their need to accelerate
progress by clicking more.





> Bonus points for anyone who can definitively tell me whether the 204
> response from the second gem would or would not prevent the user's browser
> from showing the results from the first request/first gem when it finally
> completes. With the current implementation, the Internal Server Error "Too
> many retries" seems to prevent the display of the results from the
> original
> request when it finally completes.

Not sure but I think the browser abandons the first request once the second
is initiated by the user.  In your browsers dev tools you can see for
yourself by watching the requests on the Network pane as you click around.  


> Thanks everyone!
>
>
>
>
> --
> Sent from: http://forum.world.st/GLASS-f1460844.html
> _______________________________________________
> Glass mailing list

> Glass@.gemtalksystems

> http://lists.gemtalksystems.com/mailman/listinfo/glass





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