Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This is also covered diagramatically in the attached PDF

Notes

  • Alternate Exchanges: Although the alternate-exchange is listed as an attribute of the Queue and Exchange above, it probably shouldnt be: the 'attribute' for any given Queue or Exchange will simply be the name of its alternate exchange, but this is not somethign we would want to store on the Queue or Exchange in question since we want to be able to rename Exchanges. Additionally, storing the alternate exchange on an object could make recovery difficult as a specific recovery order would be required which may ultimately be impossible to achieve (e.g. there may be exchange-exchange alternate loops). Instead of storing the alternate exchange as an attribute directly, what we really want to do is be able to define a relationship between a given Queue/Exchange and its alternate (not unlike the parent-child relationships ConfiguredObjects will already have). For this we probably want to seperately store an 'alternate' relationship in the store, relating a given Quue/Exchange with its alternate Exchange and which can be applied after creating the ConfiguredObjects during recovery.
  • Queues in XML configuration: When doing upgrades (/before we get rid of the configuration file), it is possible there will be queues definied in the configuration file (rather than the store) which have messages. IDs will need made for these queues to allow matching id-referenced message data in the store. We will probably need to use something like a UUID generated from the queue name as the ID, eg using nameUUIDFromBytes(byte[] name).
  • User vs Store configuration: The current intension is for the storage of configuration to be through JSON, however this is also the likely avenue to be taken for users being able to extract and replay their configuration in future through the management interfaces. There is a key difference in that user-facing configuration is still likely to use names for Queue/Exchange/VirtualHost etc configuration, whereas the store is going to mainly refer to objects by their ID to allow renaming etc.