Project

General

Profile

Mon - Prioritize messages

Summary

Some messages are more important to finish quickly than others. Some other messages take less time than others. Lots of client messages, in a big enough cluster, can and will hinder progress of another messages (some of them even critical) simply due to the amount of messages to be handled.
The monitors should thus prioritize their own, mission-critical messages over any other conceivable message. The rationale should be simple: if the client waits a small fraction of a second longer, it should be okay; if the monitor waits to handle a thousand fractions of second to handle a critical message (such as a paxos lease extension), it may trigger a timeout and cause unnecessary havoc.

Owners

  • Joao Eduardo Luis (Inktank)
  • Name (Affiliation)
  • Name

Interested Parties

  • Name (Affiliation)
  • Name (Affiliation)
  • Name

Current Status

There's no support for this on the monitor. From a quick look on ceph's tree, it looks like the messenger and DispatchQueue already understand Message priority, and one can use Message::set_priority() to define a message's priority.
This blueprint can be addressed on its own, but it would be preferable if it were addressed after addressing another submitted blueprint for Giant: mon: Independently dispatch non-conflicting messages

Detailed Description

Once defined which messages should have higher priority when handled by the monitor, this task should be a matter of sending messages from the monitors to another monitors setting a higher priority on some of the messages.

For instance, with regard to message priority:

MMonPaxos > MMonElection > MMonGetMap > MMonProbe > MMonQuorumService > PaxosServiceMessage > MMonSync

Work items

Coding tasks

  1. Assess priorities
  2. Add monitor interface to appropriately send messages with an appropriate priority (instead of having to do it manually for each single message)
  3. Unit-tests
    • parse through logs (yuck!)
    • add a workunit that sends a bunch of messages with different priorities and expects replies in a priority-based order (this needs some thought!)

Documentation tasks

  1. doc: document message priorities