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