Closed dpharris closed 1 year ago
Can thus be (temporarily) mitigated by changing, in src/org/openlcb/implementations/MemoryConfigurationService.java, at line 499: // Now: something is fishy. if (memo instanceof RequestWithReplyDatagram) { logger.info("Expected reply pending, got zero."); // We will still wait for a reply datagram. return; to: // Now: something is fishy. if (memo instanceof RequestWithReplyDatagram) { logger.debug("Expected reply pending, got zero."); // We will still wait for a reply datagram. return;
@dpharris Could you say a few more words about when this is happening? I'm not seeing those messages when reading CDI.
There is a node out there which does not add the extra byte to the datagram ACK message. Normally the request datagram gets ACK-ed with a single byte of payload, setting 0x80 there indicates that there will be a reply datagram coming. Older versions of the standard text did not have this requirement. So some nodes don't send it. I don't remember which node is the one not sending it.
I would be okay removing this warning, it's not super useful for the user. If we ever have a conformance testing suite, that should check and emit the warning instead of us spamming the user with it.
Anytime using JMRI to read a CDI, the console log gets a whole bunch of these messages.
2022-02-13 14:29:49,239 mentations.MemoryConfigurationService INFO - Expected reply pending, got zero. [AWT-EventQueue-0] 2022-02-13 14:29:49,253 mentations.MemoryConfigurationService INFO - Expected reply pending, got zero. [AWT-EventQueue-0]
Can that get changed to a DEBUG so it won't show up at all unless needed? Or is it even needed anymore? That does make finding real things in the console harder.
-Ken Cameron, Member JMRI Dev Team