The RMI Connector will not be involved, when DiagStatusCommand detects that 127.0.0.1 is self-address. So we should debug why 127.0.0.1 is not coming as self-address. If is it not coming, the proposed patch from Michael also will not solve the problem.

This really (now, with the new log) is a functional Bug and no longer just a technical Enhancement idea.

No, I got totally confused... as discussed on c/71662, my proposed technical enhancement will NOT fix the problem jluhrsen hit, because it does not do away with this code path - NB getRemoteStatusSummary() VS getLocalStatusSummary(). To avoid confusing others further, I propose that we keep this issue for the technical enhancement, and track the actual functional bug under a new INFRAUTILS-38. I'll delete my previous comment above with the stack trace to avoid future confusion of this issue with the new INFRAUTILS-38.

I am not sure which Jira to comment on, this or INFRAUTILS-38 but something I just learned.

in my patch where I'm trying to do the status.getErrorCause().get() I will hit this problem
where I get:

Status retrieval JMX Operation failed for node 127.0.0.1

Ignoring the trace for now.

NOTE: this is all manually and locally.

When I remove that .get(), the problem goes away, so I'll get this:

karaf@root()> showsvcstatus
Timestamp: Wed May 02 11:14:19 PDT 2018
Node IP Address: 127.0.0.1
System is operational: true
System ready state: ACTIVE
  OPENFLOW            : OPERATIONAL       Optional.empty
karaf@root()>

So, maybe we can keep this INFRAUTILS-37 as this specific issue and figure that out. However, the
other problem we can track in INFRAUTILS-38 is maybe related, but also not because of the .get()
issue. That is running a distro that does not have that change. I'll comment more in that jira.

ok, so we can let this jira stay to track the work vorburger is doing in 71662. I did cherry pick
it locally to double check that it does not help me get past INFRAUTILS-36, so we still need that to
chase down. I'll update that jira too.