Some of the Jetty graceful shutdown tests were flaky due to the way
in which Jetty behaves when it is stopped.
Stopping the Jetty web server interrupts the thread that's handling
the active request. This initiates a race between the request-handling
thread which will decrement the number of active requests and the
main thread which expects an active request to cause the shutdown
result to be REQUESTS_ACTIVE. The test passes when the main thread
wins and fails as a request is active which it's checked. When the
request-handling thread wins the test fails as the count of active
requests has been deprecated before it is checked.
The blocking servlet that's used to stall a request and keep it
active needs to be updated to ignore the thread being interrupted
and continue waiting. This will ensure that a request remains active
until the main thread has checked the active request count and
determine the result of the shutdown.
Closes gh-27464
Previously, database initializers were detected and were configured
with dependencies based on their detection order. For example, if
detectors a, b, and c detected initializers a1, b1, b2, and c1,
c1 would depend on b2, b2 on b1, and b1 on a1:
------ ------ ------ ------
| c1 | --> | b2 | --> | b1 | --> | a1 |
------ ------ ------ ------
This could cause a dependency cycle in certain situations, for
example because the user had already configured b1 to depend on b2.
This commit reduces the risk of a cycle being created by batching
the initializers by their detector, with dependencies being
configured between each batch rather than between every initializer.
In the example above, this results in c1 depending on b1 and b2,
and b1 and b2 depending on a1:
------
------ | b1 | ------
| c1 | --> | | --> | a1 |
------ | b2 | ------
------
As b1 and b2 were detected by the same detector, no dependency
between those initializers is defined.
Closes gh-27131
Andy Wilkinson
Phillip Webb
Spring Buildmaster
saraswathy-krish
izeye
dreis2211