[ 
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:[email protected]

Reply via email to