AI OnAI Off
Trigger scheduled job on all servers in DXC
Make an initialize module of it instead and check if the page has already been created?
If you don't want to add it to project and check it in of course. That would be my first option
Edited,
Sep 16, 2019 17:10
The reason we have a job to generate the error pages is so that the navigation, footer etc are up to date on the static file. so if a page was removed from the site that previously was in the header an admin user could run this job to re-generate the error page and it would display the same as any other page on the site. this way if episerver is down for any reason the static 500error.html can be served and will not be out of date.
Sep 16, 2019 17:16
Yes fair enough, we usually remove navigation branding in favour of a more simplified version that's consistent across the 500 and maintenance static pages but I understand where you're coming from.
I don't think due to the nature of how jobs work you can't get them to work that way. Usually jobs are supposed to be run ideally on a dedicated instance so there's not really designed to be running on multiple. Plus the running status is all held in the database and wouldn't run again if already running. The IScheduledJobRepository used for programatically running jobs would just run them on the current instance.
Are you on the DXC or your own hosting? I'll have a think
Edited,
Sep 16, 2019 17:54
The site is hoested on DXC. There are a couple of options we are looking at but i wanted to see if there was a simple way to trigger the job on all other servers, just to see if we could consider it as an option.
Its a bit of a long shot becuase i can't think of any other schenarios where you would need to run the same job on all servers.
let me know if you can think of anything.
Sam
Sep 16, 2019 17:59
It's an interesting one, the only thing I can think of that's clever and might work easily is having the header markup saved in blob storage. Then having the html file loading the content in with a client side include. Due to the fact the blob storage is across all servers it would be synced across them all with the standard functionallity. An out of the box solution.
Sep 16, 2019 18:04
Actually there's one other option, I assume your navigation is either in a settings page or is driven based upon the strucutre of the site/pages.
I believe the content events that support saving, deleting, moving ect get triggerd across all instances. So if you can work out which cotent changes are triggerd when you update the site settings page or event moving a top level page (if driven by site structure) you could use those to generate the page.
This means a) It works across servers and b) Only runs when it needs to.
Edited,
Sep 16, 2019 18:09
You mention multiple servers on DXC but DXC instances are Azure web app instances rather than separate servers as such. This means that they should share a filesystem and so, when the scheduled job runs on one instance and writes the error page to that instance's filesystem, it should be the case that the file will also be accessible to all other instances. Are you getting instances where some see the error page and others don't?
Sep 16, 2019 19:12
- Sep 17, 2019 9:19
I thought that as the instances scaled they were duplicates of the file system that were created as each instance is? We had config changes that needed to be made directly before with DXC and they told me they had to kill off scaled instances to make the change so it was reflected on them all
Paul Gruffydd
- Sep 17, 2019 11:17
According to https://docs.microsoft.com/en-us/azure/app-service/operating-system-functionality#file-access-across-multiple-instances and https://github.com/projectkudu/kudu/wiki/Understanding-the-Azure-App-Service-file-system the file system is shared between instances, all of which can write to it. That said, I think you might be correct too as you can enable a performance feature called "local cache" which takes a snapshot of the filesystem on initialisation of each instance: https://docs.microsoft.com/en-us/azure/app-service/overview-local-cache
- Sep 17, 2019 11:20
Yeah I was looking through some of this earlier. To be honest I think one think this shows is it's not really clear even to people like us EMVPs exactly of the setup and auto scaling has been setup. I had problems before with random restarts which turned out to be aggressive auto heal policies which needed to be deactivated. It would be nice to have a read only view of the pre prod/prod resources if only to see what's set up.
Hi,
thanks for all the replies. I realize that there are other ways to approach this issue, but the specific question i am asking is if there is a way for a particular scheduled job to run on all server instances in dxc when its triggered manually? It runs on all servers when it is scheduled.
Its no problem if not, i just want to get a clear answer so i can work out if its an option our team can consider.
Sep 17, 2019 10:11
To answer that question directly - No. As Scott implied above, Episerver scheduled jobs always run on a single server whether they are manually triggered or run on a schedule.
Sep 17, 2019 10:31
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
I am working on a site where we have a scheduled job that generates a static 500 error page and saves it to the site root. In DXC, when we have multiple web servers, this job will only run on the specific server that the admin user has logged into, so it only generates the 500 error page on one of the servers. Our only options are to update all servers at the moment is to try to log in to each server by trial and error (opening a private window and checking the id in the ARRAffinity cookie) or to wait for the job to run on schedule.
does anyone know if there is a way to get a scheduled job to run on all servers in the dxc environment?
Thanks
Sam