Details
-
Bug
-
Resolution: Fixed
-
Medium
-
6.1.3
-
None
-
6.01
-
Description
As discovered while troubleshooting reindexing problems on an internal JIRA instance, exceptions during a reindex are caught and traced as one-liners:
try
{
result.await();
successes++;
}
catch (RuntimeException e)
{
failures++;
log.warn(e.getMessage());
}
When several issues failed to reindex due to a problem with a custom field, the result was a string of warnings like this (edited):
2013-11-15T06:23:02.135046+00:00 hostname: 2013-11-15 00:23:02,134 JiraTaskExectionThread-1 WARN admin 22x79x1 14p2q1a 127.0.0.1 /secure/admin/IndexReIndex.jspa [atlassian.jira.index.AccumulatingResultBuilder] java.util.concurrent.ExecutionException: java.lang.NullPointerException 2013-11-15T06:23:02.137881+00:00 hostname: 2013-11-15 00:23:02,137 JiraTaskExectionThread-1 WARN admin 22x79x1 14p2q1a 127.0.0.1 /secure/admin/IndexReIndex.jspa [atlassian.jira.index.AccumulatingResultBuilder] java.util.concurrent.ExecutionException: java.lang.NullPointerException 2013-11-15T06:23:02.138059+00:00 hostname: 2013-11-15 00:23:02,138 JiraTaskExectionThread-1 WARN admin 22x79x1 14p2q1a 127.0.0.1 /secure/admin/IndexReIndex.jspa [atlassian.jira.index.AccumulatingResultBuilder] java.util.concurrent.ExecutionException: java.lang.NullPointerException
While this is understandable, since the result is that the problem issue does not get indexed, there needs to be a way to view a) which issue had the problem and b) a full stack trace.
In my opinion, it is ok to require DEBUG logging to be enabled before we dump the stack trace, but others may feel differently. I think the issue whose indexing failed needs to be reported either way.
Attachments
Issue Links
- is related to
-
-
- Closed
-
-
-
- Closed
-
-
JDEV-27633 Loading...
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
-