DSFIDNotFoundException: Unknown DataSerializableFixedID: 2145

[Kirk Lund <kl...@apache.org>]

Sai and I noticed that the Acceptance style dunit tests that are starting
up locators in vm0 are generating a bunch of log statements about "Unknown
DataSerializableFixedID: 2145" and this looks wrong in several ways. I
reviewed it with Darrel and neither of us are familiar with TcpServer or
with WANFactoryImpl which seems to be responsible for registering the
DSFIDs that causing these exceptions.

1) run StartLocatorCommandDUnit or similar test and you'll see these info
level log statements:

[vm0] [info 2018/10/04 11:34:21.463 PDT <locator request thread[1]>
tid=0x33] Exception in processing request from 127.0.0.1
[vm0] org.apache.geode.internal.DSFIDNotFoundException: Unknown
DataSerializableFixedID: 2145
[vm0]   at
org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1007)
[vm0]   at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2761)
[vm0]   at
org.apache.geode.DataSerializer.readObject(DataSerializer.java:2977)
[vm0]   at
org.apache.geode.distributed.internal.tcpserver.TcpServer.processOneConnection(TcpServer.java:470)
[vm0]   at
org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:379)
[vm0]   at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[vm0]   at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[vm0]   at java.lang.Thread.run(Thread.java:748)

This is occurring in acceptance style tests -- ie, full end-to-end tests so
all of geode should be in the classpath -- nothing is missing including
wan. Or is geode-wan actually missing from the classpath?

Apparently this is the current normal for Geode -- you can expect to see
these messages being logged for some reason.

2) why is something that seems this bad being logged at info instead of
warn or error?

3) why is 2145 (DataSerializableFixedID.REMOTE_LOCATOR_JOIN_REQUEST) not
registered with DSFIDFactory?

Apparently it's registered in WANFactoryImpl:

  @Override
  public void initialize() {

DSFIDFactory.registerDSFID(DataSerializableFixedID.REMOTE_LOCATOR_JOIN_REQUEST,
        RemoteLocatorJoinRequest.class);

DSFIDFactory.registerDSFID(DataSerializableFixedID.REMOTE_LOCATOR_JOIN_RESPONSE,
        RemoteLocatorJoinResponse.class);

DSFIDFactory.registerDSFID(DataSerializableFixedID.REMOTE_LOCATOR_REQUEST,
        RemoteLocatorRequest.class);
    DSFIDFactory.registerDSFID(DataSerializableFixedID.LOCATOR_JOIN_MESSAGE,
        LocatorJoinMessage.class);

DSFIDFactory.registerDSFID(DataSerializableFixedID.REMOTE_LOCATOR_PING_REQUEST,
        RemoteLocatorPingRequest.class);

DSFIDFactory.registerDSFID(DataSerializableFixedID.REMOTE_LOCATOR_PING_RESPONSE,
        RemoteLocatorPingResponse.class);

DSFIDFactory.registerDSFID(DataSerializableFixedID.REMOTE_LOCATOR_RESPONSE,
        RemoteLocatorResponse.class);
  }

... but why aren't the WANFactoryImpl messages being registered?

4) why aren't these info-level log statements causing grep for suspect
strings to fail? StartLocatorCommandDUnit is a dunit so grep for suspect
strings should occur at the end of every test method.

5) why aren't any tests failing if things are this broken?