qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: Straw Poll: proposal to remove certain features from qpidd
Date Wed, 08 Aug 2012 15:25:00 GMT
+1 for (a).

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


Mime
View raw message