[Design the new POJO MicroContainer] - Re: JBMICROCONT-330 - Preconfigured MDR and scopes (Repost)
by adrian@jboss.org
"alesj" wrote : This move
| - protected MetaDataContext createMetaDataContext(List retrievals)
| made the following classes:
| - CachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
| - PolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
| - LRUPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
| - TimedPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
| useless, since they don't serve the caching override function anymore.
|
You should add @Override so it doesn't compile if somebody refactors
the callback.
Why didn't I see any failing tests? I must be blind?
anonymous wrote :
| What's the best way to port this?
| Overriding this in some ControllerContext impl doesn't seem like a good fit.
I don't think there is a one best way. The simplest would be to allow
a setMetaDataContextFactory() on the ScopeInfo, it could be set
by the BasicKernelMDR if you want.
If you wanted to be "clever", you could make it a piece of metadata itself. :-)
i.e. which MetaDataContextFactory to use by looking through the retrievals
before you construct it. That would allow application and system wide construction,
but how it gets populated is a different question.
NOTE: The deployers also do this, see DefaultScopeBuilder,
although there you can override it by adding a ScopeBuilder attachment
to your deployment.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169648#4169648
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169648
17 years, 8 months
[Design of JBossCache] - Re: Eviction redesign
by manik.surtani@jboss.com
Okay, so here is what I propose (and yes, it will break existing custom eviction policies and cfgs).
Just to sum things up first, there are 4 tasks involved in the eviction system:
1. Identify and record node activity (performed by the EvictionInterceptor, recorded on the Region)
2. Triggering processing of eviction queue (performed either by the EvictionTimerTask, or manually by calling Region.getEvictionPolicy().getEvictionAlgorithm().process())
3. Identifying which nodes are to be evicted: EvictionAlgorithm.process()
4. Evicting the node: EvictionPolicy.evict();
2 triggers 3 which triggers 4, so logically only 2 need be exposed to users via an API.
E.g., Region should just have 3 eviction-related methods on its public interface:
| Region.processEvictionQueue();
| Region.resetEvictionQueue();
| Region.putNodeEvent(); // used by the EvictionInterceptor
|
EvictionPolicy and EvictionAlgorithm are never exposed to client code.
Configuration
There have been requests for greater flexibility here, and I think there are 4 aspects to configuring eviction, which should be independent of one another:
* Region - region that the cfg applies to
* EvictionAlgorithm - how are nodes selected for eviction
* EvictionAlgorithmConfiguration - cfg details for an EvictionAlgorithm, such as maxNodes, etc.
* EvictionPolicy - what happens when nodes are evicted
* ancillary aspects to the eviction region such as queue size
The above will allow people to configure a LFUAlgorithm with, for example, SimpleEvictPolicy that just does a cache.evict(). Or, an LFUAlgorithm could be coupled with a RemoveOnEvictPolicy, which as the name suggests, does a remove.
Basically I see the following exposed on each of the interfaces:
| EvictionPolicy.evict(Fqn f); // this is what happens when a node is evicted.
|
| EvictionAlgorithm.process(Queue eventQueue, EvictionPolicy policy); // processes a region. Decides what to evict, sets up internal queues, and then calls policy.evict();
|
Region.processEvictionQueue() would:
| algorithm.process(eventQueue, policy);
|
I also propose that we change the XML configuration to be more consisent with what w are doing with cache loaders, to look like:
| <eviction wakeupInterval="5000">
| <region name="/org/mydata" policyClass="o.j.c.e.SimpleEvictPolicy" algorithmClass="o.j.c.e.LFUAlgorithm" eventQueueSize="100000">
| <properties>
| maxNodes=10
| timeToLive=300
| </properties>
| </region>
| </eviction>
|
What do people think? The benefit is a much cleaner and easier-to-understand set of interfaces and extension points.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169644#4169644
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169644
17 years, 8 months
[Design the new POJO MicroContainer] - Re: JBMICROCONT-330 - Preconfigured MDR and scopes
by alesj
This move
| projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/plugins/metadata/basic/BasicKernelMetaDataRepository.java
| ===================================================================
| --- projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/plugins/metadata/basic/BasicKernelMetaDataRepository.java 2008-08-08 14:37:38 UTC (rev 76832)
| +++ projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/plugins/metadata/basic/BasicKernelMetaDataRepository.java 2008-08-08 15:11:04 UTC (rev 76833)
| @@ -21,20 +21,13 @@
| */
| ...
|
| -
| - /**
| - * Create metadata context.
| - *
| - * @param retrievals the retrievals
| - * @return new metadata context instance
| - */
| - protected MetaDataContext createMetaDataContext(List<MetaDataRetrieval> retrievals)
| - {
| - return new AbstractMetaDataContext(null, retrievals);
| - }
| }
|
made the following classes:
- CachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
- PolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
- LRUPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
- TimedPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
useless, since they don't serve the caching override function anymore.
What's the best way to port this?
Overriding this in some ControllerContext impl doesn't seem like a good fit.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169635#4169635
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169635
17 years, 8 months