Priority queue

[hardliner66]

I'm currently experimentally trying to port code from CAF/C++ to Stakker. The code basically deals with package parsing, where there are header and data packages. The original code sometimes had to re-queue a message, but with a higher priority than the other messages.

To implement the same thing in Stakker, it seems I would need to use the lazy queue by default in order to do something like this. Is this correct or can I somehow send messages with a higher priority?

Edit: I think using the at macro with Instant::now() might work, but I have no idea what happens if the desired instant is in the past already.

[uazu]

It seems strange to handle parsing with asynchronous calls, since parsing is synchronous. Does it really need to be connected up by asynchronous calls? So one question is whether the architecture is mapped to the actor model in a natural way. But I will suppose there is a good reason why it has to be done this way.

There is no support for queue-jumping or anything like that in Stakker, at least not on the main queue. If you submit something to the lazy queue, that will run after everything else has been completed. So if you submit all new messages via the lazy queue, then if you resubmit the message via the main queue, then that will be run before the next message is processed from the lazy queue. So that should get you what you want.

The intention is that you limit data flow into the actor system, i.e. don't submit something to the actor system until you're sure you want to pay the cost of processing it. The lazy queue is intended as the mechanism to limit flow of data into the system (e.g. typically by fetching more data lazily).

Stuff on the timer queue will get processed after the current calls on the main queue are cleared. Timers set before 'now' get processed at the first opportunity, i.e. as if it is set for 'now'. It doesn't really help in this situation.

[hardliner66]

Makes sense, thanks for clarifying.

As for the "need":
No, it doesn't need to be handled this way, but it ties into the whole become thematic. I see actors as concurrent state machines, responding to events. So in this use case I'm not seeing it as receiving the wrong message, but being in the wrong state for the message I received. In other frameworks I would then basically requeue my message and switch my state, so then the message will get handled correctly as if it were in the right state in the first place.

I can certainly work around this, but I'd definitely prefer to use messages for this because this fit's the actor model more. If you get a failure in an actor, the idiomatic way to handle a failing actor is to try restarting it with a known good state and sending the message again. So it makes sense to do similar things when a wrong message arrives, but I also don't want to necessarily kill the actor for that.

So while it might not be the most efficient way to deal with this, it's the most actor way to deal with this.

Also, there isn't that much parsing going on. The whole thing more or less just listens for messages, decides what they are (Header or Data) and consolidates the values and routes them to the appropriate services. The current implementation as thread based and I'm evaluating different actor frameworks to see which one would fit our use-cases best.

In the long run, it is planned to utilize the actor model for more than this, but I decided to start with a prototype of a single application first.

[uazu]

Okay, that's interesting. If you've implemented the actor state as an enum, and the actor finds itself in the wrong state for the protocol received, it can update the enum to a new value, log the error and then call itself directly (synchronously) to handle it. I also don't see this as a reason to kill the actor, e.g. if it's well-defined handling of a recoverable error condition.

However having the actor fail and then starting a new one up does have some logic to it, and it is not too costly. It also has the advantage that all pending calls to that failed actor will now be dropped as they arrive. But it also means that you need to have some management outside of the actor to remember the message and retry it. Maybe it separates the concerns better, though.

I can see the logic of your approach anyway.

[hardliner66]

Yeah, there are a few approaches to this. Having control messages you send to yourself keeps things at the same level of abstraction and reduces the amount of things you need to do per message-state combination.

There is also the possibility to send high prio messages from the outside, where one part of your system detects a problem and needs to send it to another part of the system to change the behavior of that system.