-
Jean de Klerk authored
Pub/Sub ordered keys requires: - Publish with a non-empty key gets added to a per-key queue, as implemented by Bundler.HandlerLimit=1. This setting causes the bundler to only have one outstanding bundle being handled at a time; further bundles form a queue. - Receive with a message that has a non-empty key gets added to a per-key queue, as implemented by a slice. When a worker operates on a key, it processes all items in the key's slice until the slice is empty, at which point it deletes the key to release the key's resources, and the worker returns to the worker pool. Functionally, for users, this should involve: - Slightly slower processing speeds due to additional data structures along the Publish and Receive paths. (we should do some performance testing to vet this out) - PublishSettings.NumGoroutines and ReceiveSettings.NumGoroutines should both result in double the number of goroutines, since an additional data structure (publish/receive scheduler) uses that value. Documentation has been adjusted accordingly to describe it more as a scaling factor than an exact number. - Default ReceiveSettings.NumGoroutines is increased from 1 to 10. It's generally a better experience to have multiple workers than one. And, some tests - like TestStreamingPullFlowControl - implicitly require it. - Since ordered keys require only a single outstanding RPC at once, it is possible to send ordered key messages to Topic.Publish (and subsequently to PublishScheduler.Add) faster than the bundler can publish them to the Pub/Sub service, resulting in a backed up queue of Pub/Sub bundles. Each item in the bundler queue is a goroutine, which means users may see thousands of goroutines in debugging they might do. TODO: add Resume method. Change-Id: Ib710944d557970290cf12321d1fdbd9b1699231d
9e18ddb0