You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@artemis.apache.org by "Devesh Chitlangia (Jira)" <ji...@apache.org> on 2026/07/20 11:14:00 UTC
[jira] [Updated] (ARTEMIS-6160) Include the queue/binding name (and source node) in AMQ222196 "Could not find binding" warning
[ https://issues.apache.org/jira/browse/ARTEMIS-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Devesh Chitlangia updated ARTEMIS-6160:
---------------------------------------
Description:
In a clustered broker, BindingsImpl.routeFromCluster(...) logs AMQ222196 when a message forwarded from a peer node targets a binding id that no longer exists locally (the consumer/subscription was already removed).
{*}Example{*}:
AMQ222196: Could not find binding with id=6046772 on routeFromCluster for message=CoreMessage[messageID=6049061, ..., address=STATE.S.<tenant>.TEP.<device>, ...] binding = BindingsImpl [name=STATE.S.<tenant>.TEP.<device>]
The warning gives only the numeric binding id, the message, and "BindingsImpl [name=<address>]" - where name is the ADDRESS, not the queue/subscription. Because the binding is already deleted when the warning fires, operators cannot resolve which queue/consumer the stale id belonged to after the fact. In high-churn deployments (many MQTT wildcard subscribers reconnecting) this warning is logged at very high volume, and tracing each id back to a consumer requires correlating other logs.
*Requested improvement*
When logging AMQ222196, include (where available):
- the last-known queue/binding name for that id, and
- the source node / cluster bridge that supplied the routing id.
Note: the live consumer id cannot be printed because the binding is already removed when the warning fires - hence requesting the last-known name and the originating node, which is enough to identify the owning subscription/service without correlating separate logs.
+*Impact*+
Purely diagnostic/observability. No functional or routing change. Would significantly speed up troubleshooting of stale/ghost cluster bindings.
was:
In a clustered broker, BindingsImpl.routeFromCluster(...) logs AMQ222196 when a message forwarded from a peer node targets a binding id that no longer exists locally (the consumer/subscription was already removed).
{*}Example{*}:
AMQ222196: Could not find binding with id=6046772 on routeFromCluster for message=CoreMessage[messageID=6049061, ..., address=STATE.S.<tenant>.TEP.<device>, ...] binding = BindingsImpl [name=STATE.S.<tenant>.TEP.<device>]
The warning gives only the numeric binding id, the message, and "BindingsImpl [name=<address>]" - where name is the ADDRESS, not the queue/subscription. Because the binding is already deleted when the warning fires, operators cannot resolve which queue/consumer the stale id belonged to after the fact. In high-churn deployments (many MQTT wildcard subscribers reconnecting) this warning is logged at very high volume, and tracing each id back to a consumer requires correlating other logs.
+*Requested improvement*
+
When logging AMQ222196, include (where available):
- the last-known queue/binding name for that id, and
- the source node / cluster bridge that supplied the routing id.
Note: the live consumer id cannot be printed because the binding is already removed when the warning fires - hence requesting the last-known name and the originating node, which is enough to identify the owning subscription/service without correlating separate logs.
+*Impact*+
Purely diagnostic/observability. No functional or routing change. Would significantly speed up troubleshooting of stale/ghost cluster bindings.
> Include the queue/binding name (and source node) in AMQ222196 "Could not find binding" warning
> ----------------------------------------------------------------------------------------------
>
> Key: ARTEMIS-6160
> URL: https://issues.apache.org/jira/browse/ARTEMIS-6160
> Project: Artemis
> Issue Type: Improvement
> Affects Versions: 2.31.2, 2.54.0
> Reporter: Devesh Chitlangia
> Priority: Major
>
> In a clustered broker, BindingsImpl.routeFromCluster(...) logs AMQ222196 when a message forwarded from a peer node targets a binding id that no longer exists locally (the consumer/subscription was already removed).
> {*}Example{*}:
> AMQ222196: Could not find binding with id=6046772 on routeFromCluster for message=CoreMessage[messageID=6049061, ..., address=STATE.S.<tenant>.TEP.<device>, ...] binding = BindingsImpl [name=STATE.S.<tenant>.TEP.<device>]
> The warning gives only the numeric binding id, the message, and "BindingsImpl [name=<address>]" - where name is the ADDRESS, not the queue/subscription. Because the binding is already deleted when the warning fires, operators cannot resolve which queue/consumer the stale id belonged to after the fact. In high-churn deployments (many MQTT wildcard subscribers reconnecting) this warning is logged at very high volume, and tracing each id back to a consumer requires correlating other logs.
> *Requested improvement*
> When logging AMQ222196, include (where available):
> - the last-known queue/binding name for that id, and
> - the source node / cluster bridge that supplied the routing id.
> Note: the live consumer id cannot be printed because the binding is already removed when the warning fires - hence requesting the last-known name and the originating node, which is enough to identify the owning subscription/service without correlating separate logs.
> +*Impact*+
> Purely diagnostic/observability. No functional or routing change. Would significantly speed up troubleshooting of stale/ghost cluster bindings.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@artemis.apache.org
For additional commands, e-mail: issues-help@artemis.apache.org