I didn't think this was a very interesting thread leak. It only tests connect calls that fail (the test never does connect successfully). If we do keep it add a comment to the test saying it may "flicker" and to check the log for suspect threads
On Tue, Mar 22, 2016 at 9:26 AM, Hitesh Khamesra <[email protected]> wrote: > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/45142/ > > This is good test to keep as customers run into thread leak issue many > times.We can log all the threads exist before and after the test, that way, > when next time test will fail will know which thread is extra. > > > - Hitesh Khamesra > > On March 22nd, 2016, 1:10 a.m. UTC, Jianxia Chen wrote: > Review request for geode, Bruce Schuchardt, Darrel Schneider, Hitesh > Khamesra, and Udo Kohlmeyer. > By Jianxia Chen. > > *Updated March 22, 2016, 1:10 a.m.* > *Repository: * geode > Description > > The thread dump does not see any suspicious thread: > Two gradle threads; > Three JVM threads: Signal Dispatcher, Finalizer and Reference Handler; > and two test threads: main and Test worker which prints the stack trace. > There is no thread leak as the dunit test is supposed to catch. > > Remove the test. Since different number of threads at the beginning and at > the end of the test does not always mean a thread leak. There could be thread > spawned by gradle or JVM at unpredictable time. > > Diffs > > - > geode-core/src/test/java/com/gemstone/gemfire/cache/Bug42039JUnitTest.java > (dc023a9) > > View Diff <https://reviews.apache.org/r/45142/diff/> >
