Mailing-List: contact jcs-users-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JCS Users List" <jcs-users@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C76F7B.42F65D80"
Subject: RE: get method return null for existing key
Date: Mon, 26 Mar 2007 02:49:18 -0500
Message-ID: 
 <142CBE7E2572C54FB3577C534BC09DB710F23C8F@hou-ex-04.adprod.bmc.com>
Thread-Topic: RE: get method return null for existing key
Thread-Index: Acdve0Ij7ejJZ7pYSRS2EqbKSgM2jA==
From: "Gierski, Christophe" <Christophe_Gierski@bmc.com>
To: <jcs-users@jakarta.apache.org>

------_=_NextPart_001_01C76F7B.42F65D80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,=20

=20

Thanks for the answer.

=20

I have lookup the code and it seems that the purgatory is back ended by
a LRUMapJCS when a purgatory size is grather than 0 and by a simple
HashMap where the purgatory size is less than 0.

=20

The issue is that the purgatory could age out items without writing them
to the disk as the method processRemovedLRU() to process the object
removal do just a log work :

=20

    protected void processRemovedLRU( Object key, Object value )

    {

        if ( log.isDebugEnabled() )

        {

            log.debug( "Removing key [" + key + "] from key store, value
[" + value + "]" );

            log.debug( "Key store size [" + this.size() + "]" );

        }

    }

=20

=20

My configuration says that elements need to be eternal, so do the
purgatory is allowed to remove elements without respecting the contract
of eternal ?

Is it a bug or a misunderstood feature of the purgatory ?

=20

Regards,=20

--Christophe.

=20


------_=_NextPart_001_01C76F7B.42F65D80--