Manual

Coordination across workers

Publish, subscribe and claim: requests that coordinate across worker processes.

Introduction#

A Swerve server runs several worker processes, and a request in one worker sometimes needs to reach a request in another. Three primitives cover this. Swerve::publish sends a message to a named channel; Swerve::subscribe receives the messages on that channel in every worker, in the order they were published (OrderedChannel, Subscription). Swerve::claim lets exactly one request, in whichever worker, take ownership of a piece of work (Claim).

Concepts#

• OrderedChannel – One order for every subscriber, from many publishers.
• Claims – One holder at a time across all workers.

Examples#

• All examples of this topic – 29 with their output.

Reference#

• Claim – A handle on a name that one holder at a time can hold across the whole server, from Swerve::claim.
• OrderedChannel – A topic where every subscriber, in every worker, receives the messages in one and the same order, and each publisher's own messages keep theirs.
• SubscriberLagException – A subscription fell further behind its topic than its $maxLag seconds, see Subscription.
• Subscription – The messages published to a topic, from Swerve::subscribe: iterate over it to receive them.
• Swerve::publish – Send a message to every subscriber of $topic, in every worker process of this swerve, this one included.
• Swerve::publishRaw – Send $bytes unchanged to every subscriber of $topic, in every worker process of this swerve, this one included.
• Swerve::subscribe – Receive what is published to $topic from now on.
• Swerve::claim – A handle on the name $name, which one holder at a time can hold across the workers.
• SealedObject – A decoded JSON object that nobody can change: what a subscriber of Swerve::subscribe gets for a published object.