Opaque handle to an exchange.

Messages sent to an exchange can optionally provide a routing key and a list of (key, value) headers in addition to the underlying payload.

Starts an exchange process with the given ExchangeType.

Starts an exchange as part of a supervision tree.

Example: > childSpec = toChildStart $ startSupervised exType

Starts an exchange as part of a supervision tree.

Example: > childSpec = toChildStart $ startSupervisedRef exType

Posts an arbitrary Serializable datum to an exchange. The raw datum is wrapped in the Message data type, with its key set to "" and its headers to [].

Posts a Message to an exchange.

Sends an arbitrary Serializable datum to an exchange, for use as a configuration change - see configureEx for details.

Utility for creating a Message datum from its key, headers and payload.

Start a new broadcast exchange and return a handle to the exchange.

The ExchangeType of a broadcast exchange. Can be combined with the startSupervisedRef and startSupervised APIs.

Create a binding to the given broadcast exchange for the calling process and return an InputStream that can be used in the expect and receiveWait family of messaging primitives. This form of client interaction helps avoid cluttering the caller's mailbox with Message data, since the InputChannel provides a separate input stream (in a similar fashion to a typed channel). Example:

is <- broadcastClient ex
msg <- receiveWait [ matchInputStream is ]
handleMessage (payload msg)

Bind the calling process to the given broadcast exchange. For each Message the exchange receives, only the payload will be sent to the calling process' mailbox.

Example:

(producer) > post ex Hello

(consumer) > bindToBroadcaster ex > expect >>= liftIO . putStrLn

The binding key used by the built-in key and header based routers.

Things that can be used as binding keys in a router.

Used to convert a Message into a Bindable routing key.

Given to a router to indicate whether clients should receive Message payloads only, or the whole Message object itself.

Defines a router exchange. The BindingSelector is used to construct a binding (i.e., an instance of the Bindable type k) for each incoming Message. Such bindings are matched against bindings stored in the exchange. Clients of a router exchange are identified by a binding, mapped to one or more ProcessIds.

The format of the bindings, nature of their storage and mechanism for submitting new bindings is implementation dependent (i.e., will vary by exchange type). For example, the messageKeyRouter and headerContentRouter implementations both use the Binding data type, which can represent a Message key or a HeaderName and content. As with all custom exchange types, bindings should be submitted by evaluating configureExchange with a suitable data type.

Defines a router that can be used in a supervision tree.

Send a Serializable message to the supplied Exchange. The given datum will be converted to a Message, with the key set to "" and the headers to [].

The routing behaviour will be dependent on the choice of BindingSelector given when initialising the router.

Send a Message to the supplied Exchange. The routing behaviour will be dependent on the choice of BindingSelector given when initialising the router.

A router that matches on a Message key. To bind a client Process to such an exchange, use the bindKey function.

Add a binding (for the calling process) to a messageKeyRouter exchange.

A router that matches on a specific (named) header. To bind a client Process to such an exchange, use the bindHeader function.

Add a binding (for the calling process) to a headerContentRouter exchange.

Different exchange types are defined using record syntax. The configureEx and routeEx API functions are called during the exchange lifecycle when incoming traffic arrives. Configuration messages are completely arbitrary types and the exchange type author is entirely responsible for decoding them. Messages posted to the exchange (see the Message data type) are passed to the routeEx API function along with the exchange type's own internal state. Both API functions return a new (potentially updated) state and run in the Process monad.

Utility for custom exchange type authors - evaluates a set of primitive message handlers from left to right, returning the first which evaluates to Just a, or the initial e value if all the handlers yield Nothing.