[jira] [Resolved] (SOLR-7736) Add a test for ZkController.publishAndWaitForDownStates

[Shalin Shekhar Mangar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shalin Shekhar Mangar resolved SOLR-7736.
-
   Resolution: Fixed
 Assignee: Shalin Shekhar Mangar
Fix Version/s: (was: 6.0)
   (was: 5.5)
   master (8.0)
   7.4

> Add a test for ZkController.publishAndWaitForDownStates
> ---
>
> Key: SOLR-7736
> URL: https://issues.apache.org/jira/browse/SOLR-7736
> Project: Solr
>  Issue Type: Test
>  Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 7.4, master (8.0)
>
> Attachments: SOLR-7736.patch
>
>
> Add a test for ZkController.publishAndWaitForDownStates so that bugs like 
> SOLR-6665 do not occur again. A test exists but it is not correct and 
> currently disabled via AwaitsFix.



--
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

[jira] [Commented] (SOLR-7736) Add a test for ZkController.publishAndWaitForDownStates

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415040#comment-16415040
 ] 

ASF subversion and git services commented on SOLR-7736:
---

Commit 9b4d16963775f1a465f93542aef3eabc1e105afe in lucene-solr's branch 
refs/heads/branch_7x from [~shalinmangar]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9b4d169 ]

SOLR-7736: Fix ZkController.publishAndWaitForDownStates

(cherry picked from commit ecb94ba)


> Add a test for ZkController.publishAndWaitForDownStates
> ---
>
> Key: SOLR-7736
> URL: https://issues.apache.org/jira/browse/SOLR-7736
> Project: Solr
>  Issue Type: Test
>  Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-7736.patch
>
>
> Add a test for ZkController.publishAndWaitForDownStates so that bugs like 
> SOLR-6665 do not occur again. A test exists but it is not correct and 
> currently disabled via AwaitsFix.



--
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

BadApples this week

[Erick Erickson]

I've been uncomfortable with the chance that tests that _should_ fail
are going to be prematurely BadApple'd. It finally struck me that what
I'm most interested in at present is tests that fail and fail and fail
but aren't being addressed.

Mark's tests have a history available each week, and he'll try to
publish the list on Monday. I can preserve Hoss's tests in a CSV
format.

My new straw-man proposal: Each Monday I'll take any tests that failed
over the last week and BadApple them if they _also_ were reported as
failing prior to Monday of two weeks ago in either Hoss' or Mark's
reports. IOW, any failing tests that haven't been addressed for at
least a week are BadApple candidates.

Of course if anyone's working on them actively, let me know and we can
un-BadApple them. Or mark them AwaitsFix. I'll continue to publish the
list of new and current BadApples each Monday and give people a couple
of days to react.

Here's what it looks like with dates, the first Monday I'll be able to
do this is fully is 9-Apr. since it'll take me a couple of weeks to
preserve two week's worth of 7-day windows of Hoss' reports.

For instance, on 9-Apr I'll take the list of failing tests 2-9 Apr and
the BadApple candidates will be any tests mentioned in Mark's or Hoss'
reports that failed _on or before_ 26-Mar. So anything fixed in the
week of 26-Mar to 1-Apr _will not_ get BadApple'd.

For this Monday and next Monday, I'll just use Mark's archived reports
while I preserve Hoss' rollups

I'll give people a couple of days to object to new tests I'm going to
BadApple as usual.

*Remove BadApple notations:

AutoscalingHistoryTestHandler.testHistory() No appearances in
BadApples or Windows folders!


* Candidates this week (based on Mark's test results
only) Will BadApple them Thursday:


org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest.testCollectionReload
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeLostTrigger
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testScheduledTrigger
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingSorting
org.apache.solr.cloud.hdfs.HdfsBasicDistributedZk2Test.test
org.apache.solr.cloud.RestartWhileUpdatingTest.test
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeaderAfterRestart
org.apache.solr.cloud.TestPullReplica.testKillLeader
org.apache.solr.cloud.TestSegmentSorting.testAtomicUpdateOfSegmentSortField


All test failures

junit.framework.TestSuite.org.apache.lucene.index.TestIndexWriterDelete
junit.framework.TestSuite.org.apache.solr.analytics.facet.QueryFacetTest
junit.framework.TestSuite.org.apache.solr.analytics.NoFacetTest
junit.framework.TestSuite.org.apache.solr.cloud.api.collections.TestCollectionAPI
junit.framework.TestSuite.org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest
junit.framework.TestSuite.org.apache.solr.cloud.FullSolrCloudDistribCmdsTest
junit.framework.TestSuite.org.apache.solr.cloud.OverseerRolesTest
junit.framework.TestSuite.org.apache.solr.cloud.ZkControllerTest
junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample
org.apache.lucene.index.TestIndexSorting.testConcurrentUpdates
org.apache.lucene.index.TestIndexSorting.testMultiValuedRandom1
org.apache.lucene.index.TestIndexSorting.testRandom3
org.apache.lucene.index.TestIndexWriterDelete.testUpdatesOnDiskFull
org.apache.lucene.spatial3d.TestGeo3DPoint.testGeo3DRelations (DON't
BADAPPLE MAYBE)
org.apache.solr.client.solrj.impl.CloudSolrClientTest.preferLocalShardsTest
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testCopyOfRange
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testDistributions
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelCommitStream
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testParallelExecutorStream
org.apache.solr.cloud.AddReplicaTest.test
org.apache.solr.cloud.AliasIntegrationTest.testModifyPropertiesV1
org.apache.solr.cloud.api.collections.CollectionsAPIDistributedZkTest.testCollectionReload
org.apache.solr.cloud.api.collections.TestCollectionAPI.test
org.apache.solr.cloud.autoscaling.NodeLostTriggerTest.testListenerAcceptance
org.apache.solr.cloud.autoscaling.ScheduledTriggerTest.testTrigger
org.apache.solr.cloud.autoscaling.sim.TestComputePlanAction.testNodeWithMultipleReplicasLost
org.apache.solr.cloud.autoscaling.sim.TestTriggerIntegration.testNodeLostTrigger
org.apache.solr.cloud.autoscaling.TriggerIntegrationTest.testScheduledTrigger
org.apache.solr.cloud.cdcr.CdcrVersionReplicationTest.testCdcrDocVersions
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test
org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaOnIndexing
org.apache.solr.cloud.DocValuesNotIndexedTest.testGroupingSorting
org.apache.solr.cloud.hdfs.HdfsBasicDistributedZk2Test.test

[JENKINS] Lucene-Solr-7.x-MacOSX (64bit/jdk1.8.0) - Build # 538 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-MacOSX/538/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

5 tests failed.
FAILED:  org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir

Error Message:
Index: 0, Size: 0

Stack Trace:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at 
__randomizedtesting.SeedInfo.seed([38DB802FA0173E8D:7D0070CDB83972CF]:0)
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at 
org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.getDocFieldValue(CdcrBidirectionalTest.java:227)
at 
org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir(CdcrBidirectionalTest.java:200)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.cloud.cdcr.CdcrBidirectionalTest.testBiDir

Error Message:
Index: 0, Size: 0

Stack Trace:
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at 

[jira] [Commented] (SOLR-7736) Add a test for ZkController.publishAndWaitForDownStates

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415025#comment-16415025
 ] 

ASF subversion and git services commented on SOLR-7736:
---

Commit ecb94ba4422d1ed70bd368e7aa562012cc3853ba in lucene-solr's branch 
refs/heads/master from [~shalinmangar]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ecb94ba ]

SOLR-7736: Fix ZkController.publishAndWaitForDownStates


> Add a test for ZkController.publishAndWaitForDownStates
> ---
>
> Key: SOLR-7736
> URL: https://issues.apache.org/jira/browse/SOLR-7736
> Project: Solr
>  Issue Type: Test
>  Components: SolrCloud, Tests
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 5.5, 6.0
>
> Attachments: SOLR-7736.patch
>
>
> Add a test for ZkController.publishAndWaitForDownStates so that bugs like 
> SOLR-6665 do not occur again. A test exists but it is not correct and 
> currently disabled via AwaitsFix.



--
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

[jira] [Commented] (SOLR-12139) Support "eq" function for string fields

[Lucene/Solr QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16415020#comment-16415020
 ] 

Lucene/Solr QA commented on SOLR-12139:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
16s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 16s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 50m  9s{color} 
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 54m 54s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.autoscaling.TriggerIntegrationTest |
|   | solr.update.processor.AtomicUpdateProcessorFactoryTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12139 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12916226/SOLR-12139.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / e51735d |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_144 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/20/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/20/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/20/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Support "eq" function for string fields
> ---
>
> Key: SOLR-12139
> URL: https://issues.apache.org/jira/browse/SOLR-12139
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: search
>Reporter: Andrey Kudryavtsev
>Assignee: Mikhail Khludnev
>Priority: Minor
> Attachments: SOLR-12139.patch, SOLR-12139.patch
>
>
> I just discovered that {{eq}} user function will work for numeric fields only.
> For string types it results in {{java.lang.UnsupportedOperationException}}
> What do you think if we will extend it to support at least some of string 
> types as well?



--
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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_162) - Build # 21706 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21706/
Java: 64bit/jdk1.8.0_162 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaOnIndexing

Error Message:
Time out waiting for LIR state get removed

Stack Trace:
java.util.concurrent.TimeoutException: Time out waiting for LIR state get 
removed
at 
__randomizedtesting.SeedInfo.seed([C4B774F97D0D0F79:BDCC5876DE90C55A]:0)
at org.apache.solr.util.TimeOut.waitFor(TimeOut.java:66)
at 
org.apache.solr.cloud.DeleteReplicaTest.deleteReplicaOnIndexing(DeleteReplicaTest.java:331)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)




Build Log:
[...truncated 1835 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J0-20180327_023120_7141300370071473195209.sysout
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
  

[jira] [Commented] (SOLR-11934) Visit Solr logging, it's too noisy.

[Shawn Heisey (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414979#comment-16414979
 ] 

Shawn Heisey commented on SOLR-11934:
-

I wrote a lengthy comment on SOLR-7887, with some details that might help with 
deciding what the default logfile rotation size should be.  See the comment on 
that issue for full gory details.  Erick reminded me about this issue as the 
correct place to discuss it.

A summary, part of that long comment:

The 4MB log covered times from 18:51:26.552 to 18:57:58.139, about six and a 
half minutes. The 32MB log covered times from 18:01:23.375 to 18:58:13.886, 
which is almost an hour.

This server, running version 4.7.2, has a pretty low query rate, but each user 
query is quite large in terms URL parameter size -- filters are added by the 
application to limit what the user can see according to their permission level. 
 The log is dominated by the ping requests from the load balancer and those 
very large user queries.  It is my opinion that those logs should NOT be moved 
out of the INFO level.

I don't have any newer versions with production usage, so I can't comment on 
what will happen when running a version where attempts have been made to reduce 
the noise level in the logs.

Based on what I found when I examined my logs, I think the default logfile 
rotation size needs to be fairly large.  The current 4MB is certainly too 
small.  Perhaps 64MB or 128MB?  We'll need to see if we can ask some users 
varying traffic levels to provide us some information about their logfiles, to 
try and come up with a number that will preserve a decent amount of history for 
a "typical" install, without consuming REALLY large amounts of disk space.


> Visit Solr logging, it's too noisy.
> ---
>
> Key: SOLR-11934
> URL: https://issues.apache.org/jira/browse/SOLR-11934
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
>
> I think we have way too much INFO level logging. Or, perhaps more correctly, 
> Solr logging needs to be examined and messages logged at an appropriate level.
> We log every update at an INFO level for instance. But I think we log LIR at 
> INFO as well. As a sysadmin I don't care to have my logs polluted with a 
> message for every update, but if I'm trying to keep my system healthy I want 
> to see LIR messages and try to understand why.
> Plus, in large installations logging at INFO level is creating a _LOT_ of 
> files.
> What I want to discuss on this JIRA is
> 1> What kinds of messages do we want log at WARN, INFO, DEBUG, and TRACE 
> levels?
> 2> Who's the audience at each level? For a running system that's functioning, 
> sysops folks would really like WARN messages that mean something need 
> attention for instance. If I'm troubleshooting should I turn on INFO? DEBUG? 
> TRACE?
> So let's say we get some kind of agreement as to the above. Then I propose 
> three things
> 1> Someone (and probably me but all help gratefully accepted) needs to go 
> through our logging and assign appropriate levels. This will take quite a 
> while, I intend to work on it in small chunks.
> 2> Actually answer whether unnecessary objects are created when something 
> like log.info("whatever {}", someObjectOrMethodCall); is invoked. Is this 
> independent on the logging implementation used? The SLF4J and log4j seem a 
> bit contradictory.
> 3> Maybe regularize log, logger, LOG as variable names, but that's a nit.
> As a tactical approach, I suggest we tag each LoggerFactory.getLogger in 
> files we work on with //SOLR-(whatever number is assigned when I create 
> this). We can remove them all later, but since I expect to approach this 
> piecemeal it'd be nice to keep track of which files have been done already.
> Finally, I really really really don't want to do this all at once. There are 
> 5-6 thousand log messages. Even at 1,000 a week that's 6 weeks, even starting 
> now it would probably span the 7.3 release.
> This will probably be an umbrella issue so we can keep all the commits 
> straight and people can volunteer to "fix the files in core" as a separate 
> piece of work (hint).
> There are several existing JIRAs about logging in general, let's link them in 
> here as well.
> Let the discussion begin!



--
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

[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 21 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/21/

1 tests failed.
FAILED:  
org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest.testMultipleThreads

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([13B21A44A257644D:3F806DC92E9312C9]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:914)
at 
org.apache.solr.update.processor.AtomicUpdateProcessorFactoryTest.testMultipleThreads(AtomicUpdateProcessorFactoryTest.java:260)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request 
was:q=cat:cqcvbg31w5mtrxrzvyrq+2qy3iuuou9s1l04e9gup+l537586fmgnspdexar20+yom3z9jl3gimggudqv2i+y16i5ey89f8c79i2p9cv=xml
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:907)
  

[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk1.8.0) - Build # 4528 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4528/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.util.TestSolrCLIRunExample

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] 
org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: 
org.apache.solr.update.TransactionLog  at 
org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
  at org.apache.solr.update.TransactionLog.(TransactionLog.java:190)  at 
