Hi Simon,

So if I understand correctly, you have 2 app services. One for the back office and one for your front-end server.

Do you have the correct configuration on each app service : https://our.umbraco.com/documentation/Fundamentals/Setup/Server-Setup/Load-Balancing/azure-web-apps

There are some small difference compared to running a single instance in Azure.

How did you explicitly set a the server role ? https://our.umbraco.com/documentation/Fundamentals/Setup/Server-Setup/Load-Balancing/flexible-advanced#explicit-schedulingpublisher-server

Dave

Thanks for the response, Dave!

Yes that's right, 2 app services, one for back office and one for front-end.

We have the correct configuration on each app service as far as we can tell, having completed everything from the instructions in that link you shared.

Except we are not setting an explicit subscriber / publisher, because we have the same codebase deployed to both app services. This approach has been working in our non-production environments so I don't know what could be different.

We've set the UmbracoApplicationUrl to the front-end app url, but I'm wondering if that should be set to the back office url? And should that be set differently on the back-office and front-end server?

Again thanks for any insight you can share!

Hi Simon,

Here you can find some information on the applicationUrl

https://our.umbraco.com/Documentation/Fundamentals/Setup/server-setup/load-balancing/#automatic-server-role-election

Dave

We've updated the configuration now and have confirmed that we're setting the explicit subscriber / publishers by using the

builder.SetServerRegistrar<SubscriberServerRoleAccessor>() and
builder.SetServerRegistrar<SchedulingPublisherServerRoleAccessor>() calls, conditionally loading the correct one on each server by using a 'IsFrontEnd' boolean passed in from configuration.

Should we expect to see rows being updated to the dbo.umbracoServer table? Because we don't see any rows added to that since we added the explicit server roles definitions and it makes me wonder if something is wrong.

But, maybe since we are setting them explicitly now, they shouldn't be set in the database?

Hi Simon,

When you explicitly set them they won't be registered in the server table.

So your setup is correct.

Dave

Awesome, thanks for confirming that, Dave.

One more thing - I don't quite understand what the umbracoApplicationUrl should be set to? As I understand it, it should be set to the publicly accessible front-end server. But since we are setting our single admin back office server to be the publisher, should it be set to that server's url?

Thanks so much for your help!!

Simon

I set it for each server pointing to it self. The only is according to the docs that the scheduling server should be able to resolve it.

https://our.umbraco.com/documentation/Fundamentals/Setup/Server-Setup/Load-Balancing/#automatic-server-role-election

But I agree that the docs are not really clear about this.

I will ask around to see if I can get a clear answer.

Dave

Hi Simon,

It should be set to the url of the instance.

Dave

Ok, thanks Dave.

I was doing some looking through code, and older versions, and I saw in some versions that the umbracoApplicationUrl actually includes the /umbraco route... do you think it's supposed to include that?

For example, https://our.umbraco.com/Documentation/Reference/Configuration-for-Umbraco-7-and-8/umbracoSettings/#umbracoapplicationurl

I wonder if the requirement has changed for this between versions and it now should just be the hostname, or if the documentation should be updated to include the /umbraco?

We're still seeing this problem where it's taking hours for changes to be published to the front-end servers.

In addition, we're seeing lots of timeout errors in the SQL database, but the database seems to be fine, with very low usage reported. It seems like something to do with the database tables being locked for a long time by some other process.

This issue seems to be pretty much what we are experiencing: https://github.com/dotnet/SqlClient/issues/1530

We are wondering if this could be related to our publishing problems. We have temporarily scaled down to 1 front-end server and one admin server but are still having problems.

is working on a reply...