Separating the consumer from the workers that perform task execution. This allows for multi-tasking.
I'm not going to implement multi-tasking right now. I can then treat this as a FIFO queue and worry less about ordering. Also, I can limit the amount of locking on the Sqlite database.
I will separate out consuming messages from working on them. Right now it seems a MailboxProcessor is a good option.
Workflow
type StopFlag =
| None
| Shutdown
type Consumer(timeoutMs = 1000) =
let worker = MailboxProcessor()
let mutable stopFlag = None
member rec _.Loop() =
if sopFlag = Shutdown then
shutdown
()
else
try
dequeTask
|> worker.exec
with ex -> log ex
Thread.sleep time
this.Loop()
let private handleSignals consumer =
// hook up the signals to stop the consumer
if SIGIT
consumer.Shutdown()
()
let main argv =
let consumer = new Consumer()
handleSignals consumer
consumer.Loop()
0
Exception Handling
Exceptions should not terminate the process. Rather, they should cause any current task to still be in the queue. At some point I'll need to add dead-letter handling.
References
Consuming Messages
Huey has some smart features added:
I'm not going to implement multi-tasking right now. I can then treat this as a FIFO queue and worry less about ordering. Also, I can limit the amount of locking on the Sqlite database.
I will separate out consuming messages from working on them. Right now it seems a
MailboxProcessor
is a good option.Workflow
Exception Handling
Exceptions should not terminate the process. Rather, they should cause any current task to still be in the queue. At some point I'll need to add dead-letter handling.