On Fri, Jan 14, 2022 at 10:45 PM Mark Miller <markrmil...@gmail.com> wrote:
> “Your test fails or not” * > > I did see some time back, that thread leaks did need some attention. I > don’t know if it’s gotten any worse, but I did have some offenders > addressed. > The case I was looking at was zkevent threads firing after shutdown begins. There is some attempt to let those threads drain which I guess is a thought towards's graceful shutdown, but I'm increasingly feeling that such is a hopeless idea and we should just design everything to assume that the power cord will get unplugged. The change that seemed to be doing some good was synchronizing the shutdown() method in corecontainer with ZkController, which lead to some deadlocks, but I seemed to have got that worked out (at least well enough to complete 10 times in a row) I'll fiddle a little more and post it ... > > Really though, the whole idea of removing the reliance on the test > framework to sweep leaks and poor test behavior under the table is > predicated on the idea that those issues would instead become viable and > rather than accumulate and exist forever, they would be fixed and good > tests and often production behavior would be enforced like it was > originally intended to be. > > I think that’s an unlikely outcome, which is probably putting it > generously looking historically. And so the more beneficial move may just > to be to revert back to the test framework burying that stuff to the degree > that it did. > The primary thing that bugs me there is that we run in partial, mocked up jetty instead of the real thing so we may be observing things that don't relate to the real running solr, but that's a whole other thing wherein we should either kick Jetty out entirely, turn our test harness into the live server or better optimize standard jetty startup so that It doesn't kill test times as much (and yes I recall your prior notes on the difficulty of that!). I favor the later course by default but haven't looked deeply. Also the efforts to reduce which tests run by default on dev laptops worries me, it amounts to head in the sand. This sort of thing is reasonable in a non-volunteer environment where the metrics coming out of the build server are obsessed over by managers, and they assign someone to go fix things up every now and then. I'm not sure failures would get enough attention in a volunteer oriented space if it doesn't irritate us in our daily work. -Gus -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
