+1 for open sourcing drcfg!

Might be interesting to apply the same idea (drcfg) to the SS component 
model, where a component manages the atoms instead of having to def them. I 
did something very similar but on top of Curator. One component defined as 
a service discovery component, and others that depend on it. The discovery 
component exposes a "listenable" interface; when a service is discovered 
the callbacks are fired and the dependent components are notified.

Related but slightly OT - I didn't think the component lib provided the 
ability to restart an individual component within a system?

- Matt

On Thursday, May 22, 2014 10:29:50 AM UTC-4, Thomas Steffes wrote:
>
> Currently config changes that require restart of a component are not 
> supported by our drcfg
>
> On Wednesday, May 21, 2014 12:59:18 PM UTC-4, Ben Mabey wrote:
>>
>> On 5/20/14, 3:33 PM, Thomas Steffes wrote: 
>> > Hey folks, 
>> > 
>> > At Room Key we're using Apache Zookeeper and a home-grown clojure 
>> > library called drcfg for real-time application configuration 
>> > management. We're debating open-sourcing drcfg and are trying to gauge 
>> > community interest in such a tool. 
>> > 
>> > We think it's got great usage semantics, basically you just def an 
>> > atom in any namespace where you'd like a variable that can be changed 
>> > in real-time on a running system. When you define the atom, you can 
>> > also provide defaults to fall back to if zookeeper is unavailable, a 
>> > validator to be run on any value when a change is attempted (to 
>> > prevent invalid configuration data), as well as some meta-data about 
>> > the variable. 
>> > 
>> > We've also got a web UI we use to change configuration data, but that 
>> > would likely be released separate of drcfg itself. 
>> > 
>> > If anyone's interested, could you reply to this post? I can provide 
>> > more information as well if need be. 
>> > 
>> > 
>> > -Thomas Steffes @ Room Key 
>> > 
>> Hi Thomas, 
>> I'd be interested in learning more about your solution.  Have you ever 
>> ran into the case where a config change needs to restart a component?   
>> If so, have you written the logic that handles the updating of your 
>> entire system based on this change?  e.g. a new DB config requires that 
>> your DB component be restarted and each component that relies on the DB 
>> component be restarted as well to get the new connection. 
>>
>> Thanks, 
>> Ben 
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to