anchor.diff:  == A point about performance
   
   Our experiments seem to indicate that Quarkus with virtual threads will scale better than Quarkus blocking (offloading
  -the computation on a pool of platform worker threads) but not as well Quarkus reactive.
  +the computation on a pool of platform worker threads) but not as well as Quarkus reactive.
   The memory consumption especially might be an issue: if your system needs to keep its memory footprint low we would
   advise you stick to using reactive constructs.
   
  
positive.code: 
  === The Netty problem
  For JSON serialization, Netty uses their custom implementation of thread locals, `FastThreadLocal` to store buffers.
  When using virtual threads in quarkus, then number of virtual threads simultaneously living in the service is directly
  related to the incoming traffic.
  It is possible to get hundreds of thousands, if not millions, of them.
  
  
negative.code: 
  According to link:{vthreadjep}[JEP 425] this can happen in two situations:
  
  - when a virtual thread performs a blocking operation inside a `synchronized` block or method
  - when it executes a blocking operation inside a native method or a foreign function
  
  It can be fairly easy to avoid these situations in our own code, but it is hard to verify every dependency we use.
  