1190756 - Single URL does not work after repeated ajax calls

Status: RESOLVED INCOMPLETE

(Core :: Networking: Cache, defect)

Description

[walhalla247]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; rv:11.0) like Gecko

Steps to reproduce:

System Information:
OS: openSUSE 13.2 Linux
Firefox Version: 31.4 ESR 

We have about a hundred Clients which run our application. This web-application does repeated jquery ajax calls every 15 seconds to retain status information from a server. 


Actual results:

After some hours the jquery ajax requests on this specific status URL do not get a response on some of our clients. When we look into the Network Analysis View of the Developer Console we can't see the new ajax requests at all. If we send a jquery ajax request or standard JavaScript XMLHttpRequest manually via the console we get the same result. If we change the URL by adding a "?" or "#" character the request will work, we can see him in the Network view and it gets us the status from the server. Only the original URL seems broken.


Expected results:

The ajax request should always work without breaking after a few hours.

Comment 1

[walhalla247]

The problem could not be fixed by reloading the web-application (F5). Only restarting Firefox solves the problem

Comment 2

[Matthias Versen [:Matti]]

I guess that you can't provide a testcase and that makes it very difficult to do something with this report.
Did you already tried a non ESR Firefox version as test ?

>The problem could not be fixed by reloading the web-application (F5
ctrl+f5 (forced reload) also doesn't work ?

Comment 3

[walhalla247]

Thank you for the reply. 
At the moment we can't provide a simple testcase as the problem only occurs in our productive enviroment. We can't predict the exact time of the error nor the exact circumstances (network, os, cpu, ram). From our logs we see 10 Clients out of 100 having this Problem per day. We implemented a software watchdog which restarts firefox when this problem happens but this is only a dirty workaround to get the application up and running again. We will try your proposal to use ctrl+f5 by deactivating our software watchdog and give you feedback soon.

We are working on isolating the problem to get a testcase.
Meanwhile we will deploy firefox 38 on our productive enviroment and give you feedback in a few weeks.

Comment 4

[walhalla247]

Your proposal of pressing ctrl-f5 worked ! Can we use location.reload(true) from the code as a workaround ? Has it the same effect as ctrl-f5 ?
Does this information help you to further narrow down the error ? What else can we do, to support the error search ?
We tried to isolate the problem by pulling the network plug during an ajax request. This had an interesting effect on firefox: The following request did not reach the server. However, successive requests did. This was not exactly our problem, but it looks similar.
Hope this helps !

Comment 5

[Matthias Versen [:Matti]]

What I think is important here:
a) many requests for the same URL (loading every 15s over several hours/days)
b) changing the URL "by adding a "?" or "#" character" makes loading working again and this should also create a different and new cache entry.
c) restarting Firefox fixes it (seems to be an issue with something stored in the memory)
d) ctrl+f5 fixes it unlike a normal reload (seems to be a cache issue)

conclusion: this sounds like a cache issue

Honza: Do you have an idea if there is something that could overflow in the memory cache or what kind of information we could request from the reporter ?

>Can we use location.reload(true) from the code as a workaround ?
Sorry, I do not know that but from the description at https://developer.mozilla.org/en-US/docs/Web/API/Location/reload it seems to force a reload like ctrl+f5

Question: 
Would it be possible that you post the http headers for one of the jquery status URL ?
Are you in control of the web-application and are you able to change the http headers that the server sends ?

Comment 6

[walhalla247]

Attachment: Request and response headers of a ajax status request

Comment 7

[walhalla247]

1) For the http headers see above attached screenshot.
2) Yes, we are in control of the web-application and we are able to change the http headers that the server sends.

Comment 8

[Matthias Versen [:Matti]]

This is either a cache issue or some kind of issue with the keep-alive connection because the connection will never close with a 15s reload time.

I already tried to needinfo honza in comment#5, trying again

Comment 9

[Honza Bambas (:mayhemer)]

> If we change the URL by adding a "?" or "#" character the request will work

I don't understand why adding "#" would change anything here.  If so, then it's probably in layers above HTTP or the problem is somewhat intermittent.

I really need more info here.  An NSPR log [1] with 

   NSPR_LOG_MODULES=timestamp,nsHttp:5,cache2:5 

modules as a start.  It exposes URLs and cookies, so feel free to send it to my bugzilla mail directly to keep private.  Please try to keep it minimal (avoid other browsing), it can easily get bloated.  Then please lead me to the URL failing to load/be requested for and the time the problem has happened.

Thanks.


[1] https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

Comment 10

[walhalla247]

There are some problems to activate the log on our clients:
1) we use PXE to boot the machines and have only 2GByte RAM for the whole system. We don't have a harddisk, the system runs completely in the RAM.
We activated the NSPR log on our local machine. We ran our application about 8 minutes and got a log file of 7.5 MByte. This would lead to a logfile of 500 MByte in 10 hours, which is definitely too large.
2) we would need to deploy a new PXE image in our productive environment in order to activate the log, which would take some time, because the image is build by a external company

Comment 11

[Honza Bambas (:mayhemer)]

Then it will be much harder to help.  I have to think.  At least headers for the first and few subsequent requests/responses would be good to have.

BTW, you really cannot reproduce in you controlled environment?

Comment 12

[walhalla247]

The request and response headers of the first and subsequent ajax status requests are always the same. You can see an example in our attached screenshot.

Currently we are working on a solution to activate the HTTP logs on the client. We keep you up to date!

And yes, the error only occurs in our productive system. The error is intermittend and not provokable by us.

Comment 13

[walhalla247]

We finally found a way to enable the NSPR logging on about 100 clients. We did this for two weeks, but the error did not occur on those clients. The problem is still there, but only on clients that do not log !

Any idea what to try next ?

Comment 14

[Honza Bambas (:mayhemer)]

(In reply to walhalla247 from comment #6)
> Created attachment 8645593 [details]
> Request and response headers of a ajax status request

I can see the Firefox version is 31 here.  On which version(s) are you able to reproduce the problem only?

Comment 15

[walhalla247]

On our productive Environment we only use the Firefox Version 31. In the next weeks we will switch to Firefox Version 38. We will keep you informed about that.

Comment 16

[Honza Bambas (:mayhemer)]

(In reply to walhalla247 from comment #15)
> On our productive Environment we only use the Firefox Version 31. In the
> next weeks we will switch to Firefox Version 38. We will keep you informed
> about that.

So, any new information here?