activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dejan Bosanac (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (AMQ-3218) Mutlitple Exclusive Consumers: It is currently not possible to always ensure that a new exclusive consumer replaces any existing one
Date Fri, 18 Mar 2011 14:57:29 GMT

     [ 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

Mime
View raw message