You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Ellis Pritchard (JIRA)" <ji...@apache.org> on 2007/12/03 17:54:43 UTC

[jira] Commented: (COCOON-2151) Sub-optimal implementation of AbstractDoubleMapEventRegistry

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

Ellis Pritchard commented on COCOON-2151:
-----------------------------------------

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 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.