I spent some time digging into this more and it looks like these threads
are probably left behind by tests using Gfsh. It creates a JMX
heartbeat thread that issues "severe" (i.e. "fatal") warnings with the
message we're seeing
public void notifyDisconnect(String endPoints) {
String message =
CliStrings.format(CliStrings.GFSH__MSG__NO_LONGER_CONNECTED_TO_0,
new Object[] {endPoints});
printAsSevere(LINE_SEPARATOR + message);
if (gfshFileLogger.severeEnabled()) {
gfshFileLogger.severe(message);
}
setPromptPath(
org.apache.geode.management.internal.cli.converters.RegionPathConverter.DEFAULT_APP_CONTEXT_PATH);
}
In a recent test run I can see that ConnectToLocatorSSLDUnitTest ran
just before a test that logged this fatal-level message. Adding an
@After to ConnectToLocatorSSLDUnitTest that dumps threads I can see that
it is leaving behind a "JMX client heartbeat 4" thread as well as
several "Gfsh Launcher" threads.
We should fix these tests to properly terminate Gfsh threads during cleanup.
Le 10/26/2016 à 5:00 PM, Dan Smith a écrit :
Just looking at a couple of these bugs, these are fatal level errors. Do
you know what is causing them or what affect this might have?
[fatal 2016/09/29 12:12:03.891 PDT <JMX client heartbeat 3> tid=0x18d]
(tid=397 msgId=39) No longer connected to cc6-co6.gemstone.com[27162].
-Dan
On Wed, Oct 26, 2016 at 4:50 PM, Bruce Schuchardt <bschucha...@pivotal.io>
wrote:
We have 23 CI failure tickets concerning suspect strings from "JMX client
heartbeat" threads. I think we should add this to ExpectedStrings.java and
close these tickets. The suspect strings are coming from
javax.management.remote.rmi.RMIConnector and I don't think there's
anything we can do about them. Most, if not all, are assigned to security
or JMX components.
GEODE-1858
GEODE-1955
GEODE-1492
GEODE-1539
GEODE-1538
GEODE-1773
GEODE-1922
GEODE-1482
GEODE-1475
GEODE-1480
GEODE-1481
GEODE-1826
GEODE-1825
GEODE-1820
GEODE-1878
GEODE-1879
GEODE-1877
GEODE-1875
GEODE-1876
GEODE-1499
GEODE-1476
GEODE-1869
GEODE-1769
