taigrr/nats.docs
1
0
Fork 0
mirror of https://github.com/taigrr/nats.docs synced 2025-01-18 04:03:23 -08:00
Code Issues Projects Releases Wiki Activity

Added note regarding asynchronous subscriptions.

Browse Source 
There is a misconception that asynchronous subscriptions mean that
message callbacks are invoked concurrently, which is not the case.

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
This commit is contained in:
Ivan Kozlovic 2020-07-22 13:13:25 -06:00
parent 2f61c049f7
commit d02f91ff14
2 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
developing-with-nats-streaming/receiving.md
View File

@ -11,7 +11,7 @@ Subscriptions come in several forms:
For more details on the various types, check the [concepts](../nats-streaming-concepts/channels/subscriptions/) section.
_**Note: message callbacks are invoked serially, one message at a time. If your application does not care about processing ordering and would prefer the messages to be dispatched concurrently, it is the application's responsibility to move them to some internal queue to be picked up by threads/go routines.**_
_**Note: For a given subscription, messages are dispatched serially, one message at a time. If your application does not care about processing ordering and would prefer the messages to be dispatched concurrently, it is the application's responsibility to move them to some internal queue to be picked up by threads/go routines.**_
Subscriptions set their starting position on creation using position or time. For example, in Go you can start at:

2
developing-with-nats/receiving/async.md
View File

@ -2,6 +2,8 @@
Asynchronous subscriptions use callbacks of some form to notify an application when a message arrives. These subscriptions are usually easier to work with, but do represent some form of internal work and resource usage, i.e. threads, by the library. Check your library's documentation for any resource usage associated with asynchronous subscriptions.
_**Note: For a given subscription, messages are dispatched serially, one message at a time. If your application does not care about processing ordering and would prefer the messages to be dispatched concurrently, it is the application's responsibility to move them to some internal queue to be picked up by threads/go routines.**_
The following example subscribes to the subject `updates` and handles the incoming messages:
{% tabs %}