[
https://issues.apache.org/jira/browse/ACCUMULO-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated ACCUMULO-2208:
--------------------------------
Fix Version/s: 1.5.1
1.7.0
1.6.1
Summary: Provide better error handling when unable to cleanly close
log (was: Unable to cleanly close log...)
Closing as resolved, to track work done in 1.6.0 release.
[~ctubbsii] - Please update the CHANGES file for 1.6.0 accordingly
[~vines] - If you see this error again, please create a follow-on JIRA.
> Provide better error handling when unable to cleanly close log
> --------------------------------------------------------------
>
> Key: ACCUMULO-2208
> URL: https://issues.apache.org/jira/browse/ACCUMULO-2208
> Project: Accumulo
> Issue Type: Bug
> Components: tserver
> Affects Versions: 1.5.0
> Reporter: John Vines
> Fix For: 1.5.1, 1.6.1, 1.7.0
>
>
> I saw this once over 36 tserver/days, caused by an InvalidArgumentException,
> so odd occurrence. It was doing CI but before agitation started so it was a
> non issue, but it could be. The code around this is
> {code}for (DfsLogger logger : loggers) {
> try {
> logger.close();
> } catch (DfsLogger.LogClosedException ex) {
> // ignore
> } catch (Throwable ex) {
> log.error("Unable to cleanly close log " + logger.getFileName() +
> ": " + ex);
> }
> }
> loggers.clear();
> logSizeEstimate.set(0);{code}
> so it seems like it blindly powered forward. However, because of the
> frequency of syncs and such, even if there was agitation the odds of losing
> data are very minute, but I do believe their still there.
> But because the log message just relies on error.toString, I didn't get the
> violating stack trace. At the bare minimum, the message should be updated to
> log the full stack trace.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
