[
https://issues.jboss.org/browse/WFCORE-1855?page=com.atlassian.jira.plugi...
]
Brian Stansberry commented on WFCORE-1855:
------------------------------------------
A simple workaround is to expose the controller via the BootContext and switch all uses of
it by the boot thread to that. That's largely equivalent to passing it into a new
dependent service via injection. If instead we created a new service and injected the
controller, once that new service's start() was called and it got a ref to the
controller it would use it until completion of start(). Trying to stop the
AbstractControllerService would not result in the execution of start() terminating.
A separate service would be better as it would ensure the AbstractControllerService could
not stop while the boot service was starting. That could have unintended side effects
though, e.g. ServiceContainer not terminating resulting in the shutdown hook not
returning.
Possible NPE on controller service start
----------------------------------------
Key: WFCORE-1855
URL:
https://issues.jboss.org/browse/WFCORE-1855
Project: WildFly Core
Issue Type: Bug
Reporter: David Lloyd
In {{org.jboss.as.controller.AbstractControllerService}}, the {{start}} method starts up
a background thread which performs a certain amount of the boot process. Before this
thread is started, a volatile field {{controller}} is initialized with the controller
reported by the {{start()}} method.
Inside this thread, some work is performed, and at the end of a certain amount of work,
the {{finishBoot()}} method is invoked. This method calls {{controller.finishBoot()}},
referencing the field that was set in the {{start()}} method.
The problem arises when the service itself is stopped before the boot thread completes.
This causes the {{controller}} field to be nulled out, resulting in an NPE.
I think we need to look at:
* Why are we using a background thread for this?
* Why are we _not_ using the asynchronous startup feature?
I think we must do one of these two things in order to make this code "safe".
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)