Changes:

• Updated nuclei(IO system) and lever(transactional memory) to use latest parking_lot respectively.

Getting Started | Examples | API documentation

What is new?

This release is coming with exciting features:

• Agnostik executor runtime
  • With Agnostik, Bastion can run on any runtime. Head over to the agnostik project for more information.
• Nuclei , an agnostic proactive IO system
  • With nuclei and agnostik, IO and executors are separated.
  • You can mix and match any executor with agnostik and use the same IO system.
  • Nuclei is based on Proactive IO.
  • Nuclei supports io_uring and works well with completion based evented IO. Windows support is currently in the works.
  • Completely async, can be independently used from Bastion.
    • It will power Bastion’s IO system and ecosystem.
• Autoscaling feature for actors
  • Right now with the scaling feature enabled, you can create actor groups in Bastion that will adapt to incoming workload according to given resizer parameters.
  • Example construction is like:

    children
        .with_redundancy(3) // Start with 3 actors
        .with_heartbeat_tick(Duration::from_secs(5)) // Do heartbeat each 5 seconds
        .with_resizer(
            OptimalSizeExploringResizer::default()
                .with_lower_bound(1) // A minimal acceptable size of group
                .with_upper_bound(UpperBound::Limit(10)) // Max 10 actors in runtime
                .with_upscale_strategy(UpscaleStrategy::MailboxSizeThreshold(3)) // Scale up when a half of actors have more than 3 messages
                .with_upscale_rate(0.1) // Increase the size of group on 10%, if necessary to scale up
                .with_downscale_rate(0.2), // Decrease the size of group on 20%, if there are too many idle actors
        )

• Cluster/distributed actors
  • After some extensive testing of the Artillery protocol, we are super thrilled to show SWIM based epidemic cluster for Bastion. (SWIM stands for ****Scalable Weakly-consistent Infection-style Membership, we know it’s a mouthful, visit this blog post if you would like an introduction https://asafdav2.github.io/2017/swim-protocol/). You can see example code for cluster execution in here: https://github.com/bastion-rs/showcase/tree/master/bastion-cluster
  • You can see a ping pong cluster example here: https://twitter.com/vertexclique/status/1273945945126973440
• Named child in children groups
  • Right now you can get the names of the child in children groups. You can use that for logging or anything that comes to mind.
  • With this enabled everything is user readable content addressable in Bastion runtime.
• Heartbeat for children
  • Now runtime continuously watches children with heartbeat to check their status and do sampling over their internals.
  • This feature doesn’t require any feature flags.
  • Used in scaling example as seen above:

    children
        .with_heartbeat_tick(Duration::from_secs(5)) // Do heartbeat each 5 seconds

• Dispatchers allow you to route specific messages to specific groups and collect messages from them.
  • This enables creating various fan-outs and fan-ins, and streaming data processing implementations.
  • An example of dispatcher system can be found in: https://github.com/bastion-rs/bastion/blob/master/src/bastion/examples/round_robin_dispatcher.rs#L4
• Dead letters mailbox so undelivered messages can be processed or monitored later on.
• Lockfree runtime statistics sampling for run queue offloading.
• Actor registry support
• Restart strategy for actors:
  • We have written a restart strategy for actors, so they can be restarted with various backoff strategies like linear, exponential etc. Moreover, if panic or error occurs in your actors, you can define a max restart policy to give up after n attempts, or maybe never ? maybe you don’t want to restart at all…

    // At the beginning we're creating a new instance of RestartStrategy
    // we then provide a policy and a back-off strategy.
    let restart_strategy = RestartStrategy::default()
        // Set the limits for supervisor, so that it could stop
        // after 3 attempts. If the actor can't be started, the supervisor
        // will remove the failed actor from tracking.
        .with_restart_policy(RestartPolicy::Tries(3))
        // Set the desired restart strategy. By default supervisor will
        // try to restore the failed actor as soon as possible. However,
        // in our case we want to restart with a small delay between the
        // tries. Let's say that we want a regular time interval between the
        // attempts which is equal to 1 second.
        .with_actor_restart_strategy(ActorRestartStrategy::LinearBackOff {
            timeout: Duration::from_secs(1),
        });

• Adapted NUMA allocator to latest Alloc API to make use of it easily with Bastion.

Getting Started | Examples | API documentation

Bastion 0.3.0 is here, and it is a huge milestone for the project.

Features were added, the API was upgraded, the code was cleaned up, bugs were smashed but most importantly, Bastion is more powerful than it has ever been.

Don't forget to check out our examples directory and especially getting_started.rs

What's new

• Bastion uses std::future::Future.
• Children execute a std::future::Future with Result<(), ()> as an output to indicate whether they stopped or faulted.
• Messages can be sent to children directly, which can receive and eventually answer to them (using msg! and answer!).
• Messages can be broadcasted to the whole system, a supervisor's supervised elements or a children group's elements (using Bastion, SupervisorRef and ChildrenRef).
• The system, supervisors, children groups and children can be stopped or killed remotely (using Bastion, SupervisorRef, ChildrenRef and ChildRef).
• Supervisors can supervise others supervisors (they can still supervise children groups when doing so).
• Supervisors can get asked to supervise new children groups and supervisors after being created (using SupervisorRef).
• Supervisors' supervision strategy can be changed after being created (using SupervisorRef).
• Callbacks can be defined for children groups and supervisors to execute code on some of their lifecycle events (before_start, before_restart, after_restart and after_stop).
• Children contexts allow to access the child, children group or supervisor (using .current(), .parent() or .supervisor()).
• Bastion uses its own executor (bastion-executor) and processes abstraction (lightproc).
• Bastion supports using a NUMA-aware allocator (with a fallback on systems not supporting it) via the unstable feature.