-
Notifications
You must be signed in to change notification settings - Fork 1.5k
[AMQ-9692] Support destination gc sweep of destinations with only wildcard consumers #1484
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -260,16 +260,21 @@ protected List<Subscription> addSubscriptionsForDestination(ConnectionContext co | |
| } | ||
|
|
||
| @Override | ||
| public void removeDestination(ConnectionContext context, ActiveMQDestination destination, long timeout) | ||
| throws Exception { | ||
|
|
||
| public void removeDestination(ConnectionContext context, ActiveMQDestination destination, long timeout) throws Exception { | ||
| // No timeout.. then try to shut down right way, fails if there are | ||
| // current subscribers. | ||
| if (timeout == 0) { | ||
| for (Iterator<Subscription> iter = subscriptions.values().iterator(); iter.hasNext();) { | ||
| Subscription sub = iter.next(); | ||
| if (sub.matches(destination) ) { | ||
| throw new JMSException("Destination: " + destination + " still has an active subscription: " + sub); | ||
| if(sub.isWildcard()) { | ||
| var dest = destinations.get(destination); | ||
| if(dest != null && dest.isGcWithOnlyWildcardConsumers()) { | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There still seems to be a missing test case because this logic is broken, Intellij flagged it. This continue does nothing as it's in a loop and this will not throw the exception if isGcWithOnlyWildcardConsumers() is false. This should likely just be rewritten as something like and include a test that would catch a similar mistake in the future. if (sub.matches(destination) ) {
var dest = destinations.get(destination);
if(!sub.isWildcard() || dest == null || !dest.isGcWithOnlyWildcardConsumers()) {
throw new JMSException("Destination: " + destination + " still has an active subscription: " + sub);
}
}
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Would this also need to look for the same for network-only subscribers for consistency? Or better yet perhaps re-use the isActive() or canGC() methods? Note: This method is invoked by the RegionBroker gc check after confirming the expiration rules apply for the given destination. In the case of GC, this is a repeat of the check. In the case of an admin operation (ie via CLI or JMX) this is the only check to prevent deleting a destination w/ active subscribers.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. isActive() and canGC() are a bit different because they also check for active producers. I'm not entirely sure why the method to remove was written not to care about producers, maybe an oversight, but changing that now would be a behavior change that could cause some side effects that are unexpected. Re-using logic is good but maybe it just needs to be subdivided to only check for active consumers (that method already exists and isActive() calls it now). As you pointed out, the RegionBroker calls this to delete the destination but already after the gc check so we know there are no active consumer/producers. So the real question is whether or not we care about blocking a manual deletion through JMX if there are active producers. It seems odd to not check that but changing that now as I said is a behavior change that could break someone's use case. (I suppose i could see someone wanting to block deletes with active consumers but not producers). Your point about it not checking the gcWithNetworkConsumers flag is valid and probably a bug. In fact it proves the point that we should be sharing the logic because the GC automated check will check it but not the manual deletion.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There's a long list of things that are like this where we may want to revisit for AMQ 7 where we want to change default behavior or settings but it's technically a breaking change so a major version is more appropriate. I guess whether or not we change this to check active producers depends on if we consider it a bug or not. If we change it I would think by default this would share the same logic as the isActive and GC check and that should block removal by default even by an admin through JMX/console etc to prevent mistakes. But, if we do that we could add a force flag that would allow an administrator to force delete, but all of this is kind of out scope of the work for this. |
||
| continue; | ||
| } | ||
| } else { | ||
| throw new JMSException("Destination: " + destination + " still has an active subscription: " + sub); | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.