You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »


Status

Current state: Under Discussion

Discussion thread: TBD

JIRA: Unable to render Jira issues macro, execution error. Unable to render Jira issues macro, execution error.  

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Today group coordinator will take in unlimited number of join group requests into the membership metadata. There is a potential risk described in Unable to render Jira issues macro, execution error.  where too many illegal joining members will burst broker memory before session timeout GC them. To ensure stability of the broker, we propose to enforce a hard limit on the size of consumer group in order to prevent explosion of server side cache/memory.

Public Interfaces

We propose to add a new configuration into KafkaConfig.scala, and its behavior will affect the following coordinator APIs:

nice
val GroupMaxSize = "group.max.size"
...
.define(GroupMaxSizeProp, INT, Defaults.GroupMaxSize, MEDIUM, GroupMaxSizeDoc)


Proposed Changes


We shall add a config called group.max.size on the coordinator side.

KafkaConfig
val GroupMaxSize = "group.max.size"
...
.define(GroupMaxSizeProp, INT, Defaults.GroupMaxSize, MEDIUM, GroupMaxSizeDoc)


Compatibility, Deprecation, and Migration Plan

  • What impact (if any) will there be on existing users?
  • If we are changing behavior how will we phase out the older behavior?
  • If we need special migration tools, describe them here.
  • When will we remove the existing behavior?

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.

  • No labels