Vert.x’s standard verticles require non-blocking code to work optimally. A watchdog will warn you (extremely insistently) if anything does block for an excessive period. However, if you’re just trying to run an interactive debugger [1] then this can become extremely annoying as your console is flooded with io.vertx.core.impl.BlockedThreadChecker exceptions that look something like this:
What’s the cause?
The exceptions occur because the interactive debugger repeatedly halts the event loop thread while you use it: browsing around, poking at variables, stepping through your program, etc. The length of time it takes to execute the event being debugged will be drastically longer than normal; hence the watchdog starts barking.
Mercifully there’s a simple solution, which involves setting blockedThreadCheckInterval to a sufficiently long time. [2]
|
The following should only be used for debugging purposes!
If your production code is throwing BlockedThreadChecker exceptions, then you have a problem you need to fix.
|
Workarounds
Via System Properties
Whether you’re using Launcher (which has supplanted Starter) or the Vert.x CLI, pass the following VM argument:
-Dvertx.options.blockedThreadCheckInterval=200000000 (1)| 1 | Some sufficiently large integer (milliseconds). |
All IDEs also support setting system properties in some fashion. I’ve briefly outlined Eclipse and IntelliJ below, but the procedure should be similar for others.
Eclipse Debug Configurations → Arguments → VM Arguments
IntelliJ Edit Configurations → Select Application → Configuration → VM Options
| Setting blockedThreadCheckInterval via system properties is likely the best approach; avoiding debug-specific behaviour leaking into your code. |
Directly in VertxOptions
If you are not using the CLI or Launcher, or for some reason wish to avoid using system properties, then you can simply set the interval in VertxOptions directly.
VertxOptions vxOptions = new VertxOptions()
.setblockedThreadCheckInterval(200000000); (1)
Vertx myVertx = Vertx.vertx(vxOptions); (2)| 1 | Set interval in VertxOptions. |
| 2 | Pass options to Vertx.vertx() factory. |
Caveats & Conclusion
It’s worth remembering that by halting executing thread(s) in the debugger you may not encounter timing-related issues you otherwise would. So, it is wise to ensure you aren’t altering blockedThreadCheckInterval unless you really need to.
Needless to say, seeing BlockedThreadChecker warnings in production is a symptom of pathological code behaviour, indicating that the event loop is being blocked for excessive periods; you should fix it rather than altering timeouts.
Finally, you should normally prefer the system properties approach so that you can isolate this change to your debugging profiles only.