org.apache.solr.update.UpdateLog.newTransactionLog(UpdateLog.java:448)  at 
org.apache.solr.update.UpdateLog.ensureLog(UpdateLog.java:1261)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:534)  at 
org.apache.solr.update.UpdateLog.add(UpdateLog.java:519)  at 
org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:352)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:271)
  at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:221)
  at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:67)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:950)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1163)
  at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:633)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:475)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldNameMutatingUpdateProcessorFactory$1.processAdd(FieldNameMutatingUpdateProcessorFactory.java:75)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:118)
  at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55)
  at 
org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:92)
  at 
org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:98)  
at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:188)
  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readIterator(JavaBinUpdateRequestCodec.java:144)
  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:311) 
 at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:256)  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$1.readNamedList(JavaBinUpdateRequestCodec.java:130)
  at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:276) 
 at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:256)  at 
org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:178)  at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:195)
  at 
org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:109)
  at org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:55)  
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97)
  at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
  at 

[JENKINS] Lucene-Solr-7.x-Linux (32bit/jdk1.8.0_162) - Build # 1598 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1598/
Java: 32bit/jdk1.8.0_162 -server -XX:+UseSerialGC

5 tests failed.
FAILED:  org.apache.lucene.spatial3d.TestGeo3DPoint.testGeo3DRelations

Error Message:
assess edge that ends in a crossing can't both up and down

Stack Trace:
java.lang.AssertionError: assess edge that ends in a crossing can't both up and 
down
at 
__randomizedtesting.SeedInfo.seed([BACC479CC2D38CCA:AB33A084D9E2256]:0)
at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon$DualCrossingEdgeIterator.countCrossingPoint(GeoComplexPolygon.java:1438)
at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon$DualCrossingEdgeIterator.matches(GeoComplexPolygon.java:1283)
at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon$Node.traverse(GeoComplexPolygon.java:564)
at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon$Tree.traverse(GeoComplexPolygon.java:660)
at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon$Tree.traverse(GeoComplexPolygon.java:646)
at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon.isWithin(GeoComplexPolygon.java:370)
at 
org.apache.lucene.spatial3d.geom.GeoBaseMembershipShape.isWithin(GeoBaseMembershipShape.java:36)
at 
org.apache.lucene.spatial3d.geom.GeoBaseShape.getBounds(GeoBaseShape.java:43)
at 
org.apache.lucene.spatial3d.geom.GeoComplexPolygon.getBounds(GeoComplexPolygon.java:440)
at 
org.apache.lucene.spatial3d.TestGeo3DPoint.testGeo3DRelations(TestGeo3DPoint.java:224)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 

[jira] [Commented] (SOLR-11947) Math Expressions User Guide

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414911#comment-16414911
 ] 

ASF subversion and git services commented on SOLR-11947:


Commit e51735d8ea506fa003a1c6f3b81b0a9ca6488bb8 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e51735d ]

SOLR-11947: Try another new anchor format


> Math Expressions User Guide
> ---
>
> Key: SOLR-11947
> URL: https://issues.apache.org/jira/browse/SOLR-11947
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-11947.patch, SOLR-11947.patch
>
>




--
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

[jira] [Commented] (LUCENE-8192) Remove offsetsAreCorrect from BaseTokenStreamTestCase

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414907#comment-16414907
 ] 

ASF subversion and git services commented on LUCENE-8192:
-

Commit e80ee7fff85918e68c212757c0e6c4bddbdb5ab6 in lucene-solr's branch 
refs/heads/branch_7x from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e80ee7f ]

LUCENE-8192: always enforce index-time offsets are correct with 
BaseTokenStreamTestCase


> Remove offsetsAreCorrect from BaseTokenStreamTestCase
> -
>
> Key: LUCENE-8192
> URL: https://issues.apache.org/jira/browse/LUCENE-8192
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
> Fix For: trunk, 7.4
>
> Attachments: LUCENE-8192.patch, LUCENE-8192_prototype.patch, 
> LUCENE-8192_take_two.patch
>
>
> Similar to LUCENE-8191, now that indexwriter checks the offsets, this boolean 
> is useless: if offsets are broken it will still fail.
> We should just remove the boolean.



--
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

[jira] [Resolved] (LUCENE-8192) Remove offsetsAreCorrect from BaseTokenStreamTestCase

[Robert Muir (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir resolved LUCENE-8192.
-
   Resolution: Fixed
Fix Version/s: 7.4
   trunk

> Remove offsetsAreCorrect from BaseTokenStreamTestCase
> -
>
> Key: LUCENE-8192
> URL: https://issues.apache.org/jira/browse/LUCENE-8192
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
> Fix For: trunk, 7.4
>
> Attachments: LUCENE-8192.patch, LUCENE-8192_prototype.patch, 
> LUCENE-8192_take_two.patch
>
>
> Similar to LUCENE-8191, now that indexwriter checks the offsets, this boolean 
> is useless: if offsets are broken it will still fail.
> We should just remove the boolean.



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414905#comment-16414905
 ] 

Varun Thacker commented on SOLR-7887:
-

{quote}How about we do that change in master? A new major version is a great 
time for a change like that.
{quote}
+1 to wait for 8.0 for that . It's a one line change so maybe we should create 
a separate Jira for 8.0 and mark it as a blocker and when the release comes 
closer address it. That way we'll manage to keep the files in sync till then

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch, SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

Re: [JENKINS] Solr-reference-guide-master - Build # 6317 - Still Failing

[Joel Bernstein]

I've tried a couple different ways to make this work, but no luck yet.

Joel Bernstein
http://joelsolr.blogspot.com/

On Mon, Mar 26, 2018 at 10:04 PM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> Build: https://builds.apache.org/job/Solr-reference-guide-master/6317/
>
> Log:
> Started by timer
> [EnvInject] - Loading node environment variables.
> Building remotely on websites1 (git-websites) in workspace
> /home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
>  > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url git://git.apache.org/lucene-solr.git #
> timeout=10
> Cleaning workspace
>  > git rev-parse --verify HEAD # timeout=10
> Resetting working tree
>  > git reset --hard # timeout=10
>  > git clean -fdx # timeout=10
> Fetching upstream changes from git://git.apache.org/lucene-solr.git
>  > git --version # timeout=10
>  > git fetch --tags --progress git://git.apache.org/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
>  > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
>  > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
> Checking out Revision e595541ef3f9642632ac85d03c62616b5f70f1e4
> (refs/remotes/origin/master)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f e595541ef3f9642632ac85d03c62616b5f70f1e4
> Commit message: "LUCENE-8192: always enforce index-time offsets are
> correct with BaseTokenStreamTestCase"
>  > git rev-list --no-walk 3adacbc677eb23090d1d7e3775e331c98debab2e #
> timeout=10
> No emails were triggered.
> [Solr-reference-guide-master] $ /usr/bin/env bash /tmp/
> jenkins5946721804221830772.sh
> + set -e
> + RVM_PATH=/home/jenkins/.rvm
> + RUBY_VERSION=ruby-2.3.3
> + GEMSET=solr-refguide-gemset
> + curl -sSL https://get.rvm.io
> + bash -s -- --ignore-dotfiles stable
> Turning on ignore dotfiles mode.
> Downloading https://github.com/rvm/rvm/archive/1.29.3.tar.gz
> Downloading https://github.com/rvm/rvm/releases/download/1.29.3/1.29.
> 3.tar.gz.asc
> gpg: Signature made Sun 10 Sep 2017 08:59:21 PM UTC using RSA key ID
> BF04FF17
> gpg: Good signature from "Michal Papis (RVM signing) "
> gpg: aka "Michal Papis "
> gpg: aka "[jpeg image of size 5015]"
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the
> owner.
> Primary key fingerprint: 409B 6B17 96C2 7546 2A17  0311 3804 BB82 D39D C0E3
>  Subkey fingerprint: 62C9 E5F4 DA30 0D94 AC36  166B E206 C29F BF04 FF17
> GPG verified '/home/jenkins/.rvm/archives/rvm-1.29.3.tgz'
>
> Upgrading the RVM installation in /home/jenkins/.rvm/
> Upgrade of RVM in /home/jenkins/.rvm/ is complete.
>
> Upgrade Notes:
>
>   * No new notes to display.
>
> + set +x
> Running 'source /home/jenkins/.rvm/scripts/rvm'
> Running 'rvm autolibs disable'
> Running 'rvm install ruby-2.3.3'
> Already installed ruby-2.3.3.
> To reinstall use:
>
> rvm reinstall ruby-2.3.3
>
> Running 'rvm gemset create solr-refguide-gemset'
> ruby-2.3.3 - #gemset created /home/jenkins/.rvm/gems/ruby-
> 2.3.3@solr-refguide-gemset
>  [32mruby-2.3.3 - #generating solr-refguide-gemset wrappers [0m| / - \ | /
> - \ | .- \ | / - \ | / - .| / - \ | / - \ | .- \ | / - \ | / - .| / - \ | /
> - \ | .- \ | / - \ | / - .| / - \ | / - \ | .- \ | / - .
> Running 'rvm ruby-2.3.3@solr-refguide-gemset'
> Using /home/jenkins/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
> Running 'gem install --force --version 3.5.0 jekyll'
> Successfully installed jekyll-3.5.0
> Parsing documentation for jekyll-3.5.0
> Done installing documentation for jekyll after 1 seconds
> 1 gem installed
> Running 'gem install --force --version 2.1.0 jekyll-asciidoc'
> Successfully installed jekyll-asciidoc-2.1.0
> Parsing documentation for jekyll-asciidoc-2.1.0
> Done installing documentation for jekyll-asciidoc after 0 seconds
> 1 gem installed
> Running 'gem install --force --version 1.1.2 pygments.rb'
> Successfully installed pygments.rb-1.1.2
> Parsing documentation for pygments.rb-1.1.2
> Done installing documentation for pygments.rb after 0 seconds
> 1 gem installed
> Running 'ant ivy-bootstrap'
> Buildfile: /home/jenkins/jenkins-slave/workspace/Solr-reference-
> guide-master/build.xml
>
> -ivy-bootstrap1:
>  [echo] installing ivy 2.4.0 to /home/jenkins/.ant/lib
>   [get] Getting: http://repo1.maven.org/maven2/
> org/apache/ivy/ivy/2.4.0/ivy-2.4.0.jar
>   [get] To: /home/jenkins/.ant/lib/ivy-2.4.0.jar
>   [get] Not modified - so not downloaded
>
> -ivy-bootstrap2:
>
> -ivy-checksum:
>
> -ivy-remove-old-versions:
>
> ivy-bootstrap:
>
> BUILD SUCCESSFUL
> Total time: 0 seconds
> + ant clean build-site build-pdf
> Buildfile: /home/jenkins/jenkins-slave/workspace/Solr-reference-
> guide-master/solr/solr-ref-guide/build.xml
>
> clean:
>
> build-init:
> [mkdir] 

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414901#comment-16414901
 ] 

Erick Erickson commented on SOLR-7887:
--

SOLR-11934 is another place to discuss this I think. There are several thousand 
places we log messages, I suspect a lot of them could have their level changed, 
be removed, whatever.

Or maybe we just need to get better about recommending WARN level (or even 
default to WARN?).

But that discussion is for 11934.

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch, SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Commented] (SOLR-11982) Add support for indicating preferred replica types for queries

[Lucene/Solr QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414898#comment-16414898
 ] 

Lucene/Solr QA commented on SOLR-11982:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
38s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} | 
{color:green}  1m 24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} | 
{color:green}  1m 15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} | 
{color:green}  1m 15s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} Validate ref guide {color} | {color:red}  
1m 15s{color} | {color:red} Validate ref guide bare-bones-html-validation 
failed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 48m 54s{color} 
| {color:red} core in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  5m  
4s{color} | {color:green} solrj in the patch passed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 60m 13s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.cloud.TestTlogReplica |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-11982 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12916188/SOLR-11982.patch |
| Optional Tests |  compile  javac  unit  ratsources  checkforbiddenapis  
validatesourcepatterns  validaterefguide  |
| uname | Linux lucene1-us-west 3.13.0-88-generic #135-Ubuntu SMP Wed Jun 8 
21:10:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
 |
| git revision | master / 3adacbc |
| ant | version: Apache Ant(TM) version 1.9.3 compiled on April 8 2014 |
| Default Java | 1.8.0_144 |
| Validate ref guide | 
https://builds.apache.org/job/PreCommit-SOLR-Build/19/artifact/out/patch-bare-bones-html-validation-solr_solr-ref-guide.txt
 |
| unit | 
https://builds.apache.org/job/PreCommit-SOLR-Build/19/artifact/out/patch-unit-solr_core.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-SOLR-Build/19/testReport/ |
| modules | C: solr solr/core solr/solrj solr/solr-ref-guide U: solr |
| Console output | 
https://builds.apache.org/job/PreCommit-SOLR-Build/19/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Add support for indicating preferred replica types for queries
> --
>
> Key: SOLR-11982
> URL: https://issues.apache.org/jira/browse/SOLR-11982
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 7.4, master (8.0)
>Reporter: Ere Maijala
>Priority: Minor
>  Labels: patch-available, patch-with-test
> Attachments: SOLR-11982-preferReplicaTypes.patch, 
> SOLR-11982-preferReplicaTypes.patch, SOLR-11982.patch, SOLR-11982.patch, 
> SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch, SOLR-11982.patch, 
> SOLR-11982.patch, SOLR-11982.patch
>
>
> It would be nice to have the possibility to easily sort the shards in the 
> preferred order e.g. by replica type. The attached patch adds support for 
> {{shards.sort}} parameter that allows one to sort e.g. PULL and TLOG replicas 
> first with \{{shards.sort=replicaType:PULL|TLOG }}(which would mean that NRT 
> replicas wouldn't be hit with queries unless they're the only ones available) 
> and/or to sort by replica location (like preferLocalShards=true but more 
> versatile).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For 

[JENKINS] Solr-reference-guide-master - Build # 6317 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-master/6317/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision e595541ef3f9642632ac85d03c62616b5f70f1e4 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f e595541ef3f9642632ac85d03c62616b5f70f1e4
Commit message: "LUCENE-8192: always enforce index-time offsets are correct 
with BaseTokenStreamTestCase"
 > git rev-list --no-walk 3adacbc677eb23090d1d7e3775e331c98debab2e # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /usr/bin/env bash 
/tmp/jenkins5946721804221830772.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.3.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.3/1.29.3.tar.gz.asc
gpg: Signature made Sun 10 Sep 2017 08:59:21 PM UTC using RSA key ID BF04FF17
gpg: Good signature from "Michal Papis (RVM signing) "
gpg: aka "Michal Papis "
gpg: aka "[jpeg image of size 5015]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 409B 6B17 96C2 7546 2A17  0311 3804 BB82 D39D C0E3
 Subkey fingerprint: 62C9 E5F4 DA30 0D94 AC36  166B E206 C29F BF04 FF17
GPG verified '/home/jenkins/.rvm/archives/rvm-1.29.3.tgz'

Upgrading the RVM installation in /home/jenkins/.rvm/
Upgrade of RVM in /home/jenkins/.rvm/ is complete.

Upgrade Notes:

  * No new notes to display.

+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm autolibs disable'
Running 'rvm install ruby-2.3.3'
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
Parsing documentation for jekyll-3.5.0
Done installing documentation for jekyll after 1 seconds
1 gem installed
Running 'gem install --force --version 2.1.0 jekyll-asciidoc'
Successfully installed jekyll-asciidoc-2.1.0
Parsing documentation for jekyll-asciidoc-2.1.0
Done installing documentation for jekyll-asciidoc after 0 seconds
1 gem installed
Running 'gem install --force --version 1.1.2 pygments.rb'
Successfully installed pygments.rb-1.1.2
Parsing documentation for pygments.rb-1.1.2
Done installing documentation for pygments.rb after 0 seconds
1 gem installed
Running 'ant ivy-bootstrap'
Buildfile: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/build.xml

-ivy-bootstrap1:
 [echo] installing ivy 2.4.0 to /home/jenkins/.ant/lib
  [get] Getting: 
http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.4.0/ivy-2.4.0.jar
  [get] To: /home/jenkins/.ant/lib/ivy-2.4.0.jar
  [get] Not modified - so not downloaded

-ivy-bootstrap2:

-ivy-checksum:

-ivy-remove-old-versions:

ivy-bootstrap:

BUILD SUCCESSFUL
Total time: 0 seconds
+ ant clean build-site build-pdf
Buildfile: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/solr-ref-guide/build.xml

clean:

build-init:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copying all non template files from src ...
 [copy] Copying 410 files to 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copy (w/prop replacement) any template files from src...
 [copy] Copying 1 file to 

[jira] [Commented] (LUCENE-8192) Remove offsetsAreCorrect from BaseTokenStreamTestCase

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414896#comment-16414896
 ] 

ASF subversion and git services commented on LUCENE-8192:
-

Commit e595541ef3f9642632ac85d03c62616b5f70f1e4 in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e595541 ]

LUCENE-8192: always enforce index-time offsets are correct with 
BaseTokenStreamTestCase


> Remove offsetsAreCorrect from BaseTokenStreamTestCase
> -
>
> Key: LUCENE-8192
> URL: https://issues.apache.org/jira/browse/LUCENE-8192
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-8192.patch, LUCENE-8192_prototype.patch, 
> LUCENE-8192_take_two.patch
>
>
> Similar to LUCENE-8191, now that indexwriter checks the offsets, this boolean 
> is useless: if offsets are broken it will still fail.
> We should just remove the boolean.



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Shawn Heisey (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414870#comment-16414870
 ] 

Shawn Heisey commented on SOLR-7887:


Here's some data for the discussion about what file size to use to rotation:

I used "tail" to give me the last 4194304 bytes of a log, and then the last 
33554432 bytes of the same log.  It is the primary online server for our 
installation, serving as a shard aggregator for an index that spans two 
servers, with seven shards.

The query rate for the last fifteen minutes is 0.73 per second on one handler, 
and 0.06 per second on another handler.  The load balancer sends pings pretty 
frequently.  I did not check the query rate on the handler that the ping 
handler uses for its queries.  It is a separate handler so that those queries 
do not pollute the statistics for the "real" handlers.

The 4MB log covered times from 18:51:26.552 to 18:57:58.139, about six and a 
half minutes.  The 32MB log covered times from 18:01:23.375 to 18:58:13.886, 
which is almost an hour.

Keep in mind that the query rate on this system is VERY VERY low.  Users that 
are handling 20-100 queries per second on each server are going to have a LOT 
more data logged in a given time period.

My queries tend to be REALLY large.  One of them that I just looked at had 
nearly 4000 bytes of URL parameters, and I have seen some approaching 2 
bytes.  When a query like this happens, it typically gets logged four times by 
each server.  The online primary system with the aggregating core has three 
shards, plus has to log once at the end for the aggregating core, and the other 
system has four shards.

In my logging config, I set log4j.appender.file.MaxFileSize to 2GB.  Which is a 
lot larger than I think Solr should use by default, but not outrageous for a 
really busy server.  I make it that big so that I don't have to look through a 
lot of logs to find info for a query that somebody had a problem with yesterday.

It would be really nice if the size could be configured in solr.in.sh.

On the subject of gzipping the rotated logs:  I like log rotation systems that 
take care of compressing old logs for me.  How about we do that change in 
master?  A new major version is a great time for a change like that.


> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch, SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Commented] (SOLR-11947) Math Expressions User Guide

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414865#comment-16414865
 ] 

ASF subversion and git services commented on SOLR-11947:


Commit 8e68bdffebb47389298183f6a5e86ec32b3bf975 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8e68bdf ]

SOLR-11947: Try new anchor format


> Math Expressions User Guide
> ---
>
> Key: SOLR-11947
> URL: https://issues.apache.org/jira/browse/SOLR-11947
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-11947.patch, SOLR-11947.patch
>
>




--
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

[JENKINS] Solr-reference-guide-master - Build # 6316 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-master/6316/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 3adacbc677eb23090d1d7e3775e331c98debab2e 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 3adacbc677eb23090d1d7e3775e331c98debab2e
Commit message: "SOLR-11947: Fix more broken links"
 > git rev-list --no-walk bd429347b19ccee9eb8a72ad182f4332dad5eef4 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /usr/bin/env bash 
/tmp/jenkins4274351918853051198.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.3.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.3/1.29.3.tar.gz.asc
gpg: Signature made Sun 10 Sep 2017 08:59:21 PM UTC using RSA key ID BF04FF17
gpg: Good signature from "Michal Papis (RVM signing) "
gpg: aka "Michal Papis "
gpg: aka "[jpeg image of size 5015]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 409B 6B17 96C2 7546 2A17  0311 3804 BB82 D39D C0E3
 Subkey fingerprint: 62C9 E5F4 DA30 0D94 AC36  166B E206 C29F BF04 FF17
GPG verified '/home/jenkins/.rvm/archives/rvm-1.29.3.tgz'

Upgrading the RVM installation in /home/jenkins/.rvm/
Upgrade of RVM in /home/jenkins/.rvm/ is complete.

Upgrade Notes:

  * No new notes to display.

+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm autolibs disable'
Running 'rvm install ruby-2.3.3'
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
Parsing documentation for jekyll-3.5.0
Done installing documentation for jekyll after 1 seconds
1 gem installed
Running 'gem install --force --version 2.1.0 jekyll-asciidoc'
Successfully installed jekyll-asciidoc-2.1.0
Parsing documentation for jekyll-asciidoc-2.1.0
Done installing documentation for jekyll-asciidoc after 0 seconds
1 gem installed
Running 'gem install --force --version 1.1.2 pygments.rb'
Successfully installed pygments.rb-1.1.2
Parsing documentation for pygments.rb-1.1.2
Done installing documentation for pygments.rb after 0 seconds
1 gem installed
Running 'ant ivy-bootstrap'
Buildfile: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/build.xml

-ivy-bootstrap1:
 [echo] installing ivy 2.4.0 to /home/jenkins/.ant/lib
  [get] Getting: 
http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.4.0/ivy-2.4.0.jar
  [get] To: /home/jenkins/.ant/lib/ivy-2.4.0.jar
  [get] Not modified - so not downloaded

-ivy-bootstrap2:

-ivy-checksum:

-ivy-remove-old-versions:

ivy-bootstrap:

BUILD SUCCESSFUL
Total time: 0 seconds
+ ant clean build-site build-pdf
Buildfile: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/solr-ref-guide/build.xml

clean:

build-init:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copying all non template files from src ...
 [copy] Copying 410 files to 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copy (w/prop replacement) any template files from src...
 [copy] Copying 1 file to 

[jira] [Commented] (SOLR-12144) Remove SOLR_LOG_PRESTART_ROTATION and leverage log4j2

[Shawn Heisey (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414844#comment-16414844
 ] 

Shawn Heisey commented on SOLR-12144:
-

That is such a nice feature.  No more messing with logs in the start script, 
and having that rotation fail if the logging configuration changes in an 
incompatible way.


> Remove SOLR_LOG_PRESTART_ROTATION and leverage log4j2 
> --
>
> Key: SOLR-12144
> URL: https://issues.apache.org/jira/browse/SOLR-12144
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Major
>
> With log4j2 rotating the file on restart is as simple as adding a policy - 
> OnStartupTriggeringPolicy
> So we can remove Solr logic which does the same and exposes it via 
> SOLR_LOG_PRESTART_ROTATION .
>  



--
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

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-7.x #164: POMs out of sync

[Erick Erickson]

I was asking about that on the JIRA, but nobody responded with it
being necessary so I took it out. Sh, I guess it'll have to go
back in.

Erick

On Mon, Mar 26, 2018 at 2:33 PM, Steve Rowe  wrote:
> There’s a missing indirect Yetus dependency from ZooKeeper.
>
> This surfaced a while back on SOLR-7887: 
> 
>  and 
> 
>
> Looks like Erick took the dependency out of the patch before SOLR-7887 
> landed, but IIRC the dependency is still required.
>
> More links:
> * : where ZooKeeper added the 
> dependency.
> * : why compilation is 
> failing.
>
> Varun, do you have more details?
>
> --
> Steve
> www.lucidworks.com
>
>> On Mar 26, 2018, at 5:15 PM, Uwe Schindler  wrote:
>>
>> No idea what's wrong here.
>>
>> Am March 26, 2018 9:11:50 PM UTC schrieb Apache Jenkins Server 
>> :
>> Build: https://builds.apache.org/job/Lucene-Solr-Maven-7.x/164/
>>
>> No tests ran.
>>
>> Build Log:
>> [...truncated 31720 lines...]
>>   [mvn] [INFO]
>>
>>   [mvn] [INFO]
>>
>>   [mvn] [ERROR] COMPILATION ERROR :
>>   [mvn] [INFO]
>>
>>
>> [...truncated 204 lines...]
>> BUILD FAILED
>> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/build.xml:679: The 
>> following error occurred while executing this line:
>> : Java returned: 1
>>
>> Total time: 15 minutes 43 seconds
>> Build step 'Invoke Ant' marked build as failure
>> Email was triggered for: Failure - Any
>> Sending email for trigger: Failure - Any
>>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9852) Solr JDBC doesn't implement columns' metadata

[Kevin Risden (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414827#comment-16414827
 ] 

Kevin Risden commented on SOLR-9852:


[~saumitras] - As far as I know no one is working on this currently. When I 
first worked on the SQL integration with Solr, I was able to get a JDBC-ODBC 
bridge to work. 

 

You would need to figure out what the stack trace is and find the exact method 
that needs to be implemented. There are a LOT of different places where 
metadata can be pulled from. Once you have the exact stack trace, then you can 
work on implementing the proper return metadata.

> Solr JDBC doesn't implement columns' metadata
> -
>
> Key: SOLR-9852
> URL: https://issues.apache.org/jira/browse/SOLR-9852
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Parallel SQL
>Affects Versions: 6.3
> Environment: N/A
>Reporter: Rani Y.
>Priority: Major
>  Labels: solrJ
>
> This is the error I get (from Squirrel SQL) while trying to get the objects 
> -meaning both tables and columns metadata
> 2016-12-12 13:47:48,241 [Thread-2] ERROR 
> net.sourceforge.squirrel_sql.client.session.schemainfo.SchemaInfo  - Error 
> occurred creating data types collection
> java.lang.UnsupportedOperationException
>   at 
> org.apache.solr.client.solrj.io.sql.DatabaseMetaDataImpl.getTypeInfo(DatabaseMetaDataImpl.java:773)
>   at 
> net.sourceforge.squirrel_sql.fw.sql.SQLDatabaseMetaData.getDataTypesSimpleNames(SQLDatabaseMetaData.java:1978)
>   at 
> net.sourceforge.squirrel_sql.client.session.schemainfo.SchemaInfo.loadDataTypes(SchemaInfo.java:900)
>   at 
> net.sourceforge.squirrel_sql.client.session.schemainfo.SchemaInfo.privateLoadAll(SchemaInfo.java:315)
>   at 
> net.sourceforge.squirrel_sql.client.session.schemainfo.SchemaInfo.reloadAll(SchemaInfo.java:208)
>   at 
> net.sourceforge.squirrel_sql.client.session.schemainfo.SchemaInfo.reloadAll(SchemaInfo.java:198)
>   at 
> net.sourceforge.squirrel_sql.client.session.mainpanel.objecttree.ObjectTree$3.run(ObjectTree.java:315)
>   at 
> net.sourceforge.squirrel_sql.fw.util.TaskExecuter.run(TaskExecuter.java:82)
>   at java.lang.Thread.run(Thread.java:745)



--
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

[jira] [Commented] (SOLR-12144) Remove SOLR_LOG_PRESTART_ROTATION and leverage log4j2

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414826#comment-16414826
 ] 

Varun Thacker commented on SOLR-12144:
--

SOLR_LOG_PRESTART_ROTATION also archives console logs and gc logs. So the fix 
might not to remove the flag completely.

Notes from Jan on SOLR-7887 for reference 
{quote}Since the current workaround is less than optimal, e.g. you need to 
update numbers in {{bin/solr}} script whenever you reconfigure log4j – I think 
we should start using log4j2's {{OnStartupTriggeringPolicy}} and simply delete 
the whole workaround, at least the {{SolrCLI#rotateSolrLogs}}, perhaps also the 
{{#removeOldSolrLogs}} since it tries to delete timestamped {{solr_log_*}} 
files which were produced by an older version of Solr but not anymore.
{quote}
 

> Remove SOLR_LOG_PRESTART_ROTATION and leverage log4j2 
> --
>
> Key: SOLR-12144
> URL: https://issues.apache.org/jira/browse/SOLR-12144
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
>Priority: Major
>
> With log4j2 rotating the file on restart is as simple as adding a policy - 
> OnStartupTriggeringPolicy
> So we can remove Solr logic which does the same and exposes it via 
> SOLR_LOG_PRESTART_ROTATION .
>  



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414824#comment-16414824
 ] 

Varun Thacker commented on SOLR-7887:
-

[~janhoy] I created SOLR-12144 to track the work to remove 
SOLR_LOG_PRESTART_ROTATION 

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch, SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Created] (SOLR-12144) Remove SOLR_LOG_PRESTART_ROTATION and leverage log4j2

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-12144:


 Summary: Remove SOLR_LOG_PRESTART_ROTATION and leverage log4j2 
 Key: SOLR-12144
 URL: https://issues.apache.org/jira/browse/SOLR-12144
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker


With log4j2 rotating the file on restart is as simple as adding a policy - 
OnStartupTriggeringPolicy

So we can remove Solr logic which does the same and exposes it via 
SOLR_LOG_PRESTART_ROTATION .

 



--
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

[JENKINS] Lucene-Solr-7.x-Windows (64bit/jdk1.8.0_144) - Build # 520 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/520/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.common.util.TestTimeSource.testEpochTime

Error Message:
SimTimeSource:50.0 time diff=26471000

Stack Trace:
java.lang.AssertionError: SimTimeSource:50.0 time diff=26471000
at 
__randomizedtesting.SeedInfo.seed([BDD7508AB1BB814:33B1062D3FCB1A52]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.common.util.TestTimeSource.doTestEpochTime(TestTimeSource.java:48)
at 
org.apache.solr.common.util.TestTimeSource.testEpochTime(TestTimeSource.java:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.lang.Thread.run(Thread.java:748)


FAILED:  org.apache.solr.common.util.TestTimeSource.testEpochTime

Error Message:
NanoTimeSource time diff=417280

Stack Trace:
java.lang.AssertionError: NanoTimeSource time diff=417280
at 

[jira] [Resolved] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[Robert Muir (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir resolved LUCENE-8175.
-
   Resolution: Fixed
Fix Version/s: 7.4
   trunk

> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
> Fix For: trunk, 7.4
>
> Attachments: LUCENE-8175.patch
>
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Comment Edited] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414804#comment-16414804
 ] 

Uwe Schindler edited comment on SOLR-12141 at 3/27/18 12:13 AM:


Alternatively this shell command would work to get "major" java version:

{noformat}
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk1.8.0_162/bin/java -version 
2>&1 | head -1 | sed -Ee's/^.*version "(1\.)?([0-9]+)?.*$/\2/'
8
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk-9/bin/java -version 2>&1 | 
head -1 | sed -Ee's/^.*version "(1\.)?([0-9]+)?.*$/\2/'
9
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk-9.0.4/bin/java -version 
2>&1 | head -1 | sed -Ee's/^.*version "(1\.)?([0-9]+)?.*$/\2/'
9
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk-10/bin/java -version 2>&1 
| head -1 | sed -Ee's/^.*version "(1\.)?([0-9]+)?.*$/\2/'
10
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk-11-ea+5/bin/java -version 
2>&1 | head -1 | sed -Ee's/^.*version "(1\.)?([0-9]+)?.*$/\2/'
11
{noformat}

Works on Linux and Macintosh, on Solaris it would need "gsed".


was (Author: thetaphi):
Alternatively this shell command would work to get "major" java version:

{noformat}
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk1.8.0_162/bin/java -version 
2>&1 | head -1 | sed -Ee's/^.*version "(1\.)?([0-9]
+)?.*$/\2/'
8
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk-9/bin/java -version 2>&1 | 
head -1 | sed -Ee's/^.*version "(1\.)?([0-9]+)?.*$/
\2/'
9
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk-9.0.4/bin/java -version 
2>&1 | head -1 | sed -Ee's/^.*version "(1\.)?([0-9]+)?
.*$/\2/'
9
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk-10/bin/java -version 2>&1 
| head -1 | sed -Ee's/^.*version "(1\.)?([0-9]+)?.*$
/\2/'
10
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk-11-ea+5/bin/java -version 
2>&1 | head -1 | sed -Ee's/^.*version "(1\.)?([0-9]+
)?.*$/\2/'
11
{noformat}

Works on Linux and Macintosh, on Solaris it would need "gsed".

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch, SOLR-12141.patch, 
> SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[jira] [Commented] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414805#comment-16414805
 ] 

ASF subversion and git services commented on LUCENE-8175:
-

Commit 43796e516932881da7abbc8cc379ec2661020f7e in lucene-solr's branch 
refs/heads/branch_7x from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=43796e5 ]

LUCENE-8175: upgrade icu4j to 61.1 which fixes concurrency issue


> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
> Fix For: trunk, 7.4
>
> Attachments: LUCENE-8175.patch
>
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Commented] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414804#comment-16414804
 ] 

Uwe Schindler commented on SOLR-12141:
--

Alternatively this shell command would work to get "major" java version:

{noformat}
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk1.8.0_162/bin/java -version 
2>&1 | head -1 | sed -Ee's/^.*version "(1\.)?([0-9]
+)?.*$/\2/'
8
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk-9/bin/java -version 2>&1 | 
head -1 | sed -Ee's/^.*version "(1\.)?([0-9]+)?.*$/
\2/'
9
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk-9.0.4/bin/java -version 
2>&1 | head -1 | sed -Ee's/^.*version "(1\.)?([0-9]+)?
.*$/\2/'
9
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk-10/bin/java -version 2>&1 
| head -1 | sed -Ee's/^.*version "(1\.)?([0-9]+)?.*$
/\2/'
10
thetaphi@serv1:~$ /home/jenkins/tools/java/64bit/jdk-11-ea+5/bin/java -version 
2>&1 | head -1 | sed -Ee's/^.*version "(1\.)?([0-9]+
)?.*$/\2/'
11
{noformat}

Works on Linux and Macintosh, on Solaris it would need "gsed".

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch, SOLR-12141.patch, 
> SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[jira] [Commented] (SOLR-11947) Math Expressions User Guide

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414799#comment-16414799
 ] 

ASF subversion and git services commented on SOLR-11947:


Commit 3adacbc677eb23090d1d7e3775e331c98debab2e in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3adacbc ]

SOLR-11947: Fix more broken links


> Math Expressions User Guide
> ---
>
> Key: SOLR-11947
> URL: https://issues.apache.org/jira/browse/SOLR-11947
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-11947.patch, SOLR-11947.patch
>
>




--
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

[JENKINS] Solr-reference-guide-master - Build # 6315 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-master/6315/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision bd429347b19ccee9eb8a72ad182f4332dad5eef4 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f bd429347b19ccee9eb8a72ad182f4332dad5eef4
Commit message: "SOLR-7887: Log4J2 upgrade fixes part 2"
 > git rev-list --no-walk 40c8792dbfe70e09ad6b4c1fae2cdcf62da9637e # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /usr/bin/env bash 
/tmp/jenkins1221440099091940205.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.3.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.3/1.29.3.tar.gz.asc
gpg: Signature made Sun 10 Sep 2017 08:59:21 PM UTC using RSA key ID BF04FF17
gpg: Good signature from "Michal Papis (RVM signing) "
gpg: aka "Michal Papis "
gpg: aka "[jpeg image of size 5015]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 409B 6B17 96C2 7546 2A17  0311 3804 BB82 D39D C0E3
 Subkey fingerprint: 62C9 E5F4 DA30 0D94 AC36  166B E206 C29F BF04 FF17
GPG verified '/home/jenkins/.rvm/archives/rvm-1.29.3.tgz'

Upgrading the RVM installation in /home/jenkins/.rvm/
Upgrade of RVM in /home/jenkins/.rvm/ is complete.

Upgrade Notes:

  * No new notes to display.

