[ https://issues.apache.org/jira/browse/SOLR-9515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16756401#comment-16756401 ]
Kevin Risden edited comment on SOLR-9515 at 1/30/19 9:13 PM: ------------------------------------------------------------- The precommit failures from above for Hadoop are real but they are an issue with commons-lang3. I just sent a [message to the commons-lang3 mailing list|http://mail-archives.apache.org/mod_mbox/commons-user/201901.mbox/%3CCAJU9nmhqgzh7VcxyhJNfb4czC2SvJzZd4o6ARcuD4msof1U2Zw%40mail.gmail.com%3E]. I have seen these errors sporadically as well. The stacktrace that is similar is: {code:java} ava.lang.ArrayIndexOutOfBoundsException: 4 [junit4] 2> at org.apache.commons.lang3.time.FastDatePrinter$TextField.appendTo(FastDatePrinter.java:901) ~[commons-lang3-3.7.jar:3.7] [junit4] 2> at org.apache.commons.lang3.time.FastDatePrinter.applyRules(FastDatePrinter.java:573) ~[commons-lang3-3.7.jar:3.7] [junit4] 2> at org.apache.commons.lang3.time.FastDatePrinter.applyRulesToString(FastDatePrinter.java:455) ~[commons-lang3-3.7.jar:3.7] [junit4] 2> at org.apache.commons.lang3.time.FastDatePrinter.format(FastDatePrinter.java:446) ~[commons-lang3-3.7.jar:3.7] [junit4] 2> at org.apache.commons.lang3.time.FastDateFormat.format(FastDateFormat.java:428) ~[commons-lang3-3.7.jar:3.7] [junit4] 2> at org.apache.hadoop.hdfs.server.datanode.DirectoryScanner.start(DirectoryScanner.java:281) ~[hadoop-hdfs-3.2.0.jar:?] [junit4] 2> at org.apache.hadoop.hdfs.server.datanode.DataNode.initDirectoryScanner(DataNode.java:1090) ~[hadoop-hdfs-3.2.0.jar:?] [junit4] 2> at org.apache.hadoop.hdfs.server.datanode.DataNode.initBlockPool(DataNode.java:1686) ~[hadoop-hdfs-3.2.0.jar:?] [junit4] 2> at org.apache.hadoop.hdfs.server.datanode.BPOfferService.verifyAndSetNamespaceInfo(BPOfferService.java:390) ~[hadoop-hdfs-3.2.0.jar:?] [junit4] 2> at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.connectToNNAndHandshake(BPServiceActor.java:280) ~[hadoop-hdfs-3.2.0.jar:?] [junit4] 2> at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.run(BPServiceActor.java:819) [hadoop-hdfs-3.2.0.jar:?] [junit4] 2> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191] {code} This happens when the locale is set. I haven't nailed down which locales all fail but a simple reproducing test case without Hadoop or Lucene/Solr is here: {code:java} long timestamp = System.currentTimeMillis(); Locale.setDefault(Locale.forLanguageTag("ja-JP-u-ca-japanese-x-lvariant-JP")); Assert.assertEquals(SimpleDateFormat.getInstance().format(timestamp), FastDateFormat.getInstance().format(timestamp)); {code} This is with commons-lang3 3.8.1 the latest release. was (Author: risdenk): The precommit failures from above for Hadoop are real but they are an issue with commons-lang3. I just sent a message to the commons-lang3 mailing list. I have seen these errors sporadically as well. The stacktrace that is similar is: {code:java} ava.lang.ArrayIndexOutOfBoundsException: 4 [junit4] 2> at org.apache.commons.lang3.time.FastDatePrinter$TextField.appendTo(FastDatePrinter.java:901) ~[commons-lang3-3.7.jar:3.7] [junit4] 2> at org.apache.commons.lang3.time.FastDatePrinter.applyRules(FastDatePrinter.java:573) ~[commons-lang3-3.7.jar:3.7] [junit4] 2> at org.apache.commons.lang3.time.FastDatePrinter.applyRulesToString(FastDatePrinter.java:455) ~[commons-lang3-3.7.jar:3.7] [junit4] 2> at org.apache.commons.lang3.time.FastDatePrinter.format(FastDatePrinter.java:446) ~[commons-lang3-3.7.jar:3.7] [junit4] 2> at org.apache.commons.lang3.time.FastDateFormat.format(FastDateFormat.java:428) ~[commons-lang3-3.7.jar:3.7] [junit4] 2> at org.apache.hadoop.hdfs.server.datanode.DirectoryScanner.start(DirectoryScanner.java:281) ~[hadoop-hdfs-3.2.0.jar:?] [junit4] 2> at org.apache.hadoop.hdfs.server.datanode.DataNode.initDirectoryScanner(DataNode.java:1090) ~[hadoop-hdfs-3.2.0.jar:?] [junit4] 2> at org.apache.hadoop.hdfs.server.datanode.DataNode.initBlockPool(DataNode.java:1686) ~[hadoop-hdfs-3.2.0.jar:?] [junit4] 2> at org.apache.hadoop.hdfs.server.datanode.BPOfferService.verifyAndSetNamespaceInfo(BPOfferService.java:390) ~[hadoop-hdfs-3.2.0.jar:?] [junit4] 2> at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.connectToNNAndHandshake(BPServiceActor.java:280) ~[hadoop-hdfs-3.2.0.jar:?] [junit4] 2> at org.apache.hadoop.hdfs.server.datanode.BPServiceActor.run(BPServiceActor.java:819) [hadoop-hdfs-3.2.0.jar:?] [junit4] 2> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191] {code} This happens when the locale is set. I haven't nailed down which locales all fail but a simple reproducing test case without Hadoop or Lucene/Solr is here: {code:java} long timestamp = System.currentTimeMillis(); Locale.setDefault(Locale.forLanguageTag("ja-JP-u-ca-japanese-x-lvariant-JP")); Assert.assertEquals(SimpleDateFormat.getInstance().format(timestamp), FastDateFormat.getInstance().format(timestamp)); {code} This is with commons-lang3 3.8.1 the latest release. > Update to Hadoop 3 > ------------------ > > Key: SOLR-9515 > URL: https://issues.apache.org/jira/browse/SOLR-9515 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: Mark Miller > Assignee: Kevin Risden > Priority: Major > Fix For: 8.0, master (9.0) > > Attachments: SOLR-9515.patch, SOLR-9515.patch, SOLR-9515.patch, > SOLR-9515.patch > > Time Spent: 3.5h > Remaining Estimate: 0h > > Hadoop 3 is not out yet, but I'd like to iron out the upgrade to be prepared. > I'll start up a dev branch. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org