Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of rajith77@gmail.com designates
 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <95DC9AF1-1D32-40BF-ADFF-41169096CA70@redhat.com>
References: <50084A59.8090702@redhat.com>
	<50215A68.6040407@redhat.com>
	<95DC9AF1-1D32-40BF-ADFF-41169096CA70@redhat.com>
Date: Wed, 8 Aug 2012 11:25:00 -0400
Message-ID: 
 <CA+M2Xzs30wYupgm3ypf6cRBOMje1o4AYF2y+3p8NXXq=4gy0TQ@mail.gmail.com>
Subject: Re: Straw Poll: proposal to remove certain features from qpidd
From: Rajith Attapattu <rajith77@gmail.com>
To: users@qpid.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+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 que=
ue, 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 ha=
ving 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 inst=
ance, posix only[1]. It would be mutually exclusive with lvq or priority qu=
eue options. However it would be a more effective limit on the memory consu=
med as such a queue grew, and (I hope) would have a less drastic performanc=
e 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 mentio=
ned in the previous mail, subsequently focus first on AMQP 1.0 support, onl=
y then return to add paged queue support
>>
>> (b) go ahead with the refactor, including the removal of features mentio=
ned 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 al=
ternative 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 o=
rder to have something ready for the 0.20 release. I can't guarantee that t=
his path would result in the 0.20 release having the replacement for flow t=
o 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 con=
tinually 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 a=
dd decent 1.0 support (or fix a number of known issues) without something l=
ike 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 prop=
osal for the flow to disk replacement a bit more concrete.
>>
>> --Gordon.
>>
>> [1] It will be designed such that it is relatively simple to provide alt=
ernative 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