Github user ctubbsii commented on the issue:
https://github.com/apache/accumulo/pull/242
> Apparently we remember things differently. ... I thought that's why I
built that 503-response in the first place.
I was always uncomfortable with the 503 on the whole thing when it only
really mattered for the log forwarding. Even then, while I understood the
convenience of configure-less detection of monitor location for log forwarding,
I wasn't happy with the restriction. We can still do the 503, but I think we
can make it more narrowly focused, to just the feature which require
exclusivity (more specifically, when the user wants it to be exclusive). We now
have a configure-less detection of monitor location for log forwarding which
does not require this exclusivity behavior.
Personally, I would prefer to support multiple monitors, and I have a use
case where log forwarding is disabled. I don't want to launch unusable
secondary monitors which is only unusable to support a feature which I'm not
using. For this reason, I was disappointed when Eric first introduced the
"active/standby" to the monitor. I never thought this was a good idea, or a
necessary one. Not enforcing this restriction actually makes the code simpler
and supports more use cases.
> But they still only go to one place, don't they?
With the default log4j configuration, yes. However, the improvements we've
made make it easier for the user to configure log forwarding in a way that
works for them. That includes forwarding to a single monitor, multiple
monitors, or none.
> I think the simple solution would just be to return something that isn't
`"[]" with HTTP/200`
Agreed. That's basically what I thought I was describing, but with some
informative message in the view when the AJAX receives this other "something".
---
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.
---
