Couchbase java diver by default provides threading pools that are quite interesting. Why "are" instead of "is"? Because there are two of them - one for I/O operations and another one for computations.
Now we have full control over creating each thread in our application. Why should we struggle with that?
There is multiple good reasons to control that, but this is only one way to make correlationId (aka trace and span in spring sleuth). We have to provide our trace and span context (for example via TraceContextHolder) from thread managed by spring mvc to thread provided by our scheduler.
Lets focus first on I/O operations.
There is a special I/O Thread Pool provided by couchbase driver to deal with io intensive operations. You can define only pool size - there is small hint in documentation - try to set this value to number of processors in your systems. This default value is connected with a way that IO operations are performed (non blocking netty). So far so good - very easy configuration: only one int parameter to set with reasonable default.
There is no option in API to provide IO Thread Pool/Scheduler/whatever to manually tune it up.
We can do a lot more with Computational Thread Pool. First of all we can use default CTP with manually set computationPoolSize. This thread pool is produced by slightly modified default RX Scheduler (which provides custom names like cb-computational-%d).
There is more interesting thing we can do with CTP - we can provide our own RX Scheduler. We can do this like this:
https://gist.github.com/piotrpietrzak/9c6f11f8842184eae718
Now we have full control over creating each thread in our application. Why should we struggle with that?
There is multiple good reasons to control that, but this is only one way to make correlationId (aka trace and span in spring sleuth). We have to provide our trace and span context (for example via TraceContextHolder) from thread managed by spring mvc to thread provided by our scheduler.
