1
0
mirror of https://github.com/taigrr/nats.docs synced 2025-01-18 04:03:23 -08:00

Merge pull request #129 from nats-io/note_about_async_subs

Added note regarding asynchronous subscriptions.
This commit is contained in:
Ginger Collison 2020-07-22 14:35:21 -05:00 committed by GitHub
commit ad541650ec
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 3 additions and 1 deletions

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. 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: Subscriptions set their starting position on creation using position or time. For example, in Go you can start at:

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. 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: The following example subscribes to the subject `updates` and handles the incoming messages:
{% tabs %} {% tabs %}