----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19566/ -----------------------------------------------------------
(Updated March 27, 2014, 8:58 a.m.) Review request for qpid, Gordon Sim and Kim van der Riet. Changes ------- Trivial fix that adds - in parallel to qpid.msg_sequence - also qpid.boot_sequence message annotation. End user then should lexicographically compare the pair of values (qpid.boot_sequence, qpid.msg_sequence). Then message headers look like: Properties: {qpid.boot_sequence:16, qpid.msg_sequence:2, sn:1, ts:1395909295605937918, x-amqp-0-10.routing-key:} Properties: {qpid.boot_sequence:16, qpid.msg_sequence:3, sn:2, ts:1395909295606126626, x-amqp-0-10.routing-key:} Properties: {qpid.boot_sequence:16, qpid.msg_sequence:4, sn:3, ts:1395909295606179836, x-amqp-0-10.routing-key:} (broker restart) Properties: {qpid.boot_sequence:17, qpid.msg_sequence:1, sn:4, ts:1395909314496162977, x-amqp-0-10.routing-key:} Properties: {qpid.boot_sequence:17, qpid.msg_sequence:2, sn:5, ts:1395909314496364823, x-amqp-0-10.routing-key:} Properties: {qpid.boot_sequence:17, qpid.msg_sequence:3, sn:6, ts:1395909314496437384, x-amqp-0-10.routing-key:} An optional fix that sets just qpid.msg_sequence as string "boot_sequence:exchange_sequence". End user then has to parse the string but gets the sequence stuff in just one annotation : Index: cpp/src/qpid/broker/Exchange.cpp =================================================================== --- cpp/src/qpid/broker/Exchange.cpp (revision 1582207) +++ cpp/src/qpid/broker/Exchange.cpp (working copy) @@ -63,7 +63,9 @@ if (parent->sequence){ parent->sequenceNo++; - msg.getMessage().addAnnotation(qpidMsgSequence,parent->sequenceNo); + char s[129]; + sprintf(s, "%d:%ld", parent->getBroker()->getManagementAgent()->getBootSequence(), parent->sequenceNo); + msg.getMessage().addAnnotation(qpidMsgSequence,s); } if (parent->ive) { parent->lastMsg = msg.getMessage(); Then message headers look like: Properties: {qpid.msg_sequence:18:1, sn:1, ts:1395910232986094505, x-amqp-0-10.routing-key:} Properties: {qpid.msg_sequence:18:2, sn:2, ts:1395910232986239616, x-amqp-0-10.routing-key:} Properties: {qpid.msg_sequence:18:3, sn:3, ts:1395910232986274364, x-amqp-0-10.routing-key:} (broker restart) Properties: {qpid.msg_sequence:19:1, sn:4, ts:1395910238014147248, x-amqp-0-10.routing-key:} Properties: {qpid.msg_sequence:19:2, sn:5, ts:1395910238014284816, x-amqp-0-10.routing-key:} Properties: {qpid.msg_sequence:19:3, sn:6, ts:1395910238014317980, x-amqp-0-10.routing-key:} I am in favour of the first option, let me know your preference. Bugs: QPID-5642 https://issues.apache.org/jira/browse/QPID-5642 Repository: qpid Description ------- Elegant (but not performance optimal) way of patch: 1) In Exchange::PreRoute::PreRoute, update exchange in store (whole entry). 2) The update method is dealed very similarly like MessageStoreImpl::create(db_ptr db, IdSequence& seq, const qpid::broker::Persistable& p) method, i.e. calls BufferValue that calls Exchange::encode. Here the code can be unified by merging MessageStoreImpl::update intoMessageStoreImpl::create method where the code almost duplicates. However I do not see the patch as performance efficient, as with every message preroute, new qpid::framing::Buffer is filled in Exchange::encode method, data are copied from it to char* BufferValue::data and even then they are really written to the BDB. While in fact we just update the only one number in the Buffer. I tried to come up with less performance invasive approach (for those interested, see https://bugzilla.redhat.com/attachment.cgi?id=877576&action=diff - if you dont have access there, let me write), that keeps qpid::framing::Buffer for every durable exchange with sequencing enabled, but it returned (among others) into the need of changing the way store encodes/decodes Exchange instance (change in Exchange::encode / decode methods). What would make the broker backward incompatible. Is the performance penalty (due to Exchange::encode method called for every message preroute) acceptable? Is it worth merging MessageStoreImpl::update intoMessageStoreImpl::create method? Diffs (updated) ----- /trunk/qpid/cpp/src/qpid/broker/Exchange.cpp 1582207 Diff: https://reviews.apache.org/r/19566/diff/ Testing ------- - reproducer from JIRA verified - automated tests passed (except for those known to fail due to QPID-5641 (valgrind & legacystore) Thanks, Pavel Moravec