[Question] Can Factory Controls Workers Through State?

[chaozwn]

Hello, author!

First of all, thank you so much for providing us with such an excellent actor framework like Ractor. It has been incredibly helpful in our development process. Recently, I encountered a design scenario where I need to create a worker that sends API requests, implemented as a standalone actor. The functionality I’m aiming for is to allow this worker to continuously send concurrent requests. However, when it encounters a 429 Too Many Requests response from the server, the actor should pause its operations for a few seconds before resuming.

Here’s my initial approach: I implemented this within a single actor, using Tokio to spawn multiple threads while maintaining the actor's state. If a 429 response is received, the actor automatically transitions to a pending state to pause further requests.

The official documentation, however, recommends using a factory. I’m a bit unclear on how to manage multiple workers through a factory, especially when it comes to state management. Specifically, I’m wondering if a factory can maintain a shared state. For example, if multiple workers encounter a 429 response, could the factory facilitate pausing all workers simultaneously for a certain period of time?

Looking forward to your guidance and suggestions!

[slawlor]

Hmmm I think this might be beyond the functionality of a factory and you'll likely want to hand build your own use case for this. However factories in ractor can definitely provide guidance for how to manage a child's lifecycle, etc

The only thing I could think of is if you write your own queue implementation and like pause releasing new items from the queue but that might break some assumptions on how a queue is used, since the queue wouldn't be empty etc.

I think you're probably best going your own way on this since the parent isn't just managing the lifecycle and message routing but has some higher level state involvement that we don't currently have the flexibility for.

P.s. thanks for using the crate and the feedback!

[chaozwn]

Hmmm I think this might be beyond the functionality of a factory and you'll likely want to hand build your own use case for this. However factories in ractor can definitely provide guidance for how to manage a child's lifecycle, etc

The only thing I could think of is if you write your own queue implementation and like pause releasing new items from the queue but that might break some assumptions on how a queue is used, since the queue wouldn't be empty etc.

I think you're probably best going your own way on this since the parent isn't just managing the lifecycle and message routing but has some higher level state involvement that we don't currently have the flexibility for.

P.s. thanks for using the crate and the feedback!

thanks for your response. but if I use tokio::spawn within an actor handle, it should work, right? Does it align with the ractor design philosophy?

[slawlor]

I mean spawning inside an actor is fine as long as you manually wire up the failure flows. If a spawned task panicked it failed, is it handled and how does the actor respond?

Spawning child actors is probably how I'd expect it to be done so the supervision of the child tasks is automatic but that's up to you

[chaozwn]

I mean spawning inside an actor is fine as long as you manually wire up the failure flows. If a spawned task panicked it failed, is it handled and how does the actor respond?

Spawning child actors is probably how I'd expect it to be done so the supervision of the child tasks is automatic but that's up to you

Got it. BTW, in ractor, besides the actor name manually specified by the user, is there a unique actor_id generated automatically? If so, how can it be retrieved?

[slawlor]

Yes and there's an accessor on the ActorRef.

https://github.com/slawlor/ractor/blob/main/ractor/src/actor/actor_cell.rs#L294