anchor.diff:  
   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 `blockedThreadCheckPeriod` to a sufficiently long time. footnote:[Had this as maxEventLoopExecuteTime in a previous revision of the blog, but this doesn't work consistently.]
  +Mercifully there's a simple solution, which involves setting `blockedThreadCheckInterval` to a sufficiently long time. footnote:[Had this as maxEventLoopExecuteTime in a previous revision of the blog, but this doesn't work consistently.]
   
   [IMPORTANT]
   .The following should only be used for debugging purposes!
  
positive.code: 
  == 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 `blockedThreadCheckPeriod` 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.
  
  
negative.code: Whether you're using {vertx-launcher}[Launcher] (which has supplanted Starter) or the Vert.x CLI, pass the following VM argument:
  
  ```java
  -Dvertx.options.blockedThreadCheckInterval=200000000 // <1>
  ```
  <1> Some sufficiently large integer (milliseconds).
  
  