[JBoss Microcontainer Development] New message: "DependsOnMe is broken?"
by Adrian Brock
User development,
A new message was posted in the thread "DependsOnMe is broken?":
http://community.jboss.org/message/525060#525060
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
Something in jboss-kernel 2.2.0.Alpha4 breaks the dependsOnMe processing - not tidying it up.
See the jboss-cl testsuite. This test passes using 2.2.0.Alpha3
junit.framework.AssertionFailedError: expected:<0> but was:<1>
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.failNotEquals(Assert.java:277)
at junit.framework.Assert.assertEquals(Assert.java:64)
at junit.framework.Assert.assertEquals(Assert.java:195)
at junit.framework.Assert.assertEquals(Assert.java:201)
at org.jboss.test.classloading.dependency.test.DependencyUnitTestCase.testDependencyRemoval(DependencyUnitTestCase.java:300)
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/525060#525060
16 years, 5 months
[JBoss Microcontainer Development] New message: "Profiling the dependency project"
by Kabir Khan
User development,
A new message was posted in the thread "Profiling the dependency project":
http://community.jboss.org/message/525047#525047
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
Since the indexing dependency resolver I have been working on does not yield the performance improvements I was hoping for, I am now benchmarking the dependency project in isolation. It makes profiling a lot easier since there is a lot less other things going on which is the case when starting up the application server. My thinking now is that we should do the same for the other MC modules.
One thing is to not try to resolve contexts that are in the INSTALLED state (or where the , from AbstractController.resolveContexts(boolean), this shaves off about 20% for contexts installed in the right order. See http://community.jboss.org/message/524747#524747 for a description of the benchmark.
for (ControllerState fromState : stateModel)
{
ControllerState toState = stateModel.getNextState(fromState);
- if (resolveContexts(fromState, toState, trace))
+
+ if (stateModel.isValidState(toState))
{
- resolutions = true;
- break;
+ if (resolveContexts(fromState, toState, trace))
+ {
+ resolutions = true;
+ break;
+ }
}
}
}
Another simple thing that cuts deploying 2000 contexts
-with dependencies in the right order from 852ms->789ms
-with dependencies in the right order from 12788ms->8320ms
is to further modify resolveContexts to not break out of the loop once it resolves some contexts for a state, e.g.
boolean resolutions = true;
while (resolutions || onDemandEnabled)
{
if (onDemandEnabled)
wasOnDemandEnabled = true;
onDemandEnabled = false;
resolutions = false;
for (ControllerState fromState : stateModel)
{
ControllerState toState = stateModel.getNextState(fromState);
if (stateModel.isValidState(toState))
{
if (resolveContexts(fromState, toState, trace))
{
resolutions = true;
// break; // Don't exit here
}
}
}
}
Profiling this for 500 contexts reduces the number of calls to the nested resolveContexts from
-17,500 to 7000 (right order)
-17,500 to 10,493 (wrong order), a bit down the line we end up with 377K instead of 627K calls to resolveDependencies()
All tests pass apart from the ones mentioned in http://community.jboss.org/message/524862#524862 which I know how to fix if Ales agrees:
> mailto:kabir.khan@jboss.com wrote:
>
> I mean this:
>
> *public* *void* testPlainLifecycleDependencyWrongOrder() *throws* Throwable
> {
> plainLifecycleDependencyWrongOrder();
>
> ControllerContext context2 = assertInstall(1, "Name2", ControllerState.+CONFIGURED+);
> ControllerContext context1 = assertInstall(0, "Name1");
> +assertEquals+(ControllerState.+INSTALLED+, context2.getState());
>
> SimpleBeanWithLifecycle bean1 = (SimpleBeanWithLifecycle) context1.getTarget();
> +assertNotNull+(bean1);
>
> SimpleBeanWithLifecycle bean2 = (SimpleBeanWithLifecycle) context2.getTarget();
> +assertNotNull+(bean2);
>
> +assertEquals+(1, bean1.createOrder);
> +assertEquals+(2, bean2.createOrder);
> +assertEquals+(3, bean1.startOrder);
> +assertEquals+(4, bean2.startOrder);
> }
>
> The new resolver works with
> +assertEquals+(1, bean1.createOrder);
> +assertEquals+(2, bean1.startOrder);
> +assertEquals+(3, bean2.createOrder);
> +assertEquals+(4, bean2.startOrder);
>
> The actual hardcoded orders of beans 1 and 2 is an implemetation detail as I see it. The real check is making sure that the initial install of context 2 does not go beyond CONFIGURED and:
> bean1.startOrder > bean1.createOrder
> bean2.startOrder > bean2.createOrder
> bean2.createOrder > bean1.createOrder
> bean2.startOrder > bean1.startOrder
>
> I've got an infinite loop in the indexing resolver when I start up AS which I need to fix before I can get any measurements of boot time, although it sounds like we won't gain much from this.
>
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/525047#525047
16 years, 5 months
[jBPM] New message: "Async fork error with jBPM 4.3"
by Maciej Swiderski
User development,
A new message was posted in the thread "Async fork error with jBPM 4.3":
http://community.jboss.org/message/525042#525042
Author : Maciej Swiderski
Profile : http://community.jboss.org/people/swiderski.maciej
Message:
--------------------------------------------------------------
Hi,
I have created basic flow that uses async fork (based on the example from jBPM package) and it runs properly as a test case but causes errors when running on JBoss AS. Attached all files (jPDL, java classes and ftl).
The issue is that sometimes it does work but sometime it throws following exception:
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.pvm.internal.model.ExecutionImpl#10065]
but the execution goes down to the next node - in this case to task node. Entire log for one execution of this process is attached as log file.
I tried on two data bases: HSQLDB and PostgreSQL.
I tried both async and exclusive for the fork node but no difference at all.
Is there anything I am doing wrong?!
Thanks
Maciej
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/525042#525042
16 years, 5 months