[Design of JBossCache] - Re: Redesigning eviction
by galder.zamarreno@jboss.com
When is an eviction needed? When we're running out of memory. If memory was infinite, we wouldn't need evictions.
An eviction is needed, what do we kick out? the node occupying the most? the node used less frequently?...etc
I guess it depends on how the two different aspects highlighted by nnnn are gonna evolve, but the use cases could multiply in the future.
The only downside to separating the two would be that users would have to think through the two, but they already have to do to some extent. It's certainly not easy to find out what storing 100 nodes of Class X is gonna take up memory wise. And then, they have to think which one they should be removing.
Something worth noting even if it's no strictly linked to evictions. We're trying to evict nodes because we have a finite memory, but what if Cache was able to reshuffle itself to make access to nodes that are more regularly used faster? i.e. there's no need to go down the tree n times (/a/b/c/d/e/f/g/h/i/j/k...../myinstance). Evictions are driven by memory requirements, and Reshuffles would be driven by performance, but both could benefit from the same statistics gathered?
Also, a result of an eviction process could be moving it to a node which has more free space that us, rather than passivating it to a db. For example, this could be done if we're able to determine that bringing the node from another cache instance would be faster than having to go to the db.
The bottom line is, data gathered from node usage, currently only used by evictions, could server for more purposes. What to do when a node needs to be evicted could also vary, and this is on top of what nnnn suggested, which is when an eviction is needed and who needs to go. We're only scratching the surface here...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065598#4065598
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065598
18 years, 8 months
[Design of AOP on JBoss (Aspects/JBoss)] - ProfileService aspects are no longer being applied
by scott.stark@jboss.org
As I'm looking at the ProfileServiceUnitTestCase failures in more detail I see that none of the aspects registered in the bootstrap-repo-beans.xml AspectManager config are being applied to the deployers.
| <bean name="AspectManager" class="org.jboss.aop.deployers.AspectManagerJDK5">
| <constructor>
| <parameter><![CDATA[
| <aop>
| <aspect name="deployers" class="org.jboss.profileservice.aop.DeployerAspects"/>
| <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.deployer.Deployer}->prepareDeploy(..))">
| <advice name="invoke" aspect="deployers"/>
| </bind>
| <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.deployer.Deployer}->prepareUndeploy(..))">
| <advice name="invoke" aspect="deployers"/>
| </bind>
| <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.deployer.Deployer}->commitDeploy(..))">
| <advice name="invoke" aspect="deployers"/>
| </bind>
| <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.deployer.Deployer}->commitUndeploy(..))">
| <advice name="invoke" aspect="deployers"/>
| </bind>
|
| <aspect name="attachments" class="org.jboss.profileservice.aop.TrackingAdvice"/>
| <bind pointcut="execution(* $instanceof{org.jboss.deployers.spi.attachments.Attachments}->addAttachment(..))">
| <advice name="addAttachment" aspect="attachments"/>
| </bind>
| </aop>]]>
| </parameter>
| </constructor>
| <property name="enableLoadtimeWeaving">false</property>
| <!-- only relevant when EnableLoadtimeWeaving is true.
| When transformer is on, every loaded class gets
| transformed. If AOP can't find the class, then it
| throws an exception. Sometimes, classes may not have
| all the classes they reference. So, the Suppressing
| is needed. (i.e. Jboss cache in the default configuration -->
| <property name="suppressTransformationErrors">true</property>
| <property name="prune">true</property>
| <property name="include">org.jboss.test., org.jboss.injbossaop., org.jboss.deployers.</property>
| <property name="exclude">org.jboss.</property>
| <!-- This avoids instrumentation of hibernate cglib enhanced proxies
| <property name="ignore">*$$EnhancerByCGLIB$$*</property> -->
| <property name="optimized">true</property>
| <property name="verbose">false</property>
| <!--
| Available choices for this attribute are:
| org.jboss.aop.instrument.ClassicInstrumentor (default)
| org.jboss.aop.instrument.GeneratedAdvisorInstrumentor
| <property name="instrumentor">org.jboss.aop.instrument.ClassicInstrumentor</property>
| -->
| </bean>
|
Can you look into why this is now failing?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065597#4065597
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065597
18 years, 8 months
[Design of Clustering on JBoss (Clusters/JBoss)] - InstanceNotFoundException in trunk
by scott.stark@jboss.org
Shutting down the all config currently shows a couple different InstanceNotFoundExceptions like the following.
| 12:14:20,396 INFO [DefaultPartition-SFSBCache] stop(): stopping the dispatcher
| 12:14:20,396 ERROR [JChannelFactory] failed unregistering channel udp
| javax.management.InstanceNotFoundException: jboss.jgroups:type=protocol,cluster=udp,protocol=STATE_TRANSFER is not registered.
| at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java:529)
| at org.jboss.mx.server.registry.BasicMBeanRegistry.unregisterMBean(BasicMBeanRegistry.java:461)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:585)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.mx.server.MBeanServerImpl$1.run(MBeanServerImpl.java:400)
| at java.security.AccessController.doPrivileged(Native Method)
| at org.jboss.mx.server.MBeanServerImpl.unregisterMBean(MBeanServerImpl.java:395)
| at org.jgroups.jmx.JmxConfigurator.unregister(JmxConfigurator.java:139)
| at org.jgroups.JChannelFactory.unregister(JChannelFactory.java:334)
| at org.jgroups.JChannelFactory.close(JChannelFactory.java:465)
| at org.jgroups.mux.MuxChannel.close(MuxChannel.java:159)
| at org.jboss.cache.CacheImpl.killChannel(CacheImpl.java:3310)
| at org.jboss.cache.CacheImpl.internalStop(CacheImpl.java:930)
| at org.jboss.cache.CacheImpl.stop(CacheImpl.java:900)
| at org.jboss.cache.CacheImpl$2.run(CacheImpl.java:807)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065538#4065538
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065538
18 years, 8 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOP ClassLoader/Scoping for the VFSClassLoader
by adrian@jboss.org
I've committed this since I haven't broken any tests that weren't already broken. :-)
NOTE: I haven't updated the temp deployer in jboss's system project
since that would require releasing a jboss-aop snapshot which
I don't want to do yet.
P.S. There seems to be a problem with the way the pluggable instrumentor is
being used by the testsuite bootstrapping ant tasks (path problem?).
I keep seeing "random" errors like this:
| Caused by: java.lang.NoClassDefFoundError: org/jboss/aop/standalone/PluggableInstrumentor
| at org.jboss.aop.deployment.AspectManagerServiceJDK5.attachTranslator(AspectManagerServiceJDK5.java:46)
| at org.jboss.aop.deployment.AspectManagerService.setEnableLoadtimeWeaving(AspectManagerService.java:537)
| at org.jboss.mx.interceptor.AttributeDispatcher.invoke(AttributeDispatcher.java:136)
|
which I haven't seen when I start the appserver manually?
I'll also see if I can figure out why the other tests were already failing before I started this work. e.g. the ScopedEarWithClassesInWebInfTestCase test
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4065522#4065522
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4065522
18 years, 8 months