What alternatives are available after the removal of the monitor API?

[phil-skillwon]

@slawlor
The first version I worked with was ractor-0.9.2, where the monitor API was available for monitoring other actors. This API was highly convenient and frequently used. Recently, in my new project using ractor-0.14.2, I noticed that the monitor API was no longer present. After checking the Changelog, I discovered that the monitor API was entirely removed starting from ractor-0.11.0. This is quite unfortunate.

Previously, you described Ractor as "A pure-Rust actor framework inspired by Erlang's gen_server, with the speed and performance of Rust!" I enjoy using the actor model in my projects and consider the monitor API a core feature of the actor model, on par with link. Although not always necessary, the monitor API is a standard feature for the actor model. Without it, the model feels incomplete.

Similar breaking changes occurred in CAF (C++ Actor Framework) when the class group and related APIs were removed. However, CAF users could still use multicaster<T> or publisher<T> to achieve functionality similar to group.

Typical use cases for the monitor API include:

1. Network Connection Management: A ConnectActor manages automatic reconnections of a TCP client to the server. When the connection succeeds, a TcpSessionActor is dynamically created and monitored using the monitor API. If the connection is interrupted, ConnectActor receives an ActorTerminated message, retries the connection, and creates a new session once connected.

2. File Upload Service: In a file upload service, each upload request spawns an UploadActor to handle the file data. A "management" actor monitors active UploadActors for better session management.

3. IoT Device Management: In IoT systems, devices like cameras or sensors have individual DeviceActors for communication. A central DeviceManagerActor monitors these DeviceActors to handle offline devices or trigger reconnection and alerts.

4. Payment Processing System: For online payments, each transaction spawns a PaymentSessionActor to handle communication with payment gateways. A PaymentManagerActor monitors the payment process and handles retries or user notifications in case of failures.

In all these scenarios, the core idea is the same: a "manager" actor monitors a "worker" actor, receiving ActorTerminated messages upon the latter's exit. This demonstrates the robustness and self-healing capabilities of the actor model.

So, is the monitor API truly unavailable in versions after ractor-0.11.0? Or could you consider providing some basic infrastructure that allows users to implement the monitor API themselves?

[slawlor]

Hello! Yes, the monitor API was deprecated in 0.11 due to excessive memory allocation use with each instantiated actor. It's possible we could add it back under a feature gate, which would allow people to opt-in to the functionality if necessary.

From users, we also had no reported usage of the API, so it was debatable the value it brought in the system which also contributed to the deprecation. If you want, you can pretty trivially add it back by undoing what the removal PR did, and gate the struct fields and associated methods with a feature. I don't think I'll have time to do it immediately, but we did have enough test coverage that was originally removed, so undoing the removal and adding a feature is an easy thing for a new comer to take on if you're willing!

Personally, and from production experience, I don't think it's necessary to make it a hard feature of every actor without specifically opting in. From your own examples, I would personally choose direct supervision vs monitoring in actor management. The main reason being, monitoring is only possible post-spawning an actor, meaning you race with the capture functionality on the actor's post_start functionality, or even message handling. The actor may fully start, serve traffic, prior to being able to be linked. Using direct supervision, and spawn_link you can guarantee where in the lifecycle the supervision flow is connected.

I do see some value, and possibly clearer patterns, in your examples so I agree there's value in adding the API back, but it's also a tradeoff in functionality performance (unless we maybe store the functionality as a RwLock<Option<HashMap>> where the link map is only populated on first use, to save the memory allocation. That's a valid possibility, and possibly something that's worthwhile for the supervision tree as a whole, to save storage for unsupervised actors.

[slawlor]

For reference, it was dropped specifically in PR #260

[slawlor]

I had a chance to address this functionality gap and added it back in #317. However due to the memory regression it introduces, for now it's gated behind a feature (monitors). It will be included in v0.14.4