1

I have a servlet-jsp web app. One of the requests in the login action is taking upto 120 sec to complete on Firefox and IE browsers. However this same request is completed normally in chrome (below 1 sec). On debugging the code I can conclude that my web app filter is returning the response quickly but the browser shows it took 120 sec to receive it. If you see the firefox developer tool below, it shows the waiting time to be 360ms and the receiving time as 120 s approx. This same behavior can be seen on IE also. Any clue what might be causing this?

enter image description here

EDIT 1: This issue is being observed only for requests that return a 302 response code.

EDIT 2: I tried using an intercepting tool to check the requests, for this I had to route the traffic through a proxy at 127.0.0.1 (localhost) . One observation is that while doing this the application is significantly faster. A possible explanation I observed for this is the proxy application returns the 302 requests with a status code of 200 to the browser. So now the question is why are 302 calls slow on the Firefox and IE browser?

adarsh hegde
  • 1,353
  • 2
  • 21
  • 43
  • Can you give some additional information. What type of login do you use? What are the operations done by login flow? It connect to the database? What type of database? How the client side call the server side? Ajax request? it calls an action on the servlet? – Davide Nov 18 '16 at 13:57
  • I have a index.jsp page making a call to the servlet using : response.sendRedirect(request.getContextPath()+"login"); Lets assume that the database call is working properly as it is working on chrome. – adarsh hegde Nov 18 '16 at 14:03
  • I have found this http://stackoverflow.com/questions/10022704/response-sendredirect-not-working . Look in the accepted answer. The problem is slightly different but it can be useful. Have you written a **return** instruction after `response.sendRedirect()` ? – Davide Nov 18 '16 at 14:13
  • no there is no return instruction its just the end of the filter. EDIT: I mistook your question, there is a return statement after the sendRedirect() in my earlier comment. – adarsh hegde Nov 18 '16 at 14:17
  • The symptom of a long wait suggests that you're incorrecly writing some content to response body and/or explicitly setting an incorrect response content length header before calling the redirect. To exclude one and other, call `response.reset();` in the line directly before `response.sendRedirect();` and make sure you quit the servlet method as soon as possible (usually by `return;` directly after `response.sendRedirect();`). If that works, then look in the servlet code for code which incorrectly sets a header or writes to body before performing the redirect. – BalusC Nov 21 '16 at 13:30
  • Did you check the server's access log, to see when the request processing is finished on the server side? So you could find out whether the extra time is spent by the server or by the browser. – gsl Nov 22 '16 at 10:27
  • after eliminating a client-side issue, more info about code and structure is needed – code_angel Nov 22 '16 at 21:06

2 Answers2

0

Finally was able to resolve this issue from my app itself. In one of the places in the code the flush operation was being called upon the output stream of the response. 

super.getOutputStream().flush();

This was only being done in cases when the request was not of type 302 which makes sense because 302s don't have any data in the response. Chrome is smart enough to see that and doesn't wait expecting any data. However, firefox and IE keep waiting for the data and thus the connection for that particular call is not closed. This causes the delay which can be seen in the image I attached in the question (browser tries to download content which never arrives).

I have now changed the code to do the flush operation for 302s calls also. This has resolved the entire problem.

adarsh hegde
  • 1,353
  • 2
  • 21
  • 43
-2

Each browser has it own setting for handling connection. There are limits.

An answer-aggregation is already there:

how-to-solve-chromes-6-connection-limit

EDIT: Since the Question was edited, my answer don't match the topic anymore.

If a request of a web app act differently on different browsers, then the issue should be on the client side. (in the scope of single request-response interaction)

Community
  • 1
  • 1
code_angel
  • 1,537
  • 1
  • 11
  • 21
  • I tried changing the http connection limit of the browser on firefox but there is no improvement. I tried for very high values as well as low values. – adarsh hegde Nov 21 '16 at 06:59
  • You can try with one single tab in your browsers. All sessions/cookies/cache cleared. You could compare the Request-Headers from each browser. – code_angel Nov 21 '16 at 09:01
  • The only request header that is different in the two browsers is "UserAgent" – adarsh hegde Nov 21 '16 at 11:58