+1 for (a) On Tue, 2012-08-07 at 19:11 +0100, 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]
