[JBoss Microcontainer Development] New message: "Circular Dependencies and Semi-Resolve"
by Adrian Brock
User development,
A new message was posted in the thread "Circular Dependencies and Semi-Resolve":
http://community.jboss.org/message/530202#530202
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
https://jira.jboss.org/jira/browse/JBKERNEL-109
I've committed a prototype for circular dependencies.
This involved three main changes:
1) The ability to "semiResolve" a dependency which means that you know what you want to depend on,
but it is not in the correct state yet. However, if the only thing that is stopping it moving to the correct
state is a circular dependency (i.e. other things in the semi-resolved state) then it will upgraded to fully resolved.
2) Change AbstractDependencyItem to use an enum for the three different types of resolved states,
resolved, semi-resolved and unresolved and track the different types in AbstractDependencyInfo for optimized processing of the
different types.
3) A change in AbstractController to introduce an "uninstalling" set like the "installing" set, to avoid recursive
when uninstalling contexts that have circular dependencies.
Caveats:
* I haven't looked at adding ON_DEMAND processing, although it should be simple to add?
* The semi-resolved handling only looks at contexts in the previous state to what you require.
If they are in any earlier state then they are unresovled until they progress to the previous state.
This avoids having to do a complicated determination on whether there is a path to break the circular dependency,
rather than just advancing all the related semi-resolved contexts to the next state.
Its usage should be trivial:
public MyDependencyItem extends AbstractDependencyItem
{
public boolean resolve(Controller)
{
// Determine the context we want to be semi-resolved on
ControllerContext ctx = ...;
if (ctx == null)
return false;
// Pass the handling to AbstractDependencyItem
return semiResolve(ctx);
}
}
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530202#530202
16 years, 1 month
[JBoss Microcontainer Development] New message: "Undemand processing is wrong"
by Adrian Brock
User development,
A new message was posted in the thread "Undemand processing is wrong":
http://community.jboss.org/message/530199#530199
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
One of the tests in the JMX testsuite actually shows it was wrong, but it is asserting the wrong thing. :-)
Consider the following test:
<mbean name="A" mode="ON_DEMAND"/>
<mbean name="B">
<depends>A</depends>
</mbean>
As per the original JMX rules, that will set up two dependencies
B->A at CREATE
B->A at START
Now assume everything is at INSTALLED.
If I do B.stop() what is happening now is the uninstall of undemanded contexts will say that A is no longer required.
It correctly works out that A is still required for the CREATE dependency, and that it is no longer required for the START dependency.
So what would you expect it to do?
1) Move A back to DESCRIBE, even B needs it for the CREATE dependency
2) Move A back to CREATE which is what B demands
3) Don't do anything with A
The current answer is (1), which is obviously wrong. When A goes back to DESCRIBE, then B will also be destroyed
(because of the dependency at CREATE) which is not what I asked for.
I've got a fix that makes it do (3). i.e. while something still wants an ON_DEMAND service, it will stay in the fully INSTALLED state
(or its current state if somebody moved it).
This makes sense to me, since enabling an on demand service doesn't move it to an incompletely deployed state,
so why should undemanding do that?
I don't actually like this processing. Like I said when I originally did the ON_DEMAND processing,
you don't want to bounce your ON_DEMAND webserver just because you are redeploying your only web-app. ;-)
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/530199#530199
16 years, 1 month