Spring-cloud-gateway: Investigate Using BlockHound

[ryanjbaxter]

https://github.com/reactor/BlockHound

Would be nice if there was a spring-boot-starter that we could use so the install call is added to all tests for us. Or maybe some kind of junit runner

cc: @bsideup

[bsideup]

I will talk with Spring Boot team about adding an "auto-install" option when BlockHound is on the classpath.

Also, I think it at least with JUnit 5 it is possible to use the extension mechanism (unfortunately, on per-class basis) to install it.
And, if JUnit 5 will add support for global hooks (aka "before all tests in this JVM"), we could also use it.
/cc @sbrannen

[tony-clarke-amdocs]

How does block hound compare with reactive audit? https://github.com/octo-online/reactive-audit

[bsideup]

@tony-clarke-amdocs
The main difference is that they are using AspectJ for it, and they instrument the call-sites, from user's code, and if there is a nested blocking call inside some JVM's method, they have to detect the top method, not the actual blocking call.

While we're instrumenting the native calls (Like Thread.sleep, not possible with AspectJ) and the original methods (like onSpinWait). It works even if you do some shady things with reflection.

[sbrannen]

Also, I think it at least with JUnit 5 it is possible to use the extension mechanism (unfortunately, on per-class basis) to install it.
And, if JUnit 5 will add support for global hooks (aka "before all tests in this JVM"), we could also use it.

That's actually already possible in JUnit Jupiter. You'd want to write an extension that implements BeforeAllCallback and register that globally. If you want to ensure that the code in the extension only executes once, you'd then need to store a flag in the _root_ ExtensionContext.Store and check its value before executing the code.

The only drawback with such an approach is that globally registered Jupiter extensions are only actually registered if the user explicitly enables their discovery.

[sbrannen]

If users will always use the _Spring TestContext Framework_, another option is to implement a Spring TestExecutionListener and register that automatically.

The benefit of this approach over the Jupiter extension is that the Spring TestExecutionListener will be registered automatically just because of the presence of the containing JAR in the classpath.

The only downside is that there is no global TestContext store. So you'd have to implement your own "do only once" mechanism if necessary.

[bsideup]

FYI there is a PR to add the Spring Boot integration, starter-style (add dependency => see the result, no code changes):
https://github.com/reactor/BlockHound/pull/8