[
https://issues.redhat.com/browse/WFLY-13808?page=com.atlassian.jira.plugi...
]
Brian Stansberry commented on WFLY-13808:
-----------------------------------------
This isn't a bug; it was deliberately done. Accepting requests over the network while
the server is starting results in requests hitting incompletely started resources and
getting random errors.
WFCORE-4291 is a Feature Request to add an ability to turn off this behavior; it sounds
like you are looking for a similar thing.
There is no diff.patch attached.
https://github.com/bstansberry/wildfly-core/tree/WFCORE-4291 is the work I did on it
before I had to move away from it. If you have any suggestions they're welcome. I
expect the issue will be resolved for WildFly 22.
Make HTTP server available during deployment when starting up
-------------------------------------------------------------
Key: WFLY-13808
URL:
https://issues.redhat.com/browse/WFLY-13808
Project: WildFly
Issue Type: Bug
Affects Versions: 20.0.1.Final
Reporter: Alojzij Blatnik
Assignee: Brian Stansberry
Priority: Major
HTTP server isn't available during deployment when Wildfly is starting up. That
behavior is a feature, so that HTTP server is not serving until application isn't
fully deployed. That behavior causes us trouble, because we have EAR with multiple
services in WARs which communicate with each other during deployment phase.
That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this
wasn't intended to behave by default (see start suspended or start normal)
[
https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad...
settings actually make no difference - it starts suspended in both cases (only admin-only
is honored correctly).
I was poking around the source code (see diff.patch) and made small changes in
wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by
desired start mode.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)