[
https://issues.jboss.org/browse/WFCORE-4291?page=com.atlassian.jira.plugi...
]
Brian Stansberry commented on WFCORE-4291:
------------------------------------------
[~bmaxwell] My expectation is this will re-introduce the same problems that the
'graceful startup' fixed. I regard this as a request to let users deal with those
problems. which, TBH, I don't mind doing; people have the right to decide whether that
is acceptable. And, with mod_cluster it is possible to prevent external requests while
stuff having app A invoke app B over localhost:8080, or any IP on which the server is
directly listening.
If there's an elegant way to limit requests and make an HTTP-equivalent to a local EJB
call, great. But I suspect attempts at that will be buggy or hard to maintain or lead to
requests for more exceptions. And simply letting the request get through undertow
subsystem checks doesn't mean other parts of the server won't react negatively;
see my "Pros of a)" section in the wildfly-dev thread. So, I'm not really
inclined to try and solve the race problems.
Restore legacy (not "graceful") startup mode
--------------------------------------------
Key: WFCORE-4291
URL:
https://issues.jboss.org/browse/WFCORE-4291
Project: WildFly Core
Issue Type: Feature Request
Components: Management
Reporter: Vladimir Grabarchuk
Assignee: Brian Stansberry
Priority: Major
Please allow a configurable legacy startup mode which was the default before WF11, when
components can service HTTP requests as soon as they are deployed, not when the container
deploys all components.
The use case for this is the following: there is a configuration service component upon
which other components depend for configuration data, requested and served via a HTTP
request. With the new "graceful startup" this scenario no longer seems possible,
as it results in read timeouts, mis-configured artifacts, and failed deployments
altogether.
If generally feasible, another value of the *--start-mode=legacy* seems appropriate to
accommodate the original (legacy) behavior.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)