Scheduled jobs and HttpContext

Mark Everard
Member since: 2008

It always used to be that you could work out whether a job was running via scheduled execution or run via the Admin mode interface by checking within the job whether there was an HttpContext. If there was, then the job was run via Admin mode. If not it was scheduled.

Has this behaviour changed?

I'm on CMS 10.10.1 and HttpContext is always null, so I can't see a way to identify the context in which the job is run. I'm guessing may this changed with some of the improvement work around making jobs stoppable / supporting dependency injection etc. Are jobs run in their own new thread now perhaps?

Does anybody know if this is a deliberate thing?  

Can anybody think of a way to work out if the job was manually started?

#187138 Jan 12, 2018 23:12
  • Erik Norberg
    Member since: 2012

    If memory serves it was a deliberate change to always start it up in their own thread.

    I don't recall what version it was, but before the change when a job was started manually and run in the current HttpContext the job would also be aborted if the HttpRequest timed out.

    No idea if you can find out if a job was manually started now.

    #187184 Jan 15, 2018 17:03
  • Mattias Bomelin
    Member since: 2006

    I believe this changed in cms 10.3 so it's a while ago. It doesnt matter anymore if you start it manually or automatically, the job is always run in the same context.

    The trigger is set in SchedulerOptions upon execution but I haven't found a way to reach it from within the job. However, the trigger is set in tblScheuledItemLog. It's an int value that corresponds to the enum ScheduledJobTrigger.

    #187185 Jan 15, 2018 17:35
  • Mark Everard
    Member since: 2008

    Thanks both. Good to know. That has some impact for anything that relies on an HttpContext. Nothing that can't be worked out though!

    My exact requirment was to know the context so I could block automatic scheduling of the job (meaning the specific job can only be run by clicking 'start' in Admin mode). You can still do this - though its a bit of a hack. You check the job settings via the ScheduledJobRepository. If it is marked as IsEnabled (meaning it is set in Admin mode to run automatically), then I return from the job. I only allow it to execute if it isn't saved in the database to run on a schedule. 

    var job = _scheduledJobRepository.List().First(j => j.TypeName == GetType().FullName);
    if (job.IsEnabled)
    return "Execution of this job is disabled. Please turn off scheduled execution to allow this job to be executed manually";

    #187203 Jan 15, 2018 23:56
  • Erik Norberg
    Member since: 2012

    Is there any consideration that forces it to be a job?

    If a schedule isn't wanted I would prefer to add it as a Tool under CMS->Admin.

    #187222 Jan 16, 2018 12:36
  • Mark Everard
    Member since: 2008

    Good point Erik.

    In my exact case, there is a bit more context that forces it to be a job. It should run automatically in the Production environment only, I only want to disable scheduled execution on downstream test environments.

    #187224 Jan 16, 2018 12:48
  • Erik Norberg
    Member since: 2012

    That makes sense. As long as it is only for a test environment hacks are allowed. wink

    #187226 Jan 16, 2018 12:58
  • Erik Henningson
    Member since: 2006

    Haven't tested this in CMS 11, but I've solved the same issue like this 

    if (PrincipalInfo.CurrentPrincipal.Identity.IsAuthenticated)
       //is in admin mode

    since a scheduled execution is run in an anonymous user context.

    Got this tip from Philip 

    #187285 Jan 17, 2018 21:34