I'm using Quartz.net 3.x, and following what little documentation I could find on the subject, I've implemented the ability for my job to be canceled, like this:
public class MyJob : IJob
public async Task Execute(IJobExecutionContext context)
{
//Do some stuff...
context.CancellationToken.ThrowIfCancellationRequested();
//Do other stuff...
}
}
This seems to work correctly, in fact when if cancel the job, by calling the following code
scheduler.Interrupt(myJobKey);
the job stops when it hits the next ThrowIfCancellationRequested() instruction.
However, the problem is that I have a IJobListener that, when a job finishes, needs to check if the job was cancelled or if it finished correctly. I've tried to implement it like this:
public Task JobWasExecuted(IJobExecutionContext context, JobExecutionException jobException, CancellationToken cancellationToken = default(CancellationToken))
{
if(jobException != null && jobException.InnerException is OperationCanceledException){
//doesn't work, when a OperationCanceledException was raised as a result of calling ThrowIfCancellationRequested() jobException is null
}
if(cancellationToken.IsCancellationRequested){
//doesn't work either, IsCancellationRequested is always false
}
}
What am I missing here? I currently have a workaround where I set the job context's Result property to a custom value that tells me that the job was cancelled, but surely there's a "proper" way to do this?
I found out the problem: apparently I should be the one to manually throw JobExecutionException inside the job's Execute method, Quartz doesn't automatically do it when the method throws any other exceptions. Or, at least, it doesn't ALWAYS automatically do it, because it was doing it when I re-threw other exception types... maybe it automatically handles only some types of exceptions?
I don't know, but this works:
public class MyJob : IJob
public async Task Execute(IJobExecutionContext context)
{
//Do some stuff...
try{
context.CancellationToken.ThrowIfCancellationRequested();
}
catch(OperationCanceledException ex){
throw new JobExecutionException(ex);
}
//Do other stuff...
}
}
Related
Trying to roughly follow MSDN, I've added a hosted service after my scoped services in StartUp class.
public void ConfigureServices(IServiceCollection services)
{
...
services.AddScoped<IUtilityService, UtilityService>();
services.AddHostedService<StartupService>();
...
}
I've implemented StartAsync like this.
public class StartupService : IHostedService
{
private IServiceProvider Provider { get; }
public StartupService(IServiceProvider provider)
{
Provider = provider;
}
public Task StartAsync(CancellationToken cancellationToken)
{
IServiceScope scope = Provider.CreateScope();
IUtilityService service = scope.ServiceProvider
.GetRequiredService<IUtilityService>();
service.Seed();
return Task.CompletedTask;
}
public Task StopAsync(CancellationToken cancellationToken)
{
throw new NotImplementedException();
}
}
I've read a number of articles and blogs but it's above my ability to understand what should be returned at the end of the methods. It seems to work for now but I can clearly see that I'm breaching the idea by not using asynchronous calls and returninig a dummy (not even that at stop!) so I can safely conclude that I'm doing it wrong (although not apparently but I'm sure it's coming to bite my behind in the future).
What should I return in the implementation to ensure I'm "working with" not agains the framework?
StartAsync needs to return a Task, which may or may not be running (but ideally it should be running, thats the point of a HostedService - an operation/task that runs for the lifetime of the application, or just for some extended period of time longer than normal).
It looks like you are trying to perform extra startup items using a HostedService, instead of just trying to run a task/operation that will last for the entire lifetime of the application.
If this is the case, you can have a pretty simple setup. The thing you want to return from your StartAsync() method is a Task. When you return a Task.CompletedTask, you are saying that the work is already done and there is no code executing - the task is completed. What you want to return is your code that is doing your extra startup items that is running inside of a Task object. The good thing about the HostedService in asp.net is that it does not matter how long the task runs for (since it is meant to run tasks for the entire lifetime of the app).
One important note before the code example - if you are using a Scoped service in your task, then you need to generate a scope with the IServiceScopeFactory, read about that in this StackOverflow post
If you refactor your service method to return a task, you could just return that:
public Task StartAsync(CancellationToken)
{
IServiceScope scope = Provider.CreateScope();
IUtilityService service = scope.ServiceProvider
.GetRequiredService<IUtilityService>();
// If Seed returns a Task
return service.Seed();
}
If you have multiple service methods that all return a task, you could return a task that is waiting for all of the tasks to finish
public Task StartAsync(CancellationToken)
{
IServiceScope scope = Provider.CreateScope();
IUtilityService service = scope.ServiceProvider
.GetRequiredService<IUtilityService>();
ISomeOtherService someOtherService = scope.ServiceProvider
.GetRequiredService<ISomeOtherService>();
var tasks = new List<Task>();
tasks.Add(service.Seed());
tasks.Add(someOtherService.SomeOtherStartupTask());
return Task.WhenAll(tasks);
}
If your startup tasks do alot of CPU bound work, just return a Task.Run(() => {});
public Task StartAsync(CancellationToken)
{
// Return a task which represents my long running cpu startup work...
return Task.Run(() => {
IServiceScope scope = Provider.CreateScope();
IUtilityService service = scope.ServiceProvider
.GetRequiredService<IUtilityService>();
service.LongRunningCpuStartupMethod1();
service.LongRunningCpuStartupMethod2();
}
}
To use your cancellation token, some of the example code below shows how it can be done, by Catching a TaskCanceledException in a Try/Catch, and forcefully exiting our running loop.
Then we move on to tasks that will run for the entire application lifetime.
Heres the base class that I use for all of my HostedService implementations that are designed to never stop running until the application shuts down.
public abstract class HostedService : IHostedService
{
// Example untested base class code kindly provided by David Fowler: https://gist.github.com/davidfowl/a7dd5064d9dcf35b6eae1a7953d615e3
private Task _executingTask;
private CancellationTokenSource _cts;
public Task StartAsync(CancellationToken cancellationToken)
{
// Create a linked token so we can trigger cancellation outside of this token's cancellation
_cts = CancellationTokenSource.CreateLinkedTokenSource(cancellationToken);
// Store the task we're executing
_executingTask = ExecuteAsync(_cts.Token);
// If the task is completed then return it, otherwise it's running
return _executingTask.IsCompleted ? _executingTask : Task.CompletedTask;
}
public virtual async Task StopAsync(CancellationToken cancellationToken)
{
// Stop called without start
if (_executingTask == null)
{
return;
}
// Signal cancellation to the executing method
_cts.Cancel();
// Wait until the task completes or the stop token triggers
await Task.WhenAny(_executingTask, Task.Delay(-1, cancellationToken));
// Throw if cancellation triggered
cancellationToken.ThrowIfCancellationRequested();
}
// Derived classes should override this and execute a long running method until
// cancellation is requested
protected abstract Task ExecuteAsync(CancellationToken cancellationToken);
}
In this Base Class, you will see that when StartAsync is called, we invoke our ExecuteAsync() method which returns a Task that contains a while loop - the Task will not stop running until our cancellation token is triggered, or the application gracefully/forcefully stops.
The ExecuteAsync() method needs to be implemented by any class inheriting from this base class, which should be all of your HostedService's.
Here is an example HostedService implementation that inherits from this Base class designed to checkin every 30 seconds. You will notice that the ExecuteAsync() method enters into a while loop and never exits - it will 'tick' once every second, and this is where you can invoke other methods such as checking in to another server on some regular interval. All of the code in this loop is returned in the Task to StartAsync() and returned to the caller. The task will not die until the while loop exits or the application dies, or the cancellation token is triggered.
public class CounterHostedService : HostedService
{
private readonly IServiceScopeFactory _scopeFactory;
private readonly ILog _logger;
public CounterHostedService(IServiceScopeFactory scopeFactory, ILog logger)
{
_scopeFactory = scopeFactory;
_logger = logger;
}
// Checkin every 30 seconds
private int CheckinFrequency = 30;
private DateTime CheckedIn;
protected override async Task ExecuteAsync(CancellationToken cancellationToken)
{
int counter = 0;
var runningTasks = new List<Task>();
while (true)
{
// This loop will run for the lifetime of the application.
// Time since last checkin is checked every tick. If time since last exceeds the frequency, we perform the action without breaking the execution of our main Task
var timeSinceCheckin = (DateTime.UtcNow - CheckedIn).TotalSeconds;
if (timeSinceCheckin > CheckinFrequency)
{
var checkinTask = Checkin();
runningTasks.Add(checkinTask);
}
try
{
// The loop will 'tick' every second.
await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
}
catch (TaskCanceledException)
{
// Break out of the long running task because the Task was cancelled externally
break;
}
counter++;
}
}
// Custom override of StopAsync. This is only triggered when the application
// GRACEFULLY shuts down. If it is not graceful, this code will not execute. Neither will the code for StopAsync in the base method.
public override async Task StopAsync(CancellationToken cancellationToken)
{
_logger.Info($"HostedService Gracefully Shutting down");
// Perform base StopAsync
await base.StopAsync(cancellationToken);
}
// Creates a task that performs a checkin, and returns the running task
private Task Checkin()
{
return Task.Run(async () =>
{
// await DoTheThingThatWillCheckin();
});
}
}
Notice you can also override the StopAsync() method to do some logging, and anything else needed for your shutdown events. Try to avoid critical logic in StopAsync, as its not guaranteed to be called.
I have a service framework that contains many services and I can see each service's status in a web panel as well. So, in my solution:
In StartAsync method, I initialize and start all jobs, so the system waits for the jobs to be finished, after finishing, I return Task.CompletedTask
In StopAsync, I try to stop all jobs and ensure they're stopped successfully, then return Task.CompletedTask
I am developing an ASP.NET Core 3.1 API for my React front end app.
My problem is that my exceptions are not trickling up through my object hierarchy as I expect. I think it might be due to some multi-threading issue, but I don't know enough about C# to be sure! I am learning on Pluralsight, but I'm currently studying networking, which is not going to help me with this!
The calling code is a SignalR Hub method, that looks like this:
public async Task<bool> UpdateProfile(object profileDto)
{
try
{
ProfileDTO profile = ((JsonElement) profileDto).ToObject<ProfileDTO>();
_profile.UpdateProfile(profile);
return true;
}
catch (Exception e)
{
return false;
}
}
I would expect that any exceptions thrown or not handled in _profile.UpdateProfile(profile); would cause the exception block here to return false. My UpdateProfile() looks like this:
public void UpdateProfile(ProfileDTO profileDto)
{
_databaseService.ExecuteInTransaction(async session =>
{
// simulate an error
throw new Exception("Some exception");
});
}
...and my ExecuteInTransaction() looks like this:
public async void ExecuteInTransaction(Func<IClientSessionHandle, Task> databaseAction)
{
using var session = await Client.StartSessionAsync();
try
{
session.StartTransaction();
await databaseAction(session);
await session.CommitTransactionAsync();
}
catch(Exception e)
{
await session.AbortTransactionAsync();
throw e;
}
}
I would expect that the exception thrown in UpdateProfile() would trickle up to the catch block in ExecuteInTransaction() — which it does — but then further, I would expect this exception to trickle up to the Hub UpdateProfile() method. Instead, it ends up in the Throw() method on the ExceptionDispatchInfo class in the System.Runtime.ExceptionServices namespace.
Reading through the comments in this file makes me think it is a threading issue, but I don't know enough about how threading works yet in C#. Is it possible for the exceptions thrown in UpdateProfile() to make it up to the top level of my Hub UpdateProfile()? (just noticed they confusingly have the same name).
Your problem is the async void signature of ExecuteInTransaction.
Async void methods have different error-handling semantics. When an exception is thrown out of an async Task or async Task method, that exception is captured and placed on the Task object. With async void methods, there is no Task object, so any exceptions thrown out of an async void method will be raised directly on the SynchronizationContext that was active when the async void method started
Source
What this means, if you're using ASP.NET Core where there is no SynchronizationContext, your exception will be thrown most likely on a threadpool thread if you didn't mess around with the TaskScheduler. If you're on older .NET framework code, it will be on the captured context but either way, what you know about exception handling does not apply here. You can catch these exceptions by subscribing to AppDomain.UnhandledException but no one wants to do that in maintainable code.
To fix this, change public async void ExecuteInTransaction to public async Task ExecuteInTransaction, change public void UpdateProfile to public async Task UpdateProfile and call it like so:
public async Task<bool> UpdateProfile(object profileDto)
{
try
{
ProfileDTO profile = ((JsonElement) profileDto).ToObject<ProfileDTO>();
await _profile.UpdateProfile(profile);
return true;
}
catch (Exception e)
{
return false;
}
}
public async Task UpdateProfile(ProfileDTO profileDto)
{
await _databaseService.ExecuteInTransaction(async session =>
{
// simulate an error
throw new Exception("Some exception");
});
}
When I am using async await and an exception is thrown the thread context is being lost. In my code I'm using dependency injection that registered to resolve per thread so I need to execute my code on the same thread.
This is how it is setup:
I have a method that will try calling different communicators using async when one throws an exception it will go onto the next one:
public async Task<TResponse> VisitRequestAsync(Context context)
{
/* ....
prepare request from context
.... */
var communicatorEnumerableInstance = _communicatorService.GetCommunicatorInstanceEnumerable();
foreach (var communicator in communicatorEnumerableInstance)
{
using (communicator)
{
var communicatorInstance = communicator as ICommunicator<TResponse, TRequest>;
try
{
return await communicatorInstance.ProcessAsync(request).ConfigureAwait(true);
break;// call will break out of the for-each loop if successful processed.
}
catch (Exception exception)
{
continue;// Continue to load next communication method/instance
}
}
}
}
Below is a unit test that contains a communicator that always throws an exception and one that tries to get a dependency that is registered onto the original thread.
public class TestDependancy : ITestDependancy
{
}
public interface ITestDependancy
{ }
public class TestCommunicatorThrowsException :
ICommunicator<ResponseType, RequestType>
{
public async Task<ResponseType> ProcessAsync(RequestType request)
{
var task = Task.Run(() =>
{
throw new Exception();
return new ResponseType();
});
return await task;
}
public void Dispose()
{
}
}
public class TestCommunicatorGetsDependency :
ICommunicator<ResponseType, RequestType>
{
public TestCommunicatorGetsDependency()
{ }
public async Task<ResponseType> ProcessAsync(RequestType request)
{
TestDependancy = DefaultFactory.Default.Resolve<ITestDependancy>();
var task = Task.Run(() => new ResponseType());
return await task;
}
public ITestDependancy TestDependancy { get; set; }
public void Dispose()
{
}
}
[TestMethod]
[TestCategory("Unit")]
public async Task it_should_be_able_to_resolve_interface_from_original_thread()
{
var secondCommunicator = new TestCommunicatorGetsDependency();
_communicators = new ICommunicator<ResponseType, RequestType>[]
{new TestCommunicatorThrowsException(), secondCommunicator};
_communicatorServiceMock.Setup(
x => x.GetCommunicatorInstanceEnumerable(It.IsAny<string>(), It.IsAny<string>()))
.Returns(_communicators);
((IFactoryRegistrar) DefaultFactory.Default).RegisterPerThread<ITestDependancy, TestDependancy>();
var firstInstance = DefaultFactory.Default.Resolve<ITestDependancy>();
await it.VisitRequestAsync(_context).ConfigureAwait(true);
var secondInstance = secondCommunicator.TestDependancy;
Assert.AreEqual(firstInstance, secondInstance);
}
When the dependencies are resolved in the unit test they are not equal. After looking into it I see that the value for CurrentThread.ManagedThreadId changes at the point when the exception gets thrown. Then when it is caught in the VistRequestAsync method the CurrentThread.ManagedThreadId is never restored to its original state. So then the dependency injection is unable to get the same instance because it is now operating on a different thread.
Originally, I was using .ConfigureAwait(false) with the await. Then I tried setting it to true and I started seeing it sometimes get the same thread back. Which sounds a lot like what is said in this answer.
This post about the synchronization context and async sounds a lot like the problem I am facing. My trouble is I'm using WebApi and need a response back when things get done so I'm not sure how to use his message pump and asynchronously wait for an answer.
Async uses the ThreadPool to process tasks. This means that there is no guarantee that an async operation will start and complete on the same thread.
When a async task is first awaited, the task is put on a work queue. As soon as possible, the task scheduler grabs that task from the queue and assigns it to one of the many available threads.
For more information, see this overview of the structure of the TPL: https://msdn.microsoft.com/en-us/library/dd460717(v=vs.110).aspx.
If you need a context that flows with the thread, look at using something like the logical call context or CallContext.LogicalSetData / LogicalGetData.
But the behavior you're seeing is correct, and as mentioned has nothing to do with whether or not an exception is thrown. You'll see different thread ids at various points of an asynchronous task's scheduling, execution, and completion.
I'm currently developing job manager based on Quartz.net. I want to be able to display job execution status in real time so when job interruption request is made I could save context.JobDetail.JobDataMap.Put("status", "interrupting"); in job data map and read this status by fetching all currently executing jobs in scheduler. But, the problem, is I do not have access to IJobExecutionContext context object directly in Interrupt() method, so I cannot set interrupting status immediately at the moment interruption was requested. This is the functionality I basically want to achieve:
class InterruptedException : Exception { }
[PersistJobDataAfterExecution, DisallowConcurrentExecution]
class MyJob : IInterruptableJob
{
private bool _interrupted;
private void AssertContinue()
{
if (_interrupted) throw new InterruptedException();
}
public void Execute(IJobExecutionContext context)
{
try
{
context.JobDetail.JobDataMap.Put("status", "started");
AssertContinue();
// Do the work
AssertContinue();
context.JobDetail.JobDataMap.Put("status", "completed");
}
catch (InterruptedException)
{
// Set interrupted status when job is actually interrupted
context.JobDetail.JobDataMap.Put("status", "interrupted");
}
catch
{
// log any othe errors but set interrupted status only on InterruptedException
}
}
public void Interrupt()
{
_interrupted = true;
// I want to set interrupting statues here!!!
context.JobDetail.JobDataMap.Put("status", "interrupting");
}
}
The basic idea of IInterruptableJob interface implementation, as I understand, is to set some _interrupted flag value to true inside void Interrupt() method, then check this flag value on each execution step in Execute() method. So, basically, we cannot interrupt the job immediately, we can make interruption request, and only when interruption status check is executed we can interrupt the job by throwing an exception, for example. But I want to set interrupting status for my job during this short period of time. How can I do that? Is it even possible to get IJobExecutionContext context object in Interrupt() method?
Well, the solution turns out to be pretty obvious and easy. I just have to create private
IJobExecutionContext _context = null;
field of my job class and set it's value to context in Execute() method.
public void Execute(IJobExecutionContext context)
{
_context = context;
...
}
Basically we can interrupt only the executing job so if Interrupt() is called than Execute() was called at least once so this approach, basically, suits my needs and updates job's DataMap immediately after Interrupt was called.
In an ASP.NET Web API project, I have an action filter which checks for model state errors and returns the Bad Request status code if there are any. It looks like this:
public class ValidationFilter : IActionFilter
{
public Task<HttpResponseMessage> ExecuteActionFilterAsync(HttpActionContext context,
CancellationToken cancellationToken,
Func<Task<HttpResponseMessage>> continuation)
{
if(!actionContext.ModelState.IsValid)
{
return new Task<HttpResponseMessage>(() =>
actionContext.Request.CreateErrorResponse(HttpStatusCode.BadRequest,
actionContext.ModelState);
}
return continuation();
}
}
Now, for some reason, any request with a model state error never returns. It just hangs there. If I debug, I get to the next filter in the pipeline, which starts with
var result = await continuation();
If I "Step Over" that line, the debugger sort of drops out to "waiting" mode, but no more code seems to be run.
I assume all of this is because I've somehow misunderstood how all these things interact, but despite hours of googling and reading, I still can't figure out how to make this work properly. Any help - both for understanding and bugfixing - is deeply appreciated.
You never start your task. You need to call Start when you use the Task constructor. Instead of calling the constructor and then Start a better option would be to use Task.Run:
if(!actionContext.ModelState.IsValid)
{
return Task.Run(() =>
actionContext.Request.CreateErrorResponse(HttpStatusCode.BadRequest,
actionContext.ModelState);
}
In your case there's nothing really asynchronous about your operation, so you can simply use Task.FromResult to create a task with the result you get synchronously:
public Task<HttpResponseMessage> ExecuteActionFilterAsync(
HttpActionContext context,
CancellationToken cancellationToken,
Func<Task<HttpResponseMessage>> continuation)
{
if(!actionContext.ModelState.IsValid)
{
return Task.FromResult(actionContext.Request.CreateErrorResponse(
HttpStatusCode.BadRequest,
actionContext.ModelState);
}
return continuation();
}