Github user ctubbsii commented on the issue:
https://github.com/apache/accumulo/pull/242
To be clear, the registration that @joshelser describes has not changed.
What has changed is that the standby serves the REST API and views instead of
displaying a message that it does not have the lock, while it is waiting for
the lock.
The sole purpose of the lock for the monitor is to support automatic
forwarding to one, and only one, monitor with the out-of-box log configuration.
Otherwise, the service registration would be a list instead of a singleton lock.
@lstav and I discussed the possibility of adding a message to the log view
only (instead of all pages) similar to the old message, so that a user won't be
confused why no logs are showing up when they visit a standby monitor. That
would only matter for the log view, because that's the only functionality that
would differ between the active and standby monitors. However, I'm not sure
whether or not that's the right thing to do, because a user may wish to
configure a log appender to forward logs to all monitors, and such a message
would only apply to our custom monitor appender, which discriminates in favor
of the active monitor for log forwarding.
To summarize: the test should still check that HTTP is serving before
acquiring the lock. However, the text of what it is looking for in the standby
monitor may have changed. We could add a simple REST endpoint for the monitor
to report its own status... and that could contain things like: active or
standby, listening ports, listening interfaces, last master contact time, etc.
That would make it easier to verify that the HTTP service is working, even when
the lock has not yet been acquired.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
