allow user override subproperties for update properties#14217
allow user override subproperties for update properties#14217leizhiyuan wants to merge 6 commits intoapache:masterfrom
Conversation
leizhiyuan
force-pushed
the
feat/allow_override_subProperties
branch
from
dd3d2a2 to
32ee9fe
Compare
|
@leizhiyuan:Thanks for your contribution. For this PR, do we need to update docs? |
|
@leizhiyuan:Thanks for providing doc info! |
github-actions
bot
added
doc-not-needed
Jason918
left a comment
Jason918
left a comment
There was a problem hiding this comment.
How about we pass null if user don't set this. And for server, null means no change, keep the previous value?
| assertTrue(properties4.containsKey("4")); | ||
| assertEquals(properties4.get("3"), "3"); | ||
| assertEquals(properties4.get("4"), "4"); | ||
| assertTrue(properties4.isEmpty()); |
There was a problem hiding this comment.
//consumer subscribe without subscriptionProperties set, it will get the old one
This PR changed this feature. It's worth discussing.
There was a problem hiding this comment.
ok,I will change it
This reverts commit 8bfb841.
codelipenghui
left a comment
codelipenghui
left a comment
There was a problem hiding this comment.
The properties of the subscription should not be updated when new consumers use different subscription properties, the properties are applied to the subscription when creating the subscription if users have many consumers with different subscription properties, with this change we will apply the last consumer.
Users should change the subscription properties for an existing subscription by the admin API, not the new consumer command.
/cc @315157973
|
The pr had no activity for 30 days, mark with Stale label. |
|
The pr had no activity for 30 days, mark with Stale label. |
|
Closed as stale, conflict, and no consensus. Please rebase and resubmit the patch if it's still relevant. |
4 participants
now entry filter uses the first consumer properties to PersistentSubscription , but when users modified their code, and change the properties, it will not take effect.
Motivation
users use entry filter to implement tag filter,
time 1 : they use tag1
time 2 : users upgrade their code, and use tag2,
We will not take effect, only restart all brokers or users restart their apps. it is impossible.
Explain here the context, and why you're making that change. What is the problem you're trying to solve.
Modifications
override the properties every time. then when users upgrade their app, this will take effect.
Verifying this change
add test case
Does this pull request potentially affect one of the following parts:
If
yeswas chosen, please highlight the changesDocumentation
Check the box below or label this PR directly (if you have committer privilege).
Need to update docs?
doc-required(If you need help on updating docs, create a doc issue)
no-need-doc(Please explain why)
doc(If this PR contains doc changes)