Changes between Initial Version and Version 1 of Ticket #1788


Ignore:


Timestamp:
Mar 2, 2013, 5:28:36 PM (6 years ago)
Author:
dustin
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #1788

    • Property Cc ewong added
    • Property Type changed from enhancement to project-idea
    • Property Milestone changed from 1.0.+ to 0.9.+
  • Ticket #1788 – Description

    initial v1  
    11When Buildbot adopts an MQ framework, there are a number of choices.  Among them:
    22
     3 * pure-python, internal implementation (no network, only a single master)
     4 * pure-python, internal implementation that uses TCP or UDP between masters
    35 * http://morbidq.com/
    46 * http://code.google.com/p/coilmq/
     7 * txamqp
    58 * zeromq
     9
     10The first is already implemented in 'nine', but we need more.
     11
     12The more difficult part of this project is to ensure that messages are only delivered after the corresponding database changes are visible. 
     13
     14The issue is a race condition between message passing and database replication.  Imagine you have a large Buildbot installation with several replicated MySQL servers and a redundant RabbitMQ cluster.  One buildbot master writes changes to a build to the database (an UPDATE operation), then sends a message describing the change.  On another master, some service gets the message and queries a different MySQL server to see the build's new status.  If the message arrives before the database replication occurs, then this master will see stale data.  That will lead to a lot of subtle, rare bugs.
     15
     16== scope ==
     17This project would involve separate tasks:
     18 * implement one or more of the above MQ plugins (mostly just coding)
     19 * solve the data-ordering problem (requiring some CS theory)