Uploaded image for project: 'Jira Software Data Center'
  1. Jira Software Data Center
  2. JSWSERVER-21371

Autoscheduling plans after switch to new interface causes NumberFormatException

XMLWordPrintable

      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

              Unassigned Unassigned
              53291ce3ef5a Harry White
              Votes:
              4 Vote for this issue
              Watchers:
              8 Start watching this issue

                Created:
                Updated: