[
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
