[
https://issues.apache.org/jira/browse/QPID-5555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13910334#comment-13910334
]
Robbie Gemmell commented on QPID-5555:
--------------------------------------
Still reviewing this, but comment is getting a bit long, so just in case I'm
posting the partial review :)
Given they are done a different way than the other queue attributes, I think
the 'use vhost default' functionality for the alert thresholds might be even
less obvious after these changes than it was previously ;)
Unused Import? (only change made in class)
{noformat}
diff --git
a/qpid/java/bdbstore/src/test/java/org/apache/qpid/server/store/berkeleydb/upgrade/UpgradeFrom5To6Test.java
index 44f0861..0249400 100644
---
a/qpid/java/bdbstore/src/test/java/org/apache/qpid/server/store/berkeleydb/upgrade/UpgradeFrom5To6Test.java
+++
b/qpid/java/bdbstore/src/test/java/org/apache/qpid/server/store/berkeleydb/upgrade/UpgradeFrom5To6Test.java
@@ -44,6 +44,7 @@ import java.util.UUID;
import org.apache.log4j.Logger;
import org.apache.qpid.server.model.Binding;
import org.apache.qpid.server.model.Exchange;
+import org.apache.qpid.server.model.ExclusivityPolicy;
import org.apache.qpid.server.model.LifetimePolicy;
import org.apache.qpid.server.model.Queue;
import org.apache.qpid.server.model.UUIDGenerator;
{noformat}
>From QueueConfiguration:
Wrong attribute name?
{noformat}
public boolean getDurable()
{
- return getBooleanValue("durable");
+ return getDefaultedBoolean("boolean");
{noformat}
>From FilterSupport:
While the original code was too restrictive only working with an 'exclusive
owning session', not sure about the new behaviour either. If the noLocal filter
is specified on a binding for example, wont this mean that having any noLocal
consumer on a queue will prevent all consumers on the queue from the chance of
receiving the message even though they could? That obviously won't upset the
0-x JMS client based on how it uses this, but might be unexpected if anyone
else used it. Finally, should it matter if there are consumers or not if none
are identified as being on the same connection?
{noformat}
public boolean matches(Filterable message)
{
- final AMQSessionModel exclusiveOwningSession =
_queue.getExclusiveOwningSession();
- return exclusiveOwningSession == null ||
- exclusiveOwningSession.getConnectionReference() !=
message.getConnectionReference();
+ final Collection<? extends Consumer> consumers =
_queue.getConsumers();
+ for(Consumer c : consumers)
+ {
+ if(c.getSessionModel().getConnectionReference() ==
message.getConnectionReference())
+ {
+ return false;
+ }
+ }
+ return !consumers.isEmpty();
}
{noformat}
>From SimpleAMQQueue (at the time) constructor:
Call getOwner() instead?
{noformat}
+ final String ownerString;
+ switch(_exclusivityPolicy)
+ {
+ case PRINCIPAL:
+ ownerString = ((Principal) _exclusiveOwner).getName();
+ break;
+ case CONTAINER:
+ ownerString = (String) _exclusiveOwner;
+ break;
+ default:
+ ownerString = null;
+
+ }
{noformat}
> [Java Broker] Modify Queue implementation of lifetime / exclusivity policies
> ----------------------------------------------------------------------------
>
> Key: QPID-5555
> URL: https://issues.apache.org/jira/browse/QPID-5555
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Robbie Gemmell
> Fix For: 0.27
>
>
> AMQP 0-8/9/9-1 and AMQP 0-10 both have notions of "autodelete" and
> "exclusive" for Queues. However while they use the same names, they are in
> fact subtly different. The Java Broker Queue implementation should better
> abstract these notions into the lifetime and exclusivity policies.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
