On Friday, November 2, 2018 at 3:56:05 PM UTC-4, Ryan Kennedy wrote: > > On Fri, Nov 2, 2018 at 12:45 PM Steve Kradel <[email protected] > <javascript:>> wrote: > >> Your approach seems like a sound one, and Dropwizard is essentially >> silent on the how/why of background threads, scheduling, etc. >> > > That's not entirely true. Have a look at the "Managed Objects" section of > the documentation, where you'll find reference to the Environment class' > ability to provide managed [Scheduled]ExecutorService instances… >
Neat, never noticed that on Environment before--should save a few lines of code. > > https://www.dropwizard.io/1.3.5/docs/manual/core.html#managed-objects > > >> A possible consideration is that you might prefer DW to fail fast and >> exit on service non-start rather than "run unhealthy" in connection with >> startAsync. >> > > A problem with failing fast and exiting on service non-start comes up with > databases. If the database is down do you want your dropwizard service to > also be down? If it's down there's no option to return a degraded response. > Also your dropwizard service will crash loop even though there's nothing > wrong with the service itself. > A matter of personal taste... I would prefer the service to fail to start if a critical database is unavailable, which is *likely* due to improper configuration rather than transient bad luck, and later enter an unhealthy state if that resource subsequently became unavailable. systemd works pretty well to try to restart Dropwizard with a more sophisticated backoff strategy. Moreover, if one uses the healthcheck URL for load balancer participation, an unhealthy HealthCheck is approximately as good as an offline DropWizard. -- You received this message because you are subscribed to the Google Groups "dropwizard-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
