hollywood

repository·master·Indexed 25 days ago

https://github.com/anthdm/hollywood

A high-performance, low-latency actor engine for Golang designed for real-time applications such as game servers, trading engines, and advertising brokers. It implements the actor model using the Receiver interface, supporting asynchronous messaging, synchronous requests, actor hierarchies for supervision, and remote communication via the remote package. Features include configurable inboxes with backpressure, tag-based routing, middleware for interception, and an Eventstream for system monitoring.

Tokens
3.5K
Snippets
9
Records
27
Agent score
81%

What's inside hollywood

  1. Understand the Trade-Engine Actor Pattern

    master

    The Trade-Engine example demonstrates a hierarchical actor system designed for monitoring and executing trades. It uses three distinct actor roles to manage lifecycle and responsibilities:

    1. Trade Engine Actor: The central management hub. It is responsible for spawning and overseeing the lifecycle of Price Watcher and Trade Executor actors.
    2. Price Watcher: A ticker-specific actor that monitors prices. It uses (*actor.Engine).SendRepeat to trigger periodic updates. It manages its own lifecycle by checking for active subscribers; if no subscribers exist, it stops its repetition via (actor.SendRepeater).Stop() and terminates itself using (*actor.Engine).Poison.
    3. Trade Executor: An actor that manages individual trade logic. It subscribes to a Price Watcher for a specific ticker. Upon receiving a PriceUpdate, it evaluates trade parameters. If a trade is canceled, it sends an Unsubscribe message to the Price Watcher and terminates itself using (*actor.Engine).Poison.
  2. Add Middleware to Receivers

    master
    You can implement custom middleware for your Receiver implementations. Middleware is useful for cross-cutting concerns like storing metrics, or saving/loading state during actor.Started and actor.Stopped lifecycle events.
  3. How the Actor Model works in Hollywood

    master

    In Hollywood, the basic building block is an actor (also called a Receiver). Actors are independent units of computation that communicate exclusively via message passing. Each actor maintains its own state and behavior.

    Actors can be organized into hierarchies where higher-level actors supervise lower-level ones. This allows for scalable, fault-tolerant systems where actors can operate independently even if others fail.

  4. How to handle events and errors

    master

    Because Hollywood is an asynchronous system, many issues that would typically be returned as errors are instead broadcasted as Events via an Event Stream attached to the Engine.

    One of the most critical events is the DeadLetter event, which is broadcast when a message is sent to an actor that either does not exist or cannot be reached. Refer to events.go for a complete list of available events.

  5. Using Context in actors

    master

    The Context is a struct passed to all user-supplied actors. It serves two primary purposes:

    1. Dependency Injection: It should contain all the dependencies an actor requires to perform its work.
    2. Communication: It is used by the actor to send messages to other actors.
  6. Use the Eventstream for system monitoring

    master

    The Eventstream allows you to subscribe to system-wide events to handle failures gracefully. You can subscribe an actor to a list of events or broadcast custom events.

    Commonly used events include:

    • actor.DeadLetterEvent: Sent when a message cannot be delivered to an actor.
    • actor.ActorStartedEvent / actor.ActorStoppedEvent: Lifecycle events.
    • actor.ActorRestartedEvent: When an actor restarts after a panic.
    • cluster.MemberJoinEvent / cluster.MemberLeaveEvent: Cluster membership changes.

    Important: If no actor is subscribed to the event stream, events will be dropped. It is highly recommended to have at least one actor monitoring DeadLetterEvent.

  7. How actors and receivers work

    master

    In Hollywood, an actor is defined by implementing the Receiver interface. This interface is the mechanism the engine uses to communicate with the actor.

    Parent & Child Relationships

    Actors can form hierarchies. If an actor spawns another actor, the spawning actor becomes the parent of the spawned actor. This hierarchy is primarily used for:

    • Supervision: Managing the lifecycle and errors of child actors.
    • Logical Routing: Facilitating the flow of messages through a structured tree.
  8. Manage Actor Lifecycles with Poison and SendRepeat

    master

    In the Trade-Engine pattern, actors manage their own lifecycle based on system state using the following hollywood mechanisms:

    • Periodic Tasks: Use (*actor.Engine).SendRepeat to send a specific message to an actor at regular intervals (e.g., for price updates).
    • Stopping Repetition: Use (actor.SendRepeater).Stop() to halt a recurring message loop.
    • Self-Termination: Use (*actor.Engine).Poison to signal an actor to shut down once its task is complete or it is no longer needed (e.g., when a Price Watcher has no more subscribers or a Trade Executor has finished a trade).