On Mar 19, 2009, at 9:52 PM, Sam Rowe wrote: > > On Wed, Mar 18, 2009 at 1:16 PM, Luke Kanies <l...@madstop.com> wrote: >> >> Hi all, >> >> As mentioned in an email yesterday, I'm working with someone to add a >> queueing service to Puppet so that some server-side operations are >> queued and executed as cpu time is available - generally those that >> aren't on the critical path but particularly the storeconfigs save >> operation. >> >> The goal here is that the client wouldn't have to wait for the server >> to finish storing the catalog before it got its copy of the catalog; >> instead, the server would just put the catalog into the queue, and a >> queue reader would come behind and process as time was available. >> The >> only other operation I can think of where this makes sense right now >> is reporting, but I expect we'll have others over time. > > Would this help with the splay problem we discussed recently?
The queueing would only help with reducing client contention when the contention was caused by StoreConfigs, unfortunately. Although... I could see having a ping-back model, where a client sends a request for a compilation but then just sleeps, and when the config is compiled the server pushes the configuration to the client. This is obviously a far cry from the current architecture, but it's mostly a reconfiguration, once you have the queueing, rather than a fundamental shift. -- Getting caught is the mother of invention. --Robert Byrne --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
