qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Jackson <gary.jack...@ijetonboard.com>
Subject RE: Straw Poll: proposal to remove certain features from qpidd
Date Tue, 07 Aug 2012 21:42:06 GMT
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

Mime
View raw message