qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Async Store milestones
Date Fri, 21 Sep 2012 13:57:58 GMT
On 09/21/2012 01:25 PM, Kim van der Riet wrote:
> On Thu, 2012-09-20 at 19:47 +0100, Gordon Sim wrote:
>> 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.

Given there is no actual benefit until the store(s) exploit(s) the extra 
asynchronicity, why would we want to get these changes in for 0.20 
rather than waiting until we branch though? Seems like we would be 
taking on extra risk for no benefit.

If the changes end up being low risk, are reviewed in plenty of time 
before the alpha and don't cause merging issues for any actual features 
(and I'm selfishly thinking AMQP 1.0 support here(!) as well as some of 
the HA work), then I would be less concerned of course.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message