On Thu, 2012-09-20 at 19:47 +0100, Gordon Sim wrote: > On 09/20/2012 07:36 PM, Kim van der Riet wrote: > > Broad goal: Using new asyncStore interface, wire up the old store using > > a thin async/sync adapter. This work is being done broadly under > > QPID-3858 "Develop asyncronous store interface for > > qpid" (https://issues.apache.org/jira/browse/QPID-385) and is checked in > > on the asyncstore branch at present. > > > > Milestones: > > 1. Remove all current wiring in the broker to the old sync store > > interface, and replace with the equivalent async functionality. This > > will likely require some restructuring of the broker's logic to handle > > the asynchronous returns to various store functions. This task can be > > broken into the following: > > > > a. Removing old sync interface and references (done) > > b. Replacing refs & pointers to store (done) > > c. Attaching initialization and recovery to new interface. (in progress, > > 5 days Sep. 21) > > d. Replacing old queue, exchange and other broker-specific configuration > > storage (in BDB) with new async configuration interface (5 days Sep. > > 28) > > d. Attaching enqueue and dequeue ops to new interface (2 days Oct. 2) > > e. Handling local transactions through new interface (5 days Oct. 9) > > f. Handling dtx transactions through new interface (2 days Oct. 11) > > > > This will then have the broker wired to the interface and through to a > > null async store (as each async op will simply return a success code). > > > > 2. Create a thin async/sync interface layer which will take each async > > operation and push it into the old store interface. (10 days Oct. 25) > > NOTE: This will also require that the current Windows store is also > > connected via this this interface layer. > > > > 3. Test the new implementation. (2 months!!) > > Am I correct in my belief that there would be no benefit realised from > this work until at least one store implementation actually supports the > extra asynchronicity the new interface enables?
Correct. There is already the start of such a store (which will be an optimized and restructured version of the existing libaio-based store), but this will be a further block of work which can be completed for a later release. This newer store will also be designed to allow scalability of transactions, a limitation of the current synchronous implementation (although not specifically related to the fact that the interface in synchronous). > > Given that fact, the potential impact and the date of completion (a week > after alpha) am I right in assuming this is targeted for merging to > trunk *after* we branch for 0.20? It is possible that with the help of Chuck, we can run some of this work in parallel. These timelines do not reflect this possibility, and I still need to coordinate with Chuck on this line of work. I am hoping he will be able to start work on part 2 above (the async/sync shim), and his knowledge of the Windows implementation will allow him to also address the Windows store which will also need to be wired this way. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
