We have a flexible load balancing set up hosted on azure. After a release (with upgrade from 7.5.3 to 7.5.4) we have begun to have issues with publishing changes from the master server's backoffice not showing up on the frontend server.
We have noticed that the changes show up after the frontend server is restarted.
Looking into the umbracoServer table, the backoffice has the master designation and is active and the frontend is registered as active.
We have a staging environment with the same split that does not have this issue.
The largest change that was included with this change is the addition of Simple Injection framework for DI. We have had other issues with simple injection throwing errors for certain umbraco core controllers etc not being registered. However, with it continuing to work on our staging environment we are thinking of ruling this out.
Has anyone run into a similar issue of updates only propagating on app restart (master server not clearing cache of frontend?) or with including simple injection framework into their project?
When you publish on your master environment go in to the database table umbracoCacheInstructions and find the id of the latest record.
Now make a request to your front end server. After that go to your front end server and go in to the folder /App_Data/TEMP/DistCache/{machinename}/ folder and open the *-last-synced.txt file. This should contain the same id as the last id of the database. If that is the case we know Umbraco on the front end server has the latest content.
You can also check your log files of the front end server to see if it contains a entry on the time you made the request that looks like this :
This morning I ran through your suggestions: made change on master server, verified new entry in DB umbracoCacheInstructions, hit the page on frontend server, and then checked the distCache file contents.
Can you confirm that the presence of nulls and 0000 GUIDS is standard behavior? Just about all recent entries have similar values.
Next I looked at the distCache values for master and frontend:
Frontend: 3290185
Master: 3290520
And as before the change was visible on master server, but missing on the frontend.
In regards to your second question, we do have various caching (leblender on a per-grid-element level and on certain non-grid partials like menu etc) but the changes that we were making have fairly short cache duration of 5 minutes.
I would not mind the "empty" guids. I think they are there for future versions of Umbraco. In V8 umbraco will change from integer id to guid.
What me strikes most is the difference between the distCache id between front end server and master server:
Frontend: 3290185
Master: 3290520
This seems to me that the frontend server is not processing the cache instructions. Have you checked your log files for the line I mentioned in the earlier post ?
We did see those errors in our log. We ended up finding the bug in the issue trackers and saw that it was fixed in 7.5.5. We upgraded to 7.5.8 which resolved the issue!
Published Changes only display on app restart Flexible Load Balancing
We have a flexible load balancing set up hosted on azure. After a release (with upgrade from 7.5.3 to 7.5.4) we have begun to have issues with publishing changes from the master server's backoffice not showing up on the frontend server.
We have noticed that the changes show up after the frontend server is restarted.
Looking into the umbracoServer table, the backoffice has the master designation and is active and the frontend is registered as active.
We have a staging environment with the same split that does not have this issue.
The largest change that was included with this change is the addition of Simple Injection framework for DI. We have had other issues with simple injection throwing errors for certain umbraco core controllers etc not being registered. However, with it continuing to work on our staging environment we are thinking of ruling this out.
Has anyone run into a similar issue of updates only propagating on app restart (master server not clearing cache of frontend?) or with including simple injection framework into their project?
Hi Trey,
Some things you can check is the following.
When you publish on your master environment go in to the database table umbracoCacheInstructions and find the id of the latest record. Now make a request to your front end server. After that go to your front end server and go in to the folder /App_Data/TEMP/DistCache/{machinename}/ folder and open the *-last-synced.txt file. This should contain the same id as the last id of the database. If that is the case we know Umbraco on the front end server has the latest content.
You can also check your log files of the front end server to see if it contains a entry on the time you made the request that looks like this :
If all above is the case we can assume that the load balancing is working correctly.
The next question is do you have some kind of outputcaching in place on your frontend server ?
Dave
Hey Dave,
Excellent response!
This morning I ran through your suggestions: made change on master server, verified new entry in DB umbracoCacheInstructions, hit the page on frontend server, and then checked the distCache file contents.
The results of that sequence:
The new row in cacheInstructions:
Can you confirm that the presence of nulls and 0000 GUIDS is standard behavior? Just about all recent entries have similar values.
Next I looked at the distCache values for master and frontend:
Frontend: 3290185
Master: 3290520
And as before the change was visible on master server, but missing on the frontend.
In regards to your second question, we do have various caching (leblender on a per-grid-element level and on certain non-grid partials like menu etc) but the changes that we were making have fairly short cache duration of 5 minutes.
Thanks again for your help with this!
Hi Trey,
I would not mind the "empty" guids. I think they are there for future versions of Umbraco. In V8 umbraco will change from integer id to guid.
What me strikes most is the difference between the distCache id between front end server and master server:
This seems to me that the frontend server is not processing the cache instructions. Have you checked your log files for the line I mentioned in the earlier post ?
Dave
Hey Dave,
We did see those errors in our log. We ended up finding the bug in the issue trackers and saw that it was fixed in 7.5.5. We upgraded to 7.5.8 which resolved the issue!
Thanks for your help with this.
is working on a reply...