Autoscheduling plans after switch to new interface causes NumberFormatException

XMLWordPrintable

    • 8.2
    • 17
    • Severity 2 - Major
    • 1

      Issue Summary

      When running Jira on java 11 with certain locales (confirmed with swedish and slovenian) and error will occur when loading a live plan with very small workload values in the advanced roadmaps AO_D9132D_ASSIGNMENT_EXT table. When converting the plan to the new interface the same error will occur when auto-scheduling.

       

      This is reproducible on Data Center: yes

      Steps to Reproduce

      1. Run Jira with java 11 and without the java.locale.providers system property
      2. Set locale to swedish with these system properties -Duser.language=sv -Duser.country=SE
      3. Try to load a plan with workload values below 0.001

      Expected Results

      Live plan is expected to load correctly and new interface is expected to auto schedule correctly

      Actual Results

      NumberFormatException like this

      java.lang.NumberFormatException: Could not parse double from string 7.450580596923828E-9  at com.atlassian.rm.common.bridges.lucene.BaseNumberValueConverter.getDoubleFromLucene:57
  at com.atlassian.rm.common.bridges.lucene.NumberValueConverter73.getDoubleFromLucene:5
  at com.atlassian.rm.jpo.issueloading.lucene.issue.querying.fields.DoubleConverter.fromString:25
  at com.atlassian.rm.jpo.issueloading.lucene.issue.querying.fields.DoubleConverter.fromString:30
  at com.atlassian.rm.jpo.issueloading.lucene.issue.querying.fields.DoubleConverter.fromString:9
  at com.atlassian.rm.jpo.issueloading.lucene.issue.querying.extraction.BaseFieldValueDocumentExtractor.extractSingleValue:179
  at com.atlassian.rm.jpo.issueloading.lucene.issue.querying.extraction.BaseFieldValueDocumentExtractor.extractValue:112
  at com.atlassian.rm.jpo.issueloading.lucene.issue.querying.extraction.BaseFieldValueDocumentExtractor.extract:64
  at com.atlassian.rm.jpo.issueloading.lucene.issue.querying.readers.FullDataIssueLuceneReader.readGroup:77
  at com.atlassian.rm.jpo.issueloading.lucene.issue.querying.readers.FullDataIssueLuceneReader.readGroup:24
  at com.atlassian.rm.jpo.issueloading.lucene.issue.querying.IssueLuceneQuerist.query:186
  at com.atlassian.rm.jpo.issueloading.lucene.issue.querying.TranslatedIssueLuceneQuerist.query:42
  at com.atlassian.rm.jpo.issueloading.lucene.issue.querying.ParentAwareMergedIssueQuerist.queryRecursive:80
  at com.atlassian.rm.jpo.issueloading.lucene.issue.querying.ParentAwareMergedIssueQuerist.query:58
  at com.atlassian.rm.jpo.issueloading.lucene.issue.querying.DefaultIssueQueryingService.getIssuesFlat:145
  at com.atlassian.rm.jpo.issueloading.lucene.issue.LuceneIssueService.queryAndFilterIssues:407
  at com.atlassian.rm.jpo.issueloading.lucene.issue.LuceneIssueService.getIssues:154
  at com.atlassian.rm.jpo.core.issue.DefaultCalculationAwareIssueService.getIssues:117
  at com.atlassian.rm.jpo.rest.service.backlog.BacklogRestEndpoint.get:134

      Workaround

      Using the java.locale.providers=COMPAT system property should fix the issue by switching over to the java 8 compatible locale provider

            Assignee:
            Luke Ellis
            Reporter:
            Harry White
            Votes:
            4 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: