v0.7.5

This release includes a single fix identified in issue #70 where utilizing the

ActorRef::where_is

method would fail to resolve a properly named actor because it was checking the wrong type.

Associated PR: #72

Additionally there's some more test coverage and documentation additions along with the link to the new ractor website (slawlor.github.io/ractor)

Full changelog: v0.7.4...v0.7.5

v0.7.4

Ractor 0.7.4 is released!

Big news is we have a logo! Plus this improves test coverage and documentation

Full changelog:
v0.7.3...v0.7.4

v0.7.3

Ractor v0.7.3 is released!

This release includes:

1. Updated documentation + tests
2. A small bug fix from #57 where send_interval can drift over long periods
3. [cluster] upgrades for encrypted connections + transitive connections in cluster connections

Full changelog: v0.7.2...v0.7.3

v0.7.2

Ractor version 0.7.2 adds support for instant spawning!

This release adds support for spawning actors "instantly" in that we don't wait on the pre_start routine. This is helpful if you want to immediately have access to the ActorRef<TActor> so you can begin sending messages to it without blocking on the pre_start routine.

However if the pre_start fails for any reason, it won't be captured unless the specific join handle is handled manually to monitor the spawning error. Internal documentation is updated to reflect this. Additionally since this is a specialized feature, the functionality is not supported directly on the Actor trait, but only with usage of the ActorRuntime directly.

Additionally we're adding a small auto-implementation for types which implement BytesSerializable such that they are automatically implementing ractor::Message and can be network-sent. This makes most of the built-in numeric types, (), Strings, and vectors of such able to directly used as message types in a cluster context.

v0.7.1

Ractor v0.7.1 is released!

This release includes the new ractor::factory::Factory definition to manage a pool of workers which are user defined. Workers execute jobs which the factory can dispatch according to a set of routing mechanisms. Factories as useful for dispatching multiple jobs in parallel when the limits of a single actor may not be sufficient. Additionally in order to maintain the serial nature of some operations (C requires B first, which requires A, etc) you can utilize persistent key routing mechanisms or sticky queuer routing to maintain that jobs land on the same node. Explore more in the docs and tests for usage examples.

Additional functionality includes support for internal queue of messages on a factory, dead-man worker detection (i.e. a worker may be deadlocked or is "stuck), statistics on message and factory routing, and message discarding for graceful load shedding.

Documentation is still a little light and will evolve in future releases but the feature can be considered stable for use in both local node configurations and remote cluster configurations as the jobs are network serializable if the inner message is.

Full changelog: v0.7.0...v0.7.1

v0.7.0

Ractor v0.7.0 is released!

This is a small breaking change from v0.6.X in that we've added support for an Arguments to be passed to pre_start on actor initialization. This allows you to pass owned args to an actor's startup routine, rather than reading shared values from &self.

This is helpful if you need to say consume values in an actor's initialization. For example, taking a TcpSocket and breaking it into OwnedReadHalf and OwnedWriteHalf means that pre_start can't have a shared reference to the socket. This also should remove the need for "initialization" messages for most actors.

v0.6.1

Ractor v0.6.1 is released!

Version 0.6.1 includes

1. More solid testing of ractor_cluster for both unit tests and some e2e testing in Docker with a "live" networked cluster. This will be additionally where we add more functional testing going forward
2. A lot of automatic implementation of serialization for built-in types. Namely all numeric formats (i8..i128, u8..u128, f32, f64) , char, Strings, and vectors of said values. This helps with message formatting for inner types. There's also a macro to generate the serialization logic for prost::Message implementations, which can be used as simply as

ractor_cluster::derive_serialization_for_prost_type!{MyCustomType}

3. Moving from checking the actor type on pushing a message to the actor's message type. This means that you could create another actor (say Actor2) which has the same message type as Actor1 and send a message to it. This allows you to do things like

let actor2: ActorRef<Actor2> = ...;
let actor2_as_actor1: ActorRef<Actor1> = actor2.get_cell().into();

which will only allow message passing if the actors share the same message type. This is helpful for mocking actors by creating "temporary" dummy actors which modified behavior (for examples, see `ractor_cluster/src/node/node_session/tests.rs1).

Full changelog: v0.6.0...v0.6.1

v0.6.0

Introducing ractor_cluster! This crate facilitates distributed processing with ractor actors. This should be considered a pre-release version, but initial verifications have indicated the logic is sound.

Please feel free to utilize it and report any issues or missing features!

v0.5.1

Introducing ractor_cluster! This crate facilitates distributed processing with ractor actors. This should be considered a pre-release version, but initial verifications have indicated the logic is sound.

Please feel free to utilize it and report any issues or missing features!

v0.5.0

Ractor v0.5.0 is released!

This contains 2 major updates

1. Adding support for non-panic level errors in message and actor handers. This resolves #33 and is handled in a generic way, so handlers receive a Box<dyn Error + Send + Sync + 'static>.
2. The lions share of the changes here is initial support for remote actors. This includes changes in both ractor and a new crate ractor_cluster (#32). This is tracked in a longer running issue #16