[
https://issues.jboss.org/browse/WFLY-12601?page=com.atlassian.jira.plugin...
]
Richard Opalka commented on WFLY-12601:
---------------------------------------
I attached ServiceSupplier UML diagram in order to describe what MSC broken code means
there.
ServiceSupplier.get() installs new temporary MSC service in order to obtain dependency
value in a
new MSC API proper way.
There are two problems with that code in ServiceSupplier.get() method.
(1) I realized StabilityMonitor feature is broken by design and thus code calling
SM.awaitStability() may obtain false "stability achieved" notifications.
This is the case mainly for dependencies whose dependency chain is greater than 2.
(2) There is concurrent race condition between SM.awaitStability() call and
controller.getState() call.
It may happen even if "stability achieved" was properly reported that
service may transition from UP to some other state between these two calls.
It is not possible to avoid (1) kind of issues other way than eliminate usages of
StabilityMonitor.
To fix (2) kind of issues it is necessary to obtain dependency values while dependency is
in UP state.
That means values particular service provide are valid iff service finished its start()
lifecycle method
and didn't start its stop() lifecycle method.
I created MSC branch for you [~pferraro] to demonstrate how you should fix these
"obtain statistics" scenarios:
https://github.com/ropalka/jboss-msc/commits/WFLY-12601
If you will have any questions WRT jboss-msc or this reported issue please
don't hesitate and ask me either via mail or via #jboss-msc stream in WildFly Zulip
chat.
Eliminate StabilityMonitor usages in clustering subsystem
---------------------------------------------------------
Key: WFLY-12601
URL:
https://issues.jboss.org/browse/WFLY-12601
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Richard Opalka
Assignee: Paul Ferraro
Priority: Major
Fix For: 19.0.0.Beta1
Attachments: ServiceSupplier.png
Clustering needs to eliminate usages of StabilityMonitor because SM is not reliable.
It is possible that SM will prematurely inform about achieved stability even if it is not
true.
The reason is SM is not propagated up the dependencies chain and thus it may report
about achieved stability even in case dependencies chain didn't finish its processing
yet
and 'real' stability wasn't achieved yet.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)