[ 
https://issues.apache.org/jira/browse/AMQ-3218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Stocks updated AMQ-3218:
----------------------------

    Attachment: Queue.patch

> 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
>            Priority: Minor
>         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

Reply via email to