[jboss-user] [JBoss Microcontainer Development] New message: "Re: Profiling the dependency project"

[Kabir Khan]

User 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