Bastion v0.4.0

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.