[JBoss Microcontainer Development] - ClassPoolRepository vs JBossclDelegatingClassPoolRepository
by Flavia Rainone
Flavia Rainone [http://community.jboss.org/people/flavia.rainone%40jboss.com] created the discussion
"ClassPoolRepository vs JBossclDelegatingClassPoolRepository"
To view the discussion, visit: http://community.jboss.org/message/537965#537965
--------------------------------------------------------------
Since we updated the classpool and AOP versions at JBoss AS, we've been seeing some warning messages showing that unregistering of ClassPool is not working correctly.
The reason for these failures is that AspectManager is using ClassPoolRepository to register ClassLoaders, whereas the unregistering of ClassLoaders, performed by RegisterModuleCallback, is using JBossClDelegatingClassPoolRepository. As JBossClDelegatingClassPoolRepository.registeredModules map lacks the the register info, unregisterClassLoader is throwing an exception:
public void unregisterClassLoader(ClassLoader classLoader, Module module)
{
ScopedClassPool classPool = registeredModules.remove(module);
if (classLoader == null)
{
if (classPool == null)
{
throw new IllegalStateException("Module " + module + " is not registered");
}
So, to fix this, AspectManager must start using JBossClDelegatingClassPoolFactory instead of ClassPoolFactory:
public ClassPool registerClassLoader(ClassLoader ucl)
{
return ClassPoolRepository.getInstance().registerClassLoader(ucl);
}
But this cannot be hard coded because JBossClDelegatingClassPoolFactory provides support to modules and assumes that you are using jboss-cl, which is only true in AS 5/6 environment. When using JBoss AOP in standalone mode or in JBoss AS 4, we need to use ClassPoolRepository.
The way that the ClassPool architecture is today, I'll have to make this configurable on the AOP side (e.g., I'll probably add this to AspectManagerJDK5). Is this the best option? Or should we rethink ClassPool architecture, making this configurable on the ClassPool side?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/537965#537965]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
[jBPM] - Decision Activity with Join finish don't work!
by Mary Marlet
Mary Marlet [http://community.jboss.org/people/marc.carrio] created the discussion
"Decision Activity with Join finish don't work!"
To view the discussion, visit: http://community.jboss.org/message/537953#537953
--------------------------------------------------------------
Hi guys!
I use a jbpm4.3 with tomcat, mysql and jbpm-console 2.0 in Windows XP
I have the next simply process:
<?xml version="1.0" encoding="UTF-8"?>
<process name="Alta" xmlns="http://jbpm.org/4.0/jpdl">
<start form="main/GestioUsuaris/Init.ftl" g="15,86,48,48" name="Nou Usuari">
<transition to="exclusive1"/>
</start>
<end g="615,108,48,48" name="Usuari d'alta"/>
<task assignee="mary" form="main/GestioUsuaris/CA.ftl" g="454,82,100,80" name="Secretaria">
<transition to="Usuari d'alta"/>
<notification template="task-assign"/>
</task>
<task assignee="mary" form="main/GestioUsuaris/Tel.ftl" g="212,36,100,80" name="Telefonia">
<transition to="Secretaria"/>
<notification template="task-assign"/>
</task>
<decision expr="#{chkTel}" g="96,87,114,70" name="exclusive1">
<transition g="-16,-18" name="ok" to="Telefonia"/>
<transition g="-23,7" name="ko" to="Nothing"/>
</decision>
<task assignee="mary" form="main/GestioUsuaris/Tel.ftl" g="211,178,100,80" name="Nothing">
<transition to="Secretaria"/>
<notification template="task-assign"/>
</task>
</process>
The problem is after then 'Telefonia' task. the error that displays is:
org.jboss.resteasy.spi.UnhandledException: org.hibernate.NonUniqueResultException: query did not return a unique result: 2
org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:319)
org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:230)
org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:206)
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:360)
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:173)
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:93)
org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:68)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.bpm.console.server.util.GWTJsonFilter.doFilter(GWTJsonFilter.java:59)
*causa raíz*
org.hibernate.NonUniqueResultException: query did not return a unique result: 2
org.hibernate.impl.AbstractQueryImpl.uniqueElement(AbstractQueryImpl.java:844)
org.hibernate.impl.AbstractQueryImpl.uniqueResult(AbstractQueryImpl.java:835)
I tested with a "join" after tasks and before ('Secretaria' and 'Nothing') task but the error is the same.
The examples don't have joins! How I can do a decission activity with "joined" finish?
Thanks a lot for advance!
Mary
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/537953#537953]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month
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/537944#537944
--------------------------------------------------------------
I've attached the classes I put together for measuring this. I think I included everything needed to make them run, let me know if you have any problems. I used asm 3.2.
I haven't looked too deeply into why the performance is different, but I think it is due to how Bytecode and ConstPool make use of ByteVector and LongVector while their asm counterparts seem to modify the byte array directly. Javassist, on the other hand, needs to convert those to create the byte arrays. I have not done any measurements of this, but I guess with things the way they are that once the class bytes are parsed that javassist would be faster for calling things like getMethod() etc.?
The reason why this becomes important is that this is something that gets called huge numbers of times. However, there are other problems with this approach of generating accessors with bytecode, which means I am not 100% sure we should go with this approach. This is that we end up with:
* having to load a lot of extra classes which takes a lot of time and fills up PermGenSpace
* a lot of instances (although the number of instances probably holds true when we just use java.lang.reflect.Method instead)
My idea of creating bigger accessors isn't that viable either. If you have a class that has 300 members, but only 30 of those are used with the original method you end up with 30 small classes. With the "bigger accessor" idea, you end up with only one class, but with the code to access all 300 members, so that is a waste of memory.
If an accessor is called a lot of times it makes sense to generate a class for it. However, if it is called only a few times, then generating and loading a class for it will be slower due to having to load the class.
The main use-cases I know of are:
* Configuring the properties of the MC beans. For most bean classes I think each property is only installed once. However, in other cases, e.g. the properties of the beans for the AOP metadata + the beans installed by EJB 3 probably get accessed a lot of times, so for these it would make sense to generate classes.
* JBossXB parsing. It is used for parsing the schema, which only happens once, but when parsing the xml files, I think the accessors are used a lot.
I think we need some kind of differentiator, so that for accessors that only get called a few times we just go with norrnal reflection, but for heavily used accessors we go with generating the classes. I'll try to come up with some numbers for how many times we need to access the member for generating the class to be the cheapest option.
The question is what differentiator to use? A few ideas:
* Keep a counter in Javassist[Method/Field/Constructor]Info and once it has been called several times switch to the generated class. The problem with this is, what if this counter kicks in and we end up generating the class and then we don't have enough subsequent accesses to reap the performance benefits, i.e. in this case it would slow it down.
* Use some annotation to say that for a particular class we should always use generated members. If this annotation comes from MC BeanMetaData it could be put into the TypeInfo attachments.
I will build some statistics into JavassistConstructorInfo.newInstance(), JavassistMethodInfo.invoke() etc. so it is possible to get a report of the type of accessor used and the number of calls to help with being able to tune it using annotations unless somebody has some different ideas.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/537944#537944]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
16 years, 1 month