[jira] [Commented] (SOLR-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17924234#comment-17924234
]
ASF subversion and git services commented on SOLR-17379:
Commit eb07d72af281ea426b8d44006636fcf81094b745 in solr's branch
refs/heads/branch_9x from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=eb07d72af28 ]
SOLR-17379: Fix date parsing in Java 23, remove Lucene TestSecurityManager
(#3154)
* Fix system exit in test - by removing that part of the test
(cherry picked from commit b779ed0590e36f69f7d1ce17e99dc936ab46752f)
Co-authored-by: Chris Hostetter
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
>Reporter: Chris M. Hostetter
>Priority: Major
> Labels: pull-request-available
> Attachments: SOLR-17379.test-1.patch, SOLR-17379.test.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923813#comment-17923813
]
Houston Putman commented on SOLR-17379:
---
We have System.exit() used in Solr, mainly in the CLI code. But it would be
great to create a convenience method in Solr that does a System.exit() when
running as an application and throws an exception when running as a unit test.
Then we could forbidden-apis System.exit(), and not have to rely on the
TestSecurityManager's mechanics. I'll file another ticket for that.
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
>Reporter: Chris M. Hostetter
>Priority: Major
> Labels: pull-request-available
> Attachments: SOLR-17379.test-1.patch, SOLR-17379.test.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17923812#comment-17923812
]
ASF subversion and git services commented on SOLR-17379:
Commit b779ed0590e36f69f7d1ce17e99dc936ab46752f in solr's branch
refs/heads/main from Houston Putman
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=b779ed0590e ]
SOLR-17379: Fix date parsing in Java 23, remove Lucene TestSecurityManager
(#3154)
* Fix system exit in test
Co-authored-by: Chris Hostetter
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
>Reporter: Chris M. Hostetter
>Priority: Major
> Labels: pull-request-available
> Attachments: SOLR-17379.test-1.patch, SOLR-17379.test.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922155#comment-17922155
]
David Smiley commented on SOLR-17379:
-
I didn't know Lucene had a special TestSecurityManager. Looking at its
javadocs, it exists only to prevent a test calling System.exit. Wow; what a
heavy-handed solution to a non-problem in practice (I say naively without
looking deeper at the situation that led to this). +1 to use the standard one
in tests.
We can discuss non-test in the existing thread(s) on the dev list about the
SecurityManager.
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-17379.test-1.patch, SOLR-17379.test.patch
>
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17922130#comment-17922130
]
Houston Putman commented on SOLR-17379:
---
I will add, the French date test only fails with the TestSecurityManager. With
the default security manager, we get the error logs printed above, but the
tests pass. Very strange. I even made a new SolrTestSecurityManager that does
nothing but extend java.lang.SecurityManager, and it swallows the errors and
fails, just like the Lucene TestSecurityManager. very very strange. There must
be some code somewhere that is looking for just the default SecurityManager.
The TestSecurityManager/SecurityManager differnce is strange and really makes
no sense, but the CLDR issue has been reported, and the openjdk maintainers see
no real reason to fix it since the security manager is being removed in Java
24. So there is no real way to fix this issue deep down without removing the
URLPermissions from our test security.policy, which doesn't seem realistic.
[https://bugs.openjdk.org/browse/JDK-8305346|https://bugs.openjdk.org/browse/JDK-8305346?attachmentOrder=desc]
Overall I think we should either disable the security manager for Solr 10,
because it's being removed in Java 24, or we should just use the default
SecurityMnaager for tests and try to swallow the errors so that we aren't
spammed with this unfixable bug.
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-17379.test-1.patch, SOLR-17379.test.patch
>
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17921977#comment-17921977
]
Houston Putman commented on SOLR-17379:
---
So after far too much debugging, I figured out that it's an issue with the
security manager. The {{TestSecurityManager}} provided by Lucene swallows up
the error for some reason, but going back to the default Security Manager
prints out a TON of:
{{java.security.policy: error adding Permission, java.net.URLPermission:}}
{{ java.util.ServiceConfigurationError: Locale provider adapter
"CLDR"cannot be instantiated.}}
While this doesn't matter for most tests, the French test relies on having more
than just English, so it fails. When we remove the security manager this will
start succeeding.
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-17379.test-1.patch, SOLR-17379.test.patch
>
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868983#comment-17868983
]
David Smiley commented on SOLR-17379:
-
Approving your patch (I did read it) and wanted to thank you for your work.
Admittedly I don't have more time for this one.
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-17379.test-1.patch, SOLR-17379.test.patch
>
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868818#comment-17868818
]
Chris M. Hostetter commented on SOLR-17379:
---
{quote}+1 thanks
{quote}
I'm not sure I understand what you're "+1"ing, since the french test is still
very broken : )
I'm also more and more convinced that there is something weird going on here
that somebody smarter then me is going to need to figure out...
(Note: all commands in this comment were run using jdk21)
Uwe made a comment on the mailing list suggesting that maybe the CLDR data had
changed, and we should use the "parser" to format the expected Instant, and
then update the test to use that string. When I attempted to do just that my
jshell script, I got the same String the test already uses {{{}"le vendredi 15
janvier 2010"{}}}. Starting to theorize that maybe the way jshell works my {{-R
-Djava.locale.providers=CLDR}} was setting the ssyproperty too late to
influence the locale loading, I tried again using a little {{Tmp.java}} ...
{noformat}
hossman@slate:~/tmp$ cat Tmp.java
public class Tmp {
public static void main(String[] args) {
System.out.println
(
new java.time.format.DateTimeFormatterBuilder()
.parseLenient()
.parseCaseInsensitive()
.appendPattern("'le' dd ")
.toFormatter(org.apache.commons.lang3.LocaleUtils.toLocale("fr"))
.withResolverStyle(java.time.format.ResolverStyle.LENIENT)
.withZone(java.time.ZoneId.of("UTC"))
.format(java.time.Instant.parse("2010-01-15T00:00:00.000Z"))
);
}
}
hossman@slate:~/tmp$ javac -cp
/home/hossman/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-lang3/3.15.0/21581109b4be710ea4b195d5760392ec284f9f11/commons-lang3-3.15.0.jar
Tmp.java
hossman@slate:~/tmp$ java -Djava.locale.providers=CLDR -cp
/home/hossman/.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-lang3/3.15.0/21581109b4be710ea4b195d5760392ec284f9f11/commons-lang3-3.15.0.jar:.
Tmp
le vendredi 15 janvier 2010
{noformat}
So then as a hail mary I tried adding this to logging to where
ParseDateFieldUpdateProcessorFactory initializes the parsers...
{noformat}
log.debug("nocommit: {}={} + {}={} + {} => {}",
localeParam, locale,
defaultTimeZoneParam, defaultTimeZone,
value,
formatter.format(java.time.Instant.parse("2010-01-15T00:00:00.000Z")));
{noformat}
Lo and behold...
{noformat}
$ gradle test --tests ParsingFieldUpdateProcessorsTest.testParseFrenchDate
-Ptests.verbose=true -Ptests.locale=fr -Ptests.timezone=Americas/Metlakatla
-Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
-XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
...
2> 2838 DEBUG (coreLoadExecutor-14-thread-1) [n: c: s: r: x:collection1 t:]
o.a.s.u.p.ParseDateFieldUpdateProcessorFactory nocommit: fr=fr + UTC=UTC + 'le'
dd => le Fri 15 Jan 2010
...
BUILD FAILED in 33s
{noformat}
...vs...
{noformat}
gradle test --tests ParsingFieldUpdateProcessorsTest.testParseFrenchDate
-Ptests.verbose=true -Ptests.locale=fr -Ptests.timezone=Americas/Metlakatla
-Ptests.jvmargs="-XX:TieredStopAtLevel=1 -XX:+UseParallelGC
-XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
...
2> 3315 DEBUG (coreLoadExecutor-14-thread-1) [n: c: s: r: x:collection1 t:]
o.a.s.u.p.ParseDateFieldUpdateProcessorFactory nocommit: fr=fr + UTC=UTC + 'le'
dd => le vendredi 15 janvier 2010
...
BUILD SUCCESSFUL in 19s
{noformat}
...which confuses the fuck out of me in so many ways...
# what is it about Solr (or the test framework) that causes the behavior of
the DateTimeFormatter used in Solr to differ from the one in my {{Tmp.java}}
when formatting this Instant when using {{java.locale.providers=CLDR}}
# Why is the DateTimeFormatter using english {{Fri}} and {{Jan}} instead of
the french basaed on it's Locale?
** Even if it was based on the default locale, as you can see i tried setting
that to {{"fr"}} as well
# Even if english was correct – why the abbreviated forms
** the pattern uses {{}} and {{}} – those are suppose to both be
{{TextStyle.FULL}} !
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-17379.test.patch
>
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
>
[jira] [Commented] (SOLR-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868804#comment-17868804
]
David Smiley commented on SOLR-17379:
-
+1 thanks
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-17379.test.patch
>
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868518#comment-17868518
]
Chris M. Hostetter commented on SOLR-17379:
---
Examples of what these failures look like...
{noformat}
FAILED:
org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testAKSTZone
Error Message:
java.time.format.DateTimeParseException: Text 'Thu Nov 13 04:35:51 AKST 2008'
could not be parsed at index 20
Stack Trace:
java.time.format.DateTimeParseException: Text 'Thu Nov 13 04:35:51 AKST 2008'
could not be parsed at index 20
at
__randomizedtesting.SeedInfo.seed([B84D991968485BB1:B8763855675AE20A]:0)
at
java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2108)
at
java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:2010)
at
org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testAKSTZone(ParsingFieldUpdateProcessorsTest.java:1079)
{noformat}
...and...
{noformat}
FAILED:
org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseFrenchDate
Error Message:
java.lang.AssertionError
Stack Trace:
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([B84D991968485BB1:F1D6EFB1A35A7380]:0)
at org.junit.Assert.fail(Assert.java:87)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertTrue(Assert.java:53)
at
org.apache.solr.update.processor.ParsingFieldUpdateProcessorsTest.testParseFrenchDate(ParsingFieldUpdateProcessorsTest.java:253)
{noformat}
It's interesting to note that using {{-Djava.locale.providers=CLDR}} triggers
these both of problems on JDK21, but on JDK11 and JDK17 only {{testAKSTZone}}
will fail -- {{testParseFrenchDate}} works fine. Suggesting that whatever the
issue is was introduced by a CLDR version change since JDK17
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Chris M. Hostetter
>Priority: Major
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
