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
Even though sections on Message Listener Containers (both imperative and reactive ones) describe resource sharing between multiple listeners, the term multiplexing isn't explicitly called out anywhere and I believe that would be useful thing to have in the docs. Note that class javadocs of both RedisMessageListenerContainer and ReactiveRedisMessageListenerContainer do mention the concept of channel multiplexing.
Warn about pitfalls of ReactiveRedisOperations#listenTo (and other #listenTo variants)
The ReactiveRedisOperations#listenTo API is tempting to use (in comparison with manually setting up ReactiveRedisMessageListenerContainer) however it comes at a cost as it internally creates a new ReactiveRedisMessageListenerContainer instance on each invocation which can lead to excessive consumption of direct memory. This is somewhat related to issues like these:
I believe javadoc of those methods could warn users about resource usage and hint at considering whether multiplexed solution (in form of user managed ReactiveRedisMessageListenerContainer) is a more appropriate choice for their use case.
The text was updated successfully, but these errors were encountered:
mp911de
changed the title
Improve pub-sub related documentation
Refine ReactiveRedisOperations#listenTo and listenTo…Later Javadoc mentioning resource usage
Apr 16, 2024
Channel multiplexing reference
Even though sections on Message Listener Containers (both imperative and reactive ones) describe resource sharing between multiple listeners, the term multiplexing isn't explicitly called out anywhere and I believe that would be useful thing to have in the docs. Note that class javadocs of both
RedisMessageListenerContainer
andReactiveRedisMessageListenerContainer
do mention the concept of channel multiplexing.Warn about pitfalls of
ReactiveRedisOperations#listenTo
(and other#listenTo
variants)The
ReactiveRedisOperations#listenTo
API is tempting to use (in comparison with manually setting upReactiveRedisMessageListenerContainer
) however it comes at a cost as it internally creates a newReactiveRedisMessageListenerContainer
instance on each invocation which can lead to excessive consumption of direct memory. This is somewhat related to issues like these:I believe javadoc of those methods could warn users about resource usage and hint at considering whether multiplexed solution (in form of user managed
ReactiveRedisMessageListenerContainer
) is a more appropriate choice for their use case.The text was updated successfully, but these errors were encountered: