Euh... our local config would require loading a top level map with more than twenty keys and a dozen levels deep of maps.
I am not sure I would like to carry a local copy in all workers. Freezing the app somehow when a config change occurs is mandatory. Each node in the cluster runs at least a dozen workers and not all the nodes run the same set of workers. We cannot allow a worker to run with the old config in place while others pick up the changes. Mismatches in resources between collaboration workers would create a huge chaos. Allowing some workers to continue processing would require knowing which ones are impacted by a change and which ones can safely continue w/o picking up the change. This requires a tool to analyze dependencies at runtime when a config change occurs. This may be a future enhancement but up to now the value of such an enhancement has been very low. A config change does not stall the app for a significant amount of time. Luc P. > 2013/9/11 Softaddicts <lprefonta...@softaddicts.ca>: > > We load configuration data once from zookeeper and conceal it in a name > > space. > > Changing the context is quite simple, we reload resources in this name space > > using a minimal list of properties which says where the configuration data > > should be > > pulled from in zookeeper. > > > > This is doable from the REPL at any time. No other name space keeps > > this stuff in vars. Any external resource is pulled at runtime from the > > configuration name space where they are cached except for some very short > > lived > > structures (requests to storage, locks, queues, channels, ... for the > > duration of > > the request). > > > > Test configuration data is also contained in zookeeper. Tests > > pull from this configuration tree the configuration they need. > > > > Part of the test stubbing is kept in this configuration. > > > > No mutations occur in the configuration data from zookeeper during the > > "normal" > > app life cycle. We allow config changes while the app is running but in a > > special > > context of its life cycle. Namely the app has to enter a state that allows > > it to > > reconfigured itself. This means that workers have been stopped, .... > > > > We can test a new configuration without mutating the previous one in > > zookeeper > > using a versioning scheme. > > > > This requires some discipline enforced by the configuration name space API. > > So far it's been a charm to work with. > > Sure, and adding a binding call providing the same config as the one > found in root would allow for the whole thread to consistently read > the same value. > > > > > Luc P. > > > >> As far as possible, I think it is best to try and minimise mutable global > >> state (like mutable configuration data) and implicit context (like dynamic > >> vars). My preferred approach is to pass the configuration data (as a value) > >> to a higher order function that constructs the configurable object / > >> function appropriately. I regard this is more of a "functional" style. So > >> you might do something like: > >> > >> (def my-ring-application (create-application config-map)) > >> > >> Once constructed, the ring application is fully configured and doesn't need > >> any extra parameters, i.e. it works just like a regular ring application. > >> You can treat the ring application as being effectively immutable. If you > >> want to reconfigure, then just create a new one! > >> > >> This approach has several advantages: > >> - It's highly composable. Your components can easily be plugged together, > >> since they aren't bound to any external configuration state. > >> - You can perform some significant optimisations in the construction phase > >> (depending on the nature of the configuration you might be able to > >> eliminate validation checks, optimise the size of buffers etc.) > >> - It's highly testable. Just create as many differently-configured > >> instances as you like. > >> > >> The main downside, of course, is that you need to be thoughtful and do a > >> bit more work in designing the constructor function. But I think that's a > >> worthwhile activity - it can often lead to a better design overall. > >> > >> Note that this technique can apply to much more than web applications. You > >> can even use it to construct objects that themselves contain mutable state. > >> For example, I use this method to construct the entire GUI + running game > >> instance for my little Clojure roguelike game "Alchemy". There is no > >> mutable global state at all - you can launch several totally independent > >> game instances from the same REPL. If you are interested, see the "launch" > >> code at the bottom of this file: > >> https://github.com/mikera/alchemy/blob/master/src/main/clojure/mikera/alchemy/main.clj > >> > >> On Tuesday, 10 September 2013 15:19:35 UTC+8, Alexandr Kurilin wrote: > >> > > >> > I'm trying to determine how to best deal with the concept of globals in > >> > Clojure. Say I have a map of configuration values for my Ring app, > >> > populate > >> > at app startup from disk or env, and I need to reference the contents of > >> > this map from all over the project. Assuming MVC, models and controllers > >> > all would be interested in its contents. I just want to clarify that the > >> > question is not so much about "configuration" as it is about dealing with > >> > state that many different components in an application might be all > >> > interested in. This is an issue that seems to arise very often. > >> > > >> > I'm seeing a couple of options here: > >> > > >> > - Pass the configs map along with each Ring request with some > >> > middleware, and then down every subsequent function call that might > >> > eventually need it. It's a bit of a hassle since now you're passing > >> > more > >> > data, potentially increasing the # of parameters, or forcing you to > >> > use a > >> > parameter map everywhere where you might have passed along just 1 > >> > primitive. Nonetheless, this is as pure as it gets. > >> > - Def the configs map in a namespace somewhere and refer to it from > >> > wherever, just like global state. The trick is now that now you're no > >> > longer certain what e.g. your model functions are expecting there to > >> > be in > >> > the system and testing becomes trickier. Now you have to either lein > >> > test > >> > with a separate set of configurations (which doesn't actually give > >> > you much > >> > per-test granularity) or use with-redefs everywhere to make sure the > >> > right > >> > test config state is being used. > >> > - Something in the middle where perhaps you agree to never directly > >> > reference the configs map from your models (again, thinking MVC here) > >> > and > >> > instead only ever access it from controllers, and pass the necessary > >> > options along down to the model functions. This way you can test both > >> > controllers and models in isolation in purity. > >> > > >> > Ultimately I want to contain the chaos of having to know internal > >> > implementation details of my functions at different layers and want them > >> > to > >> > be easily testable in isolation. It does seem like the first option is > >> > the > >> > most straightforward, but I'd be curious to find out what those of you > >> > who > >> > have deal with the problem for a while would recommend. Purity all the > >> > way, > >> > or are there patterns that can give you the best of both worlds? Or what > >> > else? > >> > > >> > > >> > > >> > >> -- > >> -- > >> 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/groups/opt_out. > >> > > -- > > Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! > > > > -- > > -- > > 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/groups/opt_out. > > -- > -- > 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/groups/opt_out. > -- Softaddicts<lprefonta...@softaddicts.ca> sent by ibisMail from my ipad! -- -- 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/groups/opt_out.
