cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ellis Pritchard (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (COCOON-2151) Sub-optimal implementation of AbstractDoubleMapEventRegistry
Date Tue, 04 Dec 2007 13:40:43 GMT

    [ https://issues.apache.org/jira/browse/COCOON-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547898
] 

ellispritchard edited comment on COCOON-2151 at 12/4/07 5:40 AM:
------------------------------------------------------------------

An update.

I've now got a version running locally which uses MultiValueMap (once again) with a Factory
to make the Collection class held in the map a HashSet rather than an ArrayList.

This solves the issue raised by Ard, with the perpetually growing ArrayList used by MultiHashMap
and default instances of MultiValueMap.

I've also solved the serialization issue with this class, once I realized that MultiValueMap
is actually only a decorator for any other Map, so I've reimplemented  AbstractDoubleMapEventRegistry/EventRegistryDataWrapper
to take care of the serialization of the underlying Maps, rather than the unserializable MultiValueMap
itself (hmm, should I un-vote for that Commons issue?).

The remaining issue, that of entries not being removed if the underlying cache implementation
decides to expire them, is already mitigated by the EventAwareCacheImpl#veryifyEventCache
(sic) method being called on #initialize(), which at least means that on restart only current
entries will be present, however,  I propose calling this method periodically via a thread.

However, as part of this, I also want to change the EHDefaultStore#containsKey(Object) method,
which is currently just calling Cache#get(), which messes with the TTLs/Eviction Policy in
the Cache; it should really call Cache#isKeyInCache(Object) which is cheaper and doesn't affect
the TTLs/Eviction Policy. The only reference to the Store#containsKey(Object) method I can
find is AbstractCachingProcessingPipeline, where it is used to check for the pipeline lock
object, but in the Default Transient Store, so doesn't use the EHDefaultStore implementation
anyway. 

I've also noticed a couple of potential thread-safety problems in AbstractDoubleMapEventRegistry,
which I've also taken care of.

Once I've fully tested this to my satisfaction, I'll submit a final patch for 2.1.x and 2.2
and close the other issues. We should then have a fully functional and safe EventAware cache
implementation.


      was (Author: ellispritchard):
    An update.

I've now got a version running locally which uses MultiValueMap (once again) with a Factory
to make the Collection class held in the map a HashSet rather than an ArrayList.

This solves the issue raised by Ard, with the perpetually growing ArrayList used by MultiHashMap
and default instances of MultiValueMap.

I've also solved the serialization issue with this class, once I realized that MultiValueMap
is actually only a decorator for any other Map, so I've reimplemented  AbstractDoubleMapEventRegistry/EventRegistryDataWrapper
to take care of the serialization of the underlying Maps, rather than the unserializable MultiValueMap
itself (hmm, should I un-vote for that Commons issue?).

The remaining issue, that of entries not being removed if the underlying cache implementation
decides to expire them, is already mitigated by the EventAwareCacheImpl#veryifyEventCache
(sic) method being called on #initialize(), which at least means that on restart only current
entries will be present, however,  I propose calling this method periodically via a thread.

However, as part of this, I also want to change the EHDefaultStore#containsKey(Object) method,
which is currently just calling Cache#get(), which messes with the TTLs/Eviction Policy in
the Cache; it should really call Cache#isKeyInCache(Object) which is cheaper and doesn't affect
the TTLs/Eviction Policy. The only user of the EHDefaultStore#containsKey(Object) method I
can find is AbstractCachingProcessingPipeline, where it is used to check for the pipeline
lock object, but in the Default Transient Store, so doesn't use the EHDefaultStore implementation
anyway. 

I've also noticed a couple of potential thread-safety problems in AbstractDoubleMapEventRegistry,
which I've also taken care of.

Once I've fully tested this to my satisfaction, I'll submit a final patch for 2.1.x and 2.2
and close the other issues. We should then have a fully functional and safe EventAware cache
implementation.

  
> Sub-optimal implementation of AbstractDoubleMapEventRegistry
> ------------------------------------------------------------
>
>                 Key: COCOON-2151
>                 URL: https://issues.apache.org/jira/browse/COCOON-2151
>             Project: Cocoon
>          Issue Type: Improvement
>          Components: Blocks: Event Cache
>    Affects Versions: 2.1.10, 2.2-dev (Current SVN)
>            Reporter: Jörg Heinicke
>
> This is just a follow-up from COCOON-2146 where Ard pointed out some issues with AbstractDoubleMapEventRegistry.
I just didn't want to lose the information when I actually fixed the issue. So I will add
it here.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message