From users-return-6703-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Wed Aug 8 17:34:23 2012 Return-Path: X-Original-To: apmail-qpid-users-archive@www.apache.org Delivered-To: apmail-qpid-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 635EA9C73 for ; Wed, 8 Aug 2012 17:34:23 +0000 (UTC) Received: (qmail 95799 invoked by uid 500); 8 Aug 2012 17:34:23 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 95770 invoked by uid 500); 8 Aug 2012 17:34:23 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 95762 invoked by uid 99); 8 Aug 2012 17:34:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Aug 2012 17:34:23 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rafaels@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Aug 2012 17:34:16 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q78HXslM011880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 8 Aug 2012 13:33:55 -0400 Received: from [10.11.9.197] (vpn-9-197.rdu.redhat.com [10.11.9.197]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q78HXrSb010113 for ; Wed, 8 Aug 2012 13:33:53 -0400 Message-ID: <1344447233.11629.607.camel@venture> Subject: Re: Straw Poll: proposal to remove certain features from qpidd From: Rafael Schloming Reply-To: rafaels@redhat.com To: users@qpid.apache.org Date: Wed, 08 Aug 2012 13:33:53 -0400 In-Reply-To: <50215A68.6040407@redhat.com> References: <50084A59.8090702@redhat.com> <50215A68.6040407@redhat.com> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Virus-Checked: Checked by ClamAV on apache.org +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