qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weston M. Price" <wpr...@redhat.com>
Subject Re: Straw Poll: proposal to remove certain features from qpidd
Date Wed, 08 Aug 2012 15:26:28 GMT

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
> <andy.goldstein@redhat.com> 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: 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
>> 
> 
> ---------------------------------------------------------------------
> 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