Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 36597 invoked from network); 28 Oct 2003 18:31:15 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 28 Oct 2003 18:31:15 -0000 Received: (qmail 42685 invoked by uid 500); 28 Oct 2003 18:31:02 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 42637 invoked by uid 500); 28 Oct 2003 18:31:01 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 42624 invoked from network); 28 Oct 2003 18:31:01 -0000 Received: from unknown (HELO prv-mail20.provo.novell.com) (137.65.81.122) by daedalus.apache.org with SMTP; 28 Oct 2003 18:31:01 -0000 Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 28 Oct 2003 11:31:05 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Tue, 28 Oct 2003 11:30:48 -0700 From: "Jean-Jacques Clar" To: ,, Subject: Q?, BUG:[mod_mem_cache] size & object count Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartB4EA18C8.0__=" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 500/1000/N This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartB4EA18C8.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Looking at two pairs of fields used to keep the current cache size and object count: from struct: mem_cache_conf (mod_mem_cache.c): apr_size_t cache_size apr_size_t object_cnt cache_cache_t (cache_cache.c): apr_size_t current_size cache_pqueue_t (cache_pqueue.c): apr_size_t size (-1, element 0 does not count) The two pair of fields ((cache_size - current_size) & (object_cnt - size)) must be keep in sync in every case. Is that a true statement? There is at least one case, where it is not happening: cache_cache.c, cache_insert() ->ejecting one of the entity. c->current_size and the queue size are adjusted inside the while loop, but the cache_size and object_cnt fields are never adjusted down in mod_mem_cache.c. cache_size and object_cnt are not used inside any logic. My questions are: Should they be keep in sync (probably using memcache_cache_free())? Should they just be removed if they don't have any usage? This is a minor but annoying bug. Thank you, Jean-Jacques --=__PartB4EA18C8.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Looking at two pairs of fields used to keep the current cache size and object count:
from struct: 
mem_cache_conf (mod_mem_cache.c):
apr_size_t cache_size
apr_size_t object_cnt
 
cache_cache_t (cache_cache.c):
apr_size_t current_size
 
cache_pqueue_t (cache_pqueue.c):
apr_size_t size (-1, element 0 does not count)
 
The two pair of fields ((cache_size - current_size) & (object_cnt - size)) must be keep in sync in every case.
Is that a true statement?
 
There is at least one case, where it is not happening:
cache_cache.c, cache_insert() ->ejecting one of the entity.
c->current_size and the queue size are adjusted inside the while loop, but
the cache_size and object_cnt fields are never adjusted down in mod_mem_cache.c.
 
cache_size and object_cnt are not used inside any logic.
My questions are:
Should they be keep in sync (probably using memcache_cache_free())?
 
Should they just be removed if they don't have any usage?
 
This is a minor but annoying bug.
 
Thank you,
Jean-Jacques
--=__PartB4EA18C8.0__=--