[wildfly-dev] Allowing disabling of 'graceful startup'

Scott Marlow smarlow at redhat.com
Wed Aug 7 18:26:12 EDT 2019



On 7/29/19 1:17 PM, Brian Stansberry wrote:
> tl;dr question is how to disable 'graceful startup'. Skip the background 
> if you know what that means. :)
> 
> Background
> 
> 
> Back in 2016 when we added the feature to allow a server to be started 
> in 'suspended' state[1], that work also included a fix for the 
> longstanding bug whereby during server start endpoints would be started 
> and accepting external requests before all the services (e.g. from 
> deployments) would be started. The result would be requests could reach 
> the still-starting server and would fail, e.g. HTTP requests might get a 
> 404 or some variety of 500.
> 
> I refer to this bug fix as 'graceful startup'.
> 
> Since the fix was introduced we've gotten quite a number of requests to 
> be able to turn off that bug fix, e.g. WFCORE-4291.[2] The scenario is 
> users deploy two apps, where app A during start makes an *external* 
> request to app B and won't complete start until that request is handled. 
> And, the users deploy both A and B in the same server. The server won't 
> allow the external request during boot, so A won't complete start and 
> thus the overall server start hangs until timeout.
> 
> I consider this kind of deployment pattern to be a bit of an 
> anti-pattern, but we've gotten enough request to allow it that I'm 
> looking into how to satisfy it. Also, at least for HTTP requests, 
> mod_cluster can be used to prevent external requests reaching a server 
> before things are ready, so if the 'internal' requests were not sent 
> through the LB there's at least one 'error free' use case for this.
> 
> 
> The Question
> 
> Question is whether to
> 
> a) have an overall config switch to disable graceful startup across the 
> board (e.g. a new value for the --start-mode cmd line param passed to 
> standalone.sh)
> 
> b) have a subsystem specific setting in the undertow subsystem that 
> configures undertow to allow requests in during boot.

Would either of the following cover more cases?

c) have an overall config switch to specify a list of applications that 
should allow requests during boot, which would be used to specify a set 
of applications that need to be available, in order for the graceful 
starting up applications to subsequently become available.

d) Similar to (c), except allow applications to specify other 
applications that must be fully started, before them (e.g. A depends on 
B, so B is first allowed to fully start in the first graceful completion 
pass).

Scott


More information about the wildfly-dev mailing list