> On 2012-03-09 18:38:19, Gordon Sim wrote: > > In my view this is good enough to get started with. We may have some > > changes along the way based on findings from implementing above or below > > the line. I'm still unsure as to whether its worth accommodating the > > multi-enqueue message for example, but that can be revisted. > > Kim van der Riet wrote: > Agreed. We also need to think through how events will be recovered. > Enqueued messages are logically dequeued, on recovery only the remaining > enqueued records are recovered and passed back to the broker. However, as > events have no logical destroy mechanism, they will _all_ have to be recoverd > and returned to the broker (or a queue in the broker), and that could amount > to a lot of pushing of obsolete status records. > > Perhaps the right idea is to introduce some sort of optional key, and > when this is supplied to a submitRecord() (previously submitStoreEvent()), it > behaves logically like an LVQ, it logically replaces any previous record > using the same key. The store would have to be aware of the key to be able to > analyze and eliminate the older records on recovery though.
Yes, the whole events thing needs a bit more thought. Even more of a concern is the fact that if event records aren't invalidated, you will either run out of journal space or have to lose the records. Your key idea is plausible, but we need to also consider what the use cases might actually be so we don't design something that isn't as useful as it could be. The two cases I have in mind would be (a) more precise tracking of delivery state for a message and (b) tracking durable consumers 'positions' in a queue. - Gordon ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4243/#review5792 ----------------------------------------------------------- On 2012-03-09 18:33:10, Kim van der Riet wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/4243/ > ----------------------------------------------------------- > > (Updated 2012-03-09 18:33:10) > > > Review request for qpid, Andrew Stitcher, Alan Conway, Gordon Sim, Ted Ross, > and Steve Huston. > > > Summary > ------- > > The async store interface is intended to replace the current syncronous store > interface in broker/MessageStore.h. It presents a bidirectional async > interface, allowing async store operations which contain optional callbacks > to be queued up for processing by the store, and for the results of these > operations (if the callback is present in the operation) to be queued up for > action by the broker itself. > > After a good deal of back-and-forth on the list, this is the latest iteration > on the async store interface. Thanks to Andrew and Gordon who have provided > much valuable feedback. > > If this interface is accepted, it will need to be implemented in two phases: > > 1. Broker wiring - the broker will need to be hooked into this interface > using async semantics. This could be a disrptive phase, as it would likely > break or disconnect the current sync interface. An async-sync adaptor would > also be developed to allow current syncronous stores to continue operating > under the new interface. > > 2. Async store development - the current async store is not currently part of > the Qpid codebase as it was developed under an incompatible license (LGPL2). > A new async store would be developed under Apache, with any bits moved from > the old code base dual-licenced to Apache. (This will require some legal > checkups.) > > Comments welcome. > > Coordinating JIRA: https://issues.apache.org/jira/browse/QPID-3858 > > > Diffs > ----- > > branches/asyncstore/cpp/src/CMakeLists.txt 1291264 > branches/asyncstore/cpp/src/Makefile.am 1291264 > branches/asyncstore/cpp/src/qpid/broker/AsyncStore.h PRE-CREATION > branches/asyncstore/cpp/src/qpid/broker/AsyncStore.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/4243/diff > > > Testing > ------- > > Compiles as written, but is not implemented. > > > Thanks, > > Kim > >
