On Aug 8, 2012, at 11:25 AM, Rajith Attapattu wrote: > +1 for (a). > +1 from me as well.
> Rajith > > On Tue, Aug 7, 2012 at 2:16 PM, Andy Goldstein > <[email protected]> wrote: >> My vote is for (a) >> >> Andy >> >> On Aug 7, 2012, at 2:11 PM, Gordon Sim wrote: >> >>> So, to follow up and summarise this thread so far, the only contentious >>> point has been the loss of the 'flow to disk' functionality. >>> >>> Though the current solution doesn't limit the memory used by a large queue, >>> it can in certain cases reduce the rate of memory growth which in turn may >>> buy a little more time to resolve the root cause. So while those using it >>> are less than fully satisfied, they are (understandably) concerned at >>> having even this limited solution taken away without having any clear plan >>> to offer a replacement. >>> >>> I have spent a little time thinking through what a better solution might >>> look like and how much effort it would take. I believe that for ~3-5 weeks >>> work I could get something better in place. It would be, in the first >>> instance, posix only[1]. It would be mutually exclusive with lvq or >>> priority queue options. However it would be a more effective limit on the >>> memory consumed as such a queue grew, and (I hope) would have a less >>> drastic performance penalty at larger sizes. >>> >>> There are a few options for how to proceed, and I'd like to take a quick >>> straw poll to see which path the community favours. >>> >>> (a) go ahead with the refactor, including the removal of features mentioned >>> in the previous mail, subsequently focus first on AMQP 1.0 support, only >>> then return to add paged queue support >>> >>> (b) go ahead with the refactor, including the removal of features mentioned >>> in the previous mail, subsequently focus first on paged queue support, then >>> proceed to add AMQP 1.0 support >>> >>> (c) don't go ahead with the refactor until it can be combined with an >>> alternative to flow to disk, and only then proceed with AMQP 1.0 support >>> >>> (d) don't go ahead with the refactor at all >>> >>> I myself favour (a). I think AMQP 1.0 support is more important and more >>> work and would like to make more progress on that as soon as possible in >>> order to have something ready for the 0.20 release. I can't guarantee that >>> this path would result in the 0.20 release having the replacement for flow >>> to disk functionality, but if not it would come soon after. >>> >>> I'm not so keen on (c) because maintain such a large patch against a >>> continually moving trunk is a lot of work in itself and I think that time >>> can be better spent. I'm not keen on (d) because I honestly don't think I >>> can add decent 1.0 support (or fix a number of known issues) without >>> something like this refactor. >>> >>> Anyway, over to you. Let me know what you think, I'm keen we reach some >>> agreement by the end of the week. In the meantime I'll try and make my >>> proposal for the flow to disk replacement a bit more concrete. >>> >>> --Gordon. >>> >>> [1] It will be designed such that it is relatively simple to provide >>> alternative implementations for the posix functionality such that anyone >>> with interest can easily add windows support for example. From what I can >>> tell, it doesn't look like flow to disk is supported on windows at present >>> anyway. I could be wrong. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
