#19720: CollecTor should be re-configurable without restart -------------------------------+--------------------------------- Reporter: iwakeh | Owner: iwakeh Type: enhancement | Status: needs_review Priority: High | Milestone: CollecTor 1.0.0 Component: Metrics/CollecTor | Version: Severity: Normal | Resolution: Keywords: ctip | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: -------------------------------+---------------------------------
Comment (by iwakeh): Replying to [comment:10 karsten]: > The impatient? Nooo, not true. The forgetful and easily confused! :-) > > Okay, one question and two suggestions: > - What happens if the operator breaks the configuration file? Will current module runs be affected, that is, will they be aborted together with the scheduler? If not, will the scheduler make another attempt to re-read the configuration file 60 (or 5) seconds later? And if so, will it warn every 60 (or 5) seconds that the configuration is broken? Okay, that's more than one question, but these seem related. The design should be quite robust concerning editing errors. First, there are actually two categories of 'breaking' the configuration: 1. syntactically: the properties syntax is wrong and the file cannot be read by `java.util.Properties` 2. semantically: a valid property contains a bad value, e.g. a valid but wrong URL. Case 1: an [https://gitweb.torproject.org/user/iwakeh/collector.git/tree/src/main/java/org/torproject/collector/conf/Configuration.java?h=task-19720 -reread-configuration&id=abedf087def7f66b3446f5b019cff5ff2202f9f0#n74 error is logged] and the modules keep running with their working configuration, i.e. the modules don't hear about a new config. Case 2: All modules are informed and will use the new configuration with their next run. Depending on the 'wrongness' of the value supplied the module affected will in worst case throw an Exception. All modules with correct properties keep running fine. The affected module will be rescheduled at the scheduled time from the start-up configuration. In both cases `Configuration` keeps checking the modified-time, no matter what the edit caused, but it won't re-read unless there was another change. (Looking at the code after working on #19771 I'm going to change the [https://gitweb.torproject.org/user/iwakeh/collector.git/tree/src/main/java/org/torproject/collector/conf/Configuration.java?h=task-19720 -reread-configuration&id=abedf087def7f66b3446f5b019cff5ff2202f9f0#n73 catch clause] into catch-all, too.) > - 10 or 15 seconds might work, too, if 5 is too small. Just enough to save the file and `tail -f` the log file to see how the changes are processed. So, I'd say anything between 5 and 15 would work, please pick your favorite. Fine. > - The behavior of all this should be described at the top of `collector.properties`, so that operators know exactly what will happen when they edit the file while CollecTor is running rather than having to learn it from the logs after it has happened. This is a very important point! > > Sorry to make this more difficult, but I'm thinking of all the services I'm running and how to memorize how to do that, and I'm thinking of external folks running our services in the near future and making this as easy as possible for them. Thanks! In the opposite, voicing all the questions and doubts is important! It surely takes less time to write about things beforehand than troubleshooting an externally running instance later and preparing bugfix- releases. Thanks! Are there any more questions/suggestions? Can I start with the proposed changes? -- Ticket URL: <https://troodi.torproject.org/projects/tor/ticket/19720#comment:12> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs