Description
Proposed change
(*Subscription).Fetch
is thread safe, but not "multithread-friendly".
Suppose an application implements the following logic:
// pseudo-go
numThreads = 2
for i in numThreads {
go func() {
msgs, error := sub.Fetch
[... handle error...]
for msg in msgs {
[... process msgs ...]
[... ack msg ...]
}
}
}
It is GREAT that this is possible, simple and easy because sub
is thread-safe.
However, imagine the application wants to increase the processing rate and it bumps numThreads
from 2 to 200.
This will result in a 100x increase in fetch requests to the server!
Multiply this by the number of instances of this application code, and you may quickly reach a state where the cluster/server is getting HAMMERED by fetch requests, 99% of which are superfluous.
Each one creates an inbox which means it needs to set up and teardown the route, and more.
Furthermore, if the stream has tons of unconsumed messages, 100x of them will be downloaded and put in the client queue, possibly resulting in memory usage blowing up.
Number of requests and amount of messages cached should probably not depend on the number of threads the application is using.
Suggested change:
- Number of buffered messages should not exceed some fixed limits
- Fetch should make a request only if there is room in the buffer, and be a noop if the client-buffer is full
Use case
See above
Contribution
No response