You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Rob Godfrey (Created) (JIRA)" <ji...@apache.org> on 2012/01/03 20:46:39 UTC
[jira] [Created] (QPID-3720) [Java Broker] Implement Message
Grouping
[Java Broker] Implement Message Grouping
----------------------------------------
Key: QPID-3720
URL: https://issues.apache.org/jira/browse/QPID-3720
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Reporter: Rob Godfrey
Assignee: Rob Godfrey
Implement message grouping on the Java Broker (similar in style to that implemented in the C++ broker in QPID-3346)
In contrast to the C++ implementation
1) Once a group has been assigned to a subscription, assign all further messages from the same group to the same group (whether or not all prior messages in the group have been acknowledged)
2) Message grouping is allowed on priority queues, Conflation Queues (and Sorted Queues). (However it has no effect on browsers... which means if you using a ConflationQueue as an LVQ by browsing it you cannot use groups).
3) Allow for non string values for the group header
4) Setting the qpid.shared_msg_group argument is not required on queue construction (whether grouping is enforced or not depends on whether the qpid.group_header_key argument is non-null).
Note that in general 1) is stricter than the condition that is enforced by the C++ broker - however in the case where a client cancels a subscription without first releasing/acknowledging all outstanding messages that have been delivered then you can get "out of order".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] [Updated] (QPID-3720) [Java Broker] Implement Message
Grouping
Posted by "Rob Godfrey (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Godfrey updated QPID-3720:
------------------------------
Status: Ready To Review (was: In Progress)
> [Java Broker] Implement Message Grouping
> ----------------------------------------
>
> Key: QPID-3720
> URL: https://issues.apache.org/jira/browse/QPID-3720
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Rob Godfrey
> Original Estimate: 6h
> Time Spent: 6h
> Remaining Estimate: 0h
>
> Implement message grouping on the Java Broker (similar in style to that implemented in the C++ broker in QPID-3346)
> In contrast to the C++ implementation
> 1) Once a group has been assigned to a subscription, assign all further messages from the same group to the same group (whether or not all prior messages in the group have been acknowledged)
> 2) Message grouping is allowed on priority queues, Conflation Queues (and Sorted Queues). (However it has no effect on browsers... which means if you using a ConflationQueue as an LVQ by browsing it you cannot use groups).
> 3) Allow for non string values for the group header
> 4) Setting the qpid.shared_msg_group argument is not required on queue construction (whether grouping is enforced or not depends on whether the qpid.group_header_key argument is non-null).
> Note that in general 1) is stricter than the condition that is enforced by the C++ broker - however in the case where a client cancels a subscription without first releasing/acknowledging all outstanding messages that have been delivered then you can get "out of order".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] [Assigned] (QPID-3720) [Java Broker] Implement Message
Grouping
Posted by "Rob Godfrey (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Godfrey reassigned QPID-3720:
---------------------------------
Assignee: Robbie Gemmell (was: Rob Godfrey)
Addressed the comment by Robbie - assignment of the default group should now work
> [Java Broker] Implement Message Grouping
> ----------------------------------------
>
> Key: QPID-3720
> URL: https://issues.apache.org/jira/browse/QPID-3720
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Robbie Gemmell
> Original Estimate: 6h
> Time Spent: 6h
> Remaining Estimate: 0h
>
> Implement message grouping on the Java Broker (similar in style to that implemented in the C++ broker in QPID-3346)
> In contrast to the C++ implementation
> 1) Once a group has been assigned to a subscription, assign all further messages from the same group to the same group (whether or not all prior messages in the group have been acknowledged)
> 2) Message grouping is allowed on priority queues, Conflation Queues (and Sorted Queues). (However it has no effect on browsers... which means if you using a ConflationQueue as an LVQ by browsing it you cannot use groups).
> 3) Allow for non string values for the group header
> 4) Setting the qpid.shared_msg_group argument is not required on queue construction (whether grouping is enforced or not depends on whether the qpid.group_header_key argument is non-null).
> Note that in general 1) is stricter than the condition that is enforced by the C++ broker - however in the case where a client cancels a subscription without first releasing/acknowledging all outstanding messages that have been delivered then you can get "out of order".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3720) [Java Broker] Implement Message
Grouping
Posted by "Robbie Gemmell (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187029#comment-13187029 ]
Robbie Gemmell commented on QPID-3720:
--------------------------------------
Looks good. Updating the JIRA description and/or adding some docs would seem useful before closing out.
Robbie.
> [Java Broker] Implement Message Grouping
> ----------------------------------------
>
> Key: QPID-3720
> URL: https://issues.apache.org/jira/browse/QPID-3720
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Robbie Gemmell
> Original Estimate: 6h
> Time Spent: 6h
> Remaining Estimate: 0h
>
> Implement message grouping on the Java Broker (similar in style to that implemented in the C++ broker in QPID-3346)
> In contrast to the C++ implementation
> 1) Once a group has been assigned to a subscription, assign all further messages from the same group to the same group (whether or not all prior messages in the group have been acknowledged)
> 2) Message grouping is allowed on priority queues, Conflation Queues (and Sorted Queues). (However it has no effect on browsers... which means if you using a ConflationQueue as an LVQ by browsing it you cannot use groups).
> 3) Allow for non string values for the group header
> 4) Setting the qpid.shared_msg_group argument is not required on queue construction (whether grouping is enforced or not depends on whether the qpid.group_header_key argument is non-null).
> Note that in general 1) is stricter than the condition that is enforced by the C++ broker - however in the case where a client cancels a subscription without first releasing/acknowledging all outstanding messages that have been delivered then you can get "out of order".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3720) [Java Broker] Implement Message
Grouping
Posted by "Robbie Gemmell (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187003#comment-13187003 ]
Robbie Gemmell commented on QPID-3720:
--------------------------------------
Following the addition of the C++ broker style groups (possibly worth noting in the JIRA description? :P ) I see what looks like an issue with the 'default group' check in the SimpleAMQQueue constructor:
{code}
String defaultGroup = String.valueOf(arguments.get(QPID_DEFAULT_MESSAGE_GROUP));
_messageGroupManager =
new DefinedGroupMessageGroupManager(String.valueOf(arguments.get(QPID_GROUP_HEADER_KEY)),
defaultGroup == null ? QPID_NO_GROUP : defaultGroup,
this);
{code}
The check for defaultGroup == null might never be true, because String.valueof() doesnt return null (except possibly in a case the Javadoc isnt that clear on, when it is provided with a non-null Object which has a toString() implementation which returns null ?) and instead gives the String value "null" when provided with a null reference.
> [Java Broker] Implement Message Grouping
> ----------------------------------------
>
> Key: QPID-3720
> URL: https://issues.apache.org/jira/browse/QPID-3720
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Rob Godfrey
> Original Estimate: 6h
> Time Spent: 6h
> Remaining Estimate: 0h
>
> Implement message grouping on the Java Broker (similar in style to that implemented in the C++ broker in QPID-3346)
> In contrast to the C++ implementation
> 1) Once a group has been assigned to a subscription, assign all further messages from the same group to the same group (whether or not all prior messages in the group have been acknowledged)
> 2) Message grouping is allowed on priority queues, Conflation Queues (and Sorted Queues). (However it has no effect on browsers... which means if you using a ConflationQueue as an LVQ by browsing it you cannot use groups).
> 3) Allow for non string values for the group header
> 4) Setting the qpid.shared_msg_group argument is not required on queue construction (whether grouping is enforced or not depends on whether the qpid.group_header_key argument is non-null).
> Note that in general 1) is stricter than the condition that is enforced by the C++ broker - however in the case where a client cancels a subscription without first releasing/acknowledging all outstanding messages that have been delivered then you can get "out of order".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] [Updated] (QPID-3720) [Java Broker] Implement Message
Grouping
Posted by "Rob Godfrey (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Godfrey updated QPID-3720:
------------------------------
Description:
Implement message grouping on the Java Broker (similar in style to that implemented in the C++ broker in QPID-3346)
The Java Broker supports two implementations of message grouping; an implementation with the same semantics as defined by the C++ broker, and an alternative implementation.
In contrast to the C++ implementation the alternative implementation has the following properties:
1) Once a group has been assigned to a subscription, assign all further messages from the same group to the same group (whether or not all prior messages in the group have been acknowledged)
2) The absence of a value in the designated header field for grouping as treated as indicative of a lack of desire for the message to be grouped. Messages with such a lack of a value will be distributed to any available consumer.
Note that in general 1) is stricter than the condition that is enforced by the C++ broker - however in the case where a client cancels a subscription without first releasing/acknowledging all outstanding messages that have been delivered then you can get "out of order".
In general the Java implementation is more liberal than the C++ implementation in that for both strategies available in the Java Broker in that
a) Message grouping is allowed on priority queues, Conflation Queues (and Sorted Queues). (However it has no effect on browsers... which means if you using a ConflationQueue as an LVQ by browsing it you cannot use groups).
b) The broker allows for non string values for the group header
In order to choose the alternative strategy (rather than the C++ style grouping semantics) the qpid.shared_msg_group argument should not be set on queue construction (whether grouping is enforced or not depends on whether the qpid.group_header_key argument is non-null), if qpid.shared_msg_group is set to "1" the C++ style grouping is used, otherwise the alternative implementation is used.
was:
Implement message grouping on the Java Broker (similar in style to that implemented in the C++ broker in QPID-3346)
In contrast to the C++ implementation
1) Once a group has been assigned to a subscription, assign all further messages from the same group to the same group (whether or not all prior messages in the group have been acknowledged)
2) Message grouping is allowed on priority queues, Conflation Queues (and Sorted Queues). (However it has no effect on browsers... which means if you using a ConflationQueue as an LVQ by browsing it you cannot use groups).
3) Allow for non string values for the group header
4) Setting the qpid.shared_msg_group argument is not required on queue construction (whether grouping is enforced or not depends on whether the qpid.group_header_key argument is non-null).
Note that in general 1) is stricter than the condition that is enforced by the C++ broker - however in the case where a client cancels a subscription without first releasing/acknowledging all outstanding messages that have been delivered then you can get "out of order".
> [Java Broker] Implement Message Grouping
> ----------------------------------------
>
> Key: QPID-3720
> URL: https://issues.apache.org/jira/browse/QPID-3720
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Robbie Gemmell
> Original Estimate: 6h
> Time Spent: 6h
> Remaining Estimate: 0h
>
> Implement message grouping on the Java Broker (similar in style to that implemented in the C++ broker in QPID-3346)
> The Java Broker supports two implementations of message grouping; an implementation with the same semantics as defined by the C++ broker, and an alternative implementation.
> In contrast to the C++ implementation the alternative implementation has the following properties:
> 1) Once a group has been assigned to a subscription, assign all further messages from the same group to the same group (whether or not all prior messages in the group have been acknowledged)
> 2) The absence of a value in the designated header field for grouping as treated as indicative of a lack of desire for the message to be grouped. Messages with such a lack of a value will be distributed to any available consumer.
> Note that in general 1) is stricter than the condition that is enforced by the C++ broker - however in the case where a client cancels a subscription without first releasing/acknowledging all outstanding messages that have been delivered then you can get "out of order".
> In general the Java implementation is more liberal than the C++ implementation in that for both strategies available in the Java Broker in that
> a) Message grouping is allowed on priority queues, Conflation Queues (and Sorted Queues). (However it has no effect on browsers... which means if you using a ConflationQueue as an LVQ by browsing it you cannot use groups).
> b) The broker allows for non string values for the group header
> In order to choose the alternative strategy (rather than the C++ style grouping semantics) the qpid.shared_msg_group argument should not be set on queue construction (whether grouping is enforced or not depends on whether the qpid.group_header_key argument is non-null), if qpid.shared_msg_group is set to "1" the C++ style grouping is used, otherwise the alternative implementation is used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] [Resolved] (QPID-3720) [Java Broker] Implement Message
Grouping
Posted by "Robbie Gemmell (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robbie Gemmell resolved QPID-3720.
----------------------------------
Resolution: Fixed
Fix Version/s: 0.15
Closing out
> [Java Broker] Implement Message Grouping
> ----------------------------------------
>
> Key: QPID-3720
> URL: https://issues.apache.org/jira/browse/QPID-3720
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Robbie Gemmell
> Fix For: 0.15
>
> Original Estimate: 6h
> Time Spent: 6h
> Remaining Estimate: 0h
>
> Implement message grouping on the Java Broker (similar in style to that implemented in the C++ broker in QPID-3346)
> The Java Broker supports two implementations of message grouping; an implementation with the same semantics as defined by the C++ broker, and an alternative implementation.
> In contrast to the C++ implementation the alternative implementation has the following properties:
> 1) Once a group has been assigned to a subscription, assign all further messages from the same group to the same group (whether or not all prior messages in the group have been acknowledged)
> 2) The absence of a value in the designated header field for grouping as treated as indicative of a lack of desire for the message to be grouped. Messages with such a lack of a value will be distributed to any available consumer.
> Note that in general 1) is stricter than the condition that is enforced by the C++ broker - however in the case where a client cancels a subscription without first releasing/acknowledging all outstanding messages that have been delivered then you can get "out of order".
> In general the Java implementation is more liberal than the C++ implementation in that for both strategies available in the Java Broker in that
> a) Message grouping is allowed on priority queues, Conflation Queues (and Sorted Queues). (However it has no effect on browsers... which means if you using a ConflationQueue as an LVQ by browsing it you cannot use groups).
> b) The broker allows for non string values for the group header
> In order to choose the alternative strategy (rather than the C++ style grouping semantics) the qpid.shared_msg_group argument should not be set on queue construction (whether grouping is enforced or not depends on whether the qpid.group_header_key argument is non-null), if qpid.shared_msg_group is set to "1" the C++ style grouping is used, otherwise the alternative implementation is used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] [Commented] (QPID-3720) [Java Broker] Implement Message
Grouping
Posted by "Robbie Gemmell (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/QPID-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183991#comment-13183991 ]
Robbie Gemmell commented on QPID-3720:
--------------------------------------
The feature implementation itself seems fine, but the tests could use a couple of changes.
The actual message recieved should be verified to ensure the correct ordering, as the message might be from the correct group but not be the expected message. Eg in testConsumerCloseGroupAssignment, the test would pass if consumer 2 got message 1, 3 or 4 in any order, but there is an expectation of particular messages and ordering so it should be verified. Also in the tests the group verification should have the expected group as the first of the two values instead of the second.
> [Java Broker] Implement Message Grouping
> ----------------------------------------
>
> Key: QPID-3720
> URL: https://issues.apache.org/jira/browse/QPID-3720
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Rob Godfrey
> Assignee: Rob Godfrey
> Original Estimate: 6h
> Time Spent: 6h
> Remaining Estimate: 0h
>
> Implement message grouping on the Java Broker (similar in style to that implemented in the C++ broker in QPID-3346)
> In contrast to the C++ implementation
> 1) Once a group has been assigned to a subscription, assign all further messages from the same group to the same group (whether or not all prior messages in the group have been acknowledged)
> 2) Message grouping is allowed on priority queues, Conflation Queues (and Sorted Queues). (However it has no effect on browsers... which means if you using a ConflationQueue as an LVQ by browsing it you cannot use groups).
> 3) Allow for non string values for the group header
> 4) Setting the qpid.shared_msg_group argument is not required on queue construction (whether grouping is enforced or not depends on whether the qpid.group_header_key argument is non-null).
> Note that in general 1) is stricter than the condition that is enforced by the C++ broker - however in the case where a client cancels a subscription without first releasing/acknowledging all outstanding messages that have been delivered then you can get "out of order".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org