Skip to content

Multi-threaded use of subscription may result in server spamming #1854

Open
@mprimi

Description

@mprimi

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    proposalEnhancement idea or proposal

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions