Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
by Flavia Rainone
Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] replied to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/543946#543946
--------------------------------------------------------------
> Kabir Khan wrote:
>
> Once I am done with caching things as much as possible, we'll see if the classpools are still a bottleneck since there will be a lot less calls. If they are, I have an idea for how to change them into something simpler, but just want to jot it down so Flavia can take a look and see if she thinks it is a good idea or if I have missed something.
>
> The idea is quite simple, rather than managing the domains and pools and essentially recreating what the classloaders do, it might make sense to delegate everything to the classloaders. If we had a method like this, as I discussed with Ales (let's say it goes in the ClassLoading class, although where is up to Ales):
>
> ClassLoader getClassLoaderForClass(ClassLoader initiating, String classname);
>
>
>
>
> And we have a map of classpools by classloader in the classpool registry.
>
>
>
> Then I think our "dumb" class pool would not need much more than this - it has a null parent
>
>
>
>
>
> *class* DumbClassPool *extends* ClassPool{
>
> WeakReference<ClassLoader> cl;
> ClassPoolRepository repo;
>
> DumbClassPool(ClassLoader cl, ClassPoolRepository repo){
> this.cl = *new* WeakReference<ClassLoader>(cl);
> this.repo = repo;
> }
>
>
> CtClass get(String classname){
> //Check cache first, if not found then do the rest
>
> CtClass clazz = super.get0(classname);
> *if* (clazz != *null*)
> *return* clazz;
>
> String real = adjustForArraysAndPrimitives(classname);
> ClassLoader loader = ClassLoading.getClassLoaderForClass(cl.get(), real);
>
> ClassPool pool = repo.registerClassLoader(loader);
> *if* (pool != *null*)
> {
> clazz = pool.getOrNull(classname); //new method from Chiba that does not throw NFE, but behaves like get()
> }
>
> *if* (clazz != *null*)
> //cache class
> *else*
> *throw* *new* NotFoundException
> }
> }
>
>
>
>
> I'd obviously be extending ScopedClassPool or whatever is needed in AOP and other places. It would also have some knowledge of the domain and get notified when loaders get added/removed to the domain so the caches in the pools can be invalidated. There will probably be a bit more to it than this, but this is the basic idea.
>
>
>
I only see pros at implementing the classpools this way:
- it is fast to do it. I know that there is a lot of detail that needs to be filled in, but nobody is talking about reimplementing them with the same level of complexity of before
- it is so clean that we will be able of seeing the real impact of classpools in the performance
Regarding the last sentence, as has already been discussed on our team calls, it is not a piece of cake to outperform reflection:
- it is good that we don't force classes to be loaded... but what if the class has already been loaded? Do we want to use an extra loading level in that case? We can of course try to create a clever mechanism for working around this, but this is more complexity to a code that is already complex.
- we are doing with Java and Javassist (one more layer of indirection) something that the JDK already does (apart from bytecodes manipulation, of course). After years of JDK improvements, we can expect that they do this natively and fast. The JDK can use its own internal structures (the ones it uses to load and run code) for answering reflection invocations.
Thus, if we have the cleanest possible implementation of the ClassPools, we have less overhead and we will finally be able to see if it is possible to improve the performance with Javassist/Classpools and to beat our reflection-based implementation.
This is the main question we've been trying to answer all this time.
Using the ClassLoaders SPI to find the appropriate ClassLoader/ClassPool is definitely a plus in this regard, as we are using the same ClassLoader structure that the reflection implementation uses.
The only drawback is that we won't be able of getting rid of the old structure for AS 4 (ie, erasing all classpool code for as 4), unless we use an older version of the project for JBoss AOP. Which is not really a drawback, it is more like a constraint that we have to face for being backwards compatible with an older version of AS.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/543946#543946]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 4 months
Re: [jboss-user] [jBPM] - [jbpm 4.2] Finding a Process Instance
by Teofilo Copa
Teofilo Copa [http://community.jboss.org/people/intoxicadocoder] replied to the discussion
"[jbpm 4.2] Finding a Process Instance"
To view the discussion, visit: http://community.jboss.org/message/543940#543940
--------------------------------------------------------------
Hi at all when iam trying this:
ProcessInstanceQuery query = *new* ProcessInstanceQueryImpl();
List<ProcessInstance> list = query.processDefinitionId("procesDefinitionId").list();
i get this exception:
org.jbpm.api.JbpmException: no environment to get org.hibernate.Session
org.jbpm.pvm.internal.env.EnvironmentImpl.getFromCurrent(EnvironmentImpl.java:197)
org.jbpm.pvm.internal.env.EnvironmentImpl.getFromCurrent(EnvironmentImpl.java:190)
org.jbpm.pvm.internal.query.AbstractQuery.untypedList(AbstractQuery.java:70)
org.jbpm.pvm.internal.query.ProcessInstanceQueryImpl.list(ProcessInstanceQueryImpl.java:48)
org.uajms.dtic.epersonal.web.controllers.PruebaController.doInicializarVentana(PruebaController.java:67)
org.uajms.dtic.epersonal.web.controllers.PruebaController.afterCompose(PruebaController.java:78)
org.zkoss.zk.ui.impl.UiEngineImpl.execCreateChild0(UiEngineImpl.java:620)
this is my jbpm.cfg.xml
<jbpm-configuration>
<import resource="jbpm.default.cfg.xml" />
<import resource="jbpm.tx.hibernate.cfg.xml" />
<import resource="jbpm.jpdl.cfg.xml" />
<import resource="jbpm.bpmn.cfg.xml" />
<import resource="jbpm.identity.cfg.xml" />
<import resource="jbpm.businesscalendar.cfg.xml" />
<import resource="jbpm.console.cfg.xml" />
<import resource="jbpm.jobexecutor.cfg.xml" />
</jbpm-configuration>
am using jbpm-4.3 why i can fix this thanks so.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/543940#543940]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 4 months
[JBoss Microcontainer] - Deployment ordering on HornetQ destinations and MDBs
by Clebert Suconic
Clebert Suconic [http://community.jboss.org/people/clebert.suconic%40jboss.com] created the discussion
"Deployment ordering on HornetQ destinations and MDBs"
To view the discussion, visit: http://community.jboss.org/message/543932#543932
--------------------------------------------------------------
We have an issue where our destinations are being deployed after the MDBs on EAP 5.1 @ hornetq.
Users can define dependencies to other POJOs.. but we don't want to force users to do that, if they deploy the whole thing at the same time. We would like to have the priorities tweaks in a certain way destinations would always deploy before the MDBs if everything is together:
Here's the scenario:
The application server has:
- HornetQJMSParseDeployment that will produce JMSConfiguration which is an input for the real deployer
- HornetQJMSRealDeployer that will produce POJOs that will depend on the HornetQ Server and will produce the destinations.
- StandardJBossMetaDataDeployer (from the server project)
Up to HornetQJMSRealDeployer everything seems ok.. It's all happening before StandardJBossMetaDataDeployer, however the Bean deployed as part of the Real deployer will only be initialized after the whole deployment context was finished.
Which doesn't seem to be the same behaviour taken by AS 6.
We have created a branch of the EAP 5.1... maybe this is an issue that was fixed later on?
https://svn.jboss.org/repos/jbossas/branches/JBPAPP_5_1_hornetq-int/ https://svn.jboss.org/repos/jbossas/branches/JBPAPP_5_1_hornetq-int/
if you have time to reproduce the issue.. you have download this branch ^^
after building it, go to ./build/output/jboss-server/extras/hornetq
execute ./switch.sh
# we will take care of this step later
remove hornetq/examples/javaee/common/config/ant.propertie
cd build//output/jboss-server/extras/hornetq/example/javaee/bmt
ant deploy
You will see an error while deploying the MDB.
But most of the debug information I've taken is already here.
Any help would be appreciated... thanks a lot
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/543932#543932]
Start a new discussion in JBoss Microcontainer at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 4 months
Re: [jboss-user] [JBoss Microcontainer Development] - JBoss Reflect Performance Javassist vs Introspection
by Kabir Khan
Kabir Khan [http://community.jboss.org/people/kabir.khan%40jboss.com] replied to the discussion
"JBoss Reflect Performance Javassist vs Introspection"
To view the discussion, visit: http://community.jboss.org/message/543921#543921
--------------------------------------------------------------
Although too early to say yet, it looks like the classpools are a bottleneck. I have started caching things a bit more and that is speeding things up somewhat. For example calling CtBehavior.getParameterTypes() is slow since it does not cache the parameter types, instead for every call to this it parses the method signature and then hits the classpools for every class. I am attempting to avoid that as much as possible.
Another observation is that quite a few calls to JavassistMethodInfo.getParameterTypes() are only interested in the length of the parameters and the names of the parameter types, so it might be an idea to return an array of "lazy" type infos which only know the name and the declaring typeinfo. I can be found out easily from the raw method signature (I am already passing the SignatureKey into JavassistMethodInfo and using that in its equals() method to avoid having to load parameters there). Once something more advanced is called, then that could obtain the real typeinfo and delegate to that. I'm not 100% sure yet if this is what I want to do.
Once I am done with caching things as much as possible, we'll see if the classpools are still a bottleneck since there will be a lot less calls. If they are, I have an idea for how to change them into something simpler, but just want to jot it down so Flavia can take a look and see if she thinks it is a good idea or if I have missed something.
The idea is quite simple, rather than managing the domains and pools and essentially recreating what the classloaders do, it might make sense to delegate everything to the classloaders. If we had a method like this, as I discussed with Ales (let's say it goes in the ClassLoading class, although where is up to Ales):
ClassLoader getClassLoaderForClass(ClassLoader initiating, String classname);
And we have a map of classpools by classloader in the classpool registry.
Then I think our "dumb" class pool would not need much more than this - it has a null parent
class DumbClassPool extends ClassPool{
WeakReference<ClassLoader> cl;
ClassPoolRepository repo;
DumbClassPool(ClassLoader cl, ClassPoolRepository repo){
this.cl = new WeakReference<ClassLoader>(cl);
this.repo = repo;
}
CtClass get(String classname){
//Check cache first, if not found then do the rest
CtClass clazz = super.get0(classname);
if (clazz != null)
return clazz;
String real = adjustForArraysAndPrimitives(classname);
ClassLoader loader = ClassLoading.getClassLoaderForClass(cl.get(), real);
ClassPool pool = repo.registerClassLoader(loader);
if (pool != null)
{
clazz = pool.getOrNull(classname); //new method from Chiba that does not throw NFE, but behaves like get()
}
if (clazz != null)
//cache class
else
throw new NotFoundException
}
}
I'd obviously be extending ScopedClassPool or whatever is needed in AOP and other places. It would also have some knowledge of the domain and get notified when loaders get added/removed to the domain so the caches in the pools can be invalidated. There will probably be a bit more to it than this, but this is the basic idea.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/543921#543921]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 4 months