This is in preparation to make the codebase
ready to use Redis. In Redis, iterating all
the keys at once is an expensive operation.
It is recommended to work on batches of keys.
Remove the Len method as it was unused.
I tried to repurpose the Keys method to iterate
on keys rather than returning all keys at once, but
it has other complicacies because the code calls
other cache functions on those keys, so to handle
the LRU cache properly, it becomes slightly more
painful.
For now, we keep it like this and rather collect
all keys from Redis and then return.
https://mattermost.atlassian.net/browse/MM-56987
```release-note
NONE
```
We take a second stab at fixing the issue. Last time,
we were a bit too aggressive in trying to fix a lot of stuff.
I believe changing the cluster event handler had an edge case
somewhere which caused things to fail. Taking a very conservative
approach this time to only fix what is obviously wrong.
Also tested locally in a HA setup.
https://mattermost.atlassian.net/browse/MM-53879
```release-note
NONE
```
Co-authored-by: Mattermost Build <build@mattermost.com>
We randomly used double the number of hubs. A proper test indicates
that using the same number of hubs as CPUs gives better performance.
https://mattermost.atlassian.net/browse/MM-56355
```release-note
NONE
```
* Expose metrics under a source available license
* do not assume Cluster()
* allow metrics if licensed or dev
* temporary vet override
* simplify BULID_TAGS handling
* auto clean old imports.go
* fix license listener
* e2e test metrics & license semantics
* update from enterprise
* switch back to mattermost-govet/v2@new now
* update metrics from upstream
* Update license_spec.js
Co-authored-by: Saturnino Abril <saturnino.abril@gmail.com>
* Update license_spec.js
Co-authored-by: Saturnino Abril <saturnino.abril@gmail.com>
* Update e2e-tests/cypress/tests/integration/channels/enterprise/metrics/license_spec.js
Co-authored-by: Saturnino Abril <saturnino.abril@gmail.com>
* Update e2e-tests/cypress/tests/integration/channels/enterprise/metrics/license_spec.js
* split up specs
* require/delete license earlier in e2e test
* expanded expect to debug failures
* more logging
* Revert "more logging"
This reverts commit 0bc513fd926c07a0c6050f4b4c742e856d8dc435.
* e2e: try deleting license first
* update from enterprise
* toggleMetricsOn to work around license delete
* eslint
* ensure admin before deleting license
* update from enterprise
* updates from enterprise
* fix cypress logging
* temp: log at DEBUG for Cypress tests
---------
Co-authored-by: Saturnino Abril <saturnino.abril@gmail.com>
Co-authored-by: Mattermost Build <build@mattermost.com>
PR https://github.com/mattermost/mattermost/pull/22560
introduced a regression in the case where we had
multiple connections for a single user.
Because if connIndex.Remove was called during the iteration
from connIndex.ForUser, then the slice would be modified
during iteration and if a connection got removed,
then a good connection would move from the last index
to the current index. But since we would be actively
iterating, the last index would be read as nil and we would
never be able to reach the good connection.
We fix this by returning a copy of the original slice
if there are more than one elements in the slice.
https://mattermost.atlassian.net/browse/MM-56260
```release-note
Fix a bug where if there were multiple websocket
connections from a single user, then in case one connection
got removed during a broadcast, there was a possibility
that the other good connection might not get the event.
```
We can have 2 types of threads open at the same time. One from
the thread view, and another from RHS.
We add another variable to distinguish between the 2 states.
In future, if we have the ability for more than 2 threads, then
we would need to track by threadID.
https://mattermost.atlassian.net/browse/MM-56071
```release-note
NONE
```
We also track the channelID of the thread opened.
Additionally on every connection create or re-connect
with an existing queue, we reset the active state to empty
to avoid any edge-cases.
https://mattermost.atlassian.net/browse/MM-56071
```release-note
NONE
```
We create a new websocket action called "presence" which
can contain the active_channel and the active_team for a given
client connection.
On the client side, for every channel or team switch, we send
out this message.
https://mattermost.atlassian.net/browse/MM-56060
```release-note
NONE
```
* MM-54238 Initial implementation
* MM-54238 Move websocket hook into app package
* MM-54238 Add tests for mentions in posted websocket messages
* Fix styling
* Fix other styling
* Idiomatic ID naming for new code
* Fix more styles
* Separate hooks to add mentions and followers
* Improved error handling for invalid types in hooks
* Rename HasChanges to ShouldProcess
* Pass broadcast hooks through hubStart
* Add test helper for asserting json unmarshaling
* Fix missing arguments in tests
* Ensure broadcast hooks are sent across the cluster and not to users
* Ensure tests actually cover following a post
* Fix code broken by merge
* Go vet again...
* Deep copy event before processing it with hooks
* Replace RemoveBroadcastHooks with WithoutBroadcastHooks
* Address feedback
* Add helper to fix type information for hook args
* Wrap WebSocketEvent and simplify BroadcastHook
* Address feedback
* Address feedback
* update session roles from user roles.
* update so user is not retrieved again
* return error, rather than log warning
* Update session.go
Fix bad merge
---------
Co-authored-by: Mattermost Build <build@mattermost.com>
Marshalling a json.RawMessage is not zero overhead. Instead,
it compacts the raw message which starts to have an overhead
at scale.
https://github.com/golang/go/issues/33422
Since we have full control over the message constructed, we
can simply write the byte slice into the network stream.
This gives considerable performance boost.
```
goos: linux
goarch: amd64
pkg: github.com/mattermost/mattermost/server/public/model
cpu: Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
│ old.txt │ new_2.txt │
│ sec/op │ sec/op vs base │
EncodeJSON-8 1640.5n ± 2% 289.6n ± 1% -82.35% (p=0.000 n=10)
│ old.txt │ new_2.txt │
│ B/op │ B/op vs base │
EncodeJSON-8 528.0 ± 0% 503.0 ± 0% -4.73% (p=0.000 n=10)
│ old.txt │ new_2.txt │
│ allocs/op │ allocs/op vs base │
EncodeJSON-8 5.000 ± 0% 4.000 ± 0% -20.00% (p=0.000 n=10)
```
P.S. No concerns over changing the model API because we are
still using 0.x
https://mattermost.atlassian.net/browse/MM-54998
```release-note
Improve websocket event marshalling performance
```
I was looking at the high number of user_updated ws events
and ran across this piece of code. Had a hard time digesting it,
thought of adding a comment for people to understand it more
clearly.
```release-note
NONE
```
There were multiple problems with loading of a license.
1. It was called from inside app/server.go and app/platform/service.go. The first one wasn't really needed anymore, so we remove it.
2. To make loading of a license work across a cluster, the license load action was attached along with the `InvalidateAllCachesSkipSend` method. But the problem with that was that it would even get called in the caller node as well, putting it in a recursive loop.
```
LoadLicense -> SaveLicense -> InvalidateAllCaches -> InvalidateAllCachesSkipSend -> LoadLicense
```
To fix this, we create a dedicated loadLicense cluster event and move it away from the `InvalidateAllCachesSkipSend` method. And then from the caller side, we just trigger this action.
3. We also remove the first call to check license expiration which would load the license again. This is unnecessary because if the license is expired, server wouldn't start at all.
While here, we also make some other improvements like removing unnecessary goroutine spawning while publishing websocket events. They are already handled asynchronously, so there is no need
to create a goroutine for that.
We also remove
```
ps.ReloadConfig()
ps.InvalidateAllCaches()
```
from requestTrialLicense as they are already called from inside `*PlatformService.SaveLicense`.
And lastly, we remove the `*model.AppError` return from `*PlatformService.InvalidateAllCaches` because there was nothing to return at all.
https://mattermost.atlassian.net/browse/MM-53879
```release-note
Fix several issues with loading of a license
```
After reliable websockets were introduced,
we would keep pushing to a webConn even after
the client has disconnected. This would lead
to the websocket.slow/full and eventually
the disconnect messages which unnecessarily
confuse the admin.
We don't log them if the connection is inactive.
We use the active field and convert it to an atomic
to use more widely.
```release-note
NONE
```
* Mark category as read
* Fix lint and test
* Fix tests
* Fix test and remove wrong aria
* Address server issues and add mark as read for unreads
* Missing changes
* Fix tests
* fix tests
* Add confirmation popup to mark as read category
* Always use viewMultipleChannels and other fixes
* Remove unneeded code
* Fix test
* Address feedback
* Address feedback
* Fix tests
* Fix test
* Fix tests
* Update aria-haspopup depending on the number of channels to mark as viewed
---------
Co-authored-by: Mattermost Build <build@mattermost.com>
If the store fails to initialize (e.g. run a migration), it would `log.Fatal` and then `os.Exit`. Unfortunately, this trips up `TestMain`, which happily keeps running tests, now guaranteed to fail.
Avoid this by instead returning an error from the store initialization, handling appropriately at the layer above.
Sometimes a broad distinction of just a channelID or a userID
is not enough to efficiently send a websocket event to users.
In several cases, depending on the user and channel, we might
need to modify the message. Therefore, we introduce the
concept of a channel hook that will get executed if the scope
is set to a channel. This hook can be populated at the app layer
to perform any application specific logic to the event.
Care must be taken to avoid race conditions as the passed event
is not deep copied. It is left to the user to treat it carefully.
For this issue, the main problem was that since we don't know
which users have permissions to which channels, we had to go through
_all_ members of a channel to figure that out. This was redundant
since a large portion of those users might not even be connected
at that time.
We solve this with the channel hook where we push this check
to be performed later while actually sending the event. This
reduces the computation to be done only for _connected_ users
rather than _all_ users of a channel.
The next iteration of this should be to use websocket subscriptions
to monitor exactly which users are on that channel to even
trim down that list. That is a larger initiative to be taken later.
Tested locally with a channel of 50 users. Here are rough results:
```
With PR:
patchPost 97ms
createPost 90ms
Master:
patchPost 306ms
createPost - 298ms
```
https://mattermost.atlassian.net/browse/MM-42810
```release-note
Improve performance while sending messages
with permalinks to channels with large number of users.
```
Having cache layer as part of the store call
Prometheus metrics can be somewhat misleading
because cache-backed methods can have very high
volume and yet not cause any load on the DB at all.
However, if the admin is not aware which calls
are cache-backed and which are not, then
it can be hard to understand why a store call
of high volume isn't causing any stress on the DB at all.
Therefore, for simplicity we reorder the layers
such that cache layer is handled outside the timer layer.
We already have cache related metrics like hit/miss
which can be used to monitor cache usage.
https://mattermost.atlassian.net/browse/MM-53058
```release-note
NONE
```
Co-authored-by: Mattermost Build <build@mattermost.com>
