My current way of dealing with this is to simple deploy a new server with each release, since I don’t trust hot code push to work without initializing a sudden infinite reload.
Interesting idea. How does that actually help things though? What’s the difference between redeploying and deploying a whole new instance?
Also, does anyone know if there’s a way to disable hot reload to avoid this problem? At the same time you would still like the app to update at some point for the user.
Just to clarify: I’m using a cordova wrapped app, which I’m pointing at a new server and resubmitting to the app store.
2 Likes
We were experiencing this issue as well. We were able to solve it by removing nginx caching. In particular, this line:
if ($uri != '/') {
expires 30d;
}
1 Like
Does anyone understand why this works? And does it take a hit on
performance at all?
My best guess is that Meteor triggers a page reload when it sees stale assets requested, in the hopes that this will force the browser to request everything fresh from the server, which appears to not work well with the nginx caching described in this thread. Below is my best guess as to why.
Meteor includes the header Cache-Control:public, max-age=31536000 for static assets like JS/CSS files, but uses a revision hash in the file name to make sure that the latest JS/CSS is always pulled from the server. Requesting HTML documents from Meteor doesn’t return any caching headers.
However, if nginx is caching pages using
if ($uri != '/') {
expires 30d;
}
…the browser continues to load an outdated copy of the document (including older revisions of the JS/CSS files) – this is what I believe Meteor does not like. Meteor detects that the client is connecting with old code and triggers a browser refresh to try and force the browser to request newer assets. But the browser continues to pull from the cache, causing yet another reload. And on and on.
This is my best guess. I’m still not sure how Meteor can detect old code, nor what performance implication it has to disable nginx caching.
Some complementing info:
-
The nginx cache as above cashes the static assets, so instead of Meteor having to serve them, nginx does. Unless there is a bug somewhere, there is no way the content of what nginx serves is any different from what Meteor would have served.
-
/is not cached, so when the app is updated, a new version of/will contain references to new static files (different hash in the URL). Since the URL is different, the browser cannot get an old version (again, unless there is a bug in nginx or the browser) -
While I was doing intensive testing of the issue at my site, removing nginx caching did not solve the problem at all.
-
Meteor does not “detect old code” but has a SockJS connection to the server where the server will tell it to reload when it has created the minified assets of the new version.
@jesperwe, I don’t think that expires in nginx gets nginx to cache the
files and serve them. There are other ways to do that such as the
proxy_cache directive. What adding expires does is adds a header to the
http message being sent telling the browser to cache the files it’s
receiving for a certain amount of time and that it doesn’t have to ask for
these files again in the future if it already has a copy of them. (someone
correct me if I’m wrong! Not an nginx expert!)
Of course the browser does the caching, not nginx 
That’s what I get for writing posts at 6 in the morning…
@abernix @martijnwalraven or anyone else from MDG. Would you be able to add any input?
I think it was a mistake to have this discussion in the forums as opposed to the github issue since it seems to being overlooked despite a month of talk about it and multiple people having issues and guessing at what the problem is.
2 Likes
I had the same problem since approx 1 month.
But weirdly enough, the problem is gone :
Yesterday, I upgraded my DO droplet to a droplet with 2 CPUs/core.
After adding meteorhacks:cluster, in order for my app to run on both CPUs instead of just one, I re-deployed, and the constant refresh problem just vanished (deployed 6 times since, I can confirm the problem is gone).
I know meteorhacks:cluster has a bit of code to manage the proxy/load balancer between apps, so maybe it has something to do with the constant refresh
Just my 2 cents, this isn’t a fix, but somehow the problem is gone
Yeah. Random things seem to stop the problem from happening. I’ve stopped
seeing it on a certain subdomain where I used to see it, but really have no
idea why it stopped and whether it’s stopped for everyone.
I do know there are still browsers refreshing an old version of our site
constantly from a month ago still. No idea how that’s still possible but
it’s happening.
I’m still afraid to make an update to a much more used subdomain.
Wonder if this had any affect:
I’m back from holiday, but unfortunately, I don’t have anything new to contribute here. Hopefully upgrading will somehow resolve it for others too!
I maintain that there is some weird cache issue going on, but I can’t get to the bottom of why. Though, what I worked through with @jesperwe didn’t appear to be a cache issue (that we could see), it appears some folks have successfully found and resolved issues by fixing cache problems so I have to go with that as the cause for now. It’s also possible that because it was a cache issue the problem might not have actually gone away until those cached files/redirects/etc. were truly expired (30 days [30d] in some cases I saw above)
Disagree and I don’t believe it’s been overlooked. Throughout my holiday, I’ve seen the updates for this thread but just don’t have anything beyond what I’ve already suggested. GitHub Issues are for documented issues with reproducible reproductions. I realize it’s frustrating, but this issue never really got to that point and would sit unresolved in GH Issues just the same as here.
Additionally, these forums have a lot more traffic/activity than GitHub issues so you really have more eyes on problems (and people who can sympathize with it) when they are posted here first.
3 Likes
Thank you for the help. I appreciate it a lot.
I can confirm that the issue still happens. I have removed the caching from my nginx config. It was set to 30 days however, so maybe it will take a while till it’s fully gone.
Just want to say, I’ve seen people logging in to my app over 8000 times in the space of a couple of days due to this bug (and there are probably users that have logged in even more). About 10 logins per minute, for days straight 24/7. It is super annoying, can kill your servers if you don’t have enough up and will also drive users away.
If I know a user is logging in 5+ times per minute, is there a way I can show an alert or something and get the user to manually hit the stop browser button to stop the issue?
I am having this issue as well. Using a Nitrous.io server, and when running the app in --production, the constant refreshes happen. When I stop meteor and run it in dev mode, the refresh does not happen. This is really frustrating as it’s 2 months now since it popped up and MDG has not said a word about it.
Its killing our server and means we have to run the app in dev mode constantly. This is the first app I have built with meteor and I have to be honest, I am starting to regret it.
I can confirm that I am using some of the accounts- packages, and have not made any changes to the caching other than using default caching that Meteor sets up. I thought Meteor was meant to be really straight forward and easy to use!?
Do you have a way to reliably reproduce the error? That would help a lot in
terms of getting it fixed.
And am I correct in thinking that you haven’t touched any nginx
configuration or similar yourself? That’s all done by nitrous?
I agree this problem majorly majorly sucks, and has really hurt us too.
It seems to crop up as soon as I start meteor with --production. Whether that is on Heroku or Nitrous. However, when starting with just the meteor command, there is no issue. This does not happen on my localhost, whether in --production or not.
I have not made any Nginx changes, to be honest I am still a noob when it comes to NodeJS and Meteor. I have been working on the LAMP stack for about three years, and moved over to Meteor in April this year. I really love it but this bug is killing me.
I also have a really strange issue where the server slows down completely when we get alot of traffic, which we get a couple of times a week - but that’s a story for another day (and thread).
As for the serving slowing down, that seems like a standard scaling issue. Basically your server is being overloaded. The way to fix this is to add more servers as described here: https://medium.com/@eliezer/first-experiences-scaling-a-meteor-app-14a48e62a4af
1 Like