We're using this library in production for sending non-critical signals to users. Over time we notice a degradation in performance and an increase in memory consumption until at some point we get an application restart with an OOM message.
We suspect the problem is with RewindableMessageGrain. As its associated to Clients (which come and go) and persists messages in state, State however is not cleared when the client goes away and will always stay persisted.
2 relatively easy wins would be to never persist when MaxMessageRewind is configured as 0 and to make persistence optional. A proper fix would involve observing the client and clearing state when the client goes away.
We're using MemoryStorage which exacerbates the issue. If we were to use a proper storage provider then we would expect to see an ever increasing db size.
I'm happy to contribute here.
We're using this library in production for sending non-critical signals to users. Over time we notice a degradation in performance and an increase in memory consumption until at some point we get an application restart with an OOM message.
We suspect the problem is with
RewindableMessageGrain. As its associated to Clients (which come and go) and persists messages in state, State however is not cleared when the client goes away and will always stay persisted.2 relatively easy wins would be to never persist when
MaxMessageRewindis configured as 0 and to make persistence optional. A proper fix would involve observing the client and clearing state when the client goes away.We're using MemoryStorage which exacerbates the issue. If we were to use a proper storage provider then we would expect to see an ever increasing db size.
I'm happy to contribute here.