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 |
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 |
Free forum by Nabble | Edit this page |