Qpid
  1. Qpid
  2. QPID-3720

[Java Broker] Implement Message Grouping

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.15
    • Component/s: Java Broker
    • Labels:
      None

      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.

        Issue Links

          Activity

          Rob Godfrey created issue -
          Rob Godfrey made changes -
          Field Original Value New Value
          Status Open [ 1 ] In Progress [ 3 ]
          Rob Godfrey made changes -
          Remaining Estimate 6h [ 21600 ] 0h [ 0 ]
          Time Spent 6h [ 21600 ]
          Worklog Id 12634 [ 12634 ]
          Rob Godfrey made changes -
          Status In Progress [ 3 ] Ready To Review [ 10006 ]
          Rob Godfrey made changes -
          Assignee Rob Godfrey [ rgodfrey ] Robbie Gemmell [ gemmellr ]
          Rob Godfrey made changes -
          Description 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".
          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.

          Robbie Gemmell made changes -
          Status Ready To Review [ 10006 ] Resolved [ 5 ]
          Fix Version/s 0.15 [ 12319043 ]
          Resolution Fixed [ 1 ]
          Philip Harvey made changes -
          Link This issue is related to QPID-4817 [ QPID-4817 ]
          Rob Godfrey made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Robbie Gemmell
              Reporter:
              Rob Godfrey
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 6h
                6h
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 6h
                6h

                  Development