Re: [VOTE] Release Lucene 9.8.0 RC1

2023-09-25 Thread Lu Xugang
+1   (non-binding)
SUCCESS! [1:05:42.202068]

Xugang
https://www.amazingkoala.com.cn/


Michael McCandless  于2023年9月26日周二 10:10写道:

> +1
>
> SUCCESS! [0:21:40.221538]
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Mon, Sep 25, 2023 at 7:01 AM Julie Tibshirani 
> wrote:
>
>> +1
>>
>> SUCCESS! [0:41:00.311710]
>>
>> Julie
>>
>> On Mon, Sep 25, 2023 at 9:38 AM Anshum Gupta 
>> wrote:
>>
>>> +1
>>>
>>> Smoke tester is happy!
>>>
>>> SUCCESS! [0:46:49.090567]
>>>
>>> On Thu, Sep 21, 2023 at 10:49 PM Patrick Zhai 
>>> wrote:
>>>
 Please vote for release candidate 1 for Lucene 9.8.0

 The artifacts can be downloaded from:

 https://dist.apache.org/repos/dist/dev/lucene/lucene-9.8.0-RC1-rev-d914b3722bd5b8ef31ccf7e8ddc638a87fd648db

 You can run the smoke tester directly with this command:

 python3 -u dev-tools/scripts/smokeTestRelease.py \

 https://dist.apache.org/repos/dist/dev/lucene/lucene-9.8.0-RC1-rev-d914b3722bd5b8ef31ccf7e8ddc638a87fd648db

 The vote will be open for at least 72 hours, as there's a weekend, the
 vote will last until 2023-09-27 06:00 UTC.

 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

 Here is my +1 (non-binding)

>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>>


Re: [VOTE] Release Lucene 9.8.0 RC1

2023-09-25 Thread Michael McCandless
+1

SUCCESS! [0:21:40.221538]

Mike McCandless

http://blog.mikemccandless.com


On Mon, Sep 25, 2023 at 7:01 AM Julie Tibshirani 
wrote:

> +1
>
> SUCCESS! [0:41:00.311710]
>
> Julie
>
> On Mon, Sep 25, 2023 at 9:38 AM Anshum Gupta 
> wrote:
>
>> +1
>>
>> Smoke tester is happy!
>>
>> SUCCESS! [0:46:49.090567]
>>
>> On Thu, Sep 21, 2023 at 10:49 PM Patrick Zhai  wrote:
>>
>>> Please vote for release candidate 1 for Lucene 9.8.0
>>>
>>> The artifacts can be downloaded from:
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.8.0-RC1-rev-d914b3722bd5b8ef31ccf7e8ddc638a87fd648db
>>>
>>> You can run the smoke tester directly with this command:
>>>
>>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.8.0-RC1-rev-d914b3722bd5b8ef31ccf7e8ddc638a87fd648db
>>>
>>> The vote will be open for at least 72 hours, as there's a weekend, the
>>> vote will last until 2023-09-27 06:00 UTC.
>>>
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>>
>>> Here is my +1 (non-binding)
>>>
>>
>>
>> --
>> Anshum Gupta
>>
>


Re: [VOTE] Release Lucene 9.8.0 RC1

2023-09-25 Thread Julie Tibshirani
+1

SUCCESS! [0:41:00.311710]

Julie

On Mon, Sep 25, 2023 at 9:38 AM Anshum Gupta  wrote:

> +1
>
> Smoke tester is happy!
>
> SUCCESS! [0:46:49.090567]
>
> On Thu, Sep 21, 2023 at 10:49 PM Patrick Zhai  wrote:
>
>> Please vote for release candidate 1 for Lucene 9.8.0
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.8.0-RC1-rev-d914b3722bd5b8ef31ccf7e8ddc638a87fd648db
>>
>> You can run the smoke tester directly with this command:
>>
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.8.0-RC1-rev-d914b3722bd5b8ef31ccf7e8ddc638a87fd648db
>>
>> The vote will be open for at least 72 hours, as there's a weekend, the
>> vote will last until 2023-09-27 06:00 UTC.
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Here is my +1 (non-binding)
>>
>
>
> --
> Anshum Gupta
>


Re: [VOTE] Release Lucene 9.8.0 RC1

2023-09-25 Thread Anshum Gupta
+1

Smoke tester is happy!

SUCCESS! [0:46:49.090567]

On Thu, Sep 21, 2023 at 10:49 PM Patrick Zhai  wrote:

> Please vote for release candidate 1 for Lucene 9.8.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.8.0-RC1-rev-d914b3722bd5b8ef31ccf7e8ddc638a87fd648db
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.8.0-RC1-rev-d914b3722bd5b8ef31ccf7e8ddc638a87fd648db
>
> The vote will be open for at least 72 hours, as there's a weekend, the
> vote will last until 2023-09-27 06:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1 (non-binding)
>


-- 
Anshum Gupta


Re: [VOTE] Release Lucene 9.8.0 RC1

2023-09-25 Thread Michael Sokolov
thanks for the detailed info, folks. I'll see if I can understand why
I may have been running an old instance of that agent. The host I was
running on was created recently.

On Mon, Sep 25, 2023 at 6:09 AM Chris Hegarty
 wrote:
>
> Hi,
>
>   2>at Log4jHotPatch.asmVersion(Log4jHotPatch.java:71)
>
>
> This coming from Amazon’s Log4Shell hot patch [1], which I believe was 
> deployed by default on many (all?) JVM’s running on Amazon instances. Well… 
> that was almost 2yrs ago, not sure why it’s still showing up in some places 
> now - it should not be needed.
>
> In fact, I do remember seeing and reporting this issue back in late 2021. The 
> hot patcher initially used the JDK’s internal ASM library, which is the root 
> cause of the security exception. The hot patcher was subsequently fixed to 
> not do this - it bundles/shades ASM itself. This fix was made in late 2021.
>
> I have no idea why the system in question is running an old version of the 
> hot patcher. @Michael, you should probably take a look at that system, maybe 
> it needs some updates or something?
>
> -Chris.
>
> [1] https://github.com/corretto/hotpatch-for-apache-log4j2/tree/main
>
> On 25 Sep 2023, at 09:22, Uwe Schindler  wrote:
>
> Hi,
>
> as Lucene does not use Log4j, it is unclear why it wants to patch anything. 
> The problem in indeed caused by SecurityManager which is enabled for running 
> Lucene tests. Actually it detects that something tries to access some 
> internals of ASM, not sure what it exactly does. The "injected" Agent code 
> must possibly use AccessController#doPrivileged and the security context must 
> allow patching of classes.
>
> In short: SecurityManager has done everything it should do: It detected an 
> illegal access. Mission achieved! You have to report this issue and patch 
> your tool so it works correctly with SecurityManager.
>
> Uwe
>
> Am 24.09.2023 um 23:52 schrieb Michael Sokolov:
>
> I ran the smoketester and had a failure. It seems related to some
> log4j hot patch script we are required to run at work which is somehow
> conflicting with the security manager? I'm killing that and trying
> again, but I wonder if this is going to cause problems at runtime as
> well? How do we enable the security manager -is it only when running
> tests?
>
> org.apache.lucene.codecs.simpletext.TestSimpleTextPostingsFormat >
> classMethod FAILED
> java.lang.AssertionError: The test or suite printed 15378 bytes to
> stdout and stderr, even though the limit was set to 8192 bytes.
> Increase the limit with @Limit, ignore it
>  completely with @SuppressSysoutChecks or run with
> -Dtests.verbose=true
> at __randomizedtesting.SeedInfo.seed([3E554FE0FEE122B9]:0)
> at 
> org.apache.lucene.tests.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:283)
> at 
> com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
> at 
> org.apache.lucene.tests.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
> at 
> org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
> at 
> org.apache.lucene.tests.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:44)
> at 
> org.apache.lucene.tests.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:60)
> at 
> org.apache.lucene.tests.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:47)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:390)
> at 
> com.carrotsearch.randomizedtesting.ThreadLeakControl.lambda$forkTimeoutingTask$0(ThreadLeakControl.java:850)
> at java.base/java.lang.Thread.run(Thread.java:829)
>
> org.apache.lucene.codecs.simpletext.TestSimpleTextPostingsFormat >
> test suite's output saved to
> /tmp/smoke_lucene_9.8.0_d914b3722bd5b8ef31ccf7e8ddc638a87fd648db/unpack/lucene-9
> .8.0/lucene/codecs/build/test-results/test/outputs/OUTPUT-org.apache.lucene.codecs.simpletext.TestSimpleTextPostingsFormat.txt,
> copied below:
>   2> java.lang.reflect.InvocationTargetException
>   2>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
>   2>at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   2>at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   2>at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   2>at 
> 

Re: [JENKINS] Lucene » Lucene-NightlyTests-main - Build # 1132 - Unstable!

2023-09-25 Thread Luca Cavanna
I opened https://github.com/apache/lucene/pull/12588 as one way to address
this.

On Mon, Sep 25, 2023 at 2:07 PM Luca Cavanna  wrote:

> This is caused by https://github.com/apache/lucene/pull/12183 , yet I
> don't think there is anything wrong with the PR itself.
>
> Looking at the test and QueryUtils, we create a new searcher for each leaf
> reader, and each searcher gets a separate executor. That would be ok as
> long as the executors are shutdown promptly, but that is not the case here
> as they get terminated via a close listener associated with each index
> reader, which I believe is called only later in the AfterClass.
> I am thinking that we end up creating too many executors and that is why
> we in turn end up creating too many threads. I am looking into fixing this.
>
> On Fri, Sep 22, 2023 at 9:30 AM Dawid Weiss  wrote:
>
>>
>> This failed because the thread limit has been exhausted.
>>
>> [3241.014s][warning][os,thread] Failed to start thread "Unknown thread" - 
>> pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 
>> 0k, detached.
>> [3241.015s][warning][os,thread] Failed to start the native thread for 
>> java.lang.Thread "LuceneTestCase-7564-thread-1
>>
>> org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs > testP7 FAILED
>> java.lang.OutOfMemoryError: unable to create native thread: possibly out 
>> of memory or process/resource limits reached
>> at 
>> __randomizedtesting.SeedInfo.seed([B5DBA9A0960A3ECC:1F73384DEAF58B95]:0)
>> at java.base/java.lang.Thread.start0(Native Method)
>> at java.base/java.lang.Thread.start(Thread.java:798)
>> at 
>> java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:937)
>> at 
>> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1343)
>> at 
>> org.apache.lucene.search.TaskExecutor.invokeAll(TaskExecutor.java:73)
>> at org.apache.lucene.index.TermStates.build(TermStates.java:119)
>> at 
>> org.apache.lucene.search.PhraseQuery$1.getStats(PhraseQuery.java:458)
>> at org.apache.lucene.search.PhraseWeight.(PhraseWeight.java:44)
>> at 
>> org.apache.lucene.search.PhraseQuery$1.(PhraseQuery.java:439)
>> at 
>> org.apache.lucene.search.PhraseQuery.createWeight(PhraseQuery.java:439)
>> at 
>> org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:893)
>> at 
>> org.apache.lucene.tests.search.AssertingIndexSearcher.createWeight(AssertingIndexSearcher.java:62)
>> at 
>> org.apache.lucene.search.BooleanWeight.(BooleanWeight.java:59)
>> at 
>> org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:245)
>> at 
>> org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:893)
>> at 
>> org.apache.lucene.tests.search.AssertingIndexSearcher.createWeight(AssertingIndexSearcher.java:62)
>> at 
>> org.apache.lucene.tests.search.QueryUtils$4.doSetNextReader(QueryUtils.java:617)
>> at 
>> org.apache.lucene.search.SimpleCollector.getLeafCollector(SimpleCollector.java:31)
>> at 
>> org.apache.lucene.search.FilterCollector.getLeafCollector(FilterCollector.java:38)
>> at 
>> org.apache.lucene.tests.search.AssertingCollector.getLeafCollector(AssertingCollector.java:54)
>> at 
>> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:748)
>> at 
>> org.apache.lucene.tests.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:79)
>> at 
>> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:547)
>> at 
>> org.apache.lucene.tests.search.QueryUtils.checkFirstSkipTo(QueryUtils.java:549)
>> at 
>> org.apache.lucene.tests.search.QueryUtils.check(QueryUtils.java:138)
>> at 
>> org.apache.lucene.tests.search.QueryUtils.check(QueryUtils.java:131)
>> at 
>> org.apache.lucene.tests.search.CheckHits.checkHitCollector(CheckHits.java:106)
>> at 
>> org.apache.lucene.tests.search.BaseExplanationTestCase.qtest(BaseExplanationTestCase.java:110)
>> at 
>> org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs.qtest(TestSimpleExplanationsWithFillerDocs.java:116)
>> at 
>> org.apache.lucene.search.TestSimpleExplanations.testP7(TestSimpleExplanations.java:87)
>> at 
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
>> Method)
>> at 
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at 
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1758)
>> at 
>> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:946)
>>

Re: [JENKINS] Lucene » Lucene-NightlyTests-main - Build # 1132 - Unstable!

2023-09-25 Thread Luca Cavanna
This is caused by https://github.com/apache/lucene/pull/12183 , yet I don't
think there is anything wrong with the PR itself.

Looking at the test and QueryUtils, we create a new searcher for each leaf
reader, and each searcher gets a separate executor. That would be ok as
long as the executors are shutdown promptly, but that is not the case here
as they get terminated via a close listener associated with each index
reader, which I believe is called only later in the AfterClass.
I am thinking that we end up creating too many executors and that is why we
in turn end up creating too many threads. I am looking into fixing this.

On Fri, Sep 22, 2023 at 9:30 AM Dawid Weiss  wrote:

>
> This failed because the thread limit has been exhausted.
>
> [3241.014s][warning][os,thread] Failed to start thread "Unknown thread" - 
> pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 
> 0k, detached.
> [3241.015s][warning][os,thread] Failed to start the native thread for 
> java.lang.Thread "LuceneTestCase-7564-thread-1
>
> org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs > testP7 FAILED
> java.lang.OutOfMemoryError: unable to create native thread: possibly out 
> of memory or process/resource limits reached
> at 
> __randomizedtesting.SeedInfo.seed([B5DBA9A0960A3ECC:1F73384DEAF58B95]:0)
> at java.base/java.lang.Thread.start0(Native Method)
> at java.base/java.lang.Thread.start(Thread.java:798)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:937)
> at 
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1343)
> at 
> org.apache.lucene.search.TaskExecutor.invokeAll(TaskExecutor.java:73)
> at org.apache.lucene.index.TermStates.build(TermStates.java:119)
> at 
> org.apache.lucene.search.PhraseQuery$1.getStats(PhraseQuery.java:458)
> at org.apache.lucene.search.PhraseWeight.(PhraseWeight.java:44)
> at org.apache.lucene.search.PhraseQuery$1.(PhraseQuery.java:439)
> at 
> org.apache.lucene.search.PhraseQuery.createWeight(PhraseQuery.java:439)
> at 
> org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:893)
> at 
> org.apache.lucene.tests.search.AssertingIndexSearcher.createWeight(AssertingIndexSearcher.java:62)
> at 
> org.apache.lucene.search.BooleanWeight.(BooleanWeight.java:59)
> at 
> org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:245)
> at 
> org.apache.lucene.search.IndexSearcher.createWeight(IndexSearcher.java:893)
> at 
> org.apache.lucene.tests.search.AssertingIndexSearcher.createWeight(AssertingIndexSearcher.java:62)
> at 
> org.apache.lucene.tests.search.QueryUtils$4.doSetNextReader(QueryUtils.java:617)
> at 
> org.apache.lucene.search.SimpleCollector.getLeafCollector(SimpleCollector.java:31)
> at 
> org.apache.lucene.search.FilterCollector.getLeafCollector(FilterCollector.java:38)
> at 
> org.apache.lucene.tests.search.AssertingCollector.getLeafCollector(AssertingCollector.java:54)
> at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:748)
> at 
> org.apache.lucene.tests.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:79)
> at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:547)
> at 
> org.apache.lucene.tests.search.QueryUtils.checkFirstSkipTo(QueryUtils.java:549)
> at 
> org.apache.lucene.tests.search.QueryUtils.check(QueryUtils.java:138)
> at 
> org.apache.lucene.tests.search.QueryUtils.check(QueryUtils.java:131)
> at 
> org.apache.lucene.tests.search.CheckHits.checkHitCollector(CheckHits.java:106)
> at 
> org.apache.lucene.tests.search.BaseExplanationTestCase.qtest(BaseExplanationTestCase.java:110)
> at 
> org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs.qtest(TestSimpleExplanationsWithFillerDocs.java:116)
> at 
> org.apache.lucene.search.TestSimpleExplanations.testP7(TestSimpleExplanations.java:87)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1758)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:946)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:982)
> at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:996)
> at 
> 

Re: [VOTE] Release Lucene 9.8.0 RC1

2023-09-25 Thread Chris Hegarty
Hi,

>>   2>at Log4jHotPatch.asmVersion(Log4jHotPatch.java:71)

This coming from Amazon’s Log4Shell hot patch [1], which I believe was deployed 
by default on many (all?) JVM’s running on Amazon instances. Well… that was 
almost 2yrs ago, not sure why it’s still showing up in some places now - it 
should not be needed.

In fact, I do remember seeing and reporting this issue back in late 2021. The 
hot patcher initially used the JDK’s internal ASM library, which is the root 
cause of the security exception. The hot patcher was subsequently fixed to not 
do this - it bundles/shades ASM itself. This fix was made in late 2021.

I have no idea why the system in question is running an old version of the hot 
patcher. @Michael, you should probably take a look at that system, maybe it 
needs some updates or something?

-Chris.

[1] https://github.com/corretto/hotpatch-for-apache-log4j2/tree/main

> On 25 Sep 2023, at 09:22, Uwe Schindler  wrote:
> 
> Hi,
> 
> as Lucene does not use Log4j, it is unclear why it wants to patch anything. 
> The problem in indeed caused by SecurityManager which is enabled for running 
> Lucene tests. Actually it detects that something tries to access some 
> internals of ASM, not sure what it exactly does. The "injected" Agent code 
> must possibly use AccessController#doPrivileged and the security context must 
> allow patching of classes.
> 
> In short: SecurityManager has done everything it should do: It detected an 
> illegal access. Mission achieved! You have to report this issue and patch 
> your tool so it works correctly with SecurityManager.
> 
> Uwe
> 
> Am 24.09.2023 um 23:52 schrieb Michael Sokolov:
>> I ran the smoketester and had a failure. It seems related to some
>> log4j hot patch script we are required to run at work which is somehow
>> conflicting with the security manager? I'm killing that and trying
>> again, but I wonder if this is going to cause problems at runtime as
>> well? How do we enable the security manager -is it only when running
>> tests?
>> 
>> org.apache.lucene.codecs.simpletext.TestSimpleTextPostingsFormat >
>> classMethod FAILED
>> java.lang.AssertionError: The test or suite printed 15378 bytes to
>> stdout and stderr, even though the limit was set to 8192 bytes.
>> Increase the limit with @Limit, ignore it
>>  completely with @SuppressSysoutChecks or run with
>> -Dtests.verbose=true
>> at __randomizedtesting.SeedInfo.seed([3E554FE0FEE122B9]:0)
>> at 
>> org.apache.lucene.tests.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:283)
>> at 
>> com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
>> at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
>> at 
>> org.apache.lucene.tests.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
>> at 
>> org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
>> at 
>> org.apache.lucene.tests.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:44)
>> at 
>> org.apache.lucene.tests.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:60)
>> at 
>> org.apache.lucene.tests.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:47)
>> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>> at 
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>> at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:390)
>> at 
>> com.carrotsearch.randomizedtesting.ThreadLeakControl.lambda$forkTimeoutingTask$0(ThreadLeakControl.java:850)
>> at java.base/java.lang.Thread.run(Thread.java:829)
>> 
>> org.apache.lucene.codecs.simpletext.TestSimpleTextPostingsFormat >
>> test suite's output saved to
>> /tmp/smoke_lucene_9.8.0_d914b3722bd5b8ef31ccf7e8ddc638a87fd648db/unpack/lucene-9
>> .8.0/lucene/codecs/build/test-results/test/outputs/OUTPUT-org.apache.lucene.codecs.simpletext.TestSimpleTextPostingsFormat.txt,
>> copied below:
>>   2> java.lang.reflect.InvocationTargetException
>>   2>at 
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>>   2>at 
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>   2>at 
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>   2>at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>   2>at 
>> java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:513)
>>   2>at 
>> java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:535)
>>   2> Caused by: java.security.AccessControlException: access 

Re: [VOTE] Release Lucene 9.8.0 RC1

2023-09-25 Thread Uwe Schindler

Hi,

as Lucene does not use Log4j, it is unclear why it wants to patch 
anything. The problem in indeed caused by SecurityManager which is 
enabled for running Lucene tests. Actually it detects that something 
tries to access some internals of ASM, not sure what it exactly does. 
The "injected" Agent code must possibly use 
AccessController#doPrivileged and the security context must allow 
patching of classes.


In short: SecurityManager has done everything it should do: It detected 
an illegal access. Mission achieved! You have to report this issue and 
patch your tool so it works correctly with SecurityManager.


Uwe

Am 24.09.2023 um 23:52 schrieb Michael Sokolov:

I ran the smoketester and had a failure. It seems related to some
log4j hot patch script we are required to run at work which is somehow
conflicting with the security manager? I'm killing that and trying
again, but I wonder if this is going to cause problems at runtime as
well? How do we enable the security manager -is it only when running
tests?

org.apache.lucene.codecs.simpletext.TestSimpleTextPostingsFormat >
classMethod FAILED
 java.lang.AssertionError: The test or suite printed 15378 bytes to
stdout and stderr, even though the limit was set to 8192 bytes.
Increase the limit with @Limit, ignore it
  completely with @SuppressSysoutChecks or run with
-Dtests.verbose=true
 at __randomizedtesting.SeedInfo.seed([3E554FE0FEE122B9]:0)
 at 
org.apache.lucene.tests.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:283)
 at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
 at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
 at 
org.apache.lucene.tests.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
 at 
org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
 at 
org.apache.lucene.tests.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:44)
 at 
org.apache.lucene.tests.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:60)
 at 
org.apache.lucene.tests.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:47)
 at org.junit.rules.RunRules.evaluate(RunRules.java:20)
 at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:390)
 at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.lambda$forkTimeoutingTask$0(ThreadLeakControl.java:850)
 at java.base/java.lang.Thread.run(Thread.java:829)

org.apache.lucene.codecs.simpletext.TestSimpleTextPostingsFormat >
test suite's output saved to
/tmp/smoke_lucene_9.8.0_d914b3722bd5b8ef31ccf7e8ddc638a87fd648db/unpack/lucene-9
.8.0/lucene/codecs/build/test-results/test/outputs/OUTPUT-org.apache.lucene.codecs.simpletext.TestSimpleTextPostingsFormat.txt,
copied below:
   2> java.lang.reflect.InvocationTargetException
   2>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
   2>at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   2>at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   2>at java.base/java.lang.reflect.Method.invoke(Method.java:566)
   2>at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:513)
   2>at 
java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:535)
   2> Caused by: java.security.AccessControlException: access denied
("java.lang.RuntimePermission"
"accessClassInPackage.jdk.internal.org.objectweb.asm")
   2>at 
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
   2>at 
java.base/java.security.AccessController.checkPermission(AccessController.java:897)
   2>at 
java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
   2>at 
java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1238)
   2>at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:174)
   2>at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:527)
   2>at Log4jHotPatch.asmVersion(Log4jHotPatch.java:71)
   2>at Log4jHotPatch.agentmain(Log4jHotPatch.java:93)
   2>... 6 more

On Sat, Sep 23, 2023 at 12:46 PM Jan Høydahl  wrote:

Smoke tester only

SUCCESS! [1:22:37.441415]

+1 (binding)

Jan

22. sep. 2023 kl. 07:48 skrev Patrick Zhai :

Please vote for release candidate 1 for Lucene 9.8.0

The artifacts can be downloaded from: