Qpid
  1. Qpid
  2. QPID-3417

Support for timestamping messages on arrival at the broker.

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 0.13
    • Fix Version/s: 0.14
    • Component/s: C++ Broker
    • Labels:
      None

      Description

      AMQP 0.10 defines an optional message delivery property of timestamp:

      name: timestamp
      type: datetime
      description: message timestamp
      (optional) The timestamp is set by the broker on arrival of the message.

      I'd like to make use of this timestamp for a proposed debugging feature for message groups. See the message groups UI proposal in https://issues.apache.org/jira/browse/QPID-3346 for details of its use.

      I think it would more useful to introduce a generic message timestamp capability based on the AMQP 0.10 delivery property, rather than integrate something limited only to message groups.

      Functional Model:

      The broker would support the configuration of a "timestamp interval". This interval would be expressed in millisecond units, and would represent the granularity of the message timestamp. The default setting of this interval would be zero - which would be interpreted as disabled. When enabled (non-zero) the broker would maintain a time-of-day time stamp. This time stamp would be updated (resync'ed to the current time-of-day) periodically based on the configured "timestamp interval".

      When enabled, each message arriving at the broker will have the "timestamp" delivery property set to the current value of the broker's time stamp.

      This feature will need to be able to be turned on and off on demand, without restarting the broker. Therefore new QMF methods would be added to the broker's QMF object to support run-time configuration:

      method: getMessageTimestamp - returns the configured timestamp value for the broker in milliseconds.
      method: setMessageTimestamp - sets the broker's timestamp value (expressed in milliseconds).

        Issue Links

          Activity

          Ken Giusti created issue -
          Hide
          Gordon Sim added a comment -

          Are you saying you could set the message timestamp itself dynamically, or just reconfigure the interval option?

          Show
          Gordon Sim added a comment - Are you saying you could set the message timestamp itself dynamically, or just reconfigure the interval option?
          Hide
          Ken Giusti added a comment -

          Reconfigure the interval, including enable and disable the feature via QMF. The broker maintains the value of the timestamp, I wouldn't expect we'd need to modify that. The names and descriptions could be clearer:

          method: getMessageTimestampInterval - returns the configured timestamp interval for the broker (in milliseconds).
          method: setMessageTimestampInterval - sets the broker's timestamp interval (expressed in milliseconds).

          Instead of 'interval', would 'granularity' be more accurate?

          Show
          Ken Giusti added a comment - Reconfigure the interval, including enable and disable the feature via QMF. The broker maintains the value of the timestamp, I wouldn't expect we'd need to modify that. The names and descriptions could be clearer: method: getMessageTimestampInterval - returns the configured timestamp interval for the broker (in milliseconds). method: setMessageTimestampInterval - sets the broker's timestamp interval (expressed in milliseconds). Instead of 'interval', would 'granularity' be more accurate?
          Hide
          Gordon Sim added a comment -

          That's what I thought, those names are indeed better. I think granularity is a little more expressive.

          Show
          Gordon Sim added a comment - That's what I thought, those names are indeed better. I think granularity is a little more expressive.
          Hide
          Alan Conway added a comment -

          Why an interval to update the a timestamp? Just use AbsTime::now() to stamp messages as they go by. No point re-inventing the system clock.

          Show
          Alan Conway added a comment - Why an interval to update the a timestamp? Just use AbsTime::now() to stamp messages as they go by. No point re-inventing the system clock.
          Hide
          Ken Giusti added a comment -

          Alan - good point. I'm guilty of putting the cart before the horse here - I'm assuming calling AbsTime::now() is going to be a bigger performance hit that using a less frequently updated timestamp (and the read-locks that would be necessary to keep it consistent).

          Since this feature is intended for use as a debug aid - and an performance impact would be the cost - we're probably best off implementing your simpler solution and qualifying the performance hit. I'll give that a try. Thanks.

          Show
          Ken Giusti added a comment - Alan - good point. I'm guilty of putting the cart before the horse here - I'm assuming calling AbsTime::now() is going to be a bigger performance hit that using a less frequently updated timestamp (and the read-locks that would be necessary to keep it consistent). Since this feature is intended for use as a debug aid - and an performance impact would be the cost - we're probably best off implementing your simpler solution and qualifying the performance hit. I'll give that a try. Thanks.
          Hide
          jiraposter@reviews.apache.org added a comment -

          -----------------------------------------------------------
          This is an automatically generated e-mail. To reply, visit:
          https://reviews.apache.org/r/2335/
          -----------------------------------------------------------

          Review request for qpid, Gordon Sim and Ted Ross.

          Summary
          -------

          A slight deviation from the design originally proposed in QPID-3417 - this change adds the timestamp delivery property to messages using the relatively simple approach as described in AMQP-0.10.

          Other than the approach itself, the QMF management interface & schema changes seem like I could be guilty of overkill - I'd like feedback before I go too far down that hole...

          This addresses bug qpid-3417.
          https://issues.apache.org/jira/browse/qpid-3417

          Diffs


          /trunk/qpid/cpp/src/qpid/broker/Broker.h 1180888
          /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1180888
          /trunk/qpid/cpp/src/qpid/broker/Message.h 1180888
          /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1180888
          /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1180888
          /trunk/qpid/cpp/src/qpid/client/amqp0_10/IncomingMessages.cpp 1180888
          /trunk/qpid/cpp/src/tests/BrokerOptions.cpp PRE-CREATION
          /trunk/qpid/cpp/src/tests/Makefile.am 1180888
          /trunk/qpid/specs/management-schema.xml 1180888

          Diff: https://reviews.apache.org/r/2335/diff

          Testing
          -------

          One unit test to verify the timestamp is being added. No dynamic control via mgmt yet.

          Simple perf testing didn't seem like the hit wasn't too bad so far:

          Pre patch, from trunk:
          [root@mrg44 tests]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000
          send-tp recv-tp l-min l-max l-avg
          68428 68388 0.16 69.59 4.16
          68238 68201 0.17 44.18 3.82
          68622 68581 0.16 102.52 4.60
          68688 68647 0.18 117.33 5.29
          69142 69104 0.19 103.30 4.50

          Patched, no timestamping:
          [root@mrg44 src]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000
          send-tp recv-tp l-min l-max l-avg
          67543 67471 0.17 79.76 4.37
          69069 69028 0.15 42.92 3.78
          68481 68439 0.17 45.91 3.98
          68674 68636 0.18 41.30 3.74
          67588 67587 0.17 60.23 4.21

          Patched, timestamping enabled:
          [root@mrg44 src]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000
          send-tp recv-tp l-min l-max l-avg
          67228 67227 0.21 41.80 3.97
          67697 67659 0.19 43.01 4.19
          67405 67368 0.19 101.61 4.99
          66515 66511 0.15 41.85 4.10
          67664 67622 0.17 47.35 4.01

          Thanks,

          Kenneth

          Show
          jiraposter@reviews.apache.org added a comment - ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2335/ ----------------------------------------------------------- Review request for qpid, Gordon Sim and Ted Ross. Summary ------- A slight deviation from the design originally proposed in QPID-3417 - this change adds the timestamp delivery property to messages using the relatively simple approach as described in AMQP-0.10. Other than the approach itself, the QMF management interface & schema changes seem like I could be guilty of overkill - I'd like feedback before I go too far down that hole... This addresses bug qpid-3417. https://issues.apache.org/jira/browse/qpid-3417 Diffs /trunk/qpid/cpp/src/qpid/broker/Broker.h 1180888 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1180888 /trunk/qpid/cpp/src/qpid/broker/Message.h 1180888 /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1180888 /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1180888 /trunk/qpid/cpp/src/qpid/client/amqp0_10/IncomingMessages.cpp 1180888 /trunk/qpid/cpp/src/tests/BrokerOptions.cpp PRE-CREATION /trunk/qpid/cpp/src/tests/Makefile.am 1180888 /trunk/qpid/specs/management-schema.xml 1180888 Diff: https://reviews.apache.org/r/2335/diff Testing ------- One unit test to verify the timestamp is being added. No dynamic control via mgmt yet. Simple perf testing didn't seem like the hit wasn't too bad so far: Pre patch, from trunk: [root@mrg44 tests] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 68428 68388 0.16 69.59 4.16 68238 68201 0.17 44.18 3.82 68622 68581 0.16 102.52 4.60 68688 68647 0.18 117.33 5.29 69142 69104 0.19 103.30 4.50 Patched, no timestamping: [root@mrg44 src] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 67543 67471 0.17 79.76 4.37 69069 69028 0.15 42.92 3.78 68481 68439 0.17 45.91 3.98 68674 68636 0.18 41.30 3.74 67588 67587 0.17 60.23 4.21 Patched, timestamping enabled: [root@mrg44 src] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 67228 67227 0.21 41.80 3.97 67697 67659 0.19 43.01 4.19 67405 67368 0.19 101.61 4.99 66515 66511 0.15 41.85 4.10 67664 67622 0.17 47.35 4.01 Thanks, Kenneth
          Hide
          jiraposter@reviews.apache.org added a comment -

          -----------------------------------------------------------
          This is an automatically generated e-mail. To reply, visit:
          https://reviews.apache.org/r/2335/#review2505
          -----------------------------------------------------------

          /trunk/qpid/cpp/src/qpid/broker/Message.cpp
          <https://reviews.apache.org/r/2335/#comment5669>

          Might be worth renaming this method. It should have been renamed much earlier, but now it seems if anything even more odd given there is a parameter that effectively indicates whether to set the timestamp.

          Maybe just routed() or handled()?

          /trunk/qpid/specs/management-schema.xml
          <https://reviews.apache.org/r/2335/#comment5670>

          I'm torn on this approach to management.

          On the one hand I like having a relatively loose schema that can be evolved more easily, and I like having generic mechanisms rather than lots of specific methods.

          On the other hand the use of the map as the value feels clunky. It also feels as if the control of attributes should be a more intrinsic part of QMF. And finally I'm concerned that the vision for management at a higher level isn't really clear and our piecemeal changes (not just this but over many other changes) is lacking coherence.

          • Gordon

          On 2011-10-10 23:14:39, Kenneth Giusti wrote:

          -----------------------------------------------------------

          This is an automatically generated e-mail. To reply, visit:

          https://reviews.apache.org/r/2335/

          -----------------------------------------------------------

          (Updated 2011-10-10 23:14:39)

          Review request for qpid, Gordon Sim and Ted Ross.

          Summary

          -------

          A slight deviation from the design originally proposed in QPID-3417 - this change adds the timestamp delivery property to messages using the relatively simple approach as described in AMQP-0.10.

          Other than the approach itself, the QMF management interface & schema changes seem like I could be guilty of overkill - I'd like feedback before I go too far down that hole...

          This addresses bug qpid-3417.

          https://issues.apache.org/jira/browse/qpid-3417

          Diffs

          -----

          /trunk/qpid/cpp/src/qpid/broker/Broker.h 1180888

          /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1180888

          /trunk/qpid/cpp/src/qpid/broker/Message.h 1180888

          /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1180888

          /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1180888

          /trunk/qpid/cpp/src/qpid/client/amqp0_10/IncomingMessages.cpp 1180888

          /trunk/qpid/cpp/src/tests/BrokerOptions.cpp PRE-CREATION

          /trunk/qpid/cpp/src/tests/Makefile.am 1180888

          /trunk/qpid/specs/management-schema.xml 1180888

          Diff: https://reviews.apache.org/r/2335/diff

          Testing

          -------

          One unit test to verify the timestamp is being added. No dynamic control via mgmt yet.

          Simple perf testing didn't seem like the hit wasn't too bad so far:

          Pre patch, from trunk:

          [root@mrg44 tests]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000

          send-tp recv-tp l-min l-max l-avg

          68428 68388 0.16 69.59 4.16

          68238 68201 0.17 44.18 3.82

          68622 68581 0.16 102.52 4.60

          68688 68647 0.18 117.33 5.29

          69142 69104 0.19 103.30 4.50

          Patched, no timestamping:

          [root@mrg44 src]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000

          send-tp recv-tp l-min l-max l-avg

          67543 67471 0.17 79.76 4.37

          69069 69028 0.15 42.92 3.78

          68481 68439 0.17 45.91 3.98

          68674 68636 0.18 41.30 3.74

          67588 67587 0.17 60.23 4.21

          Patched, timestamping enabled:

          [root@mrg44 src]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000

          send-tp recv-tp l-min l-max l-avg

          67228 67227 0.21 41.80 3.97

          67697 67659 0.19 43.01 4.19

          67405 67368 0.19 101.61 4.99

          66515 66511 0.15 41.85 4.10

          67664 67622 0.17 47.35 4.01

          Thanks,

          Kenneth

          Show
          jiraposter@reviews.apache.org added a comment - ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2335/#review2505 ----------------------------------------------------------- /trunk/qpid/cpp/src/qpid/broker/Message.cpp < https://reviews.apache.org/r/2335/#comment5669 > Might be worth renaming this method. It should have been renamed much earlier, but now it seems if anything even more odd given there is a parameter that effectively indicates whether to set the timestamp. Maybe just routed() or handled()? /trunk/qpid/specs/management-schema.xml < https://reviews.apache.org/r/2335/#comment5670 > I'm torn on this approach to management. On the one hand I like having a relatively loose schema that can be evolved more easily, and I like having generic mechanisms rather than lots of specific methods. On the other hand the use of the map as the value feels clunky. It also feels as if the control of attributes should be a more intrinsic part of QMF. And finally I'm concerned that the vision for management at a higher level isn't really clear and our piecemeal changes (not just this but over many other changes) is lacking coherence. Gordon On 2011-10-10 23:14:39, Kenneth Giusti wrote: ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2335/ ----------------------------------------------------------- (Updated 2011-10-10 23:14:39) Review request for qpid, Gordon Sim and Ted Ross. Summary ------- A slight deviation from the design originally proposed in QPID-3417 - this change adds the timestamp delivery property to messages using the relatively simple approach as described in AMQP-0.10. Other than the approach itself, the QMF management interface & schema changes seem like I could be guilty of overkill - I'd like feedback before I go too far down that hole... This addresses bug qpid-3417. https://issues.apache.org/jira/browse/qpid-3417 Diffs ----- /trunk/qpid/cpp/src/qpid/broker/Broker.h 1180888 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1180888 /trunk/qpid/cpp/src/qpid/broker/Message.h 1180888 /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1180888 /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1180888 /trunk/qpid/cpp/src/qpid/client/amqp0_10/IncomingMessages.cpp 1180888 /trunk/qpid/cpp/src/tests/BrokerOptions.cpp PRE-CREATION /trunk/qpid/cpp/src/tests/Makefile.am 1180888 /trunk/qpid/specs/management-schema.xml 1180888 Diff: https://reviews.apache.org/r/2335/diff Testing ------- One unit test to verify the timestamp is being added. No dynamic control via mgmt yet. Simple perf testing didn't seem like the hit wasn't too bad so far: Pre patch, from trunk: [root@mrg44 tests] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 68428 68388 0.16 69.59 4.16 68238 68201 0.17 44.18 3.82 68622 68581 0.16 102.52 4.60 68688 68647 0.18 117.33 5.29 69142 69104 0.19 103.30 4.50 Patched, no timestamping: [root@mrg44 src] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 67543 67471 0.17 79.76 4.37 69069 69028 0.15 42.92 3.78 68481 68439 0.17 45.91 3.98 68674 68636 0.18 41.30 3.74 67588 67587 0.17 60.23 4.21 Patched, timestamping enabled: [root@mrg44 src] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 67228 67227 0.21 41.80 3.97 67697 67659 0.19 43.01 4.19 67405 67368 0.19 101.61 4.99 66515 66511 0.15 41.85 4.10 67664 67622 0.17 47.35 4.01 Thanks, Kenneth
          Hide
          jiraposter@reviews.apache.org added a comment -

          On 2011-10-11 07:51:39, Gordon Sim wrote:

          > /trunk/qpid/cpp/src/qpid/broker/Message.cpp, line 380

          > <https://reviews.apache.org/r/2335/diff/1/?file=49291#file49291line380>

          >

          > Might be worth renaming this method. It should have been renamed much earlier, but now it seems if anything even more odd given there is a parameter that effectively indicates whether to set the timestamp.

          >

          > Maybe just routed() or handled()?

          Agreed - I'll touch that up.

          On 2011-10-11 07:51:39, Gordon Sim wrote:

          > /trunk/qpid/specs/management-schema.xml, line 106

          > <https://reviews.apache.org/r/2335/diff/1/?file=49296#file49296line106>

          >

          > I'm torn on this approach to management.

          >

          > On the one hand I like having a relatively loose schema that can be evolved more easily, and I like having generic mechanisms rather than lots of specific methods.

          >

          > On the other hand the use of the map as the value feels clunky. It also feels as if the control of attributes should be a more intrinsic part of QMF. And finally I'm concerned that the vision for management at a higher level isn't really clear and our piecemeal changes (not just this but over many other changes) is lacking coherence.

          Me too - I'd prefer having "enableTimestamp" as a simple boolean QMF property with RW access, but QMF doesn't yet support that type of access.

          The ability to turn this feature on and off at runtime is critical - at best I'll have to go with a set of "get/set" timestamping methods.

          • Kenneth

          -----------------------------------------------------------
          This is an automatically generated e-mail. To reply, visit:
          https://reviews.apache.org/r/2335/#review2505
          -----------------------------------------------------------

          On 2011-10-10 23:14:39, Kenneth Giusti wrote:

          -----------------------------------------------------------

          This is an automatically generated e-mail. To reply, visit:

          https://reviews.apache.org/r/2335/

          -----------------------------------------------------------

          (Updated 2011-10-10 23:14:39)

          Review request for qpid, Gordon Sim and Ted Ross.

          Summary

          -------

          A slight deviation from the design originally proposed in QPID-3417 - this change adds the timestamp delivery property to messages using the relatively simple approach as described in AMQP-0.10.

          Other than the approach itself, the QMF management interface & schema changes seem like I could be guilty of overkill - I'd like feedback before I go too far down that hole...

          This addresses bug qpid-3417.

          https://issues.apache.org/jira/browse/qpid-3417

          Diffs

          -----

          /trunk/qpid/cpp/src/qpid/broker/Broker.h 1180888

          /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1180888

          /trunk/qpid/cpp/src/qpid/broker/Message.h 1180888

          /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1180888

          /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1180888

          /trunk/qpid/cpp/src/qpid/client/amqp0_10/IncomingMessages.cpp 1180888

          /trunk/qpid/cpp/src/tests/BrokerOptions.cpp PRE-CREATION

          /trunk/qpid/cpp/src/tests/Makefile.am 1180888

          /trunk/qpid/specs/management-schema.xml 1180888

          Diff: https://reviews.apache.org/r/2335/diff

          Testing

          -------

          One unit test to verify the timestamp is being added. No dynamic control via mgmt yet.

          Simple perf testing didn't seem like the hit wasn't too bad so far:

          Pre patch, from trunk:

          [root@mrg44 tests]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000

          send-tp recv-tp l-min l-max l-avg

          68428 68388 0.16 69.59 4.16

          68238 68201 0.17 44.18 3.82

          68622 68581 0.16 102.52 4.60

          68688 68647 0.18 117.33 5.29

          69142 69104 0.19 103.30 4.50

          Patched, no timestamping:

          [root@mrg44 src]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000

          send-tp recv-tp l-min l-max l-avg

          67543 67471 0.17 79.76 4.37

          69069 69028 0.15 42.92 3.78

          68481 68439 0.17 45.91 3.98

          68674 68636 0.18 41.30 3.74

          67588 67587 0.17 60.23 4.21

          Patched, timestamping enabled:

          [root@mrg44 src]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000

          send-tp recv-tp l-min l-max l-avg

          67228 67227 0.21 41.80 3.97

          67697 67659 0.19 43.01 4.19

          67405 67368 0.19 101.61 4.99

          66515 66511 0.15 41.85 4.10

          67664 67622 0.17 47.35 4.01

          Thanks,

          Kenneth

          Show
          jiraposter@reviews.apache.org added a comment - On 2011-10-11 07:51:39, Gordon Sim wrote: > /trunk/qpid/cpp/src/qpid/broker/Message.cpp, line 380 > < https://reviews.apache.org/r/2335/diff/1/?file=49291#file49291line380 > > > Might be worth renaming this method. It should have been renamed much earlier, but now it seems if anything even more odd given there is a parameter that effectively indicates whether to set the timestamp. > > Maybe just routed() or handled()? Agreed - I'll touch that up. On 2011-10-11 07:51:39, Gordon Sim wrote: > /trunk/qpid/specs/management-schema.xml, line 106 > < https://reviews.apache.org/r/2335/diff/1/?file=49296#file49296line106 > > > I'm torn on this approach to management. > > On the one hand I like having a relatively loose schema that can be evolved more easily, and I like having generic mechanisms rather than lots of specific methods. > > On the other hand the use of the map as the value feels clunky. It also feels as if the control of attributes should be a more intrinsic part of QMF. And finally I'm concerned that the vision for management at a higher level isn't really clear and our piecemeal changes (not just this but over many other changes) is lacking coherence. Me too - I'd prefer having "enableTimestamp" as a simple boolean QMF property with RW access, but QMF doesn't yet support that type of access. The ability to turn this feature on and off at runtime is critical - at best I'll have to go with a set of "get/set" timestamping methods. Kenneth ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2335/#review2505 ----------------------------------------------------------- On 2011-10-10 23:14:39, Kenneth Giusti wrote: ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2335/ ----------------------------------------------------------- (Updated 2011-10-10 23:14:39) Review request for qpid, Gordon Sim and Ted Ross. Summary ------- A slight deviation from the design originally proposed in QPID-3417 - this change adds the timestamp delivery property to messages using the relatively simple approach as described in AMQP-0.10. Other than the approach itself, the QMF management interface & schema changes seem like I could be guilty of overkill - I'd like feedback before I go too far down that hole... This addresses bug qpid-3417. https://issues.apache.org/jira/browse/qpid-3417 Diffs ----- /trunk/qpid/cpp/src/qpid/broker/Broker.h 1180888 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1180888 /trunk/qpid/cpp/src/qpid/broker/Message.h 1180888 /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1180888 /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1180888 /trunk/qpid/cpp/src/qpid/client/amqp0_10/IncomingMessages.cpp 1180888 /trunk/qpid/cpp/src/tests/BrokerOptions.cpp PRE-CREATION /trunk/qpid/cpp/src/tests/Makefile.am 1180888 /trunk/qpid/specs/management-schema.xml 1180888 Diff: https://reviews.apache.org/r/2335/diff Testing ------- One unit test to verify the timestamp is being added. No dynamic control via mgmt yet. Simple perf testing didn't seem like the hit wasn't too bad so far: Pre patch, from trunk: [root@mrg44 tests] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 68428 68388 0.16 69.59 4.16 68238 68201 0.17 44.18 3.82 68622 68581 0.16 102.52 4.60 68688 68647 0.18 117.33 5.29 69142 69104 0.19 103.30 4.50 Patched, no timestamping: [root@mrg44 src] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 67543 67471 0.17 79.76 4.37 69069 69028 0.15 42.92 3.78 68481 68439 0.17 45.91 3.98 68674 68636 0.18 41.30 3.74 67588 67587 0.17 60.23 4.21 Patched, timestamping enabled: [root@mrg44 src] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 67228 67227 0.21 41.80 3.97 67697 67659 0.19 43.01 4.19 67405 67368 0.19 101.61 4.99 66515 66511 0.15 41.85 4.10 67664 67622 0.17 47.35 4.01 Thanks, Kenneth
          Hide
          jiraposter@reviews.apache.org added a comment -

          On 2011-10-11 07:51:39, Gordon Sim wrote:

          > /trunk/qpid/specs/management-schema.xml, line 106

          > <https://reviews.apache.org/r/2335/diff/1/?file=49296#file49296line106>

          >

          > I'm torn on this approach to management.

          >

          > On the one hand I like having a relatively loose schema that can be evolved more easily, and I like having generic mechanisms rather than lots of specific methods.

          >

          > On the other hand the use of the map as the value feels clunky. It also feels as if the control of attributes should be a more intrinsic part of QMF. And finally I'm concerned that the vision for management at a higher level isn't really clear and our piecemeal changes (not just this but over many other changes) is lacking coherence.

          Kenneth Giusti wrote:

          Me too - I'd prefer having "enableTimestamp" as a simple boolean QMF property with RW access, but QMF doesn't yet support that type of access.

          The ability to turn this feature on and off at runtime is critical - at best I'll have to go with a set of "get/set" timestamping methods.

          I think get/set timestamping methods would be the best option at this point. We already have get/set log-level. We can then try and genericise the approach at some later point.

          • Gordon

          -----------------------------------------------------------
          This is an automatically generated e-mail. To reply, visit:
          https://reviews.apache.org/r/2335/#review2505
          -----------------------------------------------------------

          On 2011-10-10 23:14:39, Kenneth Giusti wrote:

          -----------------------------------------------------------

          This is an automatically generated e-mail. To reply, visit:

          https://reviews.apache.org/r/2335/

          -----------------------------------------------------------

          (Updated 2011-10-10 23:14:39)

          Review request for qpid, Gordon Sim and Ted Ross.

          Summary

          -------

          A slight deviation from the design originally proposed in QPID-3417 - this change adds the timestamp delivery property to messages using the relatively simple approach as described in AMQP-0.10.

          Other than the approach itself, the QMF management interface & schema changes seem like I could be guilty of overkill - I'd like feedback before I go too far down that hole...

          This addresses bug qpid-3417.

          https://issues.apache.org/jira/browse/qpid-3417

          Diffs

          -----

          /trunk/qpid/cpp/src/qpid/broker/Broker.h 1180888

          /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1180888

          /trunk/qpid/cpp/src/qpid/broker/Message.h 1180888

          /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1180888

          /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1180888

          /trunk/qpid/cpp/src/qpid/client/amqp0_10/IncomingMessages.cpp 1180888

          /trunk/qpid/cpp/src/tests/BrokerOptions.cpp PRE-CREATION

          /trunk/qpid/cpp/src/tests/Makefile.am 1180888

          /trunk/qpid/specs/management-schema.xml 1180888

          Diff: https://reviews.apache.org/r/2335/diff

          Testing

          -------

          One unit test to verify the timestamp is being added. No dynamic control via mgmt yet.

          Simple perf testing didn't seem like the hit wasn't too bad so far:

          Pre patch, from trunk:

          [root@mrg44 tests]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000

          send-tp recv-tp l-min l-max l-avg

          68428 68388 0.16 69.59 4.16

          68238 68201 0.17 44.18 3.82

          68622 68581 0.16 102.52 4.60

          68688 68647 0.18 117.33 5.29

          69142 69104 0.19 103.30 4.50

          Patched, no timestamping:

          [root@mrg44 src]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000

          send-tp recv-tp l-min l-max l-avg

          67543 67471 0.17 79.76 4.37

          69069 69028 0.15 42.92 3.78

          68481 68439 0.17 45.91 3.98

          68674 68636 0.18 41.30 3.74

          67588 67587 0.17 60.23 4.21

          Patched, timestamping enabled:

          [root@mrg44 src]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000

          send-tp recv-tp l-min l-max l-avg

          67228 67227 0.21 41.80 3.97

          67697 67659 0.19 43.01 4.19

          67405 67368 0.19 101.61 4.99

          66515 66511 0.15 41.85 4.10

          67664 67622 0.17 47.35 4.01

          Thanks,

          Kenneth

          Show
          jiraposter@reviews.apache.org added a comment - On 2011-10-11 07:51:39, Gordon Sim wrote: > /trunk/qpid/specs/management-schema.xml, line 106 > < https://reviews.apache.org/r/2335/diff/1/?file=49296#file49296line106 > > > I'm torn on this approach to management. > > On the one hand I like having a relatively loose schema that can be evolved more easily, and I like having generic mechanisms rather than lots of specific methods. > > On the other hand the use of the map as the value feels clunky. It also feels as if the control of attributes should be a more intrinsic part of QMF. And finally I'm concerned that the vision for management at a higher level isn't really clear and our piecemeal changes (not just this but over many other changes) is lacking coherence. Kenneth Giusti wrote: Me too - I'd prefer having "enableTimestamp" as a simple boolean QMF property with RW access, but QMF doesn't yet support that type of access. The ability to turn this feature on and off at runtime is critical - at best I'll have to go with a set of "get/set" timestamping methods. I think get/set timestamping methods would be the best option at this point. We already have get/set log-level. We can then try and genericise the approach at some later point. Gordon ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2335/#review2505 ----------------------------------------------------------- On 2011-10-10 23:14:39, Kenneth Giusti wrote: ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2335/ ----------------------------------------------------------- (Updated 2011-10-10 23:14:39) Review request for qpid, Gordon Sim and Ted Ross. Summary ------- A slight deviation from the design originally proposed in QPID-3417 - this change adds the timestamp delivery property to messages using the relatively simple approach as described in AMQP-0.10. Other than the approach itself, the QMF management interface & schema changes seem like I could be guilty of overkill - I'd like feedback before I go too far down that hole... This addresses bug qpid-3417. https://issues.apache.org/jira/browse/qpid-3417 Diffs ----- /trunk/qpid/cpp/src/qpid/broker/Broker.h 1180888 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1180888 /trunk/qpid/cpp/src/qpid/broker/Message.h 1180888 /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1180888 /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1180888 /trunk/qpid/cpp/src/qpid/client/amqp0_10/IncomingMessages.cpp 1180888 /trunk/qpid/cpp/src/tests/BrokerOptions.cpp PRE-CREATION /trunk/qpid/cpp/src/tests/Makefile.am 1180888 /trunk/qpid/specs/management-schema.xml 1180888 Diff: https://reviews.apache.org/r/2335/diff Testing ------- One unit test to verify the timestamp is being added. No dynamic control via mgmt yet. Simple perf testing didn't seem like the hit wasn't too bad so far: Pre patch, from trunk: [root@mrg44 tests] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 68428 68388 0.16 69.59 4.16 68238 68201 0.17 44.18 3.82 68622 68581 0.16 102.52 4.60 68688 68647 0.18 117.33 5.29 69142 69104 0.19 103.30 4.50 Patched, no timestamping: [root@mrg44 src] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 67543 67471 0.17 79.76 4.37 69069 69028 0.15 42.92 3.78 68481 68439 0.17 45.91 3.98 68674 68636 0.18 41.30 3.74 67588 67587 0.17 60.23 4.21 Patched, timestamping enabled: [root@mrg44 src] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 67228 67227 0.21 41.80 3.97 67697 67659 0.19 43.01 4.19 67405 67368 0.19 101.61 4.99 66515 66511 0.15 41.85 4.10 67664 67622 0.17 47.35 4.01 Thanks, Kenneth
          Hide
          jiraposter@reviews.apache.org added a comment -

          -----------------------------------------------------------
          This is an automatically generated e-mail. To reply, visit:
          https://reviews.apache.org/r/2335/
          -----------------------------------------------------------

          (Updated 2011-10-12 16:15:37.240703)

          Review request for qpid, Gordon Sim and Ted Ross.

          Changes
          -------

          A complete patch, including additional tests.

          The performance does drop as expected when enabled, but the perf when disabled does not appear to degenerate from current trunk.

          Patch w/o timestamping enabled:

          [root@mrg44 tests]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000
          send-tp recv-tp l-min l-max l-avg
          68834 68794 0.18 47.48 3.77
          69200 69158 0.20 59.15 4.14
          69116 69074 0.16 44.76 3.77
          69273 69270 0.19 120.19 4.62
          68360 68320 0.17 59.79 3.96

          And enabled:

          [root@mrg44 src]# ./qpidd -d --auth no --enable-timestamp=yes
          [root@mrg44 src]# ps aux | grep qpidd
          root 19248 0.0 0.0 135624 3544 ? Ssl 11:59 0:00 /root/kgiusti/qpid/cpp/src/.libs/lt-qpidd -d --auth no --enable-timestamp=yes
          root 19259 0.0 0.0 61180 772 pts/0 S+ 11:59 0:00 grep qpidd
          [root@mrg44 src]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000
          send-tp recv-tp l-min l-max l-avg
          65561 65523 0.19 43.84 3.88
          64773 64739 0.17 43.86 4.06
          66266 66225 0.19 142.72 5.48
          64238 64203 0.18 43.09 4.29
          66369 66333 0.17 70.70 4.23

          Summary
          -------

          A slight deviation from the design originally proposed in QPID-3417 - this change adds the timestamp delivery property to messages using the relatively simple approach as described in AMQP-0.10.

          Other than the approach itself, the QMF management interface & schema changes seem like I could be guilty of overkill - I'd like feedback before I go too far down that hole...

          This addresses bug qpid-3417.
          https://issues.apache.org/jira/browse/qpid-3417

          Diffs (updated)


          /trunk/qpid/cpp/src/qpid/broker/Broker.h 1182419
          /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1182419
          /trunk/qpid/cpp/src/qpid/broker/Message.h 1182419
          /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1182419
          /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1182419
          /trunk/qpid/cpp/src/qpid/broker/SessionState.cpp 1182419
          /trunk/qpid/cpp/src/qpid/client/amqp0_10/IncomingMessages.cpp 1182419
          /trunk/qpid/cpp/src/qpid/management/ManagementAgent.cpp 1182419
          /trunk/qpid/cpp/src/tests/BrokerOptions.cpp PRE-CREATION
          /trunk/qpid/cpp/src/tests/Makefile.am 1182419
          /trunk/qpid/cpp/src/tests/QueueTest.cpp 1182419
          /trunk/qpid/cpp/src/tests/acl.py 1182419
          /trunk/qpid/java/broker/src/main/java/org/apache/qpid/qmf/QMFService.java 1182419
          /trunk/qpid/specs/management-schema.xml 1182419
          /trunk/qpid/tests/src/py/qpid_tests/broker_0_10/management.py 1182419

          Diff: https://reviews.apache.org/r/2335/diff

          Testing
          -------

          One unit test to verify the timestamp is being added. No dynamic control via mgmt yet.

          Simple perf testing didn't seem like the hit wasn't too bad so far:

          Pre patch, from trunk:
          [root@mrg44 tests]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000
          send-tp recv-tp l-min l-max l-avg
          68428 68388 0.16 69.59 4.16
          68238 68201 0.17 44.18 3.82
          68622 68581 0.16 102.52 4.60
          68688 68647 0.18 117.33 5.29
          69142 69104 0.19 103.30 4.50

          Patched, no timestamping:
          [root@mrg44 src]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000
          send-tp recv-tp l-min l-max l-avg
          67543 67471 0.17 79.76 4.37
          69069 69028 0.15 42.92 3.78
          68481 68439 0.17 45.91 3.98
          68674 68636 0.18 41.30 3.74
          67588 67587 0.17 60.23 4.21

          Patched, timestamping enabled:
          [root@mrg44 src]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000
          send-tp recv-tp l-min l-max l-avg
          67228 67227 0.21 41.80 3.97
          67697 67659 0.19 43.01 4.19
          67405 67368 0.19 101.61 4.99
          66515 66511 0.15 41.85 4.10
          67664 67622 0.17 47.35 4.01

          Thanks,

          Kenneth

          Show
          jiraposter@reviews.apache.org added a comment - ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2335/ ----------------------------------------------------------- (Updated 2011-10-12 16:15:37.240703) Review request for qpid, Gordon Sim and Ted Ross. Changes ------- A complete patch, including additional tests. The performance does drop as expected when enabled, but the perf when disabled does not appear to degenerate from current trunk. Patch w/o timestamping enabled: [root@mrg44 tests] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 68834 68794 0.18 47.48 3.77 69200 69158 0.20 59.15 4.14 69116 69074 0.16 44.76 3.77 69273 69270 0.19 120.19 4.62 68360 68320 0.17 59.79 3.96 And enabled: [root@mrg44 src] # ./qpidd -d --auth no --enable-timestamp=yes [root@mrg44 src] # ps aux | grep qpidd root 19248 0.0 0.0 135624 3544 ? Ssl 11:59 0:00 /root/kgiusti/qpid/cpp/src/.libs/lt-qpidd -d --auth no --enable-timestamp=yes root 19259 0.0 0.0 61180 772 pts/0 S+ 11:59 0:00 grep qpidd [root@mrg44 src] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 65561 65523 0.19 43.84 3.88 64773 64739 0.17 43.86 4.06 66266 66225 0.19 142.72 5.48 64238 64203 0.18 43.09 4.29 66369 66333 0.17 70.70 4.23 Summary ------- A slight deviation from the design originally proposed in QPID-3417 - this change adds the timestamp delivery property to messages using the relatively simple approach as described in AMQP-0.10. Other than the approach itself, the QMF management interface & schema changes seem like I could be guilty of overkill - I'd like feedback before I go too far down that hole... This addresses bug qpid-3417. https://issues.apache.org/jira/browse/qpid-3417 Diffs (updated) /trunk/qpid/cpp/src/qpid/broker/Broker.h 1182419 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1182419 /trunk/qpid/cpp/src/qpid/broker/Message.h 1182419 /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1182419 /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1182419 /trunk/qpid/cpp/src/qpid/broker/SessionState.cpp 1182419 /trunk/qpid/cpp/src/qpid/client/amqp0_10/IncomingMessages.cpp 1182419 /trunk/qpid/cpp/src/qpid/management/ManagementAgent.cpp 1182419 /trunk/qpid/cpp/src/tests/BrokerOptions.cpp PRE-CREATION /trunk/qpid/cpp/src/tests/Makefile.am 1182419 /trunk/qpid/cpp/src/tests/QueueTest.cpp 1182419 /trunk/qpid/cpp/src/tests/acl.py 1182419 /trunk/qpid/java/broker/src/main/java/org/apache/qpid/qmf/QMFService.java 1182419 /trunk/qpid/specs/management-schema.xml 1182419 /trunk/qpid/tests/src/py/qpid_tests/broker_0_10/management.py 1182419 Diff: https://reviews.apache.org/r/2335/diff Testing ------- One unit test to verify the timestamp is being added. No dynamic control via mgmt yet. Simple perf testing didn't seem like the hit wasn't too bad so far: Pre patch, from trunk: [root@mrg44 tests] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 68428 68388 0.16 69.59 4.16 68238 68201 0.17 44.18 3.82 68622 68581 0.16 102.52 4.60 68688 68647 0.18 117.33 5.29 69142 69104 0.19 103.30 4.50 Patched, no timestamping: [root@mrg44 src] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 67543 67471 0.17 79.76 4.37 69069 69028 0.15 42.92 3.78 68481 68439 0.17 45.91 3.98 68674 68636 0.18 41.30 3.74 67588 67587 0.17 60.23 4.21 Patched, timestamping enabled: [root@mrg44 src] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 67228 67227 0.21 41.80 3.97 67697 67659 0.19 43.01 4.19 67405 67368 0.19 101.61 4.99 66515 66511 0.15 41.85 4.10 67664 67622 0.17 47.35 4.01 Thanks, Kenneth
          Hide
          jiraposter@reviews.apache.org added a comment -

          -----------------------------------------------------------
          This is an automatically generated e-mail. To reply, visit:
          https://reviews.apache.org/r/2335/#review2532
          -----------------------------------------------------------

          Ship it!

          • Gordon

          On 2011-10-12 16:15:37, Kenneth Giusti wrote:

          -----------------------------------------------------------

          This is an automatically generated e-mail. To reply, visit:

          https://reviews.apache.org/r/2335/

          -----------------------------------------------------------

          (Updated 2011-10-12 16:15:37)

          Review request for qpid, Gordon Sim and Ted Ross.

          Summary

          -------

          A slight deviation from the design originally proposed in QPID-3417 - this change adds the timestamp delivery property to messages using the relatively simple approach as described in AMQP-0.10.

          Other than the approach itself, the QMF management interface & schema changes seem like I could be guilty of overkill - I'd like feedback before I go too far down that hole...

          This addresses bug qpid-3417.

          https://issues.apache.org/jira/browse/qpid-3417

          Diffs

          -----

          /trunk/qpid/cpp/src/qpid/broker/Broker.h 1182419

          /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1182419

          /trunk/qpid/cpp/src/qpid/broker/Message.h 1182419

          /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1182419

          /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1182419

          /trunk/qpid/cpp/src/qpid/broker/SessionState.cpp 1182419

          /trunk/qpid/cpp/src/qpid/client/amqp0_10/IncomingMessages.cpp 1182419

          /trunk/qpid/cpp/src/qpid/management/ManagementAgent.cpp 1182419

          /trunk/qpid/cpp/src/tests/BrokerOptions.cpp PRE-CREATION

          /trunk/qpid/cpp/src/tests/Makefile.am 1182419

          /trunk/qpid/cpp/src/tests/QueueTest.cpp 1182419

          /trunk/qpid/cpp/src/tests/acl.py 1182419

          /trunk/qpid/java/broker/src/main/java/org/apache/qpid/qmf/QMFService.java 1182419

          /trunk/qpid/specs/management-schema.xml 1182419

          /trunk/qpid/tests/src/py/qpid_tests/broker_0_10/management.py 1182419

          Diff: https://reviews.apache.org/r/2335/diff

          Testing

          -------

          One unit test to verify the timestamp is being added. No dynamic control via mgmt yet.

          Simple perf testing didn't seem like the hit wasn't too bad so far:

          Pre patch, from trunk:

          [root@mrg44 tests]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000

          send-tp recv-tp l-min l-max l-avg

          68428 68388 0.16 69.59 4.16

          68238 68201 0.17 44.18 3.82

          68622 68581 0.16 102.52 4.60

          68688 68647 0.18 117.33 5.29

          69142 69104 0.19 103.30 4.50

          Patched, no timestamping:

          [root@mrg44 src]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000

          send-tp recv-tp l-min l-max l-avg

          67543 67471 0.17 79.76 4.37

          69069 69028 0.15 42.92 3.78

          68481 68439 0.17 45.91 3.98

          68674 68636 0.18 41.30 3.74

          67588 67587 0.17 60.23 4.21

          Patched, timestamping enabled:

          [root@mrg44 src]# qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000

          send-tp recv-tp l-min l-max l-avg

          67228 67227 0.21 41.80 3.97

          67697 67659 0.19 43.01 4.19

          67405 67368 0.19 101.61 4.99

          66515 66511 0.15 41.85 4.10

          67664 67622 0.17 47.35 4.01

          Thanks,

          Kenneth

          Show
          jiraposter@reviews.apache.org added a comment - ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2335/#review2532 ----------------------------------------------------------- Ship it! Gordon On 2011-10-12 16:15:37, Kenneth Giusti wrote: ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/2335/ ----------------------------------------------------------- (Updated 2011-10-12 16:15:37) Review request for qpid, Gordon Sim and Ted Ross. Summary ------- A slight deviation from the design originally proposed in QPID-3417 - this change adds the timestamp delivery property to messages using the relatively simple approach as described in AMQP-0.10. Other than the approach itself, the QMF management interface & schema changes seem like I could be guilty of overkill - I'd like feedback before I go too far down that hole... This addresses bug qpid-3417. https://issues.apache.org/jira/browse/qpid-3417 Diffs ----- /trunk/qpid/cpp/src/qpid/broker/Broker.h 1182419 /trunk/qpid/cpp/src/qpid/broker/Broker.cpp 1182419 /trunk/qpid/cpp/src/qpid/broker/Message.h 1182419 /trunk/qpid/cpp/src/qpid/broker/Message.cpp 1182419 /trunk/qpid/cpp/src/qpid/broker/SemanticState.cpp 1182419 /trunk/qpid/cpp/src/qpid/broker/SessionState.cpp 1182419 /trunk/qpid/cpp/src/qpid/client/amqp0_10/IncomingMessages.cpp 1182419 /trunk/qpid/cpp/src/qpid/management/ManagementAgent.cpp 1182419 /trunk/qpid/cpp/src/tests/BrokerOptions.cpp PRE-CREATION /trunk/qpid/cpp/src/tests/Makefile.am 1182419 /trunk/qpid/cpp/src/tests/QueueTest.cpp 1182419 /trunk/qpid/cpp/src/tests/acl.py 1182419 /trunk/qpid/java/broker/src/main/java/org/apache/qpid/qmf/QMFService.java 1182419 /trunk/qpid/specs/management-schema.xml 1182419 /trunk/qpid/tests/src/py/qpid_tests/broker_0_10/management.py 1182419 Diff: https://reviews.apache.org/r/2335/diff Testing ------- One unit test to verify the timestamp is being added. No dynamic control via mgmt yet. Simple perf testing didn't seem like the hit wasn't too bad so far: Pre patch, from trunk: [root@mrg44 tests] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 68428 68388 0.16 69.59 4.16 68238 68201 0.17 44.18 3.82 68622 68581 0.16 102.52 4.60 68688 68647 0.18 117.33 5.29 69142 69104 0.19 103.30 4.50 Patched, no timestamping: [root@mrg44 src] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 67543 67471 0.17 79.76 4.37 69069 69028 0.15 42.92 3.78 68481 68439 0.17 45.91 3.98 68674 68636 0.18 41.30 3.74 67588 67587 0.17 60.23 4.21 Patched, timestamping enabled: [root@mrg44 src] # qpid-cpp-benchmark --repeat=5 --summarize --messages=5000000 send-tp recv-tp l-min l-max l-avg 67228 67227 0.21 41.80 3.97 67697 67659 0.19 43.01 4.19 67405 67368 0.19 101.61 4.99 66515 66511 0.15 41.85 4.10 67664 67622 0.17 47.35 4.01 Thanks, Kenneth
          Ken Giusti made changes -
          Field Original Value New Value
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Ken Giusti added a comment -

          Documentation of the user interface for this feature.

          Show
          Ken Giusti added a comment - Documentation of the user interface for this feature.
          Ken Giusti made changes -
          Attachment timestamp.txt [ 12502831 ]
          Ken Giusti made changes -
          Link This issue relates to QPID-3626 [ QPID-3626 ]
          Justin Ross made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Ken Giusti
              Reporter:
              Ken Giusti
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development