[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...]
15 years, 11 months
Re: [jboss-dev-forums] [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...]
15 years, 11 months
Re: [jboss-dev-forums] [EJB 3.0 Development] - HornetQ Resource Adapter and DLQ handling
by jaikiran pai
jaikiran pai [http://community.jboss.org/people/jaikiran] replied to the discussion
"HornetQ Resource Adapter and DLQ handling"
To view the discussion, visit: http://community.jboss.org/message/537907#537907
--------------------------------------------------------------
Actually, there are 2 things to be considered here:
1) Provider specific activation config properties : As Andy says - JBM used to support some of the activation config props which are no longer valid in HornetQ. As Andy and I discussed over IRC, I'll see if EJB3 code mandates some of these properties to be available. If it does, then we will have to move it out of EJB3 (including the related documentation) to make it a JMS provider specific config.
2) The meaning/usage of DLQ : In HornetQ, there are just Dead letter Addresses. But from the point of view of a JMS client (like MDB) which are just aware of (JMS) queues and (JMS) topics, how would they subscribe to a dead letter (JMS) queue. I am still looking at the hornetq configs in AS and reading through the docs to see how the (hornetq) DLA is being setup. I guess, there needs to be some layer which sets up a (HornetQ) queue subscription to the DLA to make it look like the (JMS) DLQ.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/537907#537907]
Start a new discussion in EJB 3.0 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months
[EJB 3.0 Development] - HornetQ Resource Adapter and DLQ handling
by Andy Taylor
Andy Taylor [http://community.jboss.org/people/ataylor] created the discussion
"HornetQ Resource Adapter and DLQ handling"
To view the discussion, visit: http://community.jboss.org/message/537904#537904
--------------------------------------------------------------
Theres currently an issue with DLQ handling in the HornetQ resource Adapter. Basically we ignore the DLQ settings in the Activation spec. These were only added because there is some code that calls these and sets these with defaults, but basically they are no ops.
The problem is that these methods dont really make sense in a HornetQ context, for instance one seting is for the providers JNDI, but in our RA code we dont use JNDI at all, this is so our RA will work with any container. Also we dont have the notion of a DLQ we have a dead letter address which could have n queues bound to it.
As far as I can see there are the following solutions.
1. We change the activation spec to have HornetQ specific settings. This means however that apps being migrated will have to be ported.
2. We keep the same spec and handle this at th ejb3 layer.
3. We keep the same spec but change our RA to somehow handle this, altho it would be a huge hack and we dont really want to do this.
thoughts guys, any other possible solutions.
P.S Jaikirin is looking in the ejb3 code to see where these defaults are set as this would need changing too
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/537904#537904]
Start a new discussion in EJB 3.0 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months
[JBoss ESB Development] - consume web service with complex data type
by bill zhang
bill zhang [http://community.jboss.org/people/billzhang1123] created the discussion
"consume web service with complex data type"
To view the discussion, visit: http://community.jboss.org/message/537851#537851
--------------------------------------------------------------
I have been playing with webservice_consumer1 sample in JBoss ESB. I modified the sample code to invoke another web service which has an array of string as input parameter along with another String type paramter. Here is my code of process method in webservice_consumer1 MyRequestAction method. No changes on jboss-esb.xml.
public Message process(Message message) throws Exception
{
logHeader();
String msgBody = (String) message.getBody().get();
* HashMap requestMap = new HashMap();
String[] arrayOfStr = new String[2];
arrayOfStr[0] = "b";
arrayOfStr[1] = "b1";*
*
requestMap.put("sayHello.arg1.name", "vicky");
requestMap.put("sayHello.arg1.kids", arrayOfStr);
*
*message.getBody().add(requestMap);
}
*After I ran the SendJMSMessage, on the web service side I can see the incoming value of name which is a String type. However web service can only see the number of elements but not the values. If I use SOAPUI to call the service I can see the array of kids that I send.*
*Therefore, I guess the use of 'requestMap.put("sayHello.arg1.kids", arrayOfStr);' is wrong for array as input. Can someone please give me a hint of how to send an array of string using HashMap? Thanks.**
*
****
*
*
*
*
*
**
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/537851#537851]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 11 months