0

I'm developing a server control to avoid duplicate processing of same request type on a Java server side. The main goal is avoid that an user could flood my server processor by just clicking on an hard processing request repeatedly. I'm developing a Servlet Filter to control the flow of requests, but I can just "abort" the second request by returning a HTTP 204 status if there is a prior request that is still processing. From the server point of view, it is OK. But the web browser will handle just that "aborted" request, not the first one.

Browser sends request "A"
Server starts to process the request "A"
Browser sends request "B"
Server aborts request "B" (HTTP 204)
Browser receives response "B" (Aborted)
Server finishes the request "A"
Browser does not displays / receives the request "A"

So, finally the question. Is possible to change the response of a request? Thus, I could avoid the duplicate processing on server side, and the browser could display the requested content.

Can you suggest another approach to solve that issue?

Browser sends request "A"
Server start processing request "A"
Browser sends request "B"
Server "holds" request "B"
Server finishes the request "A"
Server forwards the request "B" to the the response "A"
Server aborts the request "A" (http 204)
Browser displays / receives the request "B" with the response "A" content / headers

Thanks in advance.

Gustavo Ehrhardt
  • 13
  • 2
  • 4
  • I'd use atmosphere or some other websocket framework. – eduyayo Nov 18 '14 at 22:02
  • Hello @eduyayo, I agree with you, but I'm looking for an approach that not implies on a big redesign of existing code. – Gustavo Ehrhardt Nov 19 '14 at 15:39
  • mh... then you have to keep "alive" in session a worker thread and keep feeding it in. There´s a similar thing done in struts2 http://struts.apache.org/release/2.0.x/struts2-core/apidocs/org/apache/struts2/interceptor/ExecuteAndWaitInterceptor.html but you have to extend the logic to keep feeding when the cient calls again to check if it´s done – eduyayo Nov 19 '14 at 19:33
  • Hello @eduyayo. This is interesting. I'm thinking about a temporary context to store the first response, then the second request can get the content directly from this temporary context. – Gustavo Ehrhardt Nov 21 '14 at 10:26
  • notice you may clog the server with stuff in session... have to plan that caaaarefully – eduyayo Nov 21 '14 at 13:59
  • Yeah man... @eduyayo I'm think about a 3sec expiration of this "cache". Thanks for the advice. – Gustavo Ehrhardt Nov 27 '14 at 00:39

2 Answers2

0

Instead of using this approach, you can use micro-caching, that is caching content only small durations, like 1s,10s. This way instead of http204, you return cached content. Your users would be more happy with this approach. You can synchronize your servlet code so that only one request will processed in your servlet. But be aware that synchronized servlet is not a good design.

Community
  • 1
  • 1
Atilla Ozgur
  • 14,339
  • 3
  • 49
  • 69
  • Hello @Atilla. Do you think I can cache the response content in a http session scope? I don't want that an user see the content cached by another user. – Gustavo Ehrhardt Nov 19 '14 at 00:50
0

I will do a cache based on this Stack Overflow answer of @BalusC. How to read and copy the HTTP servlet response output stream content for logging. I can't exchange the response of other request, but I can cache the previous response by a short time. The subsequent requests can receive the cached response, thus it will avoid the processor flood. Thank @eduyayo for the suggestions.

Community
  • 1
  • 1
Gustavo Ehrhardt
  • 13
  • 2
  • 4
  • Just for mention, this approach is not correct. When I double click on a request link, the browser cancels the transfer of the first one, thus my cache stays uncompleted to serve the second request :/ – Gustavo Ehrhardt Dec 04 '14 at 11:57