[
https://issues.apache.org/jira/browse/AMQ-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dejan Bosanac resolved AMQ-3218.
--------------------------------
Resolution: Fixed
Fix Version/s: 5.5.0
Assignee: Dejan Bosanac
a modified patch applied with svn revision 1082939. Thanks!
> Mutlitple Exclusive Consumers: It is currently not possible to always ensure
> that a new exclusive consumer replaces any existing one
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-3218
> URL: https://issues.apache.org/jira/browse/AMQ-3218
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 5.4.2
> Reporter: Rob Stocks
> Assignee: Dejan Bosanac
> Priority: Minor
> Fix For: 5.5.0
>
> Attachments: Queue.patch
>
>
> The following is a proposed small change to
> org.apache.activemq.broker.region.Queue addSubscription() method:
> If the new consumer is exclusive and has the maximum priority (127), replace
> the existing exclusive consumer even if it also has a priority of 127 as
> follows (line 385 in version 5.4.2 source):
> if (exclusiveConsumer == null) {
> exclusiveConsumer = sub;
> } else if (sub.getConsumerInfo().getPriority() == Byte.MAX_VALUE) {
> exclusiveConsumer = sub;
> } else if (sub.getConsumerInfo().getPriority() >
> exclusiveConsumer.getConsumerInfo().getPriority()) {
> exclusiveConsumer = sub;
> }
> This allows new consumers to always replace any existing exclusive consumer
> (but preserves behaviour in all but 1 unusual case). There may be a better
> way of donig this (e.g. adding an ExclusiveMode property to ConsumerInfo with
> values such as 'PRIORITY', 'NEWEST' which determines whether the priority is
> checked or the latest exclusive consumer replaces an y existing one) but the
> above is a quick fix for this problem.
> The reason, we have added this to our implementation is that we have an
> application that uses a STOMP client on Windows Mobile to post messages to a
> queue and wait for the reply. However, when the device goes to sleep, the TCP
> socket remains open on the server even though it is forceably closed on
> wake-up on the client. The client then creates a new connection and we end up
> with multiple consumers on our queue with new messages being distributed
> between them. If we turn on exclusivity, the original consumer gets all the
> messages which doesn't help (it actually makes it worse).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
