<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
Now I'm seeing some odd anomalies. [..]<br class="gmail_msg">
Could this be part of the result of schedulers not being particularly<br class="gmail_msg">
reconfigurable?<br class="gmail_msg"></blockquote><div>I'd guess so. Probably that big change would deserve a scheduled master restart.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
And on that note, there seems to be 3 schemes in 0.9.x for<br class="gmail_msg">
checkConfig/reconfigService.<br class="gmail_msg">
<br class="gmail_msg">
Number 1 is how the schedulers do it. Which is that they don't, but have<br class="gmail_msg">
largish __init__() functions.<br class="gmail_msg">
<br class="gmail_msg">
Number 2 is how the workers do it. checkconfig looks a lot like __init__<br class="gmail_msg">
might, and reconfigService looks a lot like checkConfig, except that it<br class="gmail_msg">
doesn't except.<br class="gmail_msg"></blockquote><div>It is possible that the code working with workers needs to have some of the worker attribute set before they are fully configured. I guess this is the reason why the checkconfig sets attributes... Or this is a confusion. would need to remove those and see what breaks.</div><div><br></div><div>This is not bad though, it is just code duplication, as those attribute needs to be set in reconfig anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Number 3 is how things like reporters do it. checkConfig only does<br class="gmail_msg">
checks (and the occasional null-ish initialization), and reconfigService<br class="gmail_msg">
copies its arguments into itself.<br class="gmail_msg"></blockquote><div>This is how it is meant to be used.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
One slightly happier anecdote...<br class="gmail_msg">
<br class="gmail_msg">
We ended up with a situation where there were 2 builders for a<br class="gmail_msg">
particular worker. Both had current builds marked as acquiring locks<br class="gmail_msg">
(remember that we use locks to keep it to one build per worker, except<br class="gmail_msg">
for a special builder that should always run, even if there's another<br class="gmail_msg">
build running. That's why we don't restrict builds at the worker level).<br class="gmail_msg">
<br class="gmail_msg">
I did manage to go in through the manhole and release the lock from<br class="gmail_msg">
whoever was holding it. By the time I got far enough to do that, I<br class="gmail_msg">
wasn't interested in figuring out which build was actually holding onto it.<br class="gmail_msg"></blockquote><div><br></div><div>Manhole is cool for such hacks.. but its being removed in recent twisted.</div><div><br></div><div>Thanks for you feedbacks and return of experience. I think they are quite useful for the community</div><div>Cheers,</div><div>Pierre </div></div></div>