Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 2F790200C7F for ; Wed, 24 May 2017 20:16:38 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 2E1EF160BB6; Wed, 24 May 2017 18:16:38 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 751A2160BA5 for ; Wed, 24 May 2017 20:16:37 +0200 (CEST) Received: (qmail 60305 invoked by uid 500); 24 May 2017 18:16:36 -0000 Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@accumulo.apache.org Delivered-To: mailing list dev@accumulo.apache.org Received: (qmail 60293 invoked by uid 99); 24 May 2017 18:16:36 -0000 Received: from git1-us-west.apache.org (HELO git1-us-west.apache.org) (140.211.11.23) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 24 May 2017 18:16:36 +0000 Received: by git1-us-west.apache.org (ASF Mail Server at git1-us-west.apache.org, from userid 33) id D8E25DFAEB; Wed, 24 May 2017 18:16:35 +0000 (UTC) From: ctubbsii To: dev@accumulo.apache.org Reply-To: dev@accumulo.apache.org References: In-Reply-To: Subject: [GitHub] accumulo issue #242: ACCUMULO-2181/3005 REST API and new Monitor UI Content-Type: text/plain Message-Id: <20170524181635.D8E25DFAEB@git1-us-west.apache.org> Date: Wed, 24 May 2017 18:16:35 +0000 (UTC) archived-at: Wed, 24 May 2017 18:16:38 -0000 Github user ctubbsii commented on the issue: https://github.com/apache/accumulo/pull/242 > An old, standby monitor would return HTTP/503 (unavailable) to signify that it isn't polling data from the master and (thus) is useless to observe. Does the new REST API still do this? No, it does not. "Standby" monitors will function as normal (except for log receiving), because it may be desirable to have multiple monitors. The 503 response code was added in ACCUMULO-4424 for 2.0.0, and has never been released, so this won't break anyone. The monitor has never fit into the same active/standby HA paradigm that applies to the other services, because its features do not require exclusivity. The active/standby single-instance situation for the monitor was only introduced for log receiving (so Accumulo could identify and automatically forward logs to the monitor), which introduced some kind of exclusivity (but for logs only). I believe we've made sufficient improvements to the log forwarding features, so that it's no longer necessary to impose exclusivity restrictions on all monitor features simply for log forwarding. We can probably still do something to improve the way we inform users about log forwarding exclusivity. For example: we could provide `monitor.log.receiver={WITH_LOCK,ON,OFF}` (default: WITH_LOCK) config, and have the 503 response on the REST endpoint for logs, and display a message on the log view based on whether it receives 503 or 200 from the AJAX call. That should be a separate task, if we do that. --- 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 infrastructure@apache.org or file a JIRA ticket with INFRA. ---