[
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/3/07 8:55 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 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.
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 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.
