Page MenuHomePhabricator

[Tunnelbroker] publish messages from DDB to RabbitMQ when client connects
ClosedPublic

Authored by kamil on Oct 24 2023, 9:45 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Oct 2, 1:08 PM
Unknown Object (File)
Wed, Oct 2, 1:08 PM
Unknown Object (File)
Wed, Oct 2, 6:01 AM
Unknown Object (File)
Tue, Sep 24, 2:57 AM
Unknown Object (File)
Sat, Sep 7, 8:08 AM
Unknown Object (File)
Aug 29 2024, 2:35 AM
Unknown Object (File)
Aug 24 2024, 3:38 PM
Unknown Object (File)
Aug 15 2024, 4:50 AM
Subscribers

Details

Summary

This code enqueues messages in RabbitMQ, instead of directly flushing to the client.

Why we need this:

  1. In the next diffs I'll introduce code responsible for confirming message, the message is sent here, but confirmation is received here - handling third place, where we also need to confirm messages (directly from DDB) could complicate the code.
  2. This allows us to maintain the proper order of messages - messages from DDB that have higher priority are delivered first.
  3. This gracefully handles the case where different brokers send messages to the device while sending persisted messages, in the previous version of the code that case could change messages order.

Depends on D9570

Test Plan
  1. Run tests Tunnelbroker tests (most important are tunnelbroker_persist_tests and test_messages_order )
  2. Make sure priority works, do the following:
    • declare queue
    • send messages A, and B with priority 10
    • send message C with priority 1
    • send message D with priority 10
    • create consumer
    • consume messages - the order should be A, B, D, C

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kamil held this revision as a draft.
kamil published this revision for review.Oct 24 2023, 11:18 AM
bartek added inline comments.
services/tunnelbroker/src/websockets/session.rs
120–123 ↗(On Diff #32340)

Initially, I had mixed feelings about this, but it makes sense in the context of code logic. Just no messages will be published.
I need to prioritize services' monitoring to detect such cases quickly.

138–140 ↗(On Diff #32340)

If deletion fails, will the message be sent again next time publish_persisted_messages is called? Anyway it's client's responsibility to dedupe such messages

This revision is now accepted and ready to land.Oct 25 2023, 3:33 AM
services/tunnelbroker/src/websockets/session.rs
138–140 ↗(On Diff #32340)

If deletion fails, will the message be sent again next time publish_persisted_messages is called? Anyway it's client's responsibility to dedupe such messages

Yes, I don't think there is anything we can do to improve it on Tunnelbroker's side