Is possible to add job at runtime instead of startup ? about cronscheduler.aspnetcore HOT 16 CLOSED

@matteofabbri and @tomkerkhove,

I released a preview version (https://f.feedz.io/kdcllc/cronscheduler-aspnetcore/nuget/index.json) that supports the following:

1. Job class

public class TestJob : IScheduledJob
    {
        private SchedulerOptions _options;
        private readonly ILogger<TestJob> _logger;

        public TestJob(SchedulerOptions options, ILogger<TestJob> logger)
        {
            _options = options;
            _logger = logger ?? throw new ArgumentNullException(nameof(logger));
        }

        // will be removed in the next release
        public string CronSchedule { get; }

        // will be removed in the next release
        public string CronTimeZone { get; }

        // will be removed in the next release
        public bool RunImmediately { get; }

        // will be removed in the next release
        public Task ExecuteAsync(CancellationToken cancellationToken)
        {
            _logger.LogInformation("{cronSchedule} - {id}", _options.CronSchedule, Guid.NewGuid());

            return Task.CompletedTask;
        }
    }

2. In the Controller or any other class you would have to provide the injection of the constructor:

public HomeController(
            ISchedulerRegistration schedulerRegistration,
            ILoggerFactory loggerFactory)
{
            _schedulerRegistration = schedulerRegistration;
            _loggerFactory = loggerFactory;
}

public IActionResult Index()
{
            var jobOptions = new SchedulerOptions
            {
                CronSchedule = "0/1 * * * * *",
                RunImmediately = true
            };

         _schedulerRegistration.AddOrUpdate(new TestJob(jobOptions, 
        _loggerFactory.CreateLogger<TestJob>()), jobOptions);
}

Please let me know if this what you have in mind?

thanks, kdcllc

from cronscheduler.aspnetcore.

@matteofabbri the short answer is yes, there are two types of job. Here is an example of scheduled job https://github.com/kdcllc/CronScheduler.AspNetCore/blob/master/src/CronSchedulerApp/Jobs/TorahQuoteJob.cs

from cronscheduler.aspnetcore.

Sorry but I dont understand, the one that you posted is used at startup, maybe you were talking about UserJob ?

what i mean is having a controller like this

public MyController(ISchedulingService service)
{
     this._service = service;
}

public ActionResult Index()
{
      _service.Add(new ScheduledJob());
}

from cronscheduler.aspnetcore.

I'm late to the game but is there a way to register jobs with a factory approach on startup?

Noticed that this got deprecated in 2.1 but without a replacement which is blocking us from upgrading it as we depend on that.

from cronscheduler.aspnetcore.

@tomkerkhove are you referring to this extension method?

[Obsolete("This method will be depreciated in the next release.")]
        public IServiceCollection AddJob<TJob>(Func<IServiceProvider, TJob> factory, string sectionName = "SchedulerJobs")
            where TJob : class, IScheduledJob
        {
            Services.AddSingleton(typeof(IScheduledJob), factory);

            var name = typeof(TJob).Name;

            // named options used within the scheduler itself.
            Services.AddChangeTokenOptions<SchedulerOptions>($"{sectionName}:{typeof(TJob).Name}", name, _ => { });

            return Services;
        }

The idea behind the depreciation was that IScheduledJobs interface will change. I was thinking completely removing configuration of the jobs from that interface and move them to Options instead, So in principle I could still keep this extension method as long as configurations are set thru the SchedulerOptions.

from cronscheduler.aspnetcore.

I'm not using SchedulerOptions at the moment but I can move to that if it would make it easier for you.

from cronscheduler.aspnetcore.

@tomkerkhove can you provide me with a sample code? It would be helpful to make sure that I consider this case scenario moving forward.

from cronscheduler.aspnetcore.

Sure!

• Job: https://github.com/tomkerkhove/promitor/blob/master/src/Promitor.Scraper.Host/Scheduling/MetricScrapingJob.cs
• Registration: https://github.com/tomkerkhove/promitor/blob/master/src/Promitor.Scraper.Host/Extensions/IServiceCollectionExtensions.cs#L46

from cronscheduler.aspnetcore.

Let me know what you think because going with Options is less ideals since it's not coming from configuration.

from cronscheduler.aspnetcore.

@tomkerkhove it can come from different sources. I am leaning towards keeping the interface in tack and removing obsolete attribute from factory extension method.

from cronscheduler.aspnetcore.

That would be ideal as our current approach should keep on working then, but don't feel obliged because of just me...

from cronscheduler.aspnetcore.

Any update on the way forward for my scenario @kdcllc?

from cronscheduler.aspnetcore.

@tomkerkhove I have been working on and off on the solution and unfortunately I am settled on breaking changes at this time.

• IScheduledJob interface will look as follows:

    /// <summary>
    /// Forces the implementation of the required methods for the job.
    /// </summary>
    public interface IScheduledJob
    {
        /// <summary>
        /// The name of the executing job.
        /// </summary>
        string Name { get; }

        /// <summary>
        /// Job that will be executing on this schedule.
        /// </summary>
        /// <param name="cancellationToken"></param>
        /// <returns></returns>
        Task ExecuteAsync(CancellationToken cancellationToken);
    }

• Options are configured based on Job Name

 services.AddScheduler(ctx =>
                {
                    var jobName = nameof(TestJob);

                    ctx.AddJob(
                        sp => new TestJob(mockLogger.Object),
                        configure: options =>
                        {
                            options.CronSchedule = "*/05 * * * * *";
                            options.RunImmediately = false;
                        },
                        jobName: jobName);
                });

I looked over your cases and the migration should be simple. Instead of configuring IScheduledJob properties inside of the service, the options now can be configured at configurations level as demonstrated above. The main advantage in your application will be: jobs' configurations are now monitor for changes and update themselves accordingly.

Let me know your thoughts, I will try to wrap it up today or tomorrow,

from cronscheduler.aspnetcore.

Sounds reasonable, thanks for explaining! Is this already available or do I have to wait for 3.0?

from cronscheduler.aspnetcore.

@tomkerkhove I released 3.0.0-preview1. I am not expecting any major changes. I am updating documentation at the moment.

from cronscheduler.aspnetcore.

Worked like a charm, thanks @kdcllc and sorry for hijacking this issue; just think about that now :/

from cronscheduler.aspnetcore.