Return-Path: Delivered-To: apmail-qpid-users-archive@www.apache.org Received: (qmail 31459 invoked from network); 12 Jan 2011 17:35:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 12 Jan 2011 17:35:59 -0000 Received: (qmail 66988 invoked by uid 500); 12 Jan 2011 17:35:59 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 66711 invoked by uid 500); 12 Jan 2011 17:35:56 -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 66703 invoked by uid 99); 12 Jan 2011 17:35:55 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jan 2011 17:35:55 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=10.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of gsim@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, 12 Jan 2011 17:35:49 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0CHZRgt010422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 12 Jan 2011 12:35:28 -0500 Received: from [10.3.234.23] (vpn-234-23.phx2.redhat.com [10.3.234.23]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p0CHZQru004179 for ; Wed, 12 Jan 2011 12:35:27 -0500 Message-ID: <4D2DE5F5.6070309@redhat.com> Date: Wed, 12 Jan 2011 17:33:41 +0000 From: Gordon Sim Organization: Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.,Registered in England and Wales under Company Registration No. 3798903,Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc11 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: users@qpid.apache.org Subject: Re: Journal with LVQ References: <1294763431.2999.12.camel@helios.office.paradigmaxis.pt> In-Reply-To: <1294763431.2999.12.camel@helios.office.paradigmaxis.pt> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 On 01/11/2011 04:30 PM, Bruno Matos wrote: > I'm publishing messages to a durable LVQ, when I run the publisher for > the first time the journal stays almost full, then I send the exact same > messages, expecting the old ones to be replaced, but after some time the > connection is closed with "Enqueue capacity threshold exceeded on > queue". With qpid-tool I can see that msgDepth and byteDepth are exactly > the same before and after the second run. Is this the expected behavior? Depends on what you mean by 'expected' :-) It is certainly the case that the linux journal will reach capacity with different queue depths, depending on exact sequences of changes. i.e. the capacity is not simply a function of the final state, but also of the path to get there. In the second case there would be additional dequeue records and the file boundaries might not align the same way etc, so the journal space can be used up for fewer enqueued messages. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:users-subscribe@qpid.apache.org