-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WPB-10308] Use RabbitMQ queues for notifications #4272
[WPB-10308] Use RabbitMQ queues for notifications #4272
Conversation
842158f
to
2974f24
Compare
3321d48
to
861ee10
Compare
services/cannon/src/Cannon/Types.hs
Outdated
stableRabbitmqConn :: Cannon (MVar (Maybe Connection)) | ||
stableRabbitmqConn = Cannon $ asks stableRabbitmqConn_ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a limit on number of channels we can open per connection, so this solution will likely break because of that. I think it might be best to go back to separate connections per client for now because of two reasons:
- I think I misjudged that openning ~20k connections will break rabbitmq, perhaps we just need to run many nodes.
- For this we should probably implement some smart connection pooling, which would take some time and look very different from this, so perhaps we can split this work up like that.
9c4421e
to
0fc2e4e
Compare
It has been set to `true` for a few years now and seems to work well. It is being removed to reduce work for RabbitMq based notifications. Related: #4272 Also: https://wearezeta.atlassian.net/browse/WPB-10308
It has been set to `true` for a few years now and seems to work well. It is being removed to reduce work for RabbitMq based notifications. Related: #4272 Also: https://wearezeta.atlassian.net/browse/WPB-10308
It has been set to `true` for a few years now and seems to work well. It is being removed to reduce work for RabbitMq based notifications. Related: #4272 Also: https://wearezeta.atlassian.net/browse/WPB-10308
3a2c797
to
1f0792d
Compare
b9355f2
to
c87d7b0
Compare
Notifications are now also send via RabbitMQ therefore RabbitMQ is now a required configuration in brig. | ||
Notifications are now also sent via RabbitMQ therefore RabbitMQ is now a required configuration in brig. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not true, brig shouldn't require rabbitmq unless federation is enabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've updated the change log to fix the statement.
unless isAckChanEmpty $ do | ||
putStrLn $ colored yellow $ "The ack chan is not empty after 50ms, some acks may not make it to the server" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this to stay in the test?
timeout 1_000_000 (wait wsThread) >>= \case | ||
Nothing -> | ||
putStrLn $ colored yellow $ "The websocket thread did not close after waiting for 1s" | ||
Just () -> pure () |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this to stay in the test?
rsingleton0 :: forall x. x -> Range 0 1 [x] | ||
rsingleton0 = rcast . rsingleton | ||
|
||
rnil1 :: forall x. Range 0 1 [x] | ||
rnil1 = rcast rnil | ||
|
||
partitionToRange :: These a b -> (Range 0 1 [a], Range 0 1 [b]) | ||
partitionToRange = \case | ||
(This a) -> (rsingleton0 a, rnil1) | ||
(That b) -> (rnil1, rsingleton0 b) | ||
(These a b) -> (rsingleton0 a, rsingleton0 b) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do these belong in Data.Range
?
…ti-mq-classic-queues-for-notifications
…ti-mq-classic-queues-for-notifications
…ti-mq-classic-queues-for-notifications
…ti-mq-classic-queues-for-notifications
…ti-mq-classic-queues-for-notifications
…ti-mq-classic-queues-for-notifications
…ti-mq-classic-queues-for-notifications
This is not to be merged before we make a release 5.6 per https://wearezeta.atlassian.net/browse/WPB-11239. The release happened on Oct 31, 2024: https://github.com/wireapp/wire-server/releases/tag/v2024-10-30
Checklist
changelog.d
error
,undefined
,TODO
, and fix thembrig currently loads a conn into Env and keeps it even after it dies. we should load an MVar into the env and replace broken chans in a top-level loop (like the old delete users queue in brig).(this point was based on a misunderstanding.)