You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is meant to coordinate tasks required for context-propagation library integration and propagation of ThreadLocal values in Reactor to be in a desired state.
More details to come.
context-propagation: Improve ThreadLocalAccessor contract to allow entering an empty scope and reverting previously stacked values
context-propagation: Allow Reactor's use case - restoring ThreadLocal values by removing existing values when Context object doesn't have a mapping for a key -> replacing the custom implementation within reactor-core
reactor-core + reactor-netty: Allow distinguishing Flux and Mono that is guaranteed to have ThreadLocal values present in case of automatic context propagation from custom implementations that can switch threads (reactor-netty case when execution continues after event on the event loop); allow custom implementations to use a propagating Subscriber.
reactor-core: Remove the queue wrapper hook from automatic context propagation - it can be a source of ThreadLocal leaks, while it does not provide value in the current design. [depends on the above to be sure source signals have ThreadLocal values restored]
reactor-core: In 3.7 remove automatic ThreadLocal restoration in handle/tap operators and provide means to wrap a user-provided function to have ThreadLocals present. Currently there is no opt-out from the TL restoration in these operators when the context-propagation library is on the classpath; this might be undesired when users want to explicitly have TLs present in only particular places that they control.
Consider using properties to drive this feature: in 3.6 have the property of handle/tap restoration set to true, while in 3.7 have it as false
spring-boot: config knob for automatic context propagation
reactor-core: Research means to optimise the amount of ThreadLocal accesses (e.g. distinguish custom Mono that is not async and not restore ThreadLocals by a wrapping Subscriber)
The text was updated successfully, but these errors were encountered:
This issue is meant to coordinate tasks required for context-propagation library integration and propagation of
ThreadLocal
values in Reactor to be in a desired state.More details to come.
ThreadLocalAccessor
contract to allow entering an empty scope and reverting previously stacked valuesThreadLocal
values by removing existing values whenContext
object doesn't have a mapping for a key -> replacing the custom implementation within reactor-coreblock()
Flux
andMono
that is guaranteed to haveThreadLocal
values present in case of automatic context propagation from custom implementations that can switch threads (reactor-netty case when execution continues after event on the event loop); allow custom implementations to use a propagatingSubscriber
.ThreadLocal
leaks, while it does not provide value in the current design. [depends on the above to be sure source signals have ThreadLocal values restored]ThreadLocal
restoration in handle/tap operators and provide means to wrap a user-provided function to haveThreadLocal
s present. Currently there is no opt-out from the TL restoration in these operators when the context-propagation library is on the classpath; this might be undesired when users want to explicitly have TLs present in only particular places that they control.The text was updated successfully, but these errors were encountered: