A few questions

[AllTaken]

Hi. I haven't been able to find answers to the following in the Wiki, and I hope you can help me:

How do I configure Heartbeat frequency?
How do I configure Heartbeat timeout?
How do I configure Heartbeat retries?
How do I configure retries on exceptions?
How do I (is it possible to?) configure actions to take if the last retry also fails?

[blehnen]

Hi,

You can configure the heartbeat strategy like this:

//set a heartbeat every 20 seconds
queue.Configuration.HeartBeat.UpdateTime = "sec(*%20)";

//check for dead records every 60 seconds
queue.Configuration.HeartBeat.MonitorTime = TimeSpan.FromSeconds(60);

//records with no heartbeat after 180 seconds are considered dead
queue.Configuration.HeartBeat.Time = TimeSpan.FromSeconds(180);

While you cannot directly configure a heartbeat retry, the heartbeat worker will keep trying to set a heartbeat every time the 'UpdateTime' is hit. So in the above example, it would have to fail around 9 times or so before being considered stale.

You can see how to configure exception retries here:

https://github.com/blehnen/DotNetWorkQueue/wiki/RetryDelayConfiguration

If you wanted to 'do something' on a fatal error or the retry limit being hit, you would need to do some overridding / injection of the default classes. If you just want to add additional logic, see this post here:

#7 (comment)

[AllTaken]

Thank you.
A couple of follow up questions:

Are messages where the heartbeat has expired (Configuration.HeartBeat.Time has elapsed with no heartbeat) immediately re-queued?

Is there any limit to re-queuing because of expired heartbeat?

What distinguishes a FatalException (as in something that will use the FatalExceptionDelayConfiguration) and "other" Exceptions (as in something that can use RetryDelayConfiguration)?

[AllTaken]

Also: is there any way for the workerAction to know which (if any) retry it is currently at?

[blehnen]

Are messages where the heartbeat has expired (Configuration.HeartBeat.Time has elapsed with no heartbeat) immediately re-queued?

They will be re-queued based on how often you are checking for dead records, which is controlled by this setting

//check for dead records every 60 seconds
queue.Configuration.HeartBeat.MonitorTime = TimeSpan.FromSeconds(60);

Is there any limit to re-queuing because of expired heartbeat?

There is no limit on how often a item will be re-queued due to a heartbeat

What distinguishes a FatalException (as in something that will use the FatalExceptionDelayConfiguration) and "other" Exceptions (as in something that can use RetryDelayConfiguration)?

Fatal exceptions are only encountered when a worker tries to de-queue an item. Retry exceptions occur when an unhandled exception from the callback is encountered.

[blehnen]

Also: is there any way for the workerAction to know which (if any) retry it is currently at?

There is nothing built in that reports this. I suppose you could directly query the table/storage that tracks this. I'll consider passing this information as part of the worker notification interface. It would need to be <ExceptionType, RetryCount>, as there could be multiple exceptions configured that trigger retries.

[AllTaken]

I suppose you could directly query the table/storage that tracks this.

Is there any built-in method(s) for querying the storage? I would be a shame to have to have a hard coupling.

[blehnen]

Well, the internal methods for querying this weren't really written to be used externally. Creating your own instance of the QueryHandler would be tricky due to the dependencies.

The SQL statements are pretty basic however, and can all be viewed here for SQL server:

https://github.com/blehnen/DotNetWorkQueue/blob/0b7b7b6a5125d996fcd8c89299db92c7bc187dcf/Source/DotNetWorkQueue.Transport.SqlServer/Basic/SqlServerCommandStringCache.cs

I will probably add the error counts at some point, but that's probably not going to be real soon.