Hi Johnathan What version of zookeeper are you running? Sounds like you may be hitting https://issues.apache.org/jira/plugins/servlet/mobile#issue/ZOOKEEPER-1622. If so, try shutting down Accumulo, then zookeeper. Then upgrade zookeeper and restart.
Mike On Fri, Apr 22, 2022, 15:30 Wonders, Jonathan (Serco NA) < jonathan.wond...@serco-na.com> wrote: > Serco Business > > Greetings, > > > > The team I work with is encountering an issue when starting an Accumulo > 1.7.x cluster and when running troubleshooting commands such as > bin/accumulo admin checkTablets. The primary symptom is a > NumberFormatException thrown within ZookeeperLockChecker that occurs when > parsing the tablet server session id (Long.parseLong) for an input string > “ff804d767efe0004” (which is out of range when interpreting as a positive > signed long). > > > > From what I can gather, our zookeeper cluster has been running for such a > long time that the epoch component of the session id has grown to the point > where interpreting the session id as a signed long would be a negative > value. Within the ZooKeeper code, the session id is treated as an unsigned > long (e.g., Long.toHexString) which leads me to think that the Accumulo > code is not parsing the value correctly. This discrepancy is present in all > versions since the introduction of the ZookeeperLockChecker class. > > > > There does not appear to be an easy way to work around this problem. > Currently, our best idea of how to recover the data from this cluster is to > set up a separate zookeeper cluster, migrate the data we have in zookeeper > to the new cluster, and then swap over configuration to point to the new > zookeeper cluster. I would appreciate any ideas or suggestions from the > community. > > > > Thanks, > > Jonathan > > > > > > > > >
