Mattermost is migrating the old way to implement caches moving them behind a transparent layer on to of the store and we're looking for contributors to help with that effort. This Help Wanted issue is to migrate the channelByNameCache cache variable in the store/sqlstore/channel_store.go file to the store/localcachelayer.
The expected way to implement it is, go to the store/sqlstore/channel_store.go file get all the code that is related to the cache variable channelByNameCache and move it to the store/localcachelayer
Besides is expected to generate tests mocking the database store, and checking that the cache behavior is the expected one.
Example: mattermost/mattermost-server#13045
If you have any question, you can contact with jesus.espino at https://community.mattermost.com
If you're interested please comment here and come join our "Contributors" community channel on our daily build server, where you can discuss questions with community members and the Mattermost core team. For technical advice or questions, please join our "Developers" community channel.
New contributors please see our Developer's Guide.
May i take this one?
@allenlai18 reopening this issue, as we've had to revert it because it was causing performance issues. Are you still open to working on this or shall I open this up for other contributors?
revert: https://github.com/mattermost/mattermost-server/pull/13329
@ali-farooq0 yes. i am willing to work on this. Do you know why it was causing performance issues?
Great @allenlai18! No unfortunately not. We saw high latency in handling requests when your change was present, it was especially noticeable when switching channels, i.e. it took longer than normal to switch channels. Message me on the mattermost community server (@ali.farooq) and I can help you investigate further :)
@allenlai18 it has relation to the clustering and a "loop" in the invalidation of the cache generated by the new cache handling code and the old "InvalidateCache" usage, which handles the clustering part outside the cache layer. Take a look to the InvalidateCacheForChannel function in the app/web_hub.go. Probably the fix is to re-introduce the cache layer and use the invalidation "blindly" from here, knowing that the cache layer is now taking care of the cache invalidation in the cluster.
Probably you have to take a look of what is exactly doing there, because is "tunning" the cache invalidation message for the INVALIDATE_CHANNEL_BY_NAME when it doesn't have a team id.