From 500f0fdeb73da1aef9e9bd635130116b4c57893b Mon Sep 17 00:00:00 2001 From: Andrew Godwin Date: Tue, 23 Feb 2016 19:36:34 -0800 Subject: [PATCH] Couple of bits more ordering docs --- CHANGELOG.txt | 11 +++++++++++ docs/getting-started.rst | 2 ++ docs/inshort.rst | 11 +++++++++++ 3 files changed, 24 insertions(+) diff --git a/CHANGELOG.txt b/CHANGELOG.txt index 67c519b..effc855 100644 --- a/CHANGELOG.txt +++ b/CHANGELOG.txt @@ -1,8 +1,19 @@ +0.9.2 (2016-02-24) +------------------ + +* ASGI spec updated to include `order` field for WebSocket messages + +* `enforce_ordering` decorator introduced + +* DatabaseChannelLayer now uses transactions to stop duplicated messages + + 0.9.1 (2016-02-21) ------------------ * Fix packaging issues with previous release + 0.9 (2016-02-21) ---------------- diff --git a/docs/getting-started.rst b/docs/getting-started.rst index 010b8fc..2c91f0c 100644 --- a/docs/getting-started.rst +++ b/docs/getting-started.rst @@ -446,6 +446,8 @@ listening logic inside the ``chat-messages`` consumer, as every message would pass through it. +.. _enforcing-ordering: + Enforcing Ordering ------------------ diff --git a/docs/inshort.rst b/docs/inshort.rst index 070a0eb..e006150 100644 --- a/docs/inshort.rst +++ b/docs/inshort.rst @@ -66,6 +66,17 @@ it's designed to allow both easy sharding as well as the ability to run separate clusters with their own protocol and worker servers. +Why doesn't it use my favourite message queue? +---------------------------------------------- + +Channels is deliberately designed to prefer low latency (goal is a few milliseconds) +and high throughput over guaranteed delivery, which doesn't match some +message queue designs. + +Some features, like :ref:`guaranteed ordering of messages `, +are opt-in as they incur a performance hit. + + Do I need to worry about making all my code async-friendly? -----------------------------------------------------------