The fix: https://github.com/apache/curator/pull/283
> On Dec 1, 2018, at 10:20 AM, Jordan Zimmerman <[email protected]> > wrote: > > BTW - looks like there's already an open bug for this: > https://issues.apache.org/jira/browse/CURATOR-472 > <https://issues.apache.org/jira/browse/CURATOR-472> - this is what's causing > the problem. I'll have a possible fix soon. > >> On Nov 30, 2018, at 6:52 PM, Jordan Zimmerman <[email protected] >> <mailto:[email protected]>> wrote: >> >> I'm reproducing the problem. There seems to be a race in Curator's >> ConnectionState#checkTimeouts() and HandleHolder#internalClose() with >> ZooKeeper#testableWaitForShutdown. I'll figure it out over the weekend. >> >> -JZ >> >>> On Nov 30, 2018, at 3:22 PM, Cameron McKenzie <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Thanks Jordan, >>> I got one of the guys from the 2.x back port PR to try and run the tests >>> and they seem to have the same problem on the master branch. >>> >>> On Sat, 1 Dec. 2018, 12:51 am Jordan Zimmerman <[email protected] >>> <mailto:[email protected]> wrote: >>> I'll try running tests over the weekend >>> >>>> On Nov 27, 2018, at 7:49 PM, Cameron McKenzie <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Did you get anywhere with this Jordan? >>>> >>>> I've just done a bit of debugging on it, and it seems that when the >>>> teardown() method in the BaseClassForTests method gets called, the close() >>>> method on the server instance does not kill one of the threads. There is a >>>> ReaderThread that seems to run indefinitely, and this appears to cause >>>> issues with subsequent tests that run. I don't know when this has started >>>> happening and whether it's something unique to my environment, but it >>>> happens consistently, so after the first test in a suite runs, the second >>>> test just hangs when trying to close the Curator framework. >>>> >>>> On Tue, Nov 20, 2018 at 2:47 PM Cameron McKenzie <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> At the moment that's the first test that's being run for me, and it is >>>> actually worse than just failing, it's hanging indefinitely. Something is >>>> not getting cleaned up correctly it would seem. I haven't done a lot of >>>> digging yet as I want to make sure it's not just my environment first. >>>> cheers >>>> >>>> On Tue, Nov 20, 2018 at 2:39 PM Jordan Zimmerman >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> It would be good to know which ones consistently fail. >>>> >>>>> On Nov 19, 2018, at 10:18 PM, Cameron McKenzie <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Thanks, >>>>> Yeah, they've been flaky in the past but would eventually succeed, but >>>>> now, for me at least, they're just failing consistently. >>>>> >>>>> On Tue, Nov 20, 2018 at 2:14 PM Jordan Zimmerman >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> They've been flakey for a long time. I haven't run it in many months >>>>> though. I'll try to run soon. >>>>> >>>>> -JZ >>>>> >>>>> > On Nov 19, 2018, at 10:00 PM, Cameron McKenzie <[email protected] >>>>> > <mailto:[email protected]>> wrote: >>>>> > >>>>> > Guys, >>>>> > Is anyone else having issues running unit tests? I haven't done it for a >>>>> > while, but it appears that the code that injects LOST events when >>>>> > session >>>>> > expiration occurs while in a SUSPENDED state is not working. The LOST >>>>> > event >>>>> > just never appears. >>>>> > >>>>> > If I run TestBackgroundStates.testConnectionStateListenable() this just >>>>> > times out at line 124 when waiting for the LOST event to appear. >>>>> > >>>>> > Can someone run this test case when they've got a minute just to confirm >>>>> > that it's not something broken in my environment? >>>>> > cheers >>>>> > Cam >>>>> >>>> >>> >> >
