qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: Straw Poll: proposal to remove certain features from qpidd
Date Thu, 09 Aug 2012 17:55:20 GMT
I really like the refactor, and would rather see it sooner than later, so I'm good with (a)!
-K

----- Original Message -----
> 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