[
https://issues.apache.org/jira/browse/AMQ-6456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549439#comment-15549439
]
james edited comment on AMQ-6456 at 10/5/16 5:35 PM:
-----------------------------------------------------
It would seem that _somehow_ the choice of a particular consumer must be
"visible" (in some form or another), otherwise the feature wouldn't work? if
different brokers came to different conclusions about which exclusive consumer
is the "chosen one", then the exclusivity is lost. in the Queue impl, it
literally puts the first exclusive consumer subscription added to the Queue as
the exclusive consumer on the dispatchSelector. and the list of consumers in
the queue is same list which is passed to the code that i patched in
ConditionalNetworkForwardingBridge. so, it's reasonable to conclude that the
first subscription in the list is the one the Queue considers the "chosen"
exclusive consumer. (unless consumers have priorities, and then all bets might
be off, but we don't use priorities).
we use activemq as an embedded library, so all configuration is programmatic,
not xml. i believe the config you are asking for is the
DiscoveryNetworkConnector:
* prefetchSize = 1
* duplex = false
* messageTTL = 9999
also the ConditionalNetworkBridgeFilterFactory has replayWhenNoConsumers = true.
the exclusiveSub isn't used other than for checking non-null. the effect of
the patch is that any exclusive consumers other than the first are ignored when
checking for a local consumer. so even though there _is_ a local consumer in
my test scenario, since it is an exclusive consumer and is not the first in
line, it is ignored.
that's a good point about this being a factory which i'm plugging in.
technically i could use my own modified subclass. that said, it would be good
if the core features worked as intended/expected without custom impls. not to
mention that the relevant problem code is not easily re-usable, so i'd have to
duplicate a fair bit of code (if not the entire class).
was (Author: jahlborn):
It would seem that _somehow_ the choice of a particular consumer must be
"visible" (in some form or another), otherwise the feature wouldn't work? if
different brokers came to different conclusions about which exclusive consumer
is the "chosen one", then the exclusivity is lost. in the Queue impl, it
literally puts the first exclusive consumer subscription added to the Queue as
the exclusive consumer on the dispatchSelector. and the list of consumers in
the queue is same list which is passed to the code that i patched in
ConditionalNetworkForwardingBridge. so, it's reasonable to conclude that the
first subscription in the list is the one the Queue considers the "chosen"
exclusive consumer. (unless consumers have priorities, and then all bets might
be off, but we don't use priorities).
we use activemq as an embedded library, so all configuration is programmatic,
not xml. i believe the config you are asking for is the
DiscoveryNetworkConnector:
* prefetchSize = 1
* duplex = false
* messageTTL = 9999
the exclusiveSub isn't used other than for checking non-null. the effect of
the patch is that any exclusive consumers other than the first are ignored when
checking for a local consumer. so even though there _is_ a local consumer in
my test scenario, since it is an exclusive consumer and is not the first in
line, it is ignored.
that's a good point about this being a factory which i'm plugging in.
technically i could use my own modified subclass. that said, it would be good
if the core features worked as intended/expected without custom impls. not to
mention that the relevant problem code is not easily re-usable, so i'd have to
duplicate a fair bit of code (if not the entire class).
> Exclusive consumer may stop consuming in broker network
> -------------------------------------------------------
>
> Key: AMQ-6456
> URL: https://issues.apache.org/jira/browse/AMQ-6456
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.9.1, 5.14.1
> Reporter: james
> Priority: Critical
> Attachments: exclusive_consumer_patch.txt
>
>
> When exclusive consumers are restarted in a network of brokers, the "chosen"
> consumer may shift from one broker to the next. In order for existing
> messages to be consumed, they must be forwarded from the broker on which they
> currently exist to the broker on which the chosen consumer now resides.
> However, the ConditionalNetworkBridgeFilter incorrectly decides that it
> should not forward the messages and they end up getting stuck on the old
> broker.
> We found the issue in 5.9.1, but the relevant code looks unchanged in the
> current 5.x release.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
