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>
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.
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 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
```
* [MM-58355] Send invalidate cache message across the cluster so that websocket connections on other instances are invalidated correctly
* Add suggestion to clear the session cache on the local node as well
* Force read from master DB when gettting channel members for websocket to avoid any DB sync issues
* PR feedback
* Missed generated files
We were setting the user status to offline without
checking for connections on other nodes in a cluster.
Now we implement a request-response mechanism for the whole
cluster and we check that before setting a user to offline.
https://mattermost.atlassian.net/browse/MM-57153
```release-note
Fix a bug where the user status would incorrectly be set to offline
without checking for connections in other nodes in an HA cluster.
```
Co-authored-by: Ibrahim Serdar Acikgoz <serdaracikgoz86@gmail.com>
Co-authored-by: Mattermost Build <build@mattermost.com>
Co-authored-by: Ben Schumacher <ben.schumacher@mattermost.com>
* Explicitly have the client tell the server when it should expect an ACK
* Don't count missing profile errors for your own posts, added comment
* Fix test
* Make postedAck a parameter in WebSocketClient
* Snapshot fixes
---------
Co-authored-by: Mattermost Build <build@mattermost.com>
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
```
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
```
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>
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.
```
It was a good decision in hindsight to keep the public module as 0.x
because this would have been a breaking change again.
https://mattermost.atlassian.net/browse/MM-53032
```release-note
Changed the Go module path from github.com/mattermost/mattermost-server/server/v8 to github.com/mattermost/mattermost/server/v8.
For the public facing module, it's path is also changed from github.com/mattermost/mattermost-server/server/public to github.com/mattermost/mattermost/server/public
```
* platform/web_conn: fix a possible data race issue
* reflect review comments
---------
Co-authored-by: Ibrahim Serdar Acikgoz <ibrahim@ibrahims-mac.local>
Co-authored-by: Mattermost Build <build@mattermost.com>
We log warnings whenever our websocket buffer sizes exceed
certain thresholds. The problem with that is, when this happens,
the logs are completely spammed with these lines
making it annoying for the customer.
To improve the situation, we use a timer that only gets reset
every minute.
https://mattermost.atlassian.net/browse/MM-51700
```release-note
NONE
```
