accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Busbey (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-1901) starts only one GC process even if more are defined
Date Thu, 05 Dec 2013 18:22:36 GMT


Sean Busbey commented on ACCUMULO-1901:

Part of the change in behavior on 1.4.5-SNAPSHOT is that, as is, when starting in stand-alone
mode there won't be a GC process.

[~texpilot], falling back to the GC variable won't work ATM because the variable just doesn't
exit. Rather than reinstate that variable, I'd recommend you look to make the gc file optional
by following the same approach used with the tracer file. Namely, in bin/ if ACCUMULO_VERIFY_ONLY
isn't set then you write out a gc file that contains just the first master from the masters

> starts only one GC process even if more are defined
> -----------------------------------------------------------------
>                 Key: ACCUMULO-1901
>                 URL:
>             Project: Accumulo
>          Issue Type: Bug
>          Components: gc, scripts
>    Affects Versions: 1.4.2, 1.4.3, 1.4.4, 1.5.0
>         Environment: Red Hat Enterprise Linux 6.3 64-bit
>            Reporter: Terry Porter
>            Assignee: Terry Porter
>            Priority: Minor
>              Labels: gc, newbie
>             Fix For: 1.4.5, 1.5.1, 1.6.0
>   Original Estimate: 1h
>  Remaining Estimate: 1h
> Even when a second host is listed in the gc file, the gc process is only ever started
on the first host listed in the gc file.  The issue lies in lines 48-55 in as
shown below:
> {code}
> for host in $HOSTS
> do
>     if [ ${host} = ${GC} ]
>     then
>         ${bin}/ $GC gc "garbage collector"
>         break
>     fi
> done
> {code}
> Simple fix:
> {code}
> for host in $HOSTS
> do
>     if grep -q "^${host}\$" $ACCUMULO_HOME/conf/gc
>     then
>         ${bin}/ ${host} gc "garbage collector"
>         break
>     fi
> done
> {code}
> This fix works in my 1.4.2 environment. already sweeps all possible processes
to kill them, so I assumed no fix was needed there, but on my last cluster shutdown I found
the script only stopped the GC on the Master host. That fix is still outstanding.

This message was sent by Atlassian JIRA

View raw message