[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #19720 [Metrics/CollecTor]: CollecTor should be re-configurable without restart
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs