launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/29/2010 06:42 PM, Martin Pool wrote:
> On 27 September 2010 23:46, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
>> On 09/24/2010 05:45 PM, Martin Pool wrote:
>>> On 24 September 2010 23:27, Aaron Bentley <aaron@xxxxxxxxxxxxx> wrote:
>>> Right.  I was wondering if Launchpad was going to (now, or later)
>>> change to just sending "this branch tip changed" and then have the
>>> recipients decide what to do with that.  For instance, we want to
>>> update precalculated mp preview diffs when the branch changes.
>>> Ideally, in a message system, the branch scanner wouldn't need to know
>>> anything about that, only the job that's subscribed to those events.
>>
>> We are already pretty decoupled there.  When the scanner notices a
>> branch tip change, it fires a TipChanged event.  One of the subscribers
>> generates the appropriate UpdatePreviewDiffJob.
> 
> That's what I meant: it seems like we already have both pubsub and
> task-dispatch type messaging.  Perhaps we are happy having the events
> happen entirely in process for now, but if we're considering future
> architecture perhaps it should be taken into account.

"pubsub" and "task-dispatch" may not be quite the right terms, because
for task dispatch, the workers would subscribe to messages of the
appropriate types..

Rob gave some examples that I think do justify considering messaging
outside the strict bounds of task management:
- -Send oops reports to lp-oops immediately rather than later.
- -Trigger completion of long-poll paused requests on appservers.

I don't see event-style messages as the right fit for dispatching tasks,
though.

>> I don't know about that.  It's quite useful to represent this as a job,
>> not an event.  (You could do an event message which generates a job
>> message, but that seems inefficient to me.)
> 
> But isn't that basically what you described above?  Or are you saying
> it would be inefficient to do an event passed out to an external
> broker rather than just transmitted within zope?

That's what I mean.  For cases like this, I don't think we want to use
an external broker instead of doing it in-process.  An external broker
would be more moving parts, and I don't see an advantage to counter that.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkykmlgACgkQ0F+nu1YWqI2fsgCeNrYXoVfLDhcvbsfU98/fQGoy
qSIAn2YkW4kpXfIcEae409FpaR1bhzfa
=5Lc4
-----END PGP SIGNATURE-----