qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Goldstein <andy.goldst...@redhat.com>
Subject Re: Straw Poll: proposal to remove certain features from qpidd
Date Tue, 07 Aug 2012 18:16:11 GMT
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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 


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


Mime
View raw message