dpavlov2024 opened a new issue, #2519:
URL: https://github.com/apache/activemq/issues/2519
# Issue body (paste below the title field)
## Bug Report
**Describe the bug**
After upgrading to ActiveMQ Classic 6.2.7 (also 6.2.8), brokers in a broker
network log `Failed to remove consumer: ID:...` with a `NullPointerException`
when a broker is stopped/restarted or a network bridge drops under load. The
consumer/connection cleanup is interrupted, so consumers are left registered
(stale connections) until the broker is restarted.
The NPE comes from the advisory path introduced by "Send advisory messages
using Broker connection context" (#2071 / #2075):
```
WARN | Failed to remove consumer: ID:... | TransportConnection
java.lang.NullPointerException: Cannot invoke "...isQueue()" because the
return value of "...MessageEvaluationContext.getDestination()" is null
at ConditionalNetworkBridgeFilterFactory$ConditionalNetworkBridgeFilter
.matchesForwardingFilter(ConditionalNetworkBridgeFilterFactory.java:116)
...
at AdvisoryBroker.removeConsumer(AdvisoryBroker.java:400)
at
TransportConnection.processRemoveConsumer(TransportConnection.java:739)
```
We believe the shared broker-admin `ConnectionContext` (one mutable
`MessageEvaluationContext`) is cleared by one concurrent advisory dispatch
while another is evaluating a conditional network bridge filter.
**Expected behavior per documentation**
This should work correctly per ActiveMQ's documented behavior:
- Broker networks with demand forwarding and replay-when-no-consumers
(`ConditionalNetworkBridgeFilterFactory`) are a supported, documented
topology; the [6.2.7 release
notes](https://activemq.apache.org/components/classic/download/classic-06-02-07)
only describe the advisory change as a
permission improvement (the broker now publishes advisories under its own
context, so users no longer need write access to advisory topics) - no
change in dispatch or cleanup semantics is documented.
- Consumers and connections are expected to be removed cleanly when clients
disconnect and during broker shutdown/reconnect; no stale consumers should
remain.
- Advisory messages are broker-internal bookkeeping and should not be able to
break consumer cleanup.
Reality on 6.2.7/6.2.8 with an unchanged 6.2.6 configuration: the NPE above
appears during storms and cleanup is left incomplete - which is why we treat
this as a regression.
**To Reproduce**
- A docker-compose reproduction (3 brokers, loadgen, one command) will be
attached to this issue; steps to run it are included in the attachment.
- In short: a broker network with `ConditionalNetworkBridgeFilterFactory`
(`replayWhenNoConsumers`) on the destination policies and a
network-mirrored wildcard topic subscription (a `>` topic consumer).
With many concurrent consumer create/remove operations, gracefully stop
one broker; clients reconnect -> the NPE below appears.
- Expected on 6.2.7 in the first storm round; on 6.2.6 the same setup stays
clean.
**Expected behavior**
Consumer/connection removal completes cleanly during shutdown/reconnect
storms; no NPE, no stale consumers.
**Your Environment**
- Version: 6.2.7 (also reproduced on 6.2.8; not present in 6.2.6)
- Configuration: static network connectors (duplex/dynamic demand),
`conditionalNetworkBridgeFilterFactory` on queue/topic policies
- OS: Linux (docker)
**Additional context**
Introducing change: commit `15e78425`, PRs #2071/#2075. A null guard at
`ConditionalNetworkBridgeFilterFactory:116` stops this exact NPE, but giving
each advisory dispatch its own evaluation context would fix the underlying
race.
[docker.zip](https://github.com/user-attachments/files/31827824/docker.zip)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
