accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-2334) Lacking fallback when ACCUMULO_LOG_HOST isn't set
Date Tue, 11 Feb 2014 18:42:21 GMT


ASF subversion and git services commented on ACCUMULO-2334:

Commit 0351d0d416df51f0b10d91acdc074dced36e40d4 in branch refs/heads/1.6.0-SNAPSHOT from [~elserj]
[;h=0351d0d ]

ACCUMULO-2334 Remove ACCUMULO_LOG_HOST in favor of pull host and port log-forwarding from

Advertising both the host and port for log4j gives us a couple of benefits.
We can do away with ACCUMULO_LOG_HOST, simplify the code to always
do the same thing (pull from zookeeper), and gain robust failover
if the monitor is moved to a different host or is restarted with a random
port (does not require any other service restart to become aware).

The monitor will now acquire a zoolock before starting, which ensures that
all tservers will perform log-forwarding to the correct monitor (in the case
that there were multiple for some reason). Creates a better hierarchy in ZooKeeper
for all monitor data (HTTP and Log4j advertisement). Update `accumulo init`,
`accumulo info` and ensure that the zookeeper layout can handle an "upgrade"
from 1.5.0.

> Lacking fallback when ACCUMULO_LOG_HOST isn't set
> -------------------------------------------------
>                 Key: ACCUMULO-2334
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>          Components: tserver
>    Affects Versions: 1.5.0
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>             Fix For: 1.5.1, 1.6.0
> For log-forwarding, if ACCUMULO_LOG_HOST is not set, the code falls back to using the
hostname for localhost.
> We already have an address for the monitor in ZK; we should use that instead when populated.

This message was sent by Atlassian JIRA

View raw message