Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce a way to update broker service configuration dynamically #184

Closed
rdhabalia opened this issue Jan 31, 2017 · 2 comments
Closed
Labels
type/feature The PR added a new feature or issue requested a new feature
Milestone

Comments

@rdhabalia
Copy link
Contributor

As discussed at #176

We need to think well how to expose the whole thing in consistent way. You have the values from the config file + the values in ZK. There should be a clear way to understand what is the actual configuration that is:
Supposed to be applied to all brokers
It's actually being applied in a given broker...
Other problem is how to clearly identify which values are dynamically tunable (eg: zk servers string will not be dynamic...)

@merlimat @saandrews : I have created very initial level commit to propose a possible approach for this feature. Can you please provide your thoughts or ideas on it. If it makes sense then we can move forward on this approach.

@merlimat
Copy link
Contributor

merlimat commented Feb 1, 2017

Few random ideas (haven't looked at the code yet):

  • Mark dynamic settings with an annotation in ServiceConfiguration
  • Have a way to register for config changes events (this may be useful for certain class of variables)
  • Otherwise, just read the "dirty" value from the ServiceConfiguration instance (don't store it in local variable and don't use any mutex
  • Add a REST handle to change key/value pairs, that only accept variables marked as dynamic
  • Store all dynamically configured variables in a single z-node in "properties" format
  • At startup log the content of that z-node and log each time a change is detected

@rdhabalia
Copy link
Contributor Author

  • Mark dynamic settings with an annotation in ServiceConfiguration : [Yes, Included in commit]
  • Have a way to register for config changes events (this may be useful for certain class of variables) [Yes, Included in commit]
  • Otherwise, just read the "dirty" value from the ServiceConfiguration instance (don't store it in local variable and don't use any mutex [Have done similar change]
  • Add a REST handle to change key/value pairs, that only accept variables marked as dynamic [Yes, Included in commit]
  • Store all dynamically configured variables in a single z-node in "properties" format [Yes, Included in commit]
  • At startup log the content of that z-node and log each time a change is detected [Yes, Will do]

This commit includes almost all above suggestions. Once you review and if you think it is fine then I will go ahead and complete full changes.

@merlimat merlimat added this to the 1.17 milestone Mar 5, 2017
@merlimat merlimat added the type/feature The PR added a new feature or issue requested a new feature label Mar 5, 2017
@merlimat merlimat closed this as completed Mar 5, 2017
sijie pushed a commit to sijie/pulsar that referenced this issue Mar 4, 2018
hrsakai pushed a commit to hrsakai/pulsar that referenced this issue Dec 10, 2020
* Dead letter queue implementation

* Fixed formatting

* Added test case for multi-topics and fixed nacks

* Fixed indentation
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/feature The PR added a new feature or issue requested a new feature
Projects
None yet
Development

No branches or pull requests

2 participants