+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm autolibs disable'
Running 'rvm install ruby-2.3.3'
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
Parsing documentation for jekyll-3.5.0
Done installing documentation for jekyll after 1 seconds
1 gem installed
Running 'gem install --force --version 2.1.0 jekyll-asciidoc'
Successfully installed jekyll-asciidoc-2.1.0
Parsing documentation for jekyll-asciidoc-2.1.0
Done installing documentation for jekyll-asciidoc after 0 seconds
1 gem installed
Running 'gem install --force --version 1.1.2 pygments.rb'
Successfully installed pygments.rb-1.1.2
Parsing documentation for pygments.rb-1.1.2
Done installing documentation for pygments.rb after 0 seconds
1 gem installed
Running 'ant ivy-bootstrap'
Buildfile: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/build.xml

-ivy-bootstrap1:
 [echo] installing ivy 2.4.0 to /home/jenkins/.ant/lib
  [get] Getting: 
http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.4.0/ivy-2.4.0.jar
  [get] To: /home/jenkins/.ant/lib/ivy-2.4.0.jar
  [get] Not modified - so not downloaded

-ivy-bootstrap2:

-ivy-checksum:

-ivy-remove-old-versions:

ivy-bootstrap:

BUILD SUCCESSFUL
Total time: 0 seconds
+ ant clean build-site build-pdf
Buildfile: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/solr-ref-guide/build.xml

clean:

build-init:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copying all non template files from src ...
 [copy] Copying 410 files to 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copy (w/prop replacement) any template files from src...
 [copy] Copying 1 file to 

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-10) - Build # 21705 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/21705/
Java: 64bit/jdk-10 -XX:-UseCompressedOops -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 1840 lines...]
   [junit4] JVM J0: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/core/test/temp/junit4-J0-20180326_223122_6543972694805984733632.sysout
   [junit4] >>> JVM J0 emitted unexpected output (verbatim) 
   [junit4] codec: DummyCompressingStoredFields, pf: LuceneFixedGap, dvf: Direct
   [junit4] <<< JVM J0: EOF 

[...truncated 46212 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:633: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/build.xml:122: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build.xml:108: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/custom-tasks.xml:108:
 java.lang.IllegalArgumentException: named capturing group is missing trailing 
'}'
at 
java.base/java.util.regex.Matcher.appendExpandedReplacement(Matcher.java:1052)
at java.base/java.util.regex.Matcher.appendReplacement(Matcher.java:908)
at 
org.apache.lucene.dependencies.InterpolatedProperties.interpolate(InterpolatedProperties.java:64)
at 
org.apache.lucene.dependencies.InterpolatedProperties.load(InterpolatedProperties.java:50)
at 
org.apache.lucene.validation.LibVersionsCheckTask.collectDirectDependencies(LibVersionsCheckTask.java:385)
at 
org.apache.lucene.validation.LibVersionsCheckTask.execute(LibVersionsCheckTask.java:220)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at 
org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:398)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at 
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:302)
at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:221)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at 
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
at 

[JENKINS] Lucene-Solr-NightlyTests-7.3 - Build # 10 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.3/10/

1 tests failed.
FAILED:  org.apache.solr.uninverting.TestDocTermOrds.testTriggerUnInvertLimit

Error Message:
GC overhead limit exceeded

Stack Trace:
java.lang.OutOfMemoryError: GC overhead limit exceeded
at 
__randomizedtesting.SeedInfo.seed([E1A3A680F195186F:D2118E44FC22C2D8]:0)
at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectField.(DirectPostingsFormat.java:458)
at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectFields.(DirectPostingsFormat.java:129)
at 
org.apache.lucene.codecs.memory.DirectPostingsFormat.fieldsProducer(DirectPostingsFormat.java:113)
at 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:292)
at 
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:372)
at 
org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:112)
at org.apache.lucene.index.SegmentReader.(SegmentReader.java:78)
at 
org.apache.lucene.index.StandardDirectoryReader$1.doBody(StandardDirectoryReader.java:64)
at 
org.apache.lucene.index.StandardDirectoryReader$1.doBody(StandardDirectoryReader.java:56)
at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:675)
at 
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:79)
at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:63)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:394)
at 
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:324)
at 
org.apache.solr.uninverting.TestDocTermOrds.testTriggerUnInvertLimit(TestDocTermOrds.java:170)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)




Build Log:
[...truncated 13721 lines...]
   [junit4] Suite: org.apache.solr.uninverting.TestDocTermOrds
   [junit4]   2> NOTE: download the large Jenkins line-docs file by running 
'ant get-jenkins-line-docs' in the lucene directory.
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestDocTermOrds 
-Dtests.method=testTriggerUnInvertLimit -Dtests.seed=E1A3A680F195186F 
-Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
-Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-7.3/test-data/enwiki.random.lines.txt
 -Dtests.locale=th-TH-u-nu-thai-x-lvariant-TH 
-Dtests.timezone=America/Martinique -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR163s J0 | TestDocTermOrds.testTriggerUnInvertLimit <<<
   [junit4]> Throwable #1: java.lang.OutOfMemoryError: GC overhead limit 
exceeded
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([E1A3A680F195186F:D2118E44FC22C2D8]:0)
   [junit4]>at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectField.(DirectPostingsFormat.java:458)
   [junit4]>at 
org.apache.lucene.codecs.memory.DirectPostingsFormat$DirectFields.(DirectPostingsFormat.java:129)
   [junit4]>at 
org.apache.lucene.codecs.memory.DirectPostingsFormat.fieldsProducer(DirectPostingsFormat.java:113)
   [junit4]>at 

[jira] [Commented] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414775#comment-16414775
 ] 

Uwe Schindler commented on SOLR-12141:
--

+1, I'd do the same on windows. Maybe it should also simply return the major 
version number, so the later stuff enabling switches for java 9 and java 10 GC 
logging can be simplified.

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch, SOLR-12141.patch, 
> SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[jira] [Commented] (SOLR-12141) Solr does not start on Windows with Java 10

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414772#comment-16414772
 ] 

Robert Muir commented on SOLR-12141:


maybe add a simple "no-op" main method class and run it? If it fails with 
non-zero exit code, just print an error like "unsupported or broken java: `java 
-version`" or whatever. i think it would be a lot less fragile than parsing 
version strings which may change in format etc.

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch, SOLR-12141.patch, 
> SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414769#comment-16414769
 ] 

ASF subversion and git services commented on SOLR-7887:
---

Commit 003be2da436f82abc0758e8aa0c69ec9e5fdc417 in lucene-solr's branch 
refs/heads/branch_7x from [~varun_saxena]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=003be2d ]

SOLR-7887: Log4J2 upgrade fixes part 2

(cherry picked from commit bd42934)


> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch, SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414760#comment-16414760
 ] 

Varun Thacker commented on SOLR-7887:
-

Updated patch for the 2nd round of followups
- Patch merges and minor and major versions split for the log4j ivy version 
file and updates the ref guide to reflect the correct url structure
- The prometheus contrib now uses log4j2.xml files ( needed for log4j2 ) 
instead of the older log4j.properties

Java9 precommit passes with "ant precommit -Dis.jenkins.build=true"

bq. Tomás had a comment on the reviewboard which we never addressed : "Right. 
And we already have lines for forbidding 1.2 jog4j and JUL. My point is that we 
need to add the new packages there. See file "solr.txt" under 
lucene/tools/forbiddenApis

I'll look into that and if we need any changes I'll tackle that in a separate 
Jira

bq. - To keep the behaviour of SOLR_LOG_PRESTART_ROTATION consistent ( one 
could turn it off ) removed  from the default 
log4j2.xml as SOLR_LOG_PRESTART_ROTATION takes care of it

Not doing this anymore after Jan's comments. Let's remove 
SOLR_LOG_PRESTART_ROTATION as suggested. I'll create a separate Jira for that 
so that we can call it out in the CHANGES entry explicitly 

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch, SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414761#comment-16414761
 ] 

ASF subversion and git services commented on SOLR-7887:
---

Commit bd429347b19ccee9eb8a72ad182f4332dad5eef4 in lucene-solr's branch 
refs/heads/master from [~varun_saxena]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bd42934 ]

SOLR-7887: Log4J2 upgrade fixes part 2


> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch, SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Updated] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Varun Thacker (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Varun Thacker updated SOLR-7887:

Attachment: SOLR-7887_followup_2.patch

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch, SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Assigned] (SOLR-11948) Move the lang-configurations from managed-schema to its own xml file

[Varun Thacker (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-11948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Varun Thacker reassigned SOLR-11948:


Assignee: Varun Thacker

> Move the lang-configurations from managed-schema to its own xml file
> 
>
> Key: SOLR-11948
> URL: https://issues.apache.org/jira/browse/SOLR-11948
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.2, 7.2.1
>Reporter: Sachin Goyal
>Assignee: Varun Thacker
>Priority: Major
>
> Half of the current 
> [managed-schema|https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/_default/conf/managed-schema#L516-L927]
>  includes lot of configuration that is un-used by many people and is somewhat 
> painful to remove.
> This includes the files present in the *lang* folder mostly - around 500 
> lines out of the 1000-line file are configuring so many different languages 
> and other stuff in lang folder that is never used.
> It might be good to consider splitting the managed-schema file into two:
> # managed-schema: Everything but the lang folder config
> # dependency-schema: lang folder config and other things that relate to other 
> files.
> If dependency-schema is absent, Solr will just assume that it is not required.
> # This makes it easy to get rid of the extra config and ~100 files that are 
> not required to be stored in zookeeper.
> # The managed-schema file becomes easier to look at.
> *Performance*: This should also reduce a lot of pressure on zookeeper because 
> with all those un-necessary files gone, no replica will download them ever



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414742#comment-16414742
 ] 

Varun Thacker commented on SOLR-7887:
-

{quote}Did the follow-up patch make it to 7x? (everybody's a critic)
{quote}
Done. Thanks for pointing it out. It forgot to push it after merging locally 

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414741#comment-16414741
 ] 

ASF subversion and git services commented on SOLR-7887:
---

Commit 890dcb7d94d4932ded6186f393bdf280354ca647 in lucene-solr's branch 
refs/heads/branch_7x from [~varun_saxena]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=890dcb7 ]

SOLR-7887: Log4J2 upgrade fixes

(cherry picked from commit bea6e23)


> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[JENKINS] Solr-reference-guide-master - Build # 6314 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-master/6314/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 40c8792dbfe70e09ad6b4c1fae2cdcf62da9637e 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 40c8792dbfe70e09ad6b4c1fae2cdcf62da9637e
Commit message: "LUCENE-8175: upgrade icu4j to 61.1 which fixes concurrency 
issue"
 > git rev-list --no-walk be5f73c73a1ad0400ad4d753e9683fde9ca688ac # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /usr/bin/env bash 
/tmp/jenkins4950868368505089641.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.3.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.3/1.29.3.tar.gz.asc
gpg: Signature made Sun 10 Sep 2017 08:59:21 PM UTC using RSA key ID BF04FF17
gpg: Good signature from "Michal Papis (RVM signing) "
gpg: aka "Michal Papis "
gpg: aka "[jpeg image of size 5015]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 409B 6B17 96C2 7546 2A17  0311 3804 BB82 D39D C0E3
 Subkey fingerprint: 62C9 E5F4 DA30 0D94 AC36  166B E206 C29F BF04 FF17
GPG verified '/home/jenkins/.rvm/archives/rvm-1.29.3.tgz'

Upgrading the RVM installation in /home/jenkins/.rvm/
Upgrade of RVM in /home/jenkins/.rvm/ is complete.

Upgrade Notes:

  * No new notes to display.

+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm autolibs disable'
Running 'rvm install ruby-2.3.3'
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
Parsing documentation for jekyll-3.5.0
Done installing documentation for jekyll after 1 seconds
1 gem installed
Running 'gem install --force --version 2.1.0 jekyll-asciidoc'
Successfully installed jekyll-asciidoc-2.1.0
Parsing documentation for jekyll-asciidoc-2.1.0
Done installing documentation for jekyll-asciidoc after 0 seconds
1 gem installed
Running 'gem install --force --version 1.1.2 pygments.rb'
Successfully installed pygments.rb-1.1.2
Parsing documentation for pygments.rb-1.1.2
Done installing documentation for pygments.rb after 0 seconds
1 gem installed
Running 'ant ivy-bootstrap'
Buildfile: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/build.xml

-ivy-bootstrap1:
 [echo] installing ivy 2.4.0 to /home/jenkins/.ant/lib
  [get] Getting: 
http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.4.0/ivy-2.4.0.jar
  [get] To: /home/jenkins/.ant/lib/ivy-2.4.0.jar
  [get] Not modified - so not downloaded

-ivy-bootstrap2:

-ivy-checksum:

-ivy-remove-old-versions:

ivy-bootstrap:

BUILD SUCCESSFUL
Total time: 0 seconds
+ ant clean build-site build-pdf
Buildfile: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/solr-ref-guide/build.xml

clean:

build-init:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copying all non template files from src ...
 [copy] Copying 410 files to 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copy (w/prop replacement) any template files from src...
 [copy] Copying 1 file to 

[jira] [Created] (LUCENE-8225) Fix regenerate tasks to reproduce files with UNIX line endings by default

[Uwe Schindler (JIRA)]

Uwe Schindler created LUCENE-8225:
-

 Summary: Fix regenerate tasks to reproduce files with UNIX line 
endings by default
 Key: LUCENE-8225
 URL: https://issues.apache.org/jira/browse/LUCENE-8225
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Uwe Schindler
Assignee: Uwe Schindler


The ant generate tasks currently always normalize line endings to the local 
conventions. This was required by Subversion. With GIT it depends on your local 
config, but we should really use unix endings by default (don't use autofix 
crlf on windows, as this breaks shell/cmd scripts).

The idea is:
- add a property which defaults to "UNIX"
- fix the CRLF tasks in ant's build to use it

If somebody really wants to use Git's autofixing, he needs to change the 
property in his lucene.build.properties.



--
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

[jira] [Updated] (SOLR-11948) Move the lang-configurations from managed-schema to its own xml file

[Sachin Goyal (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-11948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sachin Goyal updated SOLR-11948:

Description: 
Half of the current 
[managed-schema|https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/_default/conf/managed-schema#L516-L927]
 includes lot of configuration that is un-used by many people and is somewhat 
painful to remove.

This includes the files present in the *lang* folder mostly - around 500 lines 
out of the 1000-line file are configuring so many different languages and other 
stuff in lang folder that is never used.

It might be good to consider splitting the managed-schema file into two:
# managed-schema: Everything but the lang folder config
# dependency-schema: lang folder config and other things that relate to other 
files.

If dependency-schema is absent, Solr will just assume that it is not required.
# This makes it easy to get rid of the extra config and ~100 files that are not 
required to be stored in zookeeper.
# The managed-schema file becomes easier to look at.


*Performance*: This should also reduce a lot of pressure on zookeeper because 
with all those un-necessary files gone, no replica will download them ever

  was:
Half of the current 
[managed-schema|https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/_default/conf/managed-schema#L516-L927]
 includes lot of configuration that is un-used by many people and is somewhat 
painful to remove.

This includes the files present in the *lang* folder mostly - around 500 lines 
out of the 1000-line file are configuring so many different languages and other 
stuff in lang folder that is never used.

It might be good to consider splitting the managed-schema file into two:
# managed-schema: Everything but the lang folder config
# dependency-schema: lang folder config and other things that relate to other 
files.

If dependency-schema is absent, Solr will just assume that it is not required.
# This makes it easy to get rid of the extra config and ~100 files that are not 
required to be stored in zookeeper.
# The managed-schema file becomes easier to look at.


 


> Move the lang-configurations from managed-schema to its own xml file
> 
>
> Key: SOLR-11948
> URL: https://issues.apache.org/jira/browse/SOLR-11948
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6.2, 7.2.1
>Reporter: Sachin Goyal
>Priority: Major
>
> Half of the current 
> [managed-schema|https://github.com/apache/lucene-solr/blob/master/solr/server/solr/configsets/_default/conf/managed-schema#L516-L927]
>  includes lot of configuration that is un-used by many people and is somewhat 
> painful to remove.
> This includes the files present in the *lang* folder mostly - around 500 
> lines out of the 1000-line file are configuring so many different languages 
> and other stuff in lang folder that is never used.
> It might be good to consider splitting the managed-schema file into two:
> # managed-schema: Everything but the lang folder config
> # dependency-schema: lang folder config and other things that relate to other 
> files.
> If dependency-schema is absent, Solr will just assume that it is not required.
> # This makes it easy to get rid of the extra config and ~100 files that are 
> not required to be stored in zookeeper.
> # The managed-schema file becomes easier to look at.
> *Performance*: This should also reduce a lot of pressure on zookeeper because 
> with all those un-necessary files gone, no replica will download them ever



--
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

[jira] [Commented] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414737#comment-16414737
 ] 

ASF subversion and git services commented on LUCENE-8175:
-

Commit 40c8792dbfe70e09ad6b4c1fae2cdcf62da9637e in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=40c8792 ]

LUCENE-8175: upgrade icu4j to 61.1 which fixes concurrency issue


> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
> Attachments: LUCENE-8175.patch
>
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414735#comment-16414735
 ] 

Varun Thacker commented on SOLR-7887:
-

Makes a lot of sense.  I'm happy to tackle that but maybe we should break it 
into a separate Jira ? I say that because there could be someone who turned off 
SOLR_LOG_PRESTART_ROTATION and if we remove this property altogether and with 
the latest changes will have to achieve the same by tweaking the log4j.xml file 

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[JENKINS] Lucene-Solr-master-Windows (64bit/jdk1.8.0_144) - Build # 7242 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7242/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

6 tests failed.
FAILED:  org.apache.solr.handler.TestReplicationHandler.doTestStressReplication

Error Message:
found:2[index.20180326155237441, index.20180326155237810, index.properties, 
replication.properties, snapshot_metadata]

Stack Trace:
java.lang.AssertionError: found:2[index.20180326155237441, 
index.20180326155237810, index.properties, replication.properties, 
snapshot_metadata]
at 
__randomizedtesting.SeedInfo.seed([CF1B0FE54AD94906:14B00F234FF120B5]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:962)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:933)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:909)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414731#comment-16414731
 ] 

Uwe Schindler commented on LUCENE-8175:
---

+1

> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
> Attachments: LUCENE-8175.patch
>
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Commented] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414728#comment-16414728
 ] 

Robert Muir commented on LUCENE-8175:
-

attached is a patch with the upgrade to 61.1

> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
> Attachments: LUCENE-8175.patch
>
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[JIRA]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414724#comment-16414724
 ] 

Jan Høydahl commented on SOLR-7887:
---

[~varunthacker] my intention with the {{SOLR_LOG_PRESTART_ROTATION}} feature 
was as a workaround due to lacking startup rotation in log4j1. See my comment 
in SolrCLI line 4312:
{quote}Rotates solr.log before starting Solr. Mimics log4j2 behavior
{quote}
Since the current workaround is less than optimal, e.g. you need to update 
numbers in \{{bin/solr}} script whenever you reconfigure log4j – I think we 
should start using log4j2's {{OnStartupTriggeringPolicy}} and simply delete the 
whole workaround, at least the {{SolrCLI#rotateSolrLogs}}, perhaps also the 
{{#removeOldSolrLogs}} since it tries to delete timestamped {{solr_log_*}} 
files which were produced by an older version of Solr but not anymore.

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Updated] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[Robert Muir (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated LUCENE-8175:

Attachment: LUCENE-8175.patch

> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
> Attachments: LUCENE-8175.patch
>
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Commented] (SOLR-11947) Math Expressions User Guide

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414713#comment-16414713
 ] 

ASF subversion and git services commented on SOLR-11947:


Commit 86fb45db3581bf64107d298118d49b33399a0283 in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=86fb45d ]

SOLR-11947: Try different link format


> Math Expressions User Guide
> ---
>
> Key: SOLR-11947
> URL: https://issues.apache.org/jira/browse/SOLR-11947
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-11947.patch, SOLR-11947.patch
>
>




--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414700#comment-16414700
 ] 

Varun Thacker commented on SOLR-7887:
-

{quote}I wonder if the changelog should indicate that this is a server-side 
change only, that it will not require them to update the logging in their 
projects that use SolrJ
{quote}
+1 . The more clear we are the better. I'll fold that change into the patch I'm 
currently working on

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Shawn Heisey (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414698#comment-16414698
 ] 

Shawn Heisey commented on SOLR-7887:


I wonder if the changelog should indicate that this is a server-side change 
only, that it will not require them to update the logging in their projects 
that use SolrJ.

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Commented] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414697#comment-16414697
 ] 

Uwe Schindler commented on SOLR-12141:
--

Actually on Linux it's even worse, it compares the full version string, so "10" 
< "1.8" is always true. BUMMER.

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch, SOLR-12141.patch, 
> SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[jira] [Updated] (LUCENE-8125) emoji sequence support in ICUTokenizer

[Robert Muir (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated LUCENE-8125:

Fix Version/s: (was: 7.3)
   7.4

> emoji sequence support in ICUTokenizer
> --
>
> Key: LUCENE-8125
> URL: https://issues.apache.org/jira/browse/LUCENE-8125
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Fix For: trunk, 7.4
>
> Attachments: LUCENE-8125.patch, LUCENE-8125.patch, LUCENE-8125.patch, 
> LUCENE-8125.patch, LUCENE-8125.patch
>
>
> uax29 word break rules already know how to handle these correctly, we just 
> need to assign them a token type. 
> This is better than users trying to do this with custom rules (e.g. 
> LUCENE-7916) because they are script-independent (common/inherited).



--
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

[jira] [Resolved] (LUCENE-8125) emoji sequence support in ICUTokenizer

[Robert Muir (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir resolved LUCENE-8125.
-
Resolution: Fixed

> emoji sequence support in ICUTokenizer
> --
>
> Key: LUCENE-8125
> URL: https://issues.apache.org/jira/browse/LUCENE-8125
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Fix For: trunk, 7.4
>
> Attachments: LUCENE-8125.patch, LUCENE-8125.patch, LUCENE-8125.patch, 
> LUCENE-8125.patch, LUCENE-8125.patch
>
>
> uax29 word break rules already know how to handle these correctly, we just 
> need to assign them a token type. 
> This is better than users trying to do this with custom rules (e.g. 
> LUCENE-7916) because they are script-independent (common/inherited).



--
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

[jira] [Resolved] (LUCENE-8122) upgrade to icu > 60.2

[Robert Muir (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir resolved LUCENE-8122.
-
Resolution: Fixed

> upgrade to icu > 60.2
> -
>
> Key: LUCENE-8122
> URL: https://issues.apache.org/jira/browse/LUCENE-8122
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Robert Muir
>Priority: Major
> Fix For: 7.4
>
> Attachments: LUCENE-8122.patch, LUCENE-8122.patch
>
>
> Currently we are at version 59.1. There is some change to breakiterator 
> behavior, but I think it simplifies our code. Also our tools needed to be 
> updated to pull some data files from new source code location. 
> ---
> See comments below for reasons why we are explicitly skipping past 60.2



--
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

[jira] [Commented] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414692#comment-16414692
 ] 

Uwe Schindler commented on SOLR-12141:
--

I tested Linux - Same issue (alphabetic comparison, not numeric):

{noformat}
thetaphi@serv1:~/solr-7.3.0/bin$ ./solr start -e techproducts
Your current version of Java is too old to run this version of Solr
We found version 10, using command 
'/home/jenkins/tools/java/64bit/jdk-10/bin/java -version', with response:
openjdk version "10" 2018-03-20
OpenJDK Runtime Environment 18.3 (build 10+46)
OpenJDK 64-Bit Server VM 18.3 (build 10+46, mixed mode)

Please install latest version of Java 1.8 or set JAVA_HOME properly.

Debug information:
JAVA_HOME: /home/jenkins/tools/java/64bit/jdk-10
Active Path:
/home/jenkins/tools/java/64bit/jdk-10/bin/:/home/thetaphi/apache-ant-1.8.4/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
{noformat}

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch, SOLR-12141.patch, 
> SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[jira] [Updated] (LUCENE-8122) upgrade to icu > 60.2

[Robert Muir (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Muir updated LUCENE-8122:

Fix Version/s: 7.4

> upgrade to icu > 60.2
> -
>
> Key: LUCENE-8122
> URL: https://issues.apache.org/jira/browse/LUCENE-8122
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Robert Muir
>Priority: Major
> Fix For: 7.4
>
> Attachments: LUCENE-8122.patch, LUCENE-8122.patch
>
>
> Currently we are at version 59.1. There is some change to breakiterator 
> behavior, but I think it simplifies our code. Also our tools needed to be 
> updated to pull some data files from new source code location. 
> ---
> See comments below for reasons why we are explicitly skipping past 60.2



--
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

[jira] [Commented] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414693#comment-16414693
 ] 

ASF subversion and git services commented on LUCENE-8175:
-

Commit 9272f758ac2c8d7b127526d5dc5da8faa7aa3f9c in lucene-solr's branch 
refs/heads/branch_7x from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9272f75 ]

LUCENE-8175: move CHANGES entry to next release


> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Commented] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414691#comment-16414691
 ] 

ASF subversion and git services commented on LUCENE-8175:
-

Commit cf1a08ff5fdef084f1666aa402d90b4de268c4b2 in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cf1a08f ]

LUCENE-8175: move CHANGES entry to next release


> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Commented] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414689#comment-16414689
 ] 

ASF subversion and git services commented on LUCENE-8175:
-

Commit c0b92e279423dbc6852ca2f9cce681604b44d19b in lucene-solr's branch 
refs/heads/branch_7x from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c0b92e2 ]

LUCENE-8175: un-revert "LUCENE-8125: ICUTokenizer support for emoji/emoji 
sequence tokens""

This was a casualty of war because it relied on new unicode stuff


> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Comment Edited] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414667#comment-16414667
 ] 

Varun Thacker edited comment on SOLR-7887 at 3/26/18 10:33 PM:
---

[~koji] while upgrading log4j.properties for prometheus 
[https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/conf/log4j.properties]
 , I see that it only has a CONSOLE appender . Any reason why it doesn't have a 
default file based appender as well ? If you are fine I plan on using 
[https://github.com/apache/lucene-solr/blob/master/solr/server/resources/log4j2.xml]
 configuration for prometheus as well in my subsequent patch.

 

The second change I plan on making is while converting the log4j.properties 
from the test package to log4j2.xml use SYSTEM_ERR instead of SYSTEM_OUT ( what 
it uses currently )

The reason being all test packages today use SYSTEM_ERR ( 
[https://github.com/apache/lucene-solr/blob/branch_7_3/solr/solrj/src/test-files/log4j.properties#L5]
 for example ) and this seems to be the only package using SYSTEM_OUT .  Maybe 
it doesn't make a difference but atleast we'll standardize it


was (Author: varunthacker):
[~koji] while upgrading log4j.properties for prometheus 
[https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/conf/log4j.properties]
 , I see that it only has a CONSOLE appender . Any reason why it doesn't have a 
default file based appender as well ? If you are fine I plan on using 
[https://github.com/apache/lucene-solr/blob/master/solr/server/resources/log4j2.xml]
 configuration for prometheus as well in my subsequent patch.

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Commented] (LUCENE-8125) emoji sequence support in ICUTokenizer

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414690#comment-16414690
 ] 

ASF subversion and git services commented on LUCENE-8125:
-

Commit c0b92e279423dbc6852ca2f9cce681604b44d19b in lucene-solr's branch 
refs/heads/branch_7x from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c0b92e2 ]

LUCENE-8175: un-revert "LUCENE-8125: ICUTokenizer support for emoji/emoji 
sequence tokens""

This was a casualty of war because it relied on new unicode stuff


> emoji sequence support in ICUTokenizer
> --
>
> Key: LUCENE-8125
> URL: https://issues.apache.org/jira/browse/LUCENE-8125
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Fix For: trunk, 7.3
>
> Attachments: LUCENE-8125.patch, LUCENE-8125.patch, LUCENE-8125.patch, 
> LUCENE-8125.patch, LUCENE-8125.patch
>
>
> uax29 word break rules already know how to handle these correctly, we just 
> need to assign them a token type. 
> This is better than users trying to do this with custom rules (e.g. 
> LUCENE-7916) because they are script-independent (common/inherited).



--
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

[jira] [Commented] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414680#comment-16414680
 ] 

ASF subversion and git services commented on LUCENE-8175:
-

Commit 23bff7dbc207083af2ccb1b308c121ac18c36508 in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=23bff7d ]

LUCENE-8175: un-revert "LUCENE-8125: ICUTokenizer support for emoji/emoji 
sequence tokens""

This was a casualty of war because it relied on new unicode stuff


> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Commented] (LUCENE-8125) emoji sequence support in ICUTokenizer

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414681#comment-16414681
 ] 

ASF subversion and git services commented on LUCENE-8125:
-

Commit 23bff7dbc207083af2ccb1b308c121ac18c36508 in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=23bff7d ]

LUCENE-8175: un-revert "LUCENE-8125: ICUTokenizer support for emoji/emoji 
sequence tokens""

This was a casualty of war because it relied on new unicode stuff


> emoji sequence support in ICUTokenizer
> --
>
> Key: LUCENE-8125
> URL: https://issues.apache.org/jira/browse/LUCENE-8125
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Fix For: trunk, 7.3
>
> Attachments: LUCENE-8125.patch, LUCENE-8125.patch, LUCENE-8125.patch, 
> LUCENE-8125.patch, LUCENE-8125.patch
>
>
> uax29 word break rules already know how to handle these correctly, we just 
> need to assign them a token type. 
> This is better than users trying to do this with custom rules (e.g. 
> LUCENE-7916) because they are script-independent (common/inherited).



--
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

[jira] [Commented] (LUCENE-8122) upgrade to icu > 60.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414678#comment-16414678
 ] 

ASF subversion and git services commented on LUCENE-8122:
-

Commit d25c18ea4788b8ff642dee939c4dc0edc5729fb4 in lucene-solr's branch 
refs/heads/branch_7x from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d25c18e ]

LUCENE-8175: un-revert "LUCENE-8122: Updata autogenerated code after update to 
ICU4J 60.2"


> upgrade to icu > 60.2
> -
>
> Key: LUCENE-8122
> URL: https://issues.apache.org/jira/browse/LUCENE-8122
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-8122.patch, LUCENE-8122.patch
>
>
> Currently we are at version 59.1. There is some change to breakiterator 
> behavior, but I think it simplifies our code. Also our tools needed to be 
> updated to pull some data files from new source code location. 
> ---
> See comments below for reasons why we are explicitly skipping past 60.2



--
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

[jira] [Commented] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414674#comment-16414674
 ] 

ASF subversion and git services commented on LUCENE-8175:
-

Commit bdfe1e69e68ed584ea00fa22dbc4744fcb2451ac in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bdfe1e6 ]

LUCENE-8175: un-revert "LUCENE-8122: Updata autogenerated code after update to 
ICU4J 60.2"


> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Commented] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414677#comment-16414677
 ] 

ASF subversion and git services commented on LUCENE-8175:
-

Commit d25c18ea4788b8ff642dee939c4dc0edc5729fb4 in lucene-solr's branch 
refs/heads/branch_7x from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d25c18e ]

LUCENE-8175: un-revert "LUCENE-8122: Updata autogenerated code after update to 
ICU4J 60.2"


> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Commented] (LUCENE-8122) upgrade to icu > 60.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414675#comment-16414675
 ] 

ASF subversion and git services commented on LUCENE-8122:
-

Commit bdfe1e69e68ed584ea00fa22dbc4744fcb2451ac in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=bdfe1e6 ]

LUCENE-8175: un-revert "LUCENE-8122: Updata autogenerated code after update to 
ICU4J 60.2"


> upgrade to icu > 60.2
> -
>
> Key: LUCENE-8122
> URL: https://issues.apache.org/jira/browse/LUCENE-8122
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-8122.patch, LUCENE-8122.patch
>
>
> Currently we are at version 59.1. There is some change to breakiterator 
> behavior, but I think it simplifies our code. Also our tools needed to be 
> updated to pull some data files from new source code location. 
> ---
> See comments below for reasons why we are explicitly skipping past 60.2



--
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

[jira] [Commented] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414671#comment-16414671
 ] 

ASF subversion and git services commented on LUCENE-8175:
-

Commit 2dcf263b5207243f6854c0e48d2496036f678eee in lucene-solr's branch 
refs/heads/branch_7x from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2dcf263 ]

LUCENE-8175: un-revert "LUCENE-8122: Upgrade analysis/icu to ICU 60.2"

the new icu version has been released that fixes the concurrency issue.


> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Commented] (LUCENE-8122) upgrade to icu > 60.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414672#comment-16414672
 ] 

ASF subversion and git services commented on LUCENE-8122:
-

Commit 2dcf263b5207243f6854c0e48d2496036f678eee in lucene-solr's branch 
refs/heads/branch_7x from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2dcf263 ]

LUCENE-8175: un-revert "LUCENE-8122: Upgrade analysis/icu to ICU 60.2"

the new icu version has been released that fixes the concurrency issue.


> upgrade to icu > 60.2
> -
>
> Key: LUCENE-8122
> URL: https://issues.apache.org/jira/browse/LUCENE-8122
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-8122.patch, LUCENE-8122.patch
>
>
> Currently we are at version 59.1. There is some change to breakiterator 
> behavior, but I think it simplifies our code. Also our tools needed to be 
> updated to pull some data files from new source code location. 
> ---
> See comments below for reasons why we are explicitly skipping past 60.2



--
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

[jira] [Commented] (LUCENE-8122) upgrade to icu > 60.2

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414670#comment-16414670
 ] 

ASF subversion and git services commented on LUCENE-8122:
-

Commit 4522e45bdadd4268a9270135130fc28a7f46c627 in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4522e45 ]

LUCENE-8175: un-revert "LUCENE-8122: Upgrade analysis/icu to ICU 60.2"

the new icu version has been released that fixes the concurrency issue.


> upgrade to icu > 60.2
> -
>
> Key: LUCENE-8122
> URL: https://issues.apache.org/jira/browse/LUCENE-8122
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/analysis
>Reporter: Robert Muir
>Priority: Major
> Attachments: LUCENE-8122.patch, LUCENE-8122.patch
>
>
> Currently we are at version 59.1. There is some change to breakiterator 
> behavior, but I think it simplifies our code. Also our tools needed to be 
> updated to pull some data files from new source code location. 
> ---
> See comments below for reasons why we are explicitly skipping past 60.2



--
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

[jira] [Commented] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414669#comment-16414669
 ] 

ASF subversion and git services commented on LUCENE-8175:
-

Commit 4522e45bdadd4268a9270135130fc28a7f46c627 in lucene-solr's branch 
refs/heads/master from [~rcmuir]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4522e45 ]

LUCENE-8175: un-revert "LUCENE-8122: Upgrade analysis/icu to ICU 60.2"

the new icu version has been released that fixes the concurrency issue.


> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414667#comment-16414667
 ] 

Varun Thacker commented on SOLR-7887:
-

[~koji] while upgrading log4j.properties for prometheus 
[https://github.com/apache/lucene-solr/blob/master/solr/contrib/prometheus-exporter/conf/log4j.properties]
 , I see that it only has a CONSOLE appender . Any reason why it doesn't have a 
default file based appender as well ? If you are fine I plan on using 
[https://github.com/apache/lucene-solr/blob/master/solr/server/resources/log4j2.xml]
 configuration for prometheus as well in my subsequent patch.

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Commented] (LUCENE-8175) ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J

[Robert Muir (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414665#comment-16414665
 ] 

Robert Muir commented on LUCENE-8175:
-

the new version is released. I will attempt to fight with these merge conflicts 
and revert the reverts. Then i'll make a patch for this issue to upgrade to the 
new version.


> ICUTokenizer might return corrupt tokens due to concurrency bug in ICU4J
> 
>
> Key: LUCENE-8175
> URL: https://issues.apache.org/jira/browse/LUCENE-8175
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Critical
>
> I was digging some test failures with {{testRandomHugeStrings}} that occurred 
> since the upgrade to ICU4J 60.2 which happen to boil down to this bug: 
> http://bugs.icu-project.org/trac/ticket/13512 which is fixed but not released 
> yet.
> In short an int[] is shared across several threads while it shouldn't. As a 
> consequence, ICUTokenizer may sometimes return corrupt tokens. I pinged on 
> the issue to know when a release fixing this bug is expected.



--
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

[jira] [Commented] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414658#comment-16414658
 ] 

Uwe Schindler commented on SOLR-12141:
--

New patch fixes 64 bit test (will only be executed on Java 8). Linux is not 
affected as it does not have this check.

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch, SOLR-12141.patch, 
> SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[jira] [Updated] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated SOLR-12141:
-
Attachment: SOLR-12141.patch

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch, SOLR-12141.patch, 
> SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[jira] [Assigned] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler reassigned SOLR-12141:


Assignee: Uwe Schindler

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch, SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[jira] [Comment Edited] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414627#comment-16414627
 ] 

Uwe Schindler edited comment on SOLR-12141 at 3/26/18 10:10 PM:


bq. There is a nother problem (this also affects Linux). Java 10 no longer has 
-XX:+UseParNewGC, it was removed

This flag was already obsolete in Java 8, as ConcMarkSweepGC automatically 
enables it (see http://openjdk.java.net/jeps/173). So I will simply remove it 
in both Windows and Linux.


was (Author: thetaphi):
bq. There is a nother problem (this also affects Linux). Java 10 no longer has 
-XX:+UseParNewGC, it was removed

This flag was already obsolete in Java 8, as ConcMarkSweepGC automatically 
enables ist. So I will simply remove it in both Windows and Linux.

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch, SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[jira] [Commented] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414639#comment-16414639
 ] 

Uwe Schindler commented on SOLR-12141:
--

New patch fixes GC issues by removing obsolete flag.

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch, SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[jira] [Updated] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated SOLR-12141:
-
Attachment: SOLR-12141.patch

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch, SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[JENKINS] Solr-reference-guide-master - Build # 6313 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Solr-reference-guide-master/6313/

Log: 
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites) in workspace 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/lucene-solr.git # 
 > timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
Fetching upstream changes from git://git.apache.org/lucene-solr.git
 > git --version # timeout=10
 > git fetch --tags --progress git://git.apache.org/lucene-solr.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision be5f73c73a1ad0400ad4d753e9683fde9ca688ac 
(refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f be5f73c73a1ad0400ad4d753e9683fde9ca688ac
Commit message: "SOLR-11947: Fix ref guide jenkins errors"
 > git rev-list --no-walk 05dca0493db254005e96997ef1e7c65082620ba7 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /usr/bin/env bash 
/tmp/jenkins1270126047173812431.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.3.tar.gz
Downloading 
https://github.com/rvm/rvm/releases/download/1.29.3/1.29.3.tar.gz.asc
gpg: Signature made Sun 10 Sep 2017 08:59:21 PM UTC using RSA key ID BF04FF17
gpg: Good signature from "Michal Papis (RVM signing) "
gpg: aka "Michal Papis "
gpg: aka "[jpeg image of size 5015]"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 409B 6B17 96C2 7546 2A17  0311 3804 BB82 D39D C0E3
 Subkey fingerprint: 62C9 E5F4 DA30 0D94 AC36  166B E206 C29F BF04 FF17
GPG verified '/home/jenkins/.rvm/archives/rvm-1.29.3.tgz'

Upgrading the RVM installation in /home/jenkins/.rvm/
Upgrade of RVM in /home/jenkins/.rvm/ is complete.

Upgrade Notes:

  * No new notes to display.

+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm autolibs disable'
Running 'rvm install ruby-2.3.3'
Already installed ruby-2.3.3.
To reinstall use:

rvm reinstall ruby-2.3.3

Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created 
/home/jenkins/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
ruby-2.3.3 - #generating solr-refguide-gemset 
wrappers|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
Parsing documentation for jekyll-3.5.0
Done installing documentation for jekyll after 1 seconds
1 gem installed
Running 'gem install --force --version 2.1.0 jekyll-asciidoc'
Successfully installed jekyll-asciidoc-2.1.0
Parsing documentation for jekyll-asciidoc-2.1.0
Done installing documentation for jekyll-asciidoc after 0 seconds
1 gem installed
Running 'gem install --force --version 1.1.2 pygments.rb'
Successfully installed pygments.rb-1.1.2
Parsing documentation for pygments.rb-1.1.2
Done installing documentation for pygments.rb after 0 seconds
1 gem installed
Running 'ant ivy-bootstrap'
Buildfile: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/build.xml

-ivy-bootstrap1:
 [echo] installing ivy 2.4.0 to /home/jenkins/.ant/lib
  [get] Getting: 
http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.4.0/ivy-2.4.0.jar
  [get] To: /home/jenkins/.ant/lib/ivy-2.4.0.jar
  [get] Not modified - so not downloaded

-ivy-bootstrap2:

-ivy-checksum:

-ivy-remove-old-versions:

ivy-bootstrap:

BUILD SUCCESSFUL
Total time: 0 seconds
+ ant clean build-site build-pdf
Buildfile: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/solr-ref-guide/build.xml

clean:

build-init:
[mkdir] Created dir: 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copying all non template files from src ...
 [copy] Copying 410 files to 
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/content
 [echo] Copy (w/prop replacement) any template files from src...
 [copy] Copying 1 file to 

[jira] [Commented] (SOLR-11947) Math Expressions User Guide

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414634#comment-16414634
 ] 

ASF subversion and git services commented on SOLR-11947:


Commit be5f73c73a1ad0400ad4d753e9683fde9ca688ac in lucene-solr's branch 
refs/heads/master from [~joel.bernstein]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=be5f73c ]

SOLR-11947: Fix ref guide jenkins errors


> Math Expressions User Guide
> ---
>
> Key: SOLR-11947
> URL: https://issues.apache.org/jira/browse/SOLR-11947
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: documentation, streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-11947.patch, SOLR-11947.patch
>
>




--
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

[jira] [Commented] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414627#comment-16414627
 ] 

Uwe Schindler commented on SOLR-12141:
--

bq. There is a nother problem (this also affects Linux). Java 10 no longer has 
-XX:+UseParNewGC, it was removed

This flag was already obsolete in Java 8, as ConcMarkSweepGC automatically 
enables ist. So I will simply remove it in both Windows and Linux.

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[jira] [Updated] (SOLR-11277) Add auto hard commit setting based on tlog size

[Rupa Shankar (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-11277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rupa Shankar updated SOLR-11277:

Attachment: SOLR-11277.patch

> Add auto hard commit setting based on tlog size
> ---
>
> Key: SOLR-11277
> URL: https://issues.apache.org/jira/browse/SOLR-11277
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Rupa Shankar
>Assignee: Anshum Gupta
>Priority: Major
> Attachments: SOLR-11277.patch, SOLR-11277.patch, SOLR-11277.patch, 
> max_size_auto_commit.patch
>
>
> When indexing documents of variable sizes and at variable schedules, it can 
> be hard to estimate the optimal auto hard commit maxDocs or maxTime settings. 
> We’ve had some occurrences of really huge tlogs, resulting in serious issues, 
> so in an attempt to avoid this, it would be great to have a “maxSize” setting 
> based on the tlog size on disk. 



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414612#comment-16414612
 ] 

Erick Erickson commented on SOLR-7887:
--

Did the follow-up patch make it to 7x? (everybody's a critic)

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

[jira] [Commented] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414604#comment-16414604
 ] 

Uwe Schindler commented on SOLR-12141:
--

In addition it prints a warning, as it thinks it's 32 bit (although Java 10 is 
always 64 bits). The reason is a check using {{-d64}} which is no longer 
accepted in Java 10 (it fails, so it thinks that it's not 64 bits).

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[jira] [Commented] (SOLR-12141) Solr does not start on Windows with Java 10

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414601#comment-16414601
 ] 

Uwe Schindler commented on SOLR-12141:
--

There is a nother problem (this also affects Linux). Java 10 no longer has 
{{-XX:+UseParNewGC}}, it was removed. ConcMarkSweepGC is still there but may 
get removed soon.

> Solr does not start on Windows with Java 10
> ---
>
> Key: SOLR-12141
> URL: https://issues.apache.org/jira/browse/SOLR-12141
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: scripts and tools
>Affects Versions: 7.0, 7.1, 7.2, 7.3
> Environment: Windows 10 with Java 10+
>Reporter: Uwe Schindler
>Priority: Blocker
> Fix For: 7.3
>
> Attachments: SOLR-12141.patch, SOLR-12141.patch
>
>
> If you try to start Solr on Windows with Java 10, it fails with the following 
> message:
> {noformat}
> C:\Users\Uwe Schindler\Desktop\solr-7.3.0\bin>solr start -e techproducts
> ERROR: Java 1.8 or later is required to run Solr. Current Java version is: 10
> {noformat}
> Java 8 and Java 9 works. I did not try Linux, but the version parsing on 
> Windows is so braindead (i tried to fix it for Java 9 already). Windows CMD 
> shell does not know any numerical comparisons, so it fails as "10" is 
> alphabetically smaller "9".
> I hope this is better on Linux.
> Why do we have the version check at all? Wouldn't it be better to simply wait 
> for a useful message by the Java VM on startup because of wrong class file 
> format? This is too simply to break, especially as the output of "java 
> -version" is not standardized (and changes with Java 10 to also have a date 
> code,...). It also may contain "openjdk" instead of "java".
> So please please, let's get rid of the version check!



--
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

[JENKINS] Lucene-Solr-7.x-Linux (64bit/jdk-9.0.4) - Build # 1597 - Still Failing!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/1597/
Java: 64bit/jdk-9.0.4 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.autoscaling.NodeLostTriggerTest.testListenerAcceptance

Error Message:
expected:<1> but was:<0>

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<0>
at 
__randomizedtesting.SeedInfo.seed([4618117EB5C454CB:57AC4B990C4D403D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.cloud.autoscaling.NodeLostTriggerTest.testListenerAcceptance(NodeLostTriggerTest.java:253)
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:564)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:844)




Build Log:
[...truncated 1787 lines...]
   [junit4] JVM J0: stdout was not empty, see: 

[jira] [Commented] (SOLR-10338) Configure SecureRandom non blocking for tests.

[Hoss Man (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414597#comment-16414597
 ] 

Hoss Man commented on SOLR-10338:
-

bq. I think SolrTestCaseJ4's insistence on this is a bit of an over-reach for 
external projects that want to use solr-test-framework.  It's well intentioned 
but creates an annoying hassle that randomly occurs. 

I'm no longer convinced i even understand what "this" is in the context of our 
current discussion, since the changes made SOLR-10338 do not involve 
SolrTestCaseJ4 do not involve anything that should "randomly occur" ... any 
assertion from the code committed in this issue should occur reliably 100% of 
the time assuming they are re-run on the same JVM.

I think this dicussion should be moved to a new jira, with a new subject, and a 
detailed description of exactly what error message you are seeing, and what 
your test code looks like, and the specifics of your JVM.

> Configure SecureRandom non blocking for tests.
> --
>
> Key: SOLR-10338
> URL: https://issues.apache.org/jira/browse/SOLR-10338
> Project: Solr
>  Issue Type: Sub-task
>Reporter: Mihaly Toth
>Assignee: Mark Miller
>Priority: Major
> Fix For: 7.1, master (8.0)
>
> Attachments: SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, 
> SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, SOLR-10338.patch, 
> SOLR-10338.patch
>
>
> It would be best if SecureRandom could be made non blocking. In that case we 
> could get rid of random entropy exhaustion issue related to all usages of 
> SecureRandom.



--
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

[jira] [Commented] (SOLR-7887) Upgrade Solr to use log4j2 -- log4j 1 now officially end of life

[Varun Thacker (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16414594#comment-16414594
 ] 

Varun Thacker commented on SOLR-7887:
-

Thanks [~steve_rowe] for pointing out.

I need to fix a few more things that were missed out in the initial commit 
There are *still* log4j.properties files in some of our tests. 

I'll take a couple of hours and put a more thorough patch with all the fixes in 
one go 

> Upgrade Solr to use log4j2 -- log4j 1 now officially end of life
> 
>
> Key: SOLR-7887
> URL: https://issues.apache.org/jira/browse/SOLR-7887
> Project: Solr
>  Issue Type: Task
>Reporter: Shawn Heisey
>Assignee: Erick Erickson
>Priority: Major
> Fix For: 7.4
>
> Attachments: SOLR-7887-WIP.patch, SOLR-7887-eoe-review.patch, 
> SOLR-7887-eoe-review.patch, SOLR-7887-followup_1.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, SOLR-7887.patch, 
> SOLR-7887_followup_2.patch
>
>
> The logging services project has officially announced the EOL of log4j 1:
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> In the official binary jetty deployment, we use use log4j 1.2 as our final 
> logging destination, so the admin UI has a log watcher that actually uses 
> log4j and java.util.logging classes.  That will need to be extended to add 
> log4j2.  I think that might be the largest pain point to this upgrade.
> There is some crossover between log4j2 and slf4j.  Figuring out exactly which 
> jars need to be in the lib/ext directory will take some research.



--
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

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-7.x #164: POMs out of sync

[Steve Rowe]

There’s a missing indirect Yetus dependency from ZooKeeper.  

This surfaced a while back on SOLR-7887: 

 and 


Looks like Erick took the dependency out of the patch before SOLR-7887 landed, 
but IIRC the dependency is still required.

More links: 
* : where ZooKeeper added the 
dependency.
* : why compilation is 
failing.

Varun, do you have more details?

--
Steve
www.lucidworks.com

> On Mar 26, 2018, at 5:15 PM, Uwe Schindler  wrote:
> 
> No idea what's wrong here.
> 
> Am March 26, 2018 9:11:50 PM UTC schrieb Apache Jenkins Server 
> :
> Build: https://builds.apache.org/job/Lucene-Solr-Maven-7.x/164/
> 
> No tests ran.
> 
> Build Log:
> [...truncated 31720 lines...]
>   [mvn] [INFO]
> 
>   [mvn] [INFO]
> 
>   [mvn] [ERROR] COMPILATION ERROR : 
>   [mvn] [INFO]
> 
> 
> [...truncated 204 lines...]
> BUILD FAILED
> /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/build.xml:679: The 
> following error occurred while executing this line:
> : Java returned: 1
> 
> Total time: 15 minutes 43 seconds
> Build step 'Invoke Ant' marked build as failure
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any
> 
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org