Luke Kanies wrote: > 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.
I'm a newcomer, so feel free to ignore me. But, if RESTful design has become an increasingly important consideration in interactions between client and server (and it's my impression that it has), I think you might find that it fits better in this case to: * have the server issue a 202 Accepted response, with an response entity containing: possibly a URL to periodically check for results; possibly an estimate of time before the new resource is available * have the client periodically consult the relevant URL until the data is available It's somewhat annoying to consider the possibility of having a client repeatedly, possibly fruitlessly, checking in with a server. But it may be easier to scale that approach and fit it within the current architecture than having bidirectional data flow of the sort described. Thanks. - Ethan -- Ethan Rowe End Point Corporation et...@endpoint.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 -~----------~----~----~----~------~----~------~--~---
