If the deadQueue was full, we would be incorrectly sending
the wrong index for dqPtr. Fixed that and added a test case.
https://mattermost.atlassian.net/browse/MM-63304
```release-note
NONE
```
* MM-61947 Run DND expiry job more often and round expiry time to match interval
* Move comment to make it godoc-compatible
* Change truncateDNDEndTime to work with seconds
---------
Co-authored-by: Mattermost Build <build@mattermost.com>
When Channel iteration mode is enabled, we need to ensure that
channel scoped events do not fall through to the connIndex.All()
condition. This is possible because there are multiple hubs
in a given system. So a single event will flow through all of them
and in some hubs, a channel scoped event might not have any connections.
In that case, we need to stop processing further.
https://mattermost.atlassian.net/browse/MM-62960
```release-note
NONE
```
When we added iteration by channelID, this was a known tradeoff during that.
However, it has been observed that the regular connection removal function
creates considerable blocking of the processing loop, leading to high
CPU usage and API latencies.
To fix this, we add a reverse mapping of channelIDs to connections
and their positions in the slice. This helps us to remove the connection
from the slice without iteration.
Unfortunately, this still needs to iterate through all channelIDs
during invalidation of the channel member cache. However, the user
cache invalidation is not a regular activity. So it should be an acceptable
tradeoff to make.
https://mattermost.atlassian.net/browse/MM-62960
```release-note
A new config knob ServiceSettings.EnableWebHubChannelIteration which allows a user to control the performance of websocket broadcasting. By default, this setting is turned off. If it is turned on, it improves the websocket broadcasting performance at the expense of poor performance when users join/leave a channel. It is not recommended to turn it on unless you have atleast 200,000 concurrent users actively using MM.
```
Co-authored-by: Mattermost Build <build@mattermost.com>
We were redirecting any logging happening via the Go standard logger
to our own mlog instance. The issue is that all those logs were happening
at LvlStdLog level which is higher than LvlDebug.
LvlStdLog is at 10, and LvlDebug is at 5. So unless a customer
sets the log level specifically to "stdlog" or sets up advanced
logging to specifically log for that level, no standard logs will
ever get logged.
We fix this by logging it at warn level. The reason for warn
is that mostly external libraries use this facility to log
out-of-band errors that could not be returned using standard
error returns.
I saw another plugin error which was logged similarly. This
was never surfaced before due to this bug.
https://mattermost.atlassian.net/browse/MM-62926
```release-note
NONE
```
We do a cluster request to get the active and dead queues
from other nodes in the cluster to sync any missing
information.
We check the dead queue in the other nodes to see
if there's been any message loss or not. Accordingly,
we send just the active queue or both active and dead queues.
There's still an edge case that is left out where
a client could have potentially connected and reconnected
to multiple nodes leaving multiple active queues
in multiple nodes. We don't handle this scenario
because then potentially we need to create
a slice of sendQueueSize * number_of_nodes. And then
this can happen again, leading to an infinite increase
in sendQueueSize.
We leave this edge-case to Redis, acknowledging
a limitation in our architecture.
In this PR, when there's no message loss, we just
take the active queue from the last node it connected
to.
And if there's message loss where the client's
seqNum is within the last node's dead queue, we also
handle that.
But if there's severe message loss where the client's
seqNum falls within the dead queue of another node, then
we just send the data from that node to reconstruct the
data as much as possible. It could be possible to set
a new connection ID in this case, but this involves
more data transfer always from all nodes and recomputing
the state in the requestor node.
https://mattermost.atlassian.net/browse/MM-61904
```release-note
NONE
```
Co-authored-by: Mattermost Build <build@mattermost.com>
* MM-62378: Initialize status and session cache before loading license
ps.LoadLicense could end up calling InvalidateAllCaches. Therefore,
we need to intialize those caches before calling LoadLicense
to prevent a panic from happening.
While here, we also remove some unused code.
https://mattermost.atlassian.net/browse/MM-62378
```release-note
NONE
```
* fix lint errors
```release-note
NONE
```
* fix test
```release-note
NONE
```
Drop the legacy `X` suffix from `GetMasterX` and `GetReplicaX`. The
presence of the suffix suggests there's a `non-X` version: but in fact
we migrated these away a long time ago, so remove the cognitive
overhead.
As an aside, this additionally helps avoid trip up LLMs that interpret
this as "something to fix".
We were incorrectly not broadcasting status cache updates
inspite of that being an LRU cache.
We were also not doing it for profilesInChannel cache.
Now we fix it by properly checking the invalidationEvent
which is something local to the cache itself rather
than the cache provider.
https://mattermost.atlassian.net/browse/MM-62077
```release-note
NONE
```
This introduces a new entry in the `Main Menu -> About` modal with the hostname of the currently connected websocket. This will be used to aid debugging issues in clustered environments by showing which node in the cluster is servicing requests for a particular websocket.
This information is only visible in self-managed instances. It will not be visible on cloud instances.
We don't clear the Redis cache for every test.
This can cause issues because the cache is shared
across test. We fix that with this PR.
```release-note
NONE
```
And re-order the server initialization (AGAIN).
For the nth time, we found several bugs in the initialization
process.
1. filestore.NewExportFileBackend and filestore.NewFileBackend
depended on license, but the license wasn't even loaded until
later!
2. The `ps.sqlStore.UpdateLicense` call also didn't work
because the license wouldn't get loaded. It only accidentally
worked because of `ps.AddLicenseListener` which would update
the license later on. We remove that.
Ideally, we would have loaded the license first and then
checked for redis client, but it's very difficult to do that.
Reasons are explained in the code comment.
So we just wait until the license is loaded, and simply throw an
error later.
https://mattermost.atlassian.net/browse/MM-61229
```release-note
NONE
```
---------
Co-authored-by: Mattermost Build <build@mattermost.com>
The Store variable was written to _after_ the server
started which was causing the race.
We simply move it to before we start the server.
While we are here, we fix yet another race condition
which was unrelated, but doing it in one sweep. This
was related to the user props access. When a user is updated,
there was 3 ws events that get sent out, 2 were deep-copied
whereas 1 was not. This led to race condition in postgres
binary-param mode where we were trying to set the user props.
https://mattermost.atlassian.net/browse/MM-61700
Tests at very high scale indicates that the iteration
of all connections during websocket broadcast starts
to become a bottleneck.
To optimize this, we move the channelMember cache from
inside web_conn.go to the hubConnectionIndex.
This involves adding a new map keyed by the channelID
and containing all webConns where the user is a member
of that channel. Subsequently, a new method needed to
be added to invalidate the cache which previously
used to happen in web_conn.
And as a last step, we remove the cache from web_conn
to reduce SQL queries to the DB.
https://mattermost.atlassian.net/browse/MM-61130
```release-note
NONE
```
This test actually tested that there is no race
_if_ session pooling is there. But there is no session pooling
any more so this test is irrelevant.
https://mattermost.atlassian.net/browse/MM-61225
```release-note
NONE
```
This originated from https://github.com/mattermost/mattermost/issues/15249.
However, the original idea was discarded https://github.com/mattermost/mattermost/issues/15249#issuecomment-709713065
as being too complicated to implement. Then I had another
idea to implement it just for session objects.
My thinking was that since every single request allocates a new
session struct, it would be good to use a sync.Pool for that.
However, 4 years later, now we know that the primary bottleneck
in app performance comes from websocket event marshalling.
Therefore, while it would be good to do this, it is difficult
to do it correctly (as shown by the numerous racy tests).
Hence, reverting this.
```release-note
NONE
```
We sprinkle a bit of generic magic to refactor a lot
of duplicate code.
To avoid exposing unnecessary code, I duplicated the function
twice. But let me know if you have strong opinions about this.
https://mattermost.atlassian.net/browse/MM-60171
```release-note
NONE
```
---------
Co-authored-by: Mattermost Build <build@mattermost.com>
On user login, we were aggressively clearing the channel member
cache when it wasn't necessary. There is no channel membership
info that is changing on a user login.
Additionally, we fix some more issues with pointer passing
to the cache. It's a known problem that our value passing
style isn't consistent when we fetch items from cache.
Sometimes we pass pointer-to-pointer, sometimes it's just a
pointer. This is also the reason for https://github.com/mattermost/mattermost/pull/27830.
We fix 2 such cases where we passed pointer-to-pointer
but didn't handle the special case inside the cache.
This time, we actually fix it in the app layer instead
of the cache layer and also add a test for good measure.
https://mattermost.atlassian.net/browse/MM-60480
```release-note
NONE
```
Co-authored-by: Mattermost Build <build@mattermost.com>
