Skip to main content

Design

Where ruststream-lapin sits: between the RustStream runtime and the lapin client, one connection, a channel per subscription.

The service, the RustStream runtime, this crate, the lapin client and the RabbitMQ node, top to bottomYour serviceRustStream coreruststream-lapinlapin#[subscriber]handlersRustStream::new(..).with_broker(..)Runtime: dispatch, lanes, settlementLapinSubscriberyields LapinMessageLapinPublisher,ConfirmsPublisher,ServerTxPublisherLapinBrokerconfigurationRabbitQueue,RabbitQuorumQueue,RabbitExchangeLapinRequesterConnectionone per brokerA channel persubscriptionShared publish channel;confirms, transactionsand requests: their ownRabbitMQ node
The diagram as text
  1. Your service: #[subscriber] handlers; RustStream::new(..) .with_broker(..)
  2. RustStream core: Runtime: dispatch, lanes, settlement
  3. ruststream-lapin: LapinSubscriber yields LapinMessage; LapinPublisher, ConfirmsPublisher, ServerTxPublisher; LapinBroker configuration; RabbitQueue, RabbitQuorumQueue, RabbitExchange; LapinRequester
  4. lapin: Connection one per broker; A channel per subscription; Shared publish channel; confirms, transactions and requests: their own
  5. #[subscriber] handlers → Runtime: dispatch, lanes, settlement: mounted
  6. Runtime: dispatch, lanes, settlement → LapinSubscriber yields LapinMessage: polls the stream
  7. LapinSubscriber yields LapinMessage → A channel per subscription
  8. LapinPublisher, ConfirmsPublisher, ServerTxPublisher → Shared publish channel; confirms, transactions and requests: their own
  9. LapinRequester → Shared publish channel; confirms, transactions and requests: their own
  10. A channel per subscription → RabbitMQ node
  11. Shared publish channel; confirms, transactions and requests: their own → RabbitMQ node

The crate implements the core's broker traits over lapin, a pure-Rust AMQP 0.9.1 client. The runtime above it is the same for every broker. Everything RabbitMQ-specific is in this crate: the queue descriptors, the frames a settlement sends, where a retry goes, and the three publishing modes.

One broker opens one connection. Each subscription consumes on a channel of its own, so its prefetch window and its errors stay its own. Fire-and-forget publishers share one channel. A confirms publisher, a transaction publisher and a requester each open a channel of their own on first use, because a confirm mode, a transaction and a reply consumer are channel state.

A channel error closes one channel and leaves the connection up. A publisher's channel opens again on its next use, so one publish to a missing exchange does not stop the service publishing.

LapinBroker declares nothing by default. A descriptor then states the topology the service expects, and a missing queue fails its subscription. declare_topology(true) makes each subscription declare its exchanges, its queue and its bindings, in that order.

A requester reads its replies in a task on the runtime the broker connected on, whichever thread makes the first request.

How the pieces start and stop is on Lifecycle, and the way of one delivery on Path.