Clojurians Log v2

Hi. I want to start a process in a component after it is started and configured. Is this possible out of the box or do I have to create an own lifecycle?

I provide a async channel and want to run a (go-loop … (recur)) when everything is in place.

@marco: I'm not sure I understand the question. If you have a component that implements Lifecycle then you can start threads or go's in the start method.

I’ll try to use a future for this.

But then I don’t have the initialized component. :thinking_face: I have no clue.

Ah, got it. I let the new component.

Is there a recommended way of cyclying (stop+start) a single component in a system?

Or, alternatively, is there a reason that shouldn't be done?

@potetm: There is not currently a way to update a single component within a system, such that dependencies/dependents are also updated.

@stuartsierra: Cool. Thanks!

you're welcome!

I had a sorta similar requirement on a project I’m working on, @potetm. We wanted to be able to make arbitrary changes to the system configuration and safely apply them without having to restart the entire process/webapp. I ended up with a watcher on the config that simply restarts the system at the first idle period after a change.

Another option for managing change in components is to introduce mutable references (Atoms, Refs) into the definition of the component. The state can be modified in a way that is immediately visible to all users of that component.

I'm curious, @donaldball and @potetm, what is your use case for modifying the system after the initial start? Is it just a convenience to speed up restarts during development, or are you changing a running production system? If the latter, how do you ensure code is running with the current version of a component?

We wanted the ability to e.g. change the database configuration, not change system code.

@donaldball: Was that during development, or in a running production app?

@stuartsierra: It came to mind for the while I was thinking about how we might have many services on a single machine and start/stop them from the repl if need be. Not necessarily for changing code.

We would like that capability in a running production app

@donaldball: OK, so in that case, what would you expect to be the consequence of changing the database configuration while the app is running? What would happen to outstanding requests using the old configuration? What if the current configuration has been captured in a closure or a local variable in another thread?

The config watcher sets a latch which prohibits new requests from being processed until the system restarts. All extant requests must finish before the system will be allowed to restart. Requests which fire off threads must block or use a thread pool under control of the system in order for this scheme to be safe, of course.

OK, thanks for the context.

Hey, thanks for component. This reconfig capability is something I’ve dearly wanted on some previous clojure apps. Having a coherent system lifecycle is a necessary precondition for doing it safely and sanely.

You're welcome! Glad to hear it has been useful to you

Finally I seem to get used to it. I really like the design.