Thanks, that's what I'll do in the meantime. Appreciate your help
On Tue, Aug 27, 2024 at 10:19 AM Dave Marion wrote:
> Restarting the secondary GC processes is likely the easiest thing to do.
> If you can't identify them, then you should be able to restart all of the
> GC processes. Accumulo ca
Restarting the secondary GC processes is likely the easiest thing to do. If you
can't identify them, then you should be able to restart all of the GC
processes. Accumulo can operate without the GC process for some period of time,
but it's advised to keep it running.
On 2024/08/27 12:48:21 Craig
Thanks Dave! Are there any mitigations I can employ to work around this
until 2.1.4 is released? I suppose on the standby servers I can schedule a
cronjob to restart the GC process every few hours. I'm not familiar with
how long Accumulo can operate without a GC in general, so maybe that's
somethin
Thanks for reporting this. Based on the information you provided I was able to
create https://github.com/apache/accumulo/pull/4838. It appears that the
Manager, Monitor, and SimpleGarbageCollector are creating multiple instances of
ServiceLock when in a loop waiting to acquire the lock (when the
Wasn't sure if this was bug territory or an issue with cluster
configuration.
In my dev environment, I have a 5-server AWS EMR cluster using Accumulo
2.1.2, Hadoop 3.3.6, and Zookeeper 3.5.10.The cluster is in high
availability mode so there are 3 primary nodes with Zookeeper running. On
the prima