[JBoss Microcontainer Development] New message: "Profiling the kernel project"
by Kabir Khan
JBoss development,
A new message was posted in the thread "Profiling the kernel project":
http://community.jboss.org/message/525867#525867
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
Running a very simple benchmark for deploying a 1000 beans of type Object with no dependencies or configured properties, i.e.
protected List<BeanMetaData> setupContexts()
{
List<BeanMetaData> beans = new ArrayList<BeanMetaData>(iterations);
for (int i = 0 ; i < iterations ; i++)
{
BeanMetaDataBuilder builder = BeanMetaDataBuilder.createBuilder("Bean" + i, Object.class.getName());
beans.add(builder.getBeanMetaData());
}
return beans;
}
shows 85% of this time to be spent in the PreInstallAction. A similar test deploying 500 beans with dependencies in the wrong order (which we know from http://community.jboss.org/message/525809#525809 is very slow) shows 25% of the time spent in PreInstallAction.
Most of the time spent in PreInstallAction comes down to adding to and reading from the BasicMetaDataRepository.retrievals map, which hits UnmodifiableScopeKey.equals lots of times (~2M times in the 1000 beans case):
public boolean equals(Object object)
{
if (object == this)
return true;
if (object == null || object instanceof ScopeKey == false)
return false;
ScopeKey other = (ScopeKey) object;
Scope[] otherArray = other.getArray();
return Arrays.equals(theScopes, otherArray);
}
I will dig into this tomorrow and see if this can be optimized somehow, and if it is a problem in MDR I'll open another thread for that.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/525867#525867
14 years, 7 months
[JBoss Messaging Development] New message: "How can I use duplicate JNDI names for Queues?"
by Kevin Halk
JBoss development,
A new message was posted in the thread "How can I use duplicate JNDI names for Queues?":
http://community.jboss.org/message/525826#525826
Author : Kevin Halk
Profile : http://community.jboss.org/people/khalk
Message:
--------------------------------------------------------------
Hi there,
This may seem like a stupid question but is there any way to specify duplicate JNDI names for Queues?
We require several separate EJBs to reference the same queue (A outputs to Q1, B reads Q1 etc..). I'd like to be able to have any number of these available at any time (i.e. both A and B might not necessarily be there).
This means that either one could be responsible for creating Q1.
I can specify the Queue to be created in A and B's deployment descriptors, however I get an error saying the JNDI name already exists when it tries to create the second time (obviously). I would like the Queue to be created if it does not already exist - is there any way to accomplish this without an error?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/525826#525826
14 years, 7 months
[JBoss Microcontainer Development] New message: "Re: Profiling the dependency project"
by Kabir Khan
JBoss development,
A new message was posted in the thread "Profiling the dependency project":
http://community.jboss.org/message/525792#525792
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
> alesj wrote:
> Can you do a proof check (proof by-design) that this doesn't break the resolve logic.
> At first sight it looks harmless, but we must make sure it's really OK.
> e.g. 2nd resolve would resolve same contexts in both scenarios
>
>
i have tried to find ways to break this, but apart from the point at the end of this post I can't see a way, so I think we're fine. Take this example:
Context A has a DependencyItem{iDependOn=B whenRequired=CONFIGURED dependentState=CONFIGURED}
Context B has a DependencyItem{iDependOn=C whenRequired=CONFIGURED dependentState=INSTALLED}
We install A and it hangs in INSTANTIATED
We install B and it hangs in INSTANTIATED
We then install C
Old model:
Outer loop iteration N:
inner loop until START
Find C, move it to INSTALLED
break out since we incremented contexts
next outer iteration:
inner loop until INSTANTIATED:
Find A, do nothing since B is not in CONFIGURED
Find B, B has its dependencies resolved and gets moved to CONFIGURED
break out since we incremented contexts
next iteration:
inner loop until INSTANTIATED:
Find A, A has its dependencies resolved and gets moved to CONFIGURED
break out since we incremented contexts
next iteration:
inner loop until CONFIGURED:
Find B, B gets moved to CREATE (it is before A in the COWAS for the state)
Find A, A gets moved to CREATE
break out since we incremented contexts
next iteration:
inner loop until CREATE:
Find B, B gets moved to START, break out
Find A, A gets moved to START, break out
break out since we incremented contexts
next iteration:
inner loop until START:
Find B, B gets moved to INSTALLED, break out
Find A, A gets moved to INSTALLED, break out
break out since we incremented contexts
New model:
C goes through all the states until INSTALLED
next outer iteration:
inner loop until INSTANTIATED:
Find A, A has its dependencies resolved and gets moved to CONFIGURED
next inner loop CONFIGURED
Find A, A gets moved to CREATE
next inner loop CREATE
Find A, A gets moved to START
next inner loop START
Find A, A gets moved to INSTALLED
next outer iteration
inner loop until INSTANTIATED:
Find A, do nothing since B is not in CONFIGURED
Find A, A has its dependencies resolved and gets moved to CONFIGURED
next inner loop CONFIGURED
Find A, A gets moved to CREATE
next inner loop CREATE
Find A, A gets moved to START
next inner loop START
Find A, A gets moved to INSTALLED
I was talking about changing COWAS for contextsByState earlier, but this exercise has convinced me that it is needed due to the fact that its iterator will return contexts in the order they were added.
So in both cases C enters CONFIGURED, CREATE, START and INSTALLED before B, and similarly B enters those states before A. This is as it should be at least from the old ServiceController training notes: if a context has a dependency then the context we depend on will be created by the time we are created, and the context we depend on will be started by the time we are started.
The only way I can think of breaking this is if B had a DependencyItem{iDependOn=D whenRequired=CREATE dependentState=INSTALLED}, in which case B would hang in CONFIGURED case until D is installed, meaning A would enter CREATE, START, INSTALLED before B, but that is true in both models.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/525792#525792
14 years, 7 months