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
Hello,
I've been testing Watermill with one of our services and I've noticed constant memory increase while using it (slight, but still there). After checking code in my service, I went to check Watermill implementation and I might have find an issue with implementation of GoChannel pub/sub.
Explanation
When we create new Sub, new data will be added to subscribers map and subscribersByTopicLock map.
After context is done or pub/sub is closing, subscriber will be removed from subscribers map.
But, only data from that subscriber will be removed from map. If that is last subscriber of that topic, data from g.subsribers[topic], and g.subscribersByTopicLock[topic] won't be removed.
That leads to believe that if we generate new topics over time, maps will still contain data for topics which are no longer used.
Hello,
I've been testing Watermill with one of our services and I've noticed constant memory increase while using it (slight, but still there). After checking code in my service, I went to check Watermill implementation and I might have find an issue with implementation of GoChannel pub/sub.
Explanation
When we create new Sub, new data will be added to subscribers map and subscribersByTopicLock map.
After context is done or pub/sub is closing, subscriber will be removed from subscribers map.
But, only data from that subscriber will be removed from map. If that is last subscriber of that topic, data from
g.subsribers[topic]
, andg.subscribersByTopicLock[topic]
won't be removed.That leads to believe that if we generate new topics over time, maps will still contain data for topics which are no longer used.
Proof
I've added following logs in pubSub.go L214
And I've run simple test which creates 100 new subscribers with different topics, and closes them after 500ms
Final debug logs produced from this test:
As you can see, size of
subscriber
andsubscribersByTopicLock
map remained 100 even though all subscribers are closed.The text was updated successfully, but these errors were encountered: