You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2012/08/07 20:11:52 UTC
Straw Poll: proposal to remove certain features from qpidd
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
RE: Straw Poll: proposal to remove certain features from qpidd
Posted by Gary Jackson <ga...@ijetonboard.com>.
Our team concurs: +1 for (a)
-----Original Message-----
From: Alan Conway [mailto:aconway@redhat.com]
Sent: Tuesday, August 07, 2012 2:36 PM
To: users@qpid.apache.org
Subject: Re: Straw Poll: proposal to remove certain features from qpidd
+1 for (a)
On Tue, 2012-08-07 at 19:11 +0100, 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
This message and its attachments are the property of iJet Technologies, Inc. and are intended solely for the use of the designated recipient(s) and their appointed delegates. This email may contain information that is confidential. If you are not the intended recipient, you are prohibited from printing, copying, forwarding or saving any portion of the message or attachments. Please delete the message and attachments and notify the sender immediately. Thank you for your cooperation.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Straw Poll: proposal to remove certain features from qpidd
Posted by Alan Conway <ac...@redhat.com>.
+1 for (a)
On Tue, 2012-08-07 at 19:11 +0100, 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
Re: Straw Poll: proposal to remove certain features from qpidd
Posted by Cliff Jansen <cl...@gmail.com>.
+1 for (a)
On Tue, Aug 7, 2012 at 11:11 AM, Gordon Sim <gs...@redhat.com> 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
Re: Straw Poll: proposal to remove certain features from qpidd
Posted by "Weston M. Price" <wp...@redhat.com>.
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
> <an...@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
Re: Straw Poll: proposal to remove certain features from qpidd
Posted by Rajith Attapattu <ra...@gmail.com>.
+1 for (a).
Rajith
On Tue, Aug 7, 2012 at 2:16 PM, Andy Goldstein
<an...@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
Re: Straw Poll: proposal to remove certain features from qpidd
Posted by Andy Goldstein <an...@redhat.com>.
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
Re: Straw Poll: proposal to remove certain features from qpidd
Posted by Rafael Schloming <ra...@redhat.com>.
+1 for (a)
On Tue, 2012-08-07 at 19:11 +0100, 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
Re: Last chance! (was Re: Straw Poll: proposal to remove certain
features from qpidd)
Posted by Gordon Sim <gs...@redhat.com>.
On 08/09/2012 06:52 PM, Gordon Sim wrote:
> Thanks to everyone who has voiced an opinion so far. My plan is to start
> getting the patch on to trunk tomorrow.
This has now been done. I've had one report of some intermittent issues
with ha, there may other issues that the tests didn't pick up. If you
come across something let me know or raise a bug (though Jira is a
little unwell at present it seems).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Last chance! (was Re: Straw Poll: proposal to remove certain features
from qpidd)
Posted by Gordon Sim <gs...@redhat.com>.
Thanks to everyone who has voiced an opinion so far. My plan is to start
getting the patch on to trunk tomorrow. If anyone is not happy with
option (a), has other concerns or simply needs more time, make yourself
heard!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Straw Poll: proposal to remove certain features from qpidd
Posted by Robbie Gemmell <ro...@gmail.com>.
+1 for (a)
On 7 August 2012 19:11, Gordon Sim <gs...@redhat.com> 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<us...@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: Straw Poll: proposal to remove certain features from qpidd
Posted by Chuck Rolke <cr...@redhat.com>.
+1 for (a)
----- Original Message -----
> From: "Gordon Sim" <gs...@redhat.com>
> To: users@qpid.apache.org
> Sent: Tuesday, August 7, 2012 2:11:52 PM
> Subject: Straw Poll: proposal to remove certain features from qpidd
>
> 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
Re: Straw Poll: proposal to remove certain features from qpidd
Posted by Ken Giusti <kg...@redhat.com>.
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