[JENKINS-EA] Lucene-Solr-7.x-Windows (64bit/jdk-9-ea+181) - Build # 130 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/130/
Java: 64bit/jdk-9-ea+181 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 
--illegal-access=deny

3 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.SampleTest

Error Message:
Could not remove the following files (in the order of attempts):
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_CB68F3FD951906BA-001\init-core-data-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_CB68F3FD951906BA-001\init-core-data-001
 

Stack Trace:
java.io.IOException: Could not remove the following files (in the order of 
attempts):
   
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_CB68F3FD951906BA-001\init-core-data-001:
 java.nio.file.DirectoryNotEmptyException: 
C:\Users\jenkins\workspace\Lucene-Solr-7.x-Windows\solr\build\solr-core\test\J1\temp\solr.SampleTest_CB68F3FD951906BA-001\init-core-data-001

at __randomizedtesting.SeedInfo.seed([CB68F3FD951906BA]:0)
at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
at 
org.apache.lucene.util.TestRuleTemporaryFilesCleanup.afterAlways(TestRuleTemporaryFilesCleanup.java:216)
at 
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterAlways(TestRuleAdapter.java:31)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
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)


FAILED:  
org.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster

Error Message:
Document mismatch on target after sync expected:<2000> but was:<1100>

Stack Trace:
java.lang.AssertionError: Document mismatch on target after sync 
expected:<2000> but was:<1100>
at 
__randomizedtesting.SeedInfo.seed([CB68F3FD951906BA:1F2DB8A4724FB541]: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.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster(CdcrBootstrapTest.java:309)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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 
c

[jira] [Commented] (LUCENE-7938) Bounds of bounding box are not equal to bounding box

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-7938:
--

"there are indeed some rare cases where it is difficult to compute the bounding 
box and we return a larger box as a shortcut."

What I disagree is that computing the bounding box of a bounding box should not 
be difficult. There is another "fix"  for that to make sure a bounding box 
generates the same bounds of itself. Currently the method getBounds() for 
GeoRectangle does the following:

  @Override
  public void getBounds(Bounds bounds) {
super.getBounds(bounds);
bounds.addHorizontalPlane(planetModel, topLat, topPlane, bottomPlane, 
leftPlane, rightPlane)
  .addVerticalPlane(planetModel, rightLon, rightPlane, topPlane, 
bottomPlane, leftPlane)
  .addHorizontalPlane(planetModel, bottomLat, bottomPlane, topPlane, 
leftPlane, rightPlane)
  .addVerticalPlane(planetModel, leftLon, leftPlane, topPlane, bottomPlane, 
rightPlane)
  .addIntersection(planetModel, leftPlane, rightPlane, topPlane, 
bottomPlane)
  .addPoint(ULHC).addPoint(URHC).addPoint(LLHC).addPoint(LRHC);
  }

Probably it will be enoughif the method does the following:

  @Override
  public void getBounds(Bounds bounds) {
super.getBounds(bounds);
bounds.addPoint(ULHC).addPoint(URHC).addPoint(LLHC).addPoint(LRHC);
  }

As we know the bounds of this object are the points. No need to add the panes 
as they introduce numerical imprecision.

Cheers,

I. 

> Bounds of bounding box are not equal to bounding box
> 
>
> Key: LUCENE-7938
> URL: https://issues.apache.org/jira/browse/LUCENE-7938
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Minor
> Attachments: LUCENE-7938-fix.patch, LUCENE-7938-test.patch
>
>
> Hi,
> It seems if I get the bounds of a BBox and I create a new bounding box, 
> sometimes both bounding box are not equal. It is a problem with precision.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7932) Search record with field value='a' or 'A' returns all records along with one more field value

[Rohit Balekundri (JIRA)]

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

Rohit Balekundri updated LUCENE-7932:
-
Description: 
Hi Lucene Team,

Here I explained more about issue facing after querying using 
org.apache.lucene.search.IndexSearcher API.

Here I am just giving examples of our project with field names (Not related 
with Lucene):
In our document which needs to be archived having key fields and non-key fields.
A> Key fields: 
1. LocationCode (DataType=long)
2. CollectionObjectID (DataType=long)
B> Non-key fields
Category (DataType=string)

Steps we followed:
1. Step 1: We stored multiple document records with category values as below in 
index files.
 LocationCode = 1  Category =b
 LocationCode = 2  Category =BC
 LocationCode =3  Category =bcd
2. In Step 2: we query for records and we pass query parameters as below.
a) LocationCode=1 and  Category =a  
 Result= all records displayed
b) LocationCode=1 and  Category =A  
    Result= all records displayed

I faced above issue in Lucene 5.3.
Later I found even Lucene 6.6 is also having same issue.



  was:
Hi Lucene Team,

Here I explained more about issue facing after querying using QueryParser API.

Here I am just giving examples of our project with field names (Not related 
with Lucene):
In our document which needs to be archived having key fields and non-key fields.
A> Key fields: 
1. LocationCode (DataType=long)
2. CollectionObjectID (DataType=long)
B> Non-key fields
Category (DataType=string)

Steps we followed:
1. Step 1: We stored multiple document records with category values as below in 
index files.
 LocationCode = 1  Category =b
 LocationCode = 2  Category =BC
 LocationCode =3  Category =bcd
2. In Step 2: we query for records and we pass query parameters as below.
a) LocationCode=1 and  Category =a  
 Result= all records displayed
b) LocationCode=1 and  Category =A  result= all records displayed
 Result= all records displayed

I faced above issue in Lucene 5.3.
Llater I found even Lucene 6.6 is also having same issue.
Kindly consider this bug on top priority.



> Search record with field value='a' or 'A' returns all records along with one 
> more field value
> -
>
> Key: LUCENE-7932
> URL: https://issues.apache.org/jira/browse/LUCENE-7932
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.3, 6.6
> Environment: Windows and Linux
>Reporter: Rohit Balekundri
>  Labels: features
>
> Hi Lucene Team,
> Here I explained more about issue facing after querying using 
> org.apache.lucene.search.IndexSearcher API.
> Here I am just giving examples of our project with field names (Not related 
> with Lucene):
> In our document which needs to be archived having key fields and non-key 
> fields.
> A> Key fields: 
> 1. LocationCode (DataType=long)
> 2. CollectionObjectID (DataType=long)
> B> Non-key fields
> Category (DataType=string)
> Steps we followed:
> 1. Step 1: We stored multiple document records with category values as below 
> in index files.
>  LocationCode = 1  Category =b
>  LocationCode = 2  Category =BC
>  LocationCode =3  Category =bcd
> 2. In Step 2: we query for records and we pass query parameters as below.
> a) LocationCode=1 and  Category =a  
>  Result= all records displayed
> b) LocationCode=1 and  Category =A  
> Result= all records displayed
> I faced above issue in Lucene 5.3.
> Later I found even Lucene 6.6 is also having same issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7932) Search record with field value='a' or 'A' returns all records along with one more field value

[Rohit Balekundri (JIRA)]

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

Rohit Balekundri updated LUCENE-7932:
-
Description: 
Hi Lucene Team,

Here I explained more about issue facing after querying using QueryParser API.

Here I am just giving examples of our project with field names (Not related 
with Lucene):
In our document which needs to be archived having key fields and non-key fields.
A> Key fields: 
1. LocationCode (DataType=long)
2. CollectionObjectID (DataType=long)
B> Non-key fields
Category (DataType=string)

Steps we followed:
1. Step 1: We stored multiple document records with category values as below in 
index files.
 LocationCode = 1  Category =b
 LocationCode = 2  Category =BC
 LocationCode =3  Category =bcd
2. In Step 2: we query for records and we pass query parameters as below.
a) LocationCode=1 and  Category =a  
 Result= all records displayed
b) LocationCode=1 and  Category =A  result= all records displayed
 Result= all records displayed

I faced above issue in Lucene 5.3.
Llater I found even Lucene 6.6 is also having same issue.
Kindly consider this bug on top priority.


  was:
Hi Lucene Team,

I would like to explain more on about issue facing after querying using 
QueryParser API.

Here I am just giving examples of our project with field names (Not related 
with Lucene):
In our document which needs to be archived having key fields and non-key fields.
A> Key fields: 
1. LocationCode (DataType=long)
2. CollectionObjectID (DataType=long)
B> Non-key fields
Category (DataType=string)

Steps we followed:
1. Step 1: We stored multiple document records with category values as below in 
index files.
 LocationCode = 1  Category =b
 LocationCode = 2  Category =BC
 LocationCode =3  Category =bcd
2. In Step 2: we query for records and we pass query parameters as below.
a) LocationCode=1 and  Category =a  
 Result= all records displayed
b) LocationCode=1 and  Category =A  result= all records displayed
 Result= all records displayed

I faced above issue in Lucene 5.3.
Llater I found even Lucene 6.6 is also having same issue.
Kindly consider this bug on top priority.



> Search record with field value='a' or 'A' returns all records along with one 
> more field value
> -
>
> Key: LUCENE-7932
> URL: https://issues.apache.org/jira/browse/LUCENE-7932
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.3, 6.6
> Environment: Windows and Linux
>Reporter: Rohit Balekundri
>  Labels: features
>
> Hi Lucene Team,
> Here I explained more about issue facing after querying using QueryParser API.
> Here I am just giving examples of our project with field names (Not related 
> with Lucene):
> In our document which needs to be archived having key fields and non-key 
> fields.
> A> Key fields: 
> 1. LocationCode (DataType=long)
> 2. CollectionObjectID (DataType=long)
> B> Non-key fields
> Category (DataType=string)
> Steps we followed:
> 1. Step 1: We stored multiple document records with category values as below 
> in index files.
>  LocationCode = 1  Category =b
>  LocationCode = 2  Category =BC
>  LocationCode =3  Category =bcd
> 2. In Step 2: we query for records and we pass query parameters as below.
> a) LocationCode=1 and  Category =a  
>  Result= all records displayed
> b) LocationCode=1 and  Category =A  result= all records displayed
>  Result= all records displayed
> I faced above issue in Lucene 5.3.
> Llater I found even Lucene 6.6 is also having same issue.
> Kindly consider this bug on top priority.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7936) Extend Geoshape interfaces so objects can be copied/serialized

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-7936:
--

"If these are insufficient for what you're trying to do, please let me know 
why."

For what I see there, the classes in the package only handle points in Planet 
model WGS84. I am interested in the SPHERE, indexing polygons as well as 
points. My approach is more similar to the class in spatial-extras Geo3DShape 
but creating my custom spatial context which wraps the Geo3dArea shapes. 

"So perhaps you are going to need to do something different anyway?"

This is true for generic polygons but the polygons I am working with expand as 
much as a few degrees. I made an experiment tonight creating random polygons 
that expand less than Math.PI with many points. It was never decomposed using 
concave polygons. I do think the library does what I need for my use case. 
 

> Extend Geoshape interfaces so objects can be copied/serialized
> --
>
> Key: LUCENE-7936
> URL: https://issues.apache.org/jira/browse/LUCENE-7936
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7936.patch
>
>
> Hi [~david.wri...@bksv.com],
> I would like to propose to extends the GeoShape interfaces to be able to 
> copy/serialized the objects. The current status and  propose change is as 
> following:
> GeoPoint: It can be serialized by using x, y, z
> GeoCircle:  It can be serialized by using getCenter() and getRadius() and 
> getPlanetModel()
> GeoCompositeShape: It can be serialized by accesing shapes using size() and 
> GetShape(int index)
> GeoPath: add methods to the interface getPoints() and getCutoffAngle()
> GeoPolygon: This is the most complicated one as we have different types:
>1.- GeoCompositePolygon is just a composite
>2.- GeoConcavePolygon and GeoConvexPolygon: Create a new interface for 
> those polygons which exposes the points, holes, internaledges and 
> concavity/convexity
>3.- GeoComplexPolygons: Do nothing, they are too complex to be serialize??
> I am intersested in accesing the discreatization of the polygons into convex 
> and concave ones for other reasons as well. I think this should be expose as 
> they end result can be used for other use cases.
> Cheers,
> I.
>   



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-Tests-6.6 - Build # 35 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.6/35/

3 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Something is broken in the assert for no shards using the same indexDir - 
probably something was changed in the attributes published in the MBean of 
SolrCore : {}

Stack Trace:
java.lang.AssertionError: Something is broken in the assert for no shards using 
the same indexDir - probably something was changed in the attributes published 
in the MBean of SolrCore : {}
at 
__randomizedtesting.SeedInfo.seed([91A83F8C007FE8E3:D9DD4B38064CC776]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.checkNoTwoShardsUseTheSameIndexDir(CollectionsAPIDistributedZkTest.java:646)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:524)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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$StatementRunn

[jira] [Reopened] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Varun Thacker (JIRA)]

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

Varun Thacker reopened SOLR-8689:
-

Re-opening to backport to branch_6_6

> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS-EA] Lucene-Solr-7.x-Linux (32bit/jdk-9-ea+181) - Build # 300 - Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Linux/300/
Java: 32bit/jdk-9-ea+181 -server -XX:+UseSerialGC --illegal-access=deny

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete

Error Message:
Error from server at 
https://127.0.0.1:45291/solr/testcollection_shard1_replica_n2: Expected mime 
type application/octet-stream but got text/html.Error 
404HTTP ERROR: 404 Problem accessing 
/solr/testcollection_shard1_replica_n2/update. Reason: Can not find: 
/solr/testcollection_shard1_replica_n2/update http://eclipse.org/jetty";>Powered by Jetty:// 9.3.20.v20170531 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at https://127.0.0.1:45291/solr/testcollection_shard1_replica_n2: 
Expected mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: /solr/testcollection_shard1_replica_n2/update
http://eclipse.org/jetty";>Powered by Jetty:// 
9.3.20.v20170531



at 
__randomizedtesting.SeedInfo.seed([EF3D113FE05D98D6:4CC7BF9A67B57273]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:167)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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.rule

[JENKINS-MAVEN] Lucene-Solr-Maven-master #2095: POMs out of sync

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-master/2095/

No tests ran.

Build Log:
[...truncated 23201 lines...]
-validate-maven-dependencies:
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-codecs:8.0.0-SNAPSHOT: checking for updates from 
sonatype.releases
[artifact:dependencies] Downloading: 
org/apache/lucene/lucene-codecs/8.0.0-SNAPSHOT/lucene-codecs-8.0.0-SNAPSHOT.pom 
from repository sonatype.releases at 
https://oss.sonatype.org/content/repositories/releases
[artifact:dependencies] Unable to locate resource in repository
[artifact:dependencies] [INFO] Unable to find resource 
'org.apache.lucene:lucene-codecs:pom:8.0.0-SNAPSHOT' in repository 
sonatype.releases (https://oss.sonatype.org/content/repositories/releases)
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-core:8.0.0-SNAPSHOT: checking for updates from 
sonatype.releases
[artifact:dependencies] Downloading: 
org/apache/lucene/lucene-core/8.0.0-SNAPSHOT/lucene-core-8.0.0-SNAPSHOT.pom 
from repository sonatype.releases at 
https://oss.sonatype.org/content/repositories/releases
[artifact:dependencies] Unable to locate resource in repository
[artifact:dependencies] [INFO] Unable to find resource 
'org.apache.lucene:lucene-core:pom:8.0.0-SNAPSHOT' in repository 
sonatype.releases (https://oss.sonatype.org/content/repositories/releases)
[artifact:dependencies] Downloading: 
org/apache/lucene/lucene-codecs/8.0.0-SNAPSHOT/lucene-codecs-8.0.0-SNAPSHOT.jar 
from repository sonatype.releases at 
https://oss.sonatype.org/content/repositories/releases
[artifact:dependencies] Unable to locate resource in repository
[artifact:dependencies] [INFO] Unable to find resource 
'org.apache.lucene:lucene-codecs:jar:8.0.0-SNAPSHOT' in repository 
sonatype.releases (https://oss.sonatype.org/content/repositories/releases)
[artifact:dependencies] Downloading: 
org/apache/lucene/lucene-core/8.0.0-SNAPSHOT/lucene-core-8.0.0-SNAPSHOT.jar 
from repository sonatype.releases at 
https://oss.sonatype.org/content/repositories/releases
[artifact:dependencies] Unable to locate resource in repository
[artifact:dependencies] [INFO] Unable to find resource 
'org.apache.lucene:lucene-core:jar:8.0.0-SNAPSHOT' in repository 
sonatype.releases (https://oss.sonatype.org/content/repositories/releases)
[artifact:dependencies] An error has occurred while processing the Maven 
artifact tasks.

[...truncated 44 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:828: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:379: 
The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/build.xml:441:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:1742:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/lucene/common-build.xml:583:
 Unable to resolve artifact: Missing:
--
1) org.apache.lucene:lucene-codecs:jar:8.0.0-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.lucene 
-DartifactId=lucene-codecs -Dversion=8.0.0-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.lucene 
-DartifactId=lucene-codecs -Dversion=8.0.0-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.lucene:lucene-test-framework:jar:8.0.0-SNAPSHOT
2) org.apache.lucene:lucene-codecs:jar:8.0.0-SNAPSHOT

2) org.apache.lucene:lucene-core:jar:8.0.0-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.lucene 
-DartifactId=lucene-core -Dversion=8.0.0-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.lucene 
-DartifactId=lucene-core -Dversion=8.0.0-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.lucene:lucene-test-framework:jar:8.0.0-SNAPSHOT
2) org.apache.lucene:lucene-core:jar:8.0.0-SNAPSHOT

--
2 required artifacts are missing.

for artifact: 
  org.apache.lucene:lucene-test-framework:jar:8.0.0-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  Nexus (http://repository.apache.org/snapshots),
  sonatype.releases (https://oss.sonatype.org/content/repositories/releases)



Total time: 30 minutes 33 seconds
Build step 'Invoke Ant' marked build as fa

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

[Policeman Jenkins Server]

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

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestJmxIntegration

Error Message:
No JMX server found by monitor map

Stack Trace:
java.lang.AssertionError: No JMX server found by monitor map
at __randomizedtesting.SeedInfo.seed([B2DD97DB2DBBAFD3]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.core.TestJmxIntegration.beforeClass(TestJmxIntegration.java:75)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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.schema.TestUseDocValuesAsStored.testMultipleSearchResults

Error Message:
mismatch: 'myid1'!='myid' @ response/docs/[0]/id

Stack Trace:
java.lang.RuntimeException: mismatch: 'myid1'!='myid' @ response/docs/[0]/id
at 
__randomizedtesting.SeedInfo.seed([B2DD97DB2DBBAFD3:80F79045D5458B0A]:0)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:983)
at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:930)
at 
org.apache.solr.schema.TestUseDocValuesAsStored.testMultipleSearchResults(TestUseDocValuesAsStored.java:243)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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(TestRuleIgnore

[JENKINS] Lucene-Solr-SmokeRelease-7.0 - Build # 31 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.0/31/

No tests ran.

Build Log:
[...truncated 25710 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (38.4 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.0.0-src.tgz...
   [smoker] 29.5 MB in 0.02 sec (1207.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.tgz...
   [smoker] 69.0 MB in 0.06 sec (1188.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.0.0.zip...
   [smoker] 79.3 MB in 0.07 sec (1175.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6165 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6165 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.0.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (21.8 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.0.0-src.tgz...
   [smoker] 51.1 MB in 0.76 sec (67.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.tgz...
   [smoker] 142.7 MB in 1.14 sec (124.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.0.0.zip...
   [smoker] 143.7 MB in 0.12 sec (1151.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.0.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.0.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.0/lucene/build/smokeTestRelease/tmp/unpack/solr-7.0.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=3868). Happy searching!
   [smoker] 
   [smoker] 
 

[JENKINS] Lucene-Solr-Tests-7.x - Build # 144 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.x/144/

4 tests failed.
FAILED:  org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv

Error Message:
java.lang.RuntimeException: Error from server at 
http://127.0.0.1:35952/solr/test_col: Async exception during distributed 
update: Error from server at 
http://127.0.0.1:43845/solr/test_col_shard1_replica_n1: Server Error
request: 
http://127.0.0.1:43845/solr/test_col_shard1_replica_n1/update?update.distrib=TOLEADER&distrib.from=http%3A%2F%2F127.0.0.1%3A35952%2Fsolr%2Ftest_col_shard1_replica_n2%2F&wt=javabin&version=2
 Remote error message: Failed synchronous update on shard StdNode: 
http://127.0.0.1:35952/solr/test_col_shard1_replica_n2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@13d3cdf2

Stack Trace:
java.util.concurrent.ExecutionException: java.lang.RuntimeException: Error from 
server at http://127.0.0.1:35952/solr/test_col: Async exception during 
distributed update: Error from server at 
http://127.0.0.1:43845/solr/test_col_shard1_replica_n1: Server Error



request: 
http://127.0.0.1:43845/solr/test_col_shard1_replica_n1/update?update.distrib=TOLEADER&distrib.from=http%3A%2F%2F127.0.0.1%3A35952%2Fsolr%2Ftest_col_shard1_replica_n2%2F&wt=javabin&version=2
Remote error message: Failed synchronous update on shard StdNode: 
http://127.0.0.1:35952/solr/test_col_shard1_replica_n2/ update: 
org.apache.solr.client.solrj.request.UpdateRequest@13d3cdf2
at 
__randomizedtesting.SeedInfo.seed([9E487420AEB72D2:3FF0E50480B648C3]:0)
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:283)
at 
org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv(TestStressCloudBlindAtomicUpdates.java:195)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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)
   

[jira] [Commented] (SOLR-5129) Timeout property for waiting ZK get started

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5129: Renaming test class to ZkFailoverTest


> Timeout property for waiting ZK get started
> ---
>
> Key: SOLR-5129
> URL: https://issues.apache.org/jira/browse/SOLR-5129
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 4.4
>Reporter: Shawn Heisey
>Assignee: Cao Manh Dat
>Priority: Minor
> Fix For: 7.1
>
> Attachments: SOLR-5129.patch, SOLR-5129.patch
>
>
> Summary of report from user on mailing list:
> If zookeeper is down or doesn't have quorum when you start Solr nodes, they 
> will not function correctly, even if you later start zookeeper.  While 
> zookeeper is down, the log shows connection failures as expected.  When 
> zookeeper comes back, the log shows:
> INFO  - 2013-08-09 15:48:41.528; 
> org.apache.solr.common.cloud.ConnectionManager; Client->ZooKeeper status 
> change trigger but we are already closed
> At that point, Solr (admin UI and all other functions) does not work, and 
> won't work until it is restarted.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-5129) Timeout property for waiting ZK get started

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-5129: Renaming test class to ZkFailoverTest


> Timeout property for waiting ZK get started
> ---
>
> Key: SOLR-5129
> URL: https://issues.apache.org/jira/browse/SOLR-5129
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 4.4
>Reporter: Shawn Heisey
>Assignee: Cao Manh Dat
>Priority: Minor
> Fix For: 7.1
>
> Attachments: SOLR-5129.patch, SOLR-5129.patch
>
>
> Summary of report from user on mailing list:
> If zookeeper is down or doesn't have quorum when you start Solr nodes, they 
> will not function correctly, even if you later start zookeeper.  While 
> zookeeper is down, the log shows connection failures as expected.  When 
> zookeeper comes back, the log shows:
> INFO  - 2013-08-09 15:48:41.528; 
> org.apache.solr.common.cloud.ConnectionManager; Client->ZooKeeper status 
> change trigger but we are already closed
> At that point, Solr (admin UI and all other functions) does not work, and 
> won't work until it is restarted.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6838/
Java: 32bit/jdk1.8.0_144 -client -XX:+UseG1GC

2 tests failed.
FAILED:  
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testExecutorStream

Error Message:
Error from server at http://127.0.0.1:59254/solr/mainCorpus_shard2_replica_n3: 
Expected mime type application/octet-stream but got text/html.   
 
Error 404HTTP ERROR: 404 Problem 
accessing /solr/mainCorpus_shard2_replica_n3/update. Reason: Can not 
find: /solr/mainCorpus_shard2_replica_n3/update http://eclipse.org/jetty";>Powered by Jetty:// 9.3.20.v20170531 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:59254/solr/mainCorpus_shard2_replica_n3: Expected 
mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /solr/mainCorpus_shard2_replica_n3/update. Reason:
Can not find: /solr/mainCorpus_shard2_replica_n3/update
http://eclipse.org/jetty";>Powered by Jetty:// 
9.3.20.v20170531



at 
__randomizedtesting.SeedInfo.seed([52E1C380C65926A0:7021427BE5330CB0]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.client.solrj.io.stream.StreamExpressionTest.testExecutorStream(StreamExpressionTest.java:6816)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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.StatementAd

[jira] [Closed] (SOLR-11273) Unit test exception of TestEdisMaxSolrFeature

[chenmin (JIRA)]

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

chenmin closed SOLR-11273.
--
Resolution: Fixed

> Unit test exception of TestEdisMaxSolrFeature
> -
>
> Key: SOLR-11273
> URL: https://issues.apache.org/jira/browse/SOLR-11273
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: chenmin
>
> ERROR :
> org.apache.solr.common.SolrException: ERROR: [doc=6] unknown field 
> 'description'!
> I found the unit test with the wrong configuration file (schema)
> Compiler Environment： eclipse,windows。



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11274) Unit test exception of TestEdisMaxSolrFeature

[chenmin (JIRA)]

chenmin created SOLR-11274:
--

 Summary: Unit test exception of TestEdisMaxSolrFeature
 Key: SOLR-11274
 URL: https://issues.apache.org/jira/browse/SOLR-11274
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6
Reporter: chenmin


ERROR :
org.apache.solr.common.SolrException: ERROR: [doc=6] unknown field 
'description'!

I found the unit test with the wrong configuration file (schema)

Compiler Environment： eclipse,windows。



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11273) Unit test exception of TestEdisMaxSolrFeature

[chenmin (JIRA)]

chenmin created SOLR-11273:
--

 Summary: Unit test exception of TestEdisMaxSolrFeature
 Key: SOLR-11273
 URL: https://issues.apache.org/jira/browse/SOLR-11273
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6
Reporter: chenmin


ERROR :
org.apache.solr.common.SolrException: ERROR: [doc=6] unknown field 
'description'!

I found the unit test with the wrong configuration file (schema)

Compiler Environment： eclipse,windows。



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Release a 6.6.1

[Varun Thacker]

Hi Uwe,

I can backport it and then I'll begin working on the RC

On Tue, Aug 22, 2017 at 2:17 AM, Uwe Schindler  wrote:

> Hi,
>
>
>
> The windows startup script fix was committed to 7.0, but not 6.6.1. If
> Varun has time to test the fixes in https://issues.apache.org/
> jira/browse/SOLR-8689 we may include them, but I left them out for now.
> Please reopen the issue if you think it’s worth. It should be a simple
> cherry pick.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Uwe Schindler [mailto:u...@thetaphi.de]
> *Sent:* Monday, August 21, 2017 2:11 PM
>
> *To:* dev@lucene.apache.org
> *Subject:* RE: Release a 6.6.1
>
>
>
> Hi,
>
>
>
> Is there any interest to maybe get the Windows Shell scripts fixed, so
> they work with Java 9? Currently you cannot start Solr on Windows systems,
> as the version number checking and the GC options are not working. It’s
> https://issues.apache.org/jira/browse/SOLR-8689 - I am just waiting for
> feedback and wanted to put it into 7.0. But if there is interest, I can
> backport to 6.6, too (not yet planned).
>
>
>
> Yesterday (before your mail), I already backported a Hadoop 2.7.2 -> 2.7.4
> update, so it works now with Java 9. This made the ugly workaround obsolete
> (changing java.version sysprop temporarily). This fix is now in 6.6.1 and
> 7.0 branch.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Varun Thacker [mailto:va...@vthacker.in ]
> *Sent:* Monday, August 21, 2017 12:49 PM
> *To:* dev@lucene.apache.org
> *Subject:* Re: Release a 6.6.1
>
>
>
> Hi Everyone,
>
>
>
> Does anyone plan on committing any more fixes to the release branch?
>
>
>
> I've disabled SOLR-11247 for the branch so that we get a few Jenkins runs
> without any failures.
>
>
>
> I plan on creating an RC in 12-14 hours time from now if all goes well
>
>
>
> On Mon, Aug 21, 2017 at 8:50 AM, Erick Erickson 
> wrote:
>
> Uwe:
>
>
>
> As far as I'm concerned, please do put both in. Varun is the RM and has
> final say of course. He may be traveling though and be a little delayed
> responding.
>
>
>
> Erick
>
>
>
> On Sun, Aug 20, 2017 at 5:41 AM, Uwe Schindler  wrote:
>
> Hi,
>
>
>
> I just noticed, that our Hadoop friends released Hadoop 2.7.4. This fixes
> the stupid Java 9 bug in their static initializer (StringIndexOutOfBounds).
> So I’d like to also get https://issues.apache.org/jira/browse/SOLR-11261
> in. If Jenkins is happy on 7.x and master, this should be easy.
>
>
>
> If you think it’s too risky (Hadoop 2.7.2 -> 2.7.4), we can live with the
> workaround in Lucene 6.6.1! But the workaround is really hacky: It changes
> the “java.version” system property temporarily on Java 9 while initializing
> Hadoop, which is not something you should ever do!
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Uwe Schindler [mailto:u...@thetaphi.de]
> *Sent:* Sunday, August 20, 2017 12:53 PM
> *To:* dev@lucene.apache.org
> *Subject:* RE: Release a 6.6.1
>
>
>
> Hi,
>
>
>
> I need to backport SOLR-10966 to branch 6.6, otherwise Jenkins does not
> pass with Java 9.
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Uwe Schindler [mailto:u...@thetaphi.de ]
> *Sent:* Saturday, August 19, 2017 12:00 AM
> *To:* dev@lucene.apache.org
> *Subject:* Re: Release a 6.6.1
>
>
>
> Hi,
>
> I enabled Jenkins jobs on 👮. ASF was active already.
>
> Uwe
>
> Am 18. August 2017 23:34:23 MESZ schrieb Varun Thacker  >:
>
> From the bug fixes in lucene 7.0 do we need to backport any of these
> issues :  LUCENE-7859 / LUCENE-7871 / LUCENE-7914 ?
>
>
>
> I plan on backporting these three Solr fixes on Sunday
>
>
>
> SOLR-10698
>
> SOLR-10719
>
> SOLR-11228
>
>
>
> looking through the 7.0 bug fixes these two look important to get in as
> well :
>
>
>
> SOLR-10983
>
> SOLR-9262
>
>
>
> So if no one get's to it I'll try backporting them as well
>
>
>
> Can someone please enable Jenkins on the branch again?
>
>
>
>
>
> On Thu, Aug 17, 2017 at 3:18 PM, Erick Erickson 
> wrote:
>
> Right, that was the original note before we decided to backport a
> bunch of other stuff and I decided it made no sense to omit this one.
> All that has to happen is remove the " (note, not in 7.0, is in 7.1)"
> bits since it's in 6.6, 6.x, 7.0, 7.1 and master.
>
> Good catch!
>
>
>
>
> On Thu, Aug 17, 2017 at 3:10 PM, Varun Thacker  wrote:
> > Should I then go remove the note part from the CHANGES entry in
> branch_6_6 ?
> >
> > * SOLR-11177: CoreContainer.load needs to send lazily loaded core
> > descriptors to the proper list rather than send
> >   them all to the transient lists. (Erick Erickson) (note, not in 7.0,
> is in
> > 7.1)
> >
> > I see a commit for this i

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

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  org.apache.solr.cloud.TestAuthenticationFramework.testBasics

Error Message:
Error from server at 
http://127.0.0.1:49525/solr/testcollection_shard1_replica_n2: Expected mime 
type application/octet-stream but got text/html.Error 
404HTTP ERROR: 404 Problem accessing 
/solr/testcollection_shard1_replica_n2/update. Reason: Can not find: 
/solr/testcollection_shard1_replica_n2/update http://eclipse.org/jetty";>Powered by Jetty:// 9.3.20.v20170531 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:49525/solr/testcollection_shard1_replica_n2: 
Expected mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: /solr/testcollection_shard1_replica_n2/update
http://eclipse.org/jetty";>Powered by Jetty:// 
9.3.20.v20170531



at 
__randomizedtesting.SeedInfo.seed([D1EEDE30DB35A089:EC36701CE3DBFEF9]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestAuthenticationFramework.collectionCreateSearchDeleteTwice(TestAuthenticationFramework.java:126)
at 
org.apache.solr.cloud.TestAuthenticationFramework.testBasics(TestAuthenticationFramework.java:74)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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(NoShadowingOrOverridesOnMethodsRu

[jira] [Updated] (SOLR-11272) EmbeddedSolrServer does not set the path for known SolrRequestHandlers

[Stephen Allen (JIRA)]

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

Stephen Allen updated SOLR-11272:
-
Description: 
{{EmbeddedSolrServer}} does not set the path for known {{SolrRequestHandlers}} 
in the query request context.  This leads to a {{NullPointerException}}.  Patch 
and test coming in pull request.

https://github.com/apache/lucene-solr/pull/237

  was:{{EmbeddedSolrServer}} does not set the path for known 
{{SolrRequestHandlers}} in the query request context.  This leads to a 
{{NullPointerException}}.  Patch and test coming in pull request.


> EmbeddedSolrServer does not set the path for known SolrRequestHandlers
> --
>
> Key: SOLR-11272
> URL: https://issues.apache.org/jira/browse/SOLR-11272
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Stephen Allen
>Priority: Minor
>
> {{EmbeddedSolrServer}} does not set the path for known 
> {{SolrRequestHandlers}} in the query request context.  This leads to a 
> {{NullPointerException}}.  Patch and test coming in pull request.
> https://github.com/apache/lucene-solr/pull/237



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[GitHub] lucene-solr pull request #237: Solr 11272 - EmbeddedSolrServer: Set path in ...

[Stephen-Allen]

GitHub user Stephen-Allen opened a pull request:

https://github.com/apache/lucene-solr/pull/237

Solr 11272 - EmbeddedSolrServer: Set path in query request context for 
known SolrRequestHandlers



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Stephen-Allen/lucene-solr SOLR-11272

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/lucene-solr/pull/237.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #237


commit 9df85237eec59785d8afd089e8fa69637a4d58d8
Author: Stephen Allen 
Date:   2017-08-22T01:51:14Z

Set path for known RequestHandlers in EmbeddedSolrServer

commit 67d77231a1a48b52690585f3f8fac39c42ab3e1b
Author: Stephen Allen 
Date:   2017-08-22T01:53:21Z

Unit test for EmbeddedSolrServer context path




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+181) - Build # 20356 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20356/
Java: 32bit/jdk-9-ea+181 -client -XX:+UseParallelGC --illegal-access=deny

1 tests failed.
FAILED:  
org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete

Error Message:
Error from server at 
http://127.0.0.1:38783/solr/testcollection_shard1_replica_n2: Expected mime 
type application/octet-stream but got text/html.Error 
404HTTP ERROR: 404 Problem accessing 
/solr/testcollection_shard1_replica_n2/update. Reason: Can not find: 
/solr/testcollection_shard1_replica_n2/update http://eclipse.org/jetty";>Powered by Jetty:// 9.3.20.v20170531 
  

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:38783/solr/testcollection_shard1_replica_n2: 
Expected mime type application/octet-stream but got text/html. 


Error 404 


HTTP ERROR: 404
Problem accessing /solr/testcollection_shard1_replica_n2/update. Reason:
Can not find: /solr/testcollection_shard1_replica_n2/update
http://eclipse.org/jetty";>Powered by Jetty:// 
9.3.20.v20170531



at 
__randomizedtesting.SeedInfo.seed([4DA56F9A8281768B:EE5FC13F05699C2E]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:539)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:993)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:233)
at 
org.apache.solr.cloud.TestCollectionsAPIViaSolrCloudCluster.testCollectionCreateSearchDelete(TestCollectionsAPIViaSolrCloudCluster.java:167)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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

[jira] [Created] (SOLR-11272) EmbeddedSolrServer does not set the path for known SolrRequestHandlers

[Stephen Allen (JIRA)]

Stephen Allen created SOLR-11272:


 Summary: EmbeddedSolrServer does not set the path for known 
SolrRequestHandlers
 Key: SOLR-11272
 URL: https://issues.apache.org/jira/browse/SOLR-11272
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.6
Reporter: Stephen Allen
Priority: Minor


{{EmbeddedSolrServer}} does not set the path for known {{SolrRequestHandlers}} 
in the query request context.  This leads to a {{NullPointerException}}.  Patch 
and test coming in pull request.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-SmokeRelease-6.6 - Build # 23 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.6/23/

No tests ran.

Build Log:
[...truncated 25888 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (16.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-6.6.1-src.tgz...
   [smoker] 29.6 MB in 0.02 sec (1210.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.6.1.tgz...
   [smoker] 67.6 MB in 0.06 sec (1173.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-6.6.1.zip...
   [smoker] 78.0 MB in 0.07 sec (1173.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-6.6.1.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6252 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.6.1.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6252 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-6.6.1-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 229 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (307.0 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-6.6.1-src.tgz...
   [smoker] 50.4 MB in 0.05 sec (1099.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.6.1.tgz...
   [smoker] 138.9 MB in 0.13 sec (1096.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-6.6.1.zip...
   [smoker] 140.0 MB in 0.12 sec (1144.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-6.6.1.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-6.6.1.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.1/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.1/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.1-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.1-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/tmp/unpack/solr-6.6.1-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=3425). Happy searching!
   [smoker] 
   [smoker] 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
Doc with id=1 not found in http://127.0.0.1:63001/wnwc/ja/collMinRf_1x3 due to: 
Path not found: /id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=1 not found in 
http://127.0.0.1:63001/wnwc/ja/collMinRf_1x3 due to: Path not found: /id; 
rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([BA90A51C4C724CC4:32C49AC6E28E213C]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:603)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:558)
at 
org.apache.solr.cloud.HttpPartitionTest.testMinRf(HttpPartitionTest.java:249)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:127)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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

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

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Maven-7.x/37/

No tests ran.

Build Log:
[...truncated 23213 lines...]
-validate-maven-dependencies:
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-codecs:7.1.0-SNAPSHOT: checking for updates from 
sonatype.releases
[artifact:dependencies] Downloading: 
org/apache/lucene/lucene-codecs/7.1.0-SNAPSHOT/lucene-codecs-7.1.0-SNAPSHOT.pom 
from repository sonatype.releases at 
https://oss.sonatype.org/content/repositories/releases
[artifact:dependencies] Unable to locate resource in repository
[artifact:dependencies] [INFO] Unable to find resource 
'org.apache.lucene:lucene-codecs:pom:7.1.0-SNAPSHOT' in repository 
sonatype.releases (https://oss.sonatype.org/content/repositories/releases)
[artifact:dependencies] [INFO] snapshot 
org.apache.lucene:lucene-core:7.1.0-SNAPSHOT: checking for updates from 
sonatype.releases
[artifact:dependencies] Downloading: 
org/apache/lucene/lucene-core/7.1.0-SNAPSHOT/lucene-core-7.1.0-SNAPSHOT.pom 
from repository sonatype.releases at 
https://oss.sonatype.org/content/repositories/releases
[artifact:dependencies] Unable to locate resource in repository
[artifact:dependencies] [INFO] Unable to find resource 
'org.apache.lucene:lucene-core:pom:7.1.0-SNAPSHOT' in repository 
sonatype.releases (https://oss.sonatype.org/content/repositories/releases)
[artifact:dependencies] Downloading: 
org/apache/lucene/lucene-codecs/7.1.0-SNAPSHOT/lucene-codecs-7.1.0-SNAPSHOT.jar 
from repository sonatype.releases at 
https://oss.sonatype.org/content/repositories/releases
[artifact:dependencies] Unable to locate resource in repository
[artifact:dependencies] [INFO] Unable to find resource 
'org.apache.lucene:lucene-codecs:jar:7.1.0-SNAPSHOT' in repository 
sonatype.releases (https://oss.sonatype.org/content/repositories/releases)
[artifact:dependencies] Downloading: 
org/apache/lucene/lucene-core/7.1.0-SNAPSHOT/lucene-core-7.1.0-SNAPSHOT.jar 
from repository sonatype.releases at 
https://oss.sonatype.org/content/repositories/releases
[artifact:dependencies] Unable to locate resource in repository
[artifact:dependencies] [INFO] Unable to find resource 
'org.apache.lucene:lucene-core:jar:7.1.0-SNAPSHOT' in repository 
sonatype.releases (https://oss.sonatype.org/content/repositories/releases)
[artifact:dependencies] An error has occurred while processing the Maven 
artifact tasks.

[...truncated 44 lines...]
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/build.xml:828: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/build.xml:379: The 
following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/build.xml:441:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/common-build.xml:1742:
 The following error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-7.x/lucene/common-build.xml:583:
 Unable to resolve artifact: Missing:
--
1) org.apache.lucene:lucene-codecs:jar:7.1.0-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.lucene 
-DartifactId=lucene-codecs -Dversion=7.1.0-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.lucene 
-DartifactId=lucene-codecs -Dversion=7.1.0-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.lucene:lucene-test-framework:jar:7.1.0-SNAPSHOT
2) org.apache.lucene:lucene-codecs:jar:7.1.0-SNAPSHOT

2) org.apache.lucene:lucene-core:jar:7.1.0-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.lucene 
-DartifactId=lucene-core -Dversion=7.1.0-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.lucene 
-DartifactId=lucene-core -Dversion=7.1.0-SNAPSHOT -Dpackaging=jar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.lucene:lucene-test-framework:jar:7.1.0-SNAPSHOT
2) org.apache.lucene:lucene-core:jar:7.1.0-SNAPSHOT

--
2 required artifacts are missing.

for artifact: 
  org.apache.lucene:lucene-test-framework:jar:7.1.0-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  Nexus (http://repository.apache.org/snapshots),
  sonatype.releases (https://oss.sonatype.org/content/repositories/releases)



Total time: 31 minutes 31 seconds
Build step 'Invoke Ant' marked build as failure
Email was trig

[JENKINS] Lucene-Solr-Tests-7.0 - Build # 119 - Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-7.0/119/

1 tests failed.
FAILED:  
org.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster

Error Message:
Document mismatch on target after sync expected:<2000> but was:<1100>

Stack Trace:
java.lang.AssertionError: Document mismatch on target after sync 
expected:<2000> but was:<1100>
at 
__randomizedtesting.SeedInfo.seed([CE56A3BA73F4242C:1A13E8E394A297D7]: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.apache.solr.cloud.CdcrBootstrapTest.testBootstrapWithContinousIndexingOnSourceCluster(CdcrBootstrapTest.java:309)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 12552 lines...]
   [junit4] Suite: org.apache.solr.cloud.CdcrBootstrapTest
   

[JENKINS] Lucene-Solr-6.6-Linux (64bit/jdk1.8.0_144) - Build # 77 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Linux/77/
Java: 64bit/jdk1.8.0_144 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth

Error Message:
Error from server at https://127.0.0.1:42163/solr/authCollection: No registered 
leader was found after waiting for 4000ms , collection: authCollection slice: 
shard2

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:42163/solr/authCollection: No registered 
leader was found after waiting for 4000ms , collection: authCollection slice: 
shard2
at 
__randomizedtesting.SeedInfo.seed([3443B7047EB14507:882DC116DAE2C67D]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:612)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:447)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:388)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1383)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1134)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:194)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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.Statement

[jira] [Commented] (SOLR-10317) Solr Nightly Benchmarks

[Vivek Narang (JIRA)]

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

Vivek Narang commented on SOLR-10317:
-

Hi [~ichattopadhyaya],
I was working on a big section of backend refactoring last week, I will send an 
update after committing the code tonight. Regards. 

> Solr Nightly Benchmarks
> ---
>
> Key: SOLR-10317
> URL: https://issues.apache.org/jira/browse/SOLR-10317
> Project: Solr
>  Issue Type: Task
>Reporter: Ishan Chattopadhyaya
>  Labels: gsoc2017, mentor
> Attachments: changes-lucene-20160907.json, 
> changes-solr-20160907.json, managed-schema, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks.docx, 
> Narang-Vivek-SOLR-10317-Solr-Nightly-Benchmarks-FINAL-PROPOSAL.pdf, 
> Screenshot from 2017-07-30 20-30-05.png, SOLR-10317.patch, SOLR-10317.patch, 
> solrconfig.xml
>
>
> Solr needs nightly benchmarks reporting. Similar Lucene benchmarks can be 
> found here, https://home.apache.org/~mikemccand/lucenebench/.
> Preferably, we need:
> # A suite of benchmarks that build Solr from a commit point, start Solr 
> nodes, both in SolrCloud and standalone mode, and record timing information 
> of various operations like indexing, querying, faceting, grouping, 
> replication etc.
> # It should be possible to run them either as an independent suite or as a 
> Jenkins job, and we should be able to report timings as graphs (Jenkins has 
> some charting plugins).
> # The code should eventually be integrated in the Solr codebase, so that it 
> never goes out of date.
> There is some prior work / discussion:
> # https://github.com/shalinmangar/solr-perf-tools (Shalin)
> # https://github.com/chatman/solr-upgrade-tests/blob/master/BENCHMARKS.md 
> (Ishan/Vivek)
> # SOLR-2646 & SOLR-9863 (Mark Miller)
> # https://home.apache.org/~mikemccand/lucenebench/ (Mike McCandless)
> # https://github.com/lucidworks/solr-scale-tk (Tim Potter)
> There is support for building, starting, indexing/querying and stopping Solr 
> in some of these frameworks above. However, the benchmarks run are very 
> limited. Any of these can be a starting point, or a new framework can as well 
> be used. The motivation is to be able to cover every functionality of Solr 
> with a corresponding benchmark that is run every night.
> Proposing this as a GSoC 2017 project. I'm willing to mentor, and I'm sure 
> [~shalinmangar] and [~markrmil...@gmail.com] would help here.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

5 tests failed.
FAILED:  org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test

Error Message:
Could not find collection:collection2

Stack Trace:
java.lang.AssertionError: Could not find collection:collection2
at 
__randomizedtesting.SeedInfo.seed([C1FB6CE31C3B1A32:49AF5339B2C777CA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:140)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:135)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:908)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.testIndexingBatchPerRequestWithHttpSolrClient(FullSolrCloudDistribCmdsTest.java:612)
at 
org.apache.solr.cloud.FullSolrCloudDistribCmdsTest.test(FullSolrCloudDistribCmdsTest.java:152)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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(Statem

[JENKINS] Lucene-Solr-NightlyTests-7.x - Build # 32 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.x/32/

4 tests failed.
FAILED:  org.apache.lucene.index.TestIndexSorting.testRandom3

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([2E240DD4F2684B9D:8CFC430E969A629B]:0)
at org.apache.lucene.util.packed.Packed64.(Packed64.java:73)
at 
org.apache.lucene.util.packed.PackedInts.getMutable(PackedInts.java:972)
at 
org.apache.lucene.util.packed.PackedInts.getMutable(PackedInts.java:939)
at 
org.apache.lucene.util.packed.GrowableWriter.ensureCapacity(GrowableWriter.java:80)
at 
org.apache.lucene.util.packed.GrowableWriter.set(GrowableWriter.java:88)
at 
org.apache.lucene.util.packed.AbstractPagedMutable.set(AbstractPagedMutable.java:98)
at org.apache.lucene.util.fst.NodeHash.addNew(NodeHash.java:152)
at org.apache.lucene.util.fst.NodeHash.rehash(NodeHash.java:169)
at org.apache.lucene.util.fst.NodeHash.add(NodeHash.java:133)
at org.apache.lucene.util.fst.Builder.compileNode(Builder.java:200)
at org.apache.lucene.util.fst.Builder.freezeTail(Builder.java:296)
at org.apache.lucene.util.fst.Builder.add(Builder.java:400)
at 
org.apache.lucene.codecs.memory.MemoryDocValuesConsumer.writeFST(MemoryDocValuesConsumer.java:373)
at 
org.apache.lucene.codecs.memory.MemoryDocValuesConsumer.addSortedField(MemoryDocValuesConsumer.java:416)
at 
org.apache.lucene.codecs.memory.MemoryDocValuesConsumer.addSortedField(MemoryDocValuesConsumer.java:406)
at 
org.apache.lucene.codecs.DocValuesConsumer.mergeSortedField(DocValuesConsumer.java:527)
at 
org.apache.lucene.codecs.DocValuesConsumer.merge(DocValuesConsumer.java:139)
at 
org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.merge(PerFieldDocValuesFormat.java:151)
at 
org.apache.lucene.index.SegmentMerger.mergeDocValues(SegmentMerger.java:181)
at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:125)
at 
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4392)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:4032)
at 
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2235)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2068)
at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:2019)
at 
org.apache.lucene.index.TestIndexSorting.testRandom3(TestIndexSorting.java:2318)
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:1713)


FAILED:  org.apache.solr.update.AutoCommitTest.testMaxDocs

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([40BFB5BAEEAE1CBC:F93E6365C2441836]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:880)
at 
org.apache.solr.update.AutoCommitTest.testMaxDocs(AutoCommitTest.java:225)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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(StatementAda

RE: Release a 6.6.1

[Uwe Schindler]

Hi,

 

The windows startup script fix was committed to 7.0, but not 6.6.1. If Varun 
has time to test the fixes in https://issues.apache.org/jira/browse/SOLR-8689 
we may include them, but I left them out for now. Please reopen the issue if 
you think it’s worth. It should be a simple cherry pick.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Uwe Schindler [mailto:u...@thetaphi.de] 
Sent: Monday, August 21, 2017 2:11 PM
To: dev@lucene.apache.org
Subject: RE: Release a 6.6.1

 

Hi,

 

Is there any interest to maybe get the Windows Shell scripts fixed, so they 
work with Java 9? Currently you cannot start Solr on Windows systems, as the 
version number checking and the GC options are not working. It’s 
https://issues.apache.org/jira/browse/SOLR-8689 - I am just waiting for 
feedback and wanted to put it into 7.0. But if there is interest, I can 
backport to 6.6, too (not yet planned).

 

Yesterday (before your mail), I already backported a Hadoop 2.7.2 -> 2.7.4 
update, so it works now with Java 9. This made the ugly workaround obsolete 
(changing java.version sysprop temporarily). This fix is now in 6.6.1 and 7.0 
branch.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de  

 

From: Varun Thacker [mailto:va...@vthacker.in] 
Sent: Monday, August 21, 2017 12:49 PM
To: dev@lucene.apache.org  
Subject: Re: Release a 6.6.1

 

Hi Everyone,

 

Does anyone plan on committing any more fixes to the release branch? 

 

I've disabled SOLR-11247 for the branch so that we get a few Jenkins runs 
without any failures. 

 

I plan on creating an RC in 12-14 hours time from now if all goes well 

 

On Mon, Aug 21, 2017 at 8:50 AM, Erick Erickson < 
 erickerick...@gmail.com> wrote:

Uwe:

 

As far as I'm concerned, please do put both in. Varun is the RM and has final 
say of course. He may be traveling though and be a little delayed responding.

 

Erick

 

On Sun, Aug 20, 2017 at 5:41 AM, Uwe Schindler <  
u...@thetaphi.de> wrote:

Hi,

 

I just noticed, that our Hadoop friends released Hadoop 2.7.4. This fixes the 
stupid Java 9 bug in their static initializer (StringIndexOutOfBounds). So I’d 
like to also get   
https://issues.apache.org/jira/browse/SOLR-11261 in. If Jenkins is happy on 7.x 
and master, this should be easy.

 

If you think it’s too risky (Hadoop 2.7.2 -> 2.7.4), we can live with the 
workaround in Lucene 6.6.1! But the workaround is really hacky: It changes the 
“java.version” system property temporarily on Java 9 while initializing Hadoop, 
which is not something you should ever do!

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de  

 

From: Uwe Schindler [mailto:  u...@thetaphi.de] 
Sent: Sunday, August 20, 2017 12:53 PM
To:   dev@lucene.apache.org
Subject: RE: Release a 6.6.1

 

Hi,

 

I need to backport SOLR-10966 to branch 6.6, otherwise Jenkins does not pass 
with Java 9.

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de  

 

From: Uwe Schindler [  mailto:u...@thetaphi.de] 
Sent: Saturday, August 19, 2017 12:00 AM
To:   dev@lucene.apache.org
Subject: Re: Release a 6.6.1

 

Hi,

I enabled Jenkins jobs on 👮. ASF was active already.

Uwe

Am 18. August 2017 23:34:23 MESZ schrieb Varun Thacker mailto:va...@vthacker.in> >:

>From the bug fixes in lucene 7.0 do we need to backport any of these issues :  
>LUCENE-7859 / LUCENE-7871 / LUCENE-7914 ?

 

I plan on backporting these three Solr fixes on Sunday 

 

SOLR-10698

SOLR-10719

SOLR-11228

 

looking through the 7.0 bug fixes these two look important to get in as well :

 

SOLR-10983

SOLR-9262

 

So if no one get's to it I'll try backporting them as well 

 

Can someone please enable Jenkins on the branch again?

 

 

On Thu, Aug 17, 2017 at 3:18 PM, Erick Erickson < 
 erickerick...@gmail.com> wrote:

Right, that was the original note before we decided to backport a
bunch of other stuff and I decided it made no sense to omit this one.
All that has to happen is remove the " (note, not in 7.0, is in 7.1)"
bits since it's in 6.6, 6.x, 7.0, 7.1 and master.

Good catch!




On Thu, Aug 17, 2017 at 3:10 PM, Varun Thacker <  
va...@vthacker.in> wrote:
> Should I then go remove the note part from the CHANGES entry in branch_6_6 ?
>
> * SOLR-11177: CoreContainer.load needs to send lazily loaded co

RE: Ready for JDK 9 ?

[Uwe Schindler]

Hi Rory,

Apache Lucene/Solr 7.0 will be the first version that "offcially" supports Java 
9. It will come out the next weeks. I fixed the startup scripts of Apache Solr 
and we also tested GC logging successfully:

https://issues.apache.org/jira/browse/SOLR-8689
https://issues.apache.org/jira/browse/SOLR-10184
https://issues.apache.org/jira/browse/SOLR-8689

We finally fixed the issues with Apache Hadoop integration, as upstream updated 
their library to not fail on the plain "9" as version number with 
StringIndexOutOfBoundsException.

Apache Lucene and Solr 6.6.1 will also be released soon, but it is not yet 
decided if we backport everything (the Hadoop upgrade was committed already, 
the shell scripts of windows not yet).

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Rory O'Donnell [mailto:rory.odonn...@oracle.com]
> Sent: Thursday, August 10, 2017 10:49 AM
> To: dev@lucene.apache.org; Uwe Schindler ; 'Dawid
> Weiss' 
> Cc: rory.odonn...@oracle.com; 'Dalibor Topic' ;
> 'Balchandra Vaidya' ; 'Muneer Kolarkunnu'
> 
> Subject: Re: Ready for JDK 9 ?
> 
> Thanks for the update Uwe!
> 
> Rgds,Rory
> 
> 
> On 09/08/2017 17:50, Uwe Schindler wrote:
> > Hi Rory,
> >
> > Thank you for heads-up. I installed JDK 8 update 144 and Java 9 build 181 a
> minute ago. Once the first runs have succeeded, I'll report back.
> >
> > About the current state:
> > - Apache Lucene 6.6 and the coming Apache Lucene 7.0 is fully comliant to
> Java 9 and works with "--illegal-access=deny", so the "kill switch" is not
> needed.
> > - Apache Solr 6.6 and Apache Solr 7.0 work (Java wise), but the startup
> (shell) scripts don't detect the Java version correctly. I think a fix is in 
> the
> make (for Windows and Linux). But if you ignore the startup scripts and do it
> yourself, it works. We applied some fixes for third party libraries that don't
> work correctly (e.g. Hadoop in the version we use).
> >
> > Older Solr and Lucene versions may still have problems, as the Module
> system changed some internal APIs we need for unmapping files, but
> generally they should work, but not everything might be with best
> performance (e.g. it chooses slow NIOFSDirectory instead on memory
> mapping).
> >
> > We currently do not support Lucene with Automodules, so you *have* to
> use Lucene on classpath. The reason is that the JAR files share same
> packages. So you cannot make modules out of Lucene or Solr. We may
> support this in later versions, but that's not an important reason for us. You
> can still combine all of Lucene and Solr and make one huge "Uber Module"
> out of it (and that's what I personally recommend), but that's up to the user.
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >> -Original Message-
> >> From: Rory O'Donnell [mailto:rory.odonn...@oracle.com]
> >> Sent: Tuesday, August 8, 2017 12:04 PM
> >> To: Dawid Weiss ; Uwe Schindler
> >> 
> >> Cc: rory.odonn...@oracle.com; Dalibor Topic
> ;
> >> Balchandra Vaidya ; Muneer
> Kolarkunnu
> >> ; dev@lucene.apache.org
> >> Subject: Ready for JDK 9 ?
> >>
> >>
> >> Hi Uwe & Dawid,
> >>
> >> Thank you very much for all your testing of JDK 9 during its
> >> development! Such contributions have significantly helped shape and
> >> improve JDK 9.
> >>
> >> Now that we have reached the JDK 9 Final Release Candidate phase [1] , I
> >> would like to ask if your project can be considered to be 'ready for JDK
> >> 9', or if there are any remaining show stopper issues which you've
> >> encountered when testing with the JDK 9 release candidate.
> >>
> >> JDK 9  b181 is available at http://jdk.java.net/9/
> >>
> >> If you have a public web page, mailing list post, or even a tweet
> >> announcing you project's readiness for JDK 9, I'd love to add the URL to
> >> the upcoming JDK 9 readiness page on the Quality Outreach wiki.
> >>
> >>
> >> Looking forward to hearing from you,
> >> Rory
> >>
> >> [1] http://openjdk.java.net/projects/jdk9/
> >>
> >> --
> >> Rgds,Rory O'Donnell
> >> Quality Engineering Manager
> >> Oracle EMEA , Dublin, Ireland
> >>
> >>
> >> -
> >> 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
> >
> 
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


--

[jira] [Commented] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8689:
-

I just noticed, the CHANGES.txt is out of sync, before release, somebody should 
update the 7.0 section so its identical everywhere.

> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11238) Solr authorization plugin is not able to pass additional params downstream

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-11238:
-

[~noble.paul], Do you have some time to review this, please?

> Solr authorization plugin is not able to pass additional params downstream
> --
>
> Key: SOLR-11238
> URL: https://issues.apache.org/jira/browse/SOLR-11238
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Hrishikesh Gadre
> Attachments: SOLR-11238.patch
>
>
> Authorization checks in Solr are implemented by invoking configured 
> authorization plugin with AuthorizationContext object. The plugin is expected 
> to return an AuthorizationResponse object which provides the result (which 
> can be OK/FORBIDDEN/PROMPT).
> In some cases (e.g. document level security implemented in Apache Sentry), it 
> is useful for the authorization plugin to add (or override) the request 
> parameters sent by the user (which are represented as SolrParams in 
> [AuthorizationContext| 
> https://github.com/apache/lucene-solr/blob/3cbbecca026eb2a9491fa4a24ecc2c43c26e58bd/solr/core/src/java/org/apache/solr/security/AuthorizationContext.java#L38]).
>  This jira is to introduce an ability to customize the parameters by the 
> authorization plugin.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Uwe Schindler (JIRA)]

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

Uwe Schindler resolved SOLR-8689.
-
Resolution: Fixed

> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8689:
-

I did some minor changes in the config.in files (updates in comments, because 
"Java 8 and lower" is no longer applicable, Solr is minimum Java 8).
I committed to master, 7.x and 7.0.

If somebody wants this also in 6.6.1, please reopen!

> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[ASF subversion and git services (JIRA)]

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

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

Commit ef0f443d4cf002bc24576f1e72556fa06584365f in lucene-solr's branch 
refs/heads/branch_7_0 from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ef0f443 ]

SOLR-8689: Fix bin/solr.cmd so it can run properly on Java 9

# Conflicts:
#   solr/CHANGES.txt


> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8689: Fix bin/solr.cmd so it can run properly on Java 9


> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-8689: Fix bin/solr.cmd so it can run properly on Java 9


> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11238) Solr authorization plugin is not able to pass additional params downstream

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya commented on SOLR-11238:
-

Hi Hrishikesh, apologies for missing this one. I'll have a detailed look by 
this Friday, 25th. Sorry for the delay.

> Solr authorization plugin is not able to pass additional params downstream
> --
>
> Key: SOLR-11238
> URL: https://issues.apache.org/jira/browse/SOLR-11238
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Hrishikesh Gadre
> Attachments: SOLR-11238.patch
>
>
> Authorization checks in Solr are implemented by invoking configured 
> authorization plugin with AuthorizationContext object. The plugin is expected 
> to return an AuthorizationResponse object which provides the result (which 
> can be OK/FORBIDDEN/PROMPT).
> In some cases (e.g. document level security implemented in Apache Sentry), it 
> is useful for the authorization plugin to add (or override) the request 
> parameters sent by the user (which are represented as SolrParams in 
> [AuthorizationContext| 
> https://github.com/apache/lucene-solr/blob/3cbbecca026eb2a9491fa4a24ecc2c43c26e58bd/solr/core/src/java/org/apache/solr/security/AuthorizationContext.java#L38]).
>  This jira is to introduce an ability to customize the parameters by the 
> authorization plugin.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11181) Deploying Maven artifacts (generate-maven-artifacts) pushes the same artifacts multiple times

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11181:


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

SOLR-11181: changes entry


> Deploying Maven artifacts (generate-maven-artifacts) pushes the same 
> artifacts multiple times
> -
>
> Key: SOLR-11181
> URL: https://issues.apache.org/jira/browse/SOLR-11181
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6, master (8.0), 7.1
>Reporter: Lynn Monson
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11181.patch, SOLR-11181.patch
>
>
> When following the instructions in the README.maven file, and watching the 
> wire traffic, the build system issues HTTP PUT operations for the same 
> artifacts multiple times.   For example, issuing this command:
>   ant -Dm2.repository.id=my-repo-id \
>   -Dm2.repository.url=http://example.org/my/repo \
>   generate-maven-artifacts
> from the lucene/ directory will generate redundant puts.  For example:
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.sha1
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.md5
> ...
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> ...
> The maven repo I am using does not allow the second PUT and, hence, the build 
> fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11181) Deploying Maven artifacts (generate-maven-artifacts) pushes the same artifacts multiple times

[Steve Rowe (JIRA)]

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

Steve Rowe resolved SOLR-11181.
---
   Resolution: Fixed
Fix Version/s: 7.1
   master (8.0)

Committed.  Thanks [~lmonson]!

> Deploying Maven artifacts (generate-maven-artifacts) pushes the same 
> artifacts multiple times
> -
>
> Key: SOLR-11181
> URL: https://issues.apache.org/jira/browse/SOLR-11181
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6, master (8.0), 7.1
>Reporter: Lynn Monson
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11181.patch, SOLR-11181.patch
>
>
> When following the instructions in the README.maven file, and watching the 
> wire traffic, the build system issues HTTP PUT operations for the same 
> artifacts multiple times.   For example, issuing this command:
>   ant -Dm2.repository.id=my-repo-id \
>   -Dm2.repository.url=http://example.org/my/repo \
>   generate-maven-artifacts
> from the lucene/ directory will generate redundant puts.  For example:
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.sha1
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.md5
> ...
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> ...
> The maven repo I am using does not allow the second PUT and, hence, the build 
> fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11181) Deploying Maven artifacts (generate-maven-artifacts) pushes the same artifacts multiple times

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11181:


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

SOLR-11181: changes entry


> Deploying Maven artifacts (generate-maven-artifacts) pushes the same 
> artifacts multiple times
> -
>
> Key: SOLR-11181
> URL: https://issues.apache.org/jira/browse/SOLR-11181
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6, master (8.0), 7.1
>Reporter: Lynn Monson
>Assignee: Steve Rowe
>Priority: Minor
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11181.patch, SOLR-11181.patch
>
>
> When following the instructions in the README.maven file, and watching the 
> wire traffic, the build system issues HTTP PUT operations for the same 
> artifacts multiple times.   For example, issuing this command:
>   ant -Dm2.repository.id=my-repo-id \
>   -Dm2.repository.url=http://example.org/my/repo \
>   generate-maven-artifacts
> from the lucene/ directory will generate redundant puts.  For example:
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.sha1
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.md5
> ...
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> ...
> The maven repo I am using does not allow the second PUT and, hence, the build 
> fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11181) Deploying Maven artifacts (generate-maven-artifacts) pushes the same artifacts multiple times

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11181:


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

SOLR-11181: Switch order of maven artifact publishing procedure: deploy first 
instead of locally installing first, to workaround a double repository push of 
*-sources.jar and *-javadoc.jar files.


> Deploying Maven artifacts (generate-maven-artifacts) pushes the same 
> artifacts multiple times
> -
>
> Key: SOLR-11181
> URL: https://issues.apache.org/jira/browse/SOLR-11181
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6, master (8.0), 7.1
>Reporter: Lynn Monson
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-11181.patch, SOLR-11181.patch
>
>
> When following the instructions in the README.maven file, and watching the 
> wire traffic, the build system issues HTTP PUT operations for the same 
> artifacts multiple times.   For example, issuing this command:
>   ant -Dm2.repository.id=my-repo-id \
>   -Dm2.repository.url=http://example.org/my/repo \
>   generate-maven-artifacts
> from the lucene/ directory will generate redundant puts.  For example:
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.sha1
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.md5
> ...
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> ...
> The maven repo I am using does not allow the second PUT and, hence, the build 
> fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11181) Deploying Maven artifacts (generate-maven-artifacts) pushes the same artifacts multiple times

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11181:


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

SOLR-11181: Switch order of maven artifact publishing procedure: deploy first 
instead of locally installing first, to workaround a double repository push of 
*-sources.jar and *-javadoc.jar files.


> Deploying Maven artifacts (generate-maven-artifacts) pushes the same 
> artifacts multiple times
> -
>
> Key: SOLR-11181
> URL: https://issues.apache.org/jira/browse/SOLR-11181
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6, master (8.0), 7.1
>Reporter: Lynn Monson
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-11181.patch, SOLR-11181.patch
>
>
> When following the instructions in the README.maven file, and watching the 
> wire traffic, the build system issues HTTP PUT operations for the same 
> artifacts multiple times.   For example, issuing this command:
>   ant -Dm2.repository.id=my-repo-id \
>   -Dm2.repository.url=http://example.org/my/repo \
>   generate-maven-artifacts
> from the lucene/ directory will generate redundant puts.  For example:
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.sha1
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.md5
> ...
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> ...
> The maven repo I am using does not allow the second PUT and, hence, the build 
> fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11271) merge shard facets with stream expressions

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-11271:
---

We could think about adding the streaming facet support to the FacetStream.

> merge shard facets with stream expressions 
> ---
>
> Key: SOLR-11271
> URL: https://issues.apache.org/jira/browse/SOLR-11271
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: streaming expressions
>Reporter: Mikhail Khludnev
>
> It's necessary for heavy facets.
> It should stream per shard facets and merge facet values with stream 
> expressions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11181) Deploying Maven artifacts (generate-maven-artifacts) pushes the same artifacts multiple times

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-11181:
---

I ran the build locally against {{repository.apache.org/snapshots}} with your 
latest patch, and the {{-sources}} and {{-javadoc}} jars are sent to the repo.  
You can see the result for lucene-core here (artifacts share the infix 
{{-8.0.0-20170821.193346-36.}}): 
[https://repository.apache.org/content/repositories/snapshots/org/apache/lucene/lucene-core/8.0.0-SNAPSHOT/].

bq. The patch reverses the order of the maven install and deploy tasks. This 
prevents a double push to the repository, but will cause the local install to 
happen twice instead.

I think double local install is fine (better than double remote push anyway).  

I'll commit your patch to master and branch_7x.

> Deploying Maven artifacts (generate-maven-artifacts) pushes the same 
> artifacts multiple times
> -
>
> Key: SOLR-11181
> URL: https://issues.apache.org/jira/browse/SOLR-11181
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6, master (8.0), 7.1
>Reporter: Lynn Monson
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-11181.patch, SOLR-11181.patch
>
>
> When following the instructions in the README.maven file, and watching the 
> wire traffic, the build system issues HTTP PUT operations for the same 
> artifacts multiple times.   For example, issuing this command:
>   ant -Dm2.repository.id=my-repo-id \
>   -Dm2.repository.url=http://example.org/my/repo \
>   generate-maven-artifacts
> from the lucene/ directory will generate redundant puts.  For example:
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.sha1
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.md5
> ...
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> ...
> The maven repo I am using does not allow the second PUT and, hence, the build 
> fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11238) Solr authorization plugin is not able to pass additional params downstream

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-11238:
-

[~ichattopadhyaya] ping :) Any thoughts on the proposal?

> Solr authorization plugin is not able to pass additional params downstream
> --
>
> Key: SOLR-11238
> URL: https://issues.apache.org/jira/browse/SOLR-11238
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.6
>Reporter: Hrishikesh Gadre
> Attachments: SOLR-11238.patch
>
>
> Authorization checks in Solr are implemented by invoking configured 
> authorization plugin with AuthorizationContext object. The plugin is expected 
> to return an AuthorizationResponse object which provides the result (which 
> can be OK/FORBIDDEN/PROMPT).
> In some cases (e.g. document level security implemented in Apache Sentry), it 
> is useful for the authorization plugin to add (or override) the request 
> parameters sent by the user (which are represented as SolrParams in 
> [AuthorizationContext| 
> https://github.com/apache/lucene-solr/blob/3cbbecca026eb2a9491fa4a24ecc2c43c26e58bd/solr/core/src/java/org/apache/solr/security/AuthorizationContext.java#L38]).
>  This jira is to introduce an ability to customize the parameters by the 
> authorization plugin.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_144) - Build # 20355 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20355/
Java: 32bit/jdk1.8.0_144 -server -XX:+UseParallelGC

1 tests failed.
FAILED:  org.apache.solr.cloud.HttpPartitionTest.test

Error Message:
Doc with id=1 not found in http://127.0.0.1:36769/m_w/collMinRf_1x3 due to: 
Path not found: /id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=1 not found in 
http://127.0.0.1:36769/m_w/collMinRf_1x3 due to: Path not found: /id; 
rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([D31F5E8D9AE0F05:8565CA32775262FD]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:603)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:558)
at 
org.apache.solr.cloud.HttpPartitionTest.testMinRf(HttpPartitionTest.java:249)
at 
org.apache.solr.cloud.HttpPartitionTest.test(HttpPartitionTest.java:127)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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(T

[JENKINS-EA] Lucene-Solr-7.x-Windows (32bit/jdk-9-ea+181) - Build # 129 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Windows/129/
Java: 32bit/jdk-9-ea+181 -client -XX:+UseParallelGC --illegal-access=deny

1 tests failed.
FAILED:  org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader

Error Message:
Doc with id=1 not found in 
http://127.0.0.1:52367/ny_o/h/forceleader_test_collection due to: Path not 
found: /id; rsp={doc=null}

Stack Trace:
java.lang.AssertionError: Doc with id=1 not found in 
http://127.0.0.1:52367/ny_o/h/forceleader_test_collection due to: Path not 
found: /id; rsp={doc=null}
at 
__randomizedtesting.SeedInfo.seed([9F19A80172BC1B1B:798E9CC14B3EE27A]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocExists(HttpPartitionTest.java:603)
at 
org.apache.solr.cloud.HttpPartitionTest.assertDocsExistInAllReplicas(HttpPartitionTest.java:556)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:142)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:6

[jira] [Created] (SOLR-11271) merge shard facets with stream expressions

[Mikhail Khludnev (JIRA)]

Mikhail Khludnev created SOLR-11271:
---

 Summary: merge shard facets with stream expressions 
 Key: SOLR-11271
 URL: https://issues.apache.org/jira/browse/SOLR-11271
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
  Components: streaming expressions
Reporter: Mikhail Khludnev


It's necessary for heavy facets.
It should stream per shard facets and merge facet values with stream 
expressions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-NightlyTests-6.6 - Build # 25 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.6/25/

7 tests failed.
FAILED:  org.apache.lucene.spatial3d.TestGeo3DPoint.testRandomBig

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([DF9907CEF3667FCC]:0)


FAILED:  org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([87EA478ACF01E0A7:7EA7D425F374AD2D]: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.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:280)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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(TestRuleIgnoreAfterMaxFailur

[jira] [Commented] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8689:
-

OK, I will commit this a bit later.

Maybe somebody has time to test it in addition to myself.

> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8689:
-

Latest build (build 181) of Java 9 - the official RC - also works:

{noformat}
C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>solr start 
-verbose
Using Solr root directory: C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr
Using Java: C:\Program Files\Java\jdk-9\bin\java
java version "9"
Java(TM) SE Runtime Environment (build 9+181)
Java HotSpot(TM) 64-Bit Server VM (build 9+181, mixed mode)

Archiving 1 old GC log files to C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\server\logs\archived
Archiving 1 console log files to C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\server\logs\archived
Rotating solr logs, keeping a max of 9 generations
Starting Solr using the following settings:
JAVA= C:\Program Files\Java\jdk-9\bin\java
SOLR_SERVER_DIR = C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\server
SOLR_HOME   = C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\server\solr
SOLR_HOST   =
SOLR_PORT   = 8983
STOP_PORT   = 7983
SOLR_JAVA_MEM   = -Xms512m -Xmx512m
GC_TUNE = -XX:NewRatio=3-XX:SurvivorRatio=4
-XX:TargetSurvivorRatio=90-XX:MaxTenuringThreshold=8
-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:ConcGCThreads=4 
-XX:ParallelGCThreads=4-XX:+CMSScavengeBeforeRemark
-XX:PretenureSizeThreshold=64m-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=50-XX:CMSMaxAbortablePrecleanTime=6000   
 -XX:+CMSParallelRemarkEnabled-XX:+ParallelRefProcEnabled
-XX:-OmitStackTraceInFastThrow
GC_LOG_OPTS = "-Xlog:gc*:file=\"C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\server\logs\solr_gc.log\":time,uptime:filecount=9,filesize=2"
SOLR_TIMEZONE   = UTC
SOLR_OPTS   = -Xss256k

Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
Java HotSpot(TM) 64-Bit Server VM warning: Option UseParNewGC was deprecated in 
version 9.0 and will likely be removed in a future release.
Waiting up to 30 to see Solr running on port 8983
Started Solr server on port 8983. Happy searching!

C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>solr stop -all
Stopping Solr process 9572 running on port 8983

Gewartet wird 0 Sekunden. Weiter mit beliebiger Taste...

C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>
{noformat}

> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8689:


bq. Hoss Man: Any complaints or do you trust me?

I trust you ... if you think it's ready, i believe you -- heavy commit and 
let's move on. 
If you don't think it's ready then i say it shouldn't hold up the 7.0 release. 

> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8689:
-

I will test with latest Java 9 in a minute, but the recent builds did not 
change anymore.

> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-8689 at 8/21/17 7:24 PM:
--

Patch with [~hossman]'s suggestions. If somebody sets GC_LOG_OPTS on Java 9 it 
bails out. I also updated documentation in the solr.in.cmd file.

I tested with:
- Java 8u144: Works as usual, GC_LOG_OPTS is respected if explicitely set
- Java 9b178: Works now by default; if you comment out the GC_LOG_OPTS it fails 
early. BTW, in the UNIX scripts it would also fail if somebody updates Java 8 
to Java 9, because the logging options are incompatible. So we are consistent 
for users that have GC_LOG_OPTS configured and migrate.
- IBM J9 (Java 8): Works as before
- Java 7u90: Fails early
- Java 6: Fails early

I think we should really commit this and maybe later improve this. It looks 
like I am the only active Solr committer that knows windows shell scripts a 
bit. IMHO, maybe we should switch to PowerShell, really! PowerShell is now 
installed on all supported Windows VMs, Windows 7 is out of service.

[~hossman]: Any complaints or do you trust me? The current state is much better 
than before and the added code is trivial. IMHO, we should really not release 
that without basic Java 9 support and some migration path. Java comes out on 
Sept 21 (for sure, I already booked my tickets to the party in Munich).


was (Author: thetaphi):
Patch with [~hossman]'s suggestions. If somebody sets GC_LOG_OPTS on Java 9 it 
bails out. I also updated documentation in the solr.in.cmd file.

I tested with:
- Java 8u144: Works as usual, GC_LOG_OPTS is respected if explicitely set
- Java 9b182: Works now by default; if you comment out the GC_LOG_OPTS it fails 
early. BTW, in the UNIX scripts it would also fail if somebody updates Java 8 
to Java 9, because the logging options are incompatible. So we are consistent 
for users that have GC_LOG_OPTS configured and migrate.
- IBM J9 (Java 8): Works as before
- Java 7u90: Fails early
- Java 6: Fails early

I think we should really commit this and maybe later improve this. It looks 
like I am the only active Solr committer that knows windows shell scripts a 
bit. IMHO, maybe we should switch to PowerShell, really! PowerShell is now 
installed on all supported Windows VMs, Windows 7 is out of service.

[~hossman]: Any complaints or do you trust me? The current state is much better 
than before and the added code is trivial. IMHO, we should really not release 
that without basic Java 9 support and some migration path. Java comes out on 
Sept 21 (for sure, I already booked my tickets to the party in Munich).

> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8689:
-

FYI, here is the Java 9 output:
{noformat}
C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin>solr start -e 
techproducts -verbose
Using Solr root directory: C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr
Using Java: C:\Program Files\Java\jdk-9\bin\java
java version "9"
Java(TM) SE Runtime Environment (build 9+178)
Java HotSpot(TM) 64-Bit Server VM (build 9+178, mixed mode)

Running with
serverDir=C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\server,
exampleDir=C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\example
script=C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin\solr.cmd
Creating Solr home directory C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\example\techproducts\solr

Starting up Solr on port 8983 using command:
"C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\solr\bin\solr.cmd" start 
-p 8983 -s "C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\example\techproducts\solr"

Using Solr root directory: C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr
Using Java: C:\Program Files\Java\jdk-9\bin\java
java version "9"
Java(TM) SE Runtime Environment (build 9+178)
Java HotSpot(TM) 64-Bit Server VM (build 9+178, mixed mode)

Starting Solr using the following settings:
JAVA= C:\Program Files\Java\jdk-9\bin\java
SOLR_SERVER_DIR = C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\server
SOLR_HOME   = C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\example\techproducts\solr
SOLR_HOST   =
SOLR_PORT   = 8983
STOP_PORT   = 7983
SOLR_JAVA_MEM   = -Xms512m -Xmx512m
GC_TUNE = -XX:NewRatio=3-XX:SurvivorRatio=4
-XX:TargetSurvivorRatio=90-XX:MaxTenuringThreshold=8
-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:ConcGCThreads=4 
-XX:ParallelGCThreads=4-XX:+CMSScavengeBeforeRemark
-XX:PretenureSizeThreshold=64m-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=50-XX:CMSMaxAbortablePrecleanTime=6000   
 -XX:+CMSParallelRemarkEnabled-XX:+ParallelRefProcEnabled
-XX:-OmitStackTraceInFastThrow
GC_LOG_OPTS = "-Xlog:gc*:file=\"C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\example\techproducts\solr\..\logs\solr_gc.log\":time,uptime:filecount=9,filesize=2"
SOLR_TIMEZONE   = UTC
SOLR_OPTS   = -Xss256k

Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was 
deprecated in version 9.0 and will likely be removed in a future release.
Java HotSpot(TM) 64-Bit Server VM warning: Option UseParNewGC was deprecated in 
version 9.0 and will likely be removed in a future release.

Checking status of Solr at http://localhost:8983/solr ...
Waiting up to 30 to see Solr running on port 8983
Started Solr server on port 8983. Happy searching!

Solr is running on 8983 in standalone mode with status:
{
  "solr_home":"C:\\Users\\Uwe 
Schindler\\Projects\\lucene\\trunk-lusolr1\\solr\\example\\techproducts\\solr",
  "version":"8.0.0-SNAPSHOT a7f2c30b405cb5d131826cf6c9ea5fe8a7cc3d71 - Uwe 
Schindler - 2017-08-20 19:20:02",
  "startTime":"2017-08-21T19:21:56.240Z",
  "uptime":"0 days, 0 hours, 0 minutes, 3 seconds",
  "memory":"58.9 MB (%12) of 490.7 MB",
  "baseUrl":"http://localhost:8983/solr"}

Copying configuration to new core instance directory:
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\example\techproducts\solr\techproducts

Creating new core 'techproducts' using command:
http://localhost:8983/solr/admin/cores?action=CREATE&name=techproducts&instanceDir=techproducts

{
  "responseHeader":{
"status":0,
"QTime":2529},
  "core":"techproducts"}


Indexing tech product example docs from C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr1\solr\example\exampledocs
SimplePostTool version 5.0.0
Posting files to [base] url http://localhost:8983/solr/techproducts/update 
using content-type application/xml...
POSTing file gb18030-example.xml to [base]
POSTing file hd.xml to [base]
POSTing file ipod_other.xml to [base]
POSTing file ipod_video.xml to [base]
POSTing file manufacturers.xml to [base]
POSTing file mem.xml to [base]
POSTing file money.xml to [base]
POSTing file monitor.xml to [base]
POSTing file monitor2.xml to [base]
POSTing file mp500.xml to [base]
POSTing file sd500.xml to [base]
POSTing file solr.xml to [base]
POSTing file utf8-example.xml to [base]
POSTing file vidcard.xml to [base]
14 files indexed.
COMMITting Solr index changes to 
http://localhost:8983/solr/techproducts/update...
Time spent: 0:00:00.689

Solr techproducts example launched successfully. Direct your Web browser to 
http://localhost:8983/solr to visit the Solr Admin UI

C:\Users\Uwe Schindler\Projects\lu

[jira] [Commented] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-8689:
-

And BTW, it also works with whitespace in Solr's installation directory. :-)

> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-8689 at 8/21/17 7:20 PM:
--

Patch with [~hossman]'s suggestions. If somebody sets GC_LOG_OPTS on Java 9 it 
bails out. I also updated documentation in the solr.in.cmd file.

I tested with:
- Java 8u144: Works as usual, GC_LOG_OPTS is respected if explicitely set
- Java 9b182: Works now by default; if you comment out the GC_LOG_OPTS it fails 
early. BTW, in the UNIX scripts it would also fail if somebody updates Java 8 
to Java 9, because the logging options are incompatible. So we are consistent 
for users that have GC_LOG_OPTS configured and migrate.
- IBM J9 (Java 8): Works as before
- Java 7u90: Fails early
- Java 6: Fails early

I think we should really commit this and maybe later improve this. It looks 
like I am the only active Solr committer that knows windows shell scripts a 
bit. IMHO, maybe we should switch to PowerShell, really! PowerShell is now 
installed on all supported Windows VMs, Windows 7 is out of service.

[~hossman]: Any complaints or do you trust me? The current state is much better 
than before and the added code is trivial. IMHO, we should really not release 
that without basic Java 9 support and some migration path. Java comes out on 
Sept 21 (for sure, I already booked my tickets to the party in Munich).


was (Author: thetaphi):
Patch with [~hossman]'s suggestions. If somebody sets GC_LOG_OPTS on Java 9 it 
bails out. I also updated documentation in the solr.in.cmd file.

I tested with:
- Java 8u144: Works as usual, GC_LOG_OPT is respected if explicitely set
- Java 9b182: Works now by default; if you comment out the GC_LOG_OPTS it fails 
early. BTW, in the UNIX scripts it would also fail if somebody updates Java 8 
to Java 9, because the logging options are incompatible. So we are consistent 
for users that have GC_LOG_OPTS configured and migrate.
- IBM J9 (Java 8): Works as before
- Java 7u90: Fails early
- Java 6: Fails early

I think we should really commit this and maybe later improve this. It looks 
like I am the only active Solr committer that knows windows shell scripts a 
bit. IMHO, maybe we should switch to PowerShell, really! PowerShell is now 
installed on all supported Windows VMs, Windows 7 is out of service.

[~hossman]: Any complaints or do you trust me? The current state is much better 
than before and the added code is trivial. IMHO, we should really not release 
that without basic Java 9 support and some migration path. Java comes out on 
Sept 21 (for sure, I already booked my tickets to the party in Munich).

> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11181) Deploying Maven artifacts (generate-maven-artifacts) pushes the same artifacts multiple times

[Lynn Monson (JIRA)]

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

Lynn Monson edited comment on SOLR-11181 at 8/21/17 7:18 PM:
-

[~steve_rowe]
I attached the alternate version of a patch for the problem. 

The patch reverses the order of the maven install and deploy tasks.  This 
prevents a double push to the repository, but will cause the local install to 
happen twice instead.


was (Author: lmonson):
Alternate version of a patch

> Deploying Maven artifacts (generate-maven-artifacts) pushes the same 
> artifacts multiple times
> -
>
> Key: SOLR-11181
> URL: https://issues.apache.org/jira/browse/SOLR-11181
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6, master (8.0), 7.1
>Reporter: Lynn Monson
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-11181.patch, SOLR-11181.patch
>
>
> When following the instructions in the README.maven file, and watching the 
> wire traffic, the build system issues HTTP PUT operations for the same 
> artifacts multiple times.   For example, issuing this command:
>   ant -Dm2.repository.id=my-repo-id \
>   -Dm2.repository.url=http://example.org/my/repo \
>   generate-maven-artifacts
> from the lucene/ directory will generate redundant puts.  For example:
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.sha1
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.md5
> ...
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> ...
> The maven repo I am using does not allow the second PUT and, hence, the build 
> fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-8689 at 8/21/17 7:18 PM:
--

Patch with [~hossman]'s suggestions. If somebody sets GC_LOG_OPTS on Java 9 it 
bails out. I also updated documentation in the solr.in.cmd file.

I tested with:
- Java 8u144: Works as usual, GC_LOG_OPT is respected if explicitely set
- Java 9b182: Works now by default; if you comment out the GC_LOG_OPTS it fails 
early. BTW, in the UNIX scripts it would also fail if somebody updates Java 8 
to Java 9, because the logging options are incompatible. So we are consistent 
for users that have GC_LOG_OPTS configured and migrate.
- IBM J9 (Java 8): Works as before
- Java 7u90: Fails early
- Java 6: Fails early

I think we should really commit this and maybe later improve this. It looks 
like I am the only active Solr committer that knows windows shell scripts a 
bit. IMHO, maybe we should switch to PowerShell, really! PowerShell is now 
installed on all supported Windows VMs, Windows 7 is out of service.

[~hossman]: Any complaints or do you trust me? The current state is much better 
than before and the added code is trivial. IMHO, we should really not release 
that without basic Java 9 support and some migration path. Java comes out on 
Sept 21 (for sure, I already booked my tickets to the party in Munich).


was (Author: thetaphi):
Patch with [~hossman]'s suggestions. If somebody sets GC_LOG_OPTS on Java 9 it 
bails out. I also updated documentation in the solr.in.cmd file.

I tested with:
- Java 8u144: Works as usual, GC_LOG_OPT is respected if explicitely set
- Java 9b182: Works now by default; if you comment out the GC_LOG_OPTS it fails 
early. BTW, in the UNIX scripts it would also fail if somebody updates Java 8 
to Java 9, becaus ethe logging options are incompatible So we are consistent 
for users that have GC_LOG_OPTS configured.
- IBM J9 (Java 8): Works as before
- Java 7u90: Fails early
- Java 6: Fails early

I think we should really commit this and maybe later improve this. It looks 
like I am the only person lkeft that knows windows shell scripts a bit. IMHO, 
maybe we should switch to PowerShell, really! PowerShell is now installed on 
all supported Windows VMs, Windows 7 is out of service.

[~hossman]: Any complaints or do you trust me? The current state is much better 
than before and the added code is trivial. IMHO, we should really not release 
that without basic Java 9 support and some migration path. Java comes out on 
Sept 21 (for sure, I already booked my tickets to the party in Munich).

> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11181) Deploying Maven artifacts (generate-maven-artifacts) pushes the same artifacts multiple times

[Lynn Monson (JIRA)]

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

Lynn Monson updated SOLR-11181:
---
Attachment: SOLR-11181.patch

Alternate version of a patch

> Deploying Maven artifacts (generate-maven-artifacts) pushes the same 
> artifacts multiple times
> -
>
> Key: SOLR-11181
> URL: https://issues.apache.org/jira/browse/SOLR-11181
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6, master (8.0), 7.1
>Reporter: Lynn Monson
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-11181.patch, SOLR-11181.patch
>
>
> When following the instructions in the README.maven file, and watching the 
> wire traffic, the build system issues HTTP PUT operations for the same 
> artifacts multiple times.   For example, issuing this command:
>   ant -Dm2.repository.id=my-repo-id \
>   -Dm2.repository.url=http://example.org/my/repo \
>   generate-maven-artifacts
> from the lucene/ directory will generate redundant puts.  For example:
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.sha1
>  
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar.md5
> ...
> PUT 
> //org/apache/lucene/lucene-core//lucene-core-4.10.4-fs.31-sources.jar
>  
> ...
> The maven repo I am using does not allow the second PUT and, hence, the build 
> fails.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-8689:

Attachment: SOLR-8689.patch

Patch with [~hossman]'s suggestions. If somebody sets GC_LOG_OPTS on Java 9 it 
bails out. I also updated documentation in the solr.in.cmd file.

I tested with:
- Java 8u144: Works as usual, GC_LOG_OPT is respected if explicitely set
- Java 9b182: Works now by default; if you comment out the GC_LOG_OPTS it fails 
early. BTW, in the UNIX scripts it would also fail if somebody updates Java 8 
to Java 9, becaus ethe logging options are incompatible So we are consistent 
for users that have GC_LOG_OPTS configured.
- IBM J9 (Java 8): Works as before
- Java 7u90: Fails early
- Java 6: Fails early

I think we should really commit this and maybe later improve this. It looks 
like I am the only person lkeft that knows windows shell scripts a bit. IMHO, 
maybe we should switch to PowerShell, really! PowerShell is now installed on 
all supported Windows VMs, Windows 7 is out of service.

[~hossman]: Any complaints or do you trust me? The current state is much better 
than before and the added code is trivial. IMHO, we should really not release 
that without basic Java 9 support and some migration path. Java comes out on 
Sept 21 (for sure, I already booked my tickets to the party in Munich).

> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch, SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.update.AutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([9A2C05662E3D85FF:20FE6A1EAD136BEA]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:879)
at 
org.apache.solr.update.AutoCommitTest.testCommitWithin(AutoCommitTest.java:353)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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=id:529&qt=&start=0&rows=20&version=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:872)
... 40 more




Build Log:
[...truncated 12160 lines...]
   [junit4] Suite: org.apache.solr.updat

[jira] [Resolved] (LUCENE-7938) Bounds of bounding box are not equal to bounding box

[Karl Wright (JIRA)]

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

Karl Wright resolved LUCENE-7938.
-
Resolution: Not A Problem

> Bounds of bounding box are not equal to bounding box
> 
>
> Key: LUCENE-7938
> URL: https://issues.apache.org/jira/browse/LUCENE-7938
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Minor
> Attachments: LUCENE-7938-fix.patch, LUCENE-7938-test.patch
>
>
> Hi,
> It seems if I get the bounds of a BBox and I create a new bounding box, 
> sometimes both bounding box are not equal. It is a problem with precision.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7938) Bounds of bounding box are not equal to bounding box

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7938:
-

[~ivera], this is by design.  Bounding boxes are supposed to *contain* the 
objects within; there are indeed some rare cases where it is difficult to 
compute the bounding box and we return a larger box as a shortcut.

Furthermore, you should not modify the "equals" method to allow a match that is 
not a precise object match; that's a violation of the contract of "equals".

I'm going to close this as "not a bug".



> Bounds of bounding box are not equal to bounding box
> 
>
> Key: LUCENE-7938
> URL: https://issues.apache.org/jira/browse/LUCENE-7938
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Minor
> Attachments: LUCENE-7938-fix.patch, LUCENE-7938-test.patch
>
>
> Hi,
> It seems if I get the bounds of a BBox and I create a new bounding box, 
> sometimes both bounding box are not equal. It is a problem with precision.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Assigned] (LUCENE-7938) Bounds of bounding box are not equal to bounding box

[Karl Wright (JIRA)]

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

Karl Wright reassigned LUCENE-7938:
---

Assignee: Karl Wright

> Bounds of bounding box are not equal to bounding box
> 
>
> Key: LUCENE-7938
> URL: https://issues.apache.org/jira/browse/LUCENE-7938
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Minor
> Attachments: LUCENE-7938-fix.patch, LUCENE-7938-test.patch
>
>
> Hi,
> It seems if I get the bounds of a BBox and I create a new bounding box, 
> sometimes both bounding box are not equal. It is a problem with precision.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7936) Extend Geoshape interfaces so objects can be copied/serialized

[Karl Wright (JIRA)]

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

Karl Wright commented on LUCENE-7936:
-

{quote}
This class is used to generate docValues which at the same time is used by the 
SerializedDVStrategy to check the relationship between indexed and query 
shapes. If we achieve this, we can pass through the interfaces the Geo3dShapes 
and use it with Lucene (I have already done it with very promising results).
{quote}

[~ivera], the conversion to docvalues actually should live in the package 
org.apache.lucene.spatial3d.  There are classes in there already that implement 
doc values fields, distance comparators, and DV logic.  If these are 
insufficient for what you're trying to do, please let me know why.

As for the polygon pixelation, there are two considerations.  First, this 
statement is not correct:

{quote}
The library requires polygons to be convex therefore for concave polygons I 
need to break them into the equivalent convex ones, which is what the 
GeoPolygonFactory actually does.
{quote}

GeoPolygonFactory generates concave polygons in the case where that's the best 
representation.  It either generates ONE concave polygon or potentially 
MULTIPLE convex polygons.  So perhaps you are going to need to do something 
different anyway?

In fact, I'm not certain that it's always possible to tile a concave polygon 
with convex polygons without adding vertices by interpolation.



> Extend Geoshape interfaces so objects can be copied/serialized
> --
>
> Key: LUCENE-7936
> URL: https://issues.apache.org/jira/browse/LUCENE-7936
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7936.patch
>
>
> Hi [~david.wri...@bksv.com],
> I would like to propose to extends the GeoShape interfaces to be able to 
> copy/serialized the objects. The current status and  propose change is as 
> following:
> GeoPoint: It can be serialized by using x, y, z
> GeoCircle:  It can be serialized by using getCenter() and getRadius() and 
> getPlanetModel()
> GeoCompositeShape: It can be serialized by accesing shapes using size() and 
> GetShape(int index)
> GeoPath: add methods to the interface getPoints() and getCutoffAngle()
> GeoPolygon: This is the most complicated one as we have different types:
>1.- GeoCompositePolygon is just a composite
>2.- GeoConcavePolygon and GeoConvexPolygon: Create a new interface for 
> those polygons which exposes the points, holes, internaledges and 
> concavity/convexity
>3.- GeoComplexPolygons: Do nothing, they are too complex to be serialize??
> I am intersested in accesing the discreatization of the polygons into convex 
> and concave ones for other reasons as well. I think this should be expose as 
> they end result can be used for other use cases.
> Cheers,
> I.
>   



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7939) Speed up MinShouldMatchSumScorer in conjunctions

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-7939:
-
Attachment: LUCENE-7939.patch

Here is a proposal. I ran a benchmark with the following tasks (taken from 
LUCENE-4571):

{noformat}
HighMinShouldMatch4: ref http from name title +minShouldMatch=4
HighMinShouldMatch3: ref http from name title +minShouldMatch=3
HighMinShouldMatch2: ref http from name title +minShouldMatch=2
HighMinShouldMatch0: ref http from name title
Low1MinShouldMatch4: ref http from name dublin +minShouldMatch=4
Low1MinShouldMatch3: ref http from name dublin +minShouldMatch=3
Low1MinShouldMatch2: ref http from name dublin +minShouldMatch=2
Low1MinShouldMatch0: ref http from name dublin
Low2MinShouldMatch4: ref http from wings dublin +minShouldMatch=4
Low2MinShouldMatch3: ref http from wings dublin +minShouldMatch=3
Low2MinShouldMatch2: ref http from wings dublin +minShouldMatch=2
Low2MinShouldMatch0: ref http from wings dublin
Low3MinShouldMatch4: ref http struck wings dublin +minShouldMatch=4
Low3MinShouldMatch3: ref http struck wings dublin +minShouldMatch=3
Low3MinShouldMatch2: ref http struck wings dublin +minShouldMatch=2
Low3MinShouldMatch0: ref http struck wings dublin
Low4MinShouldMatch4: ref restored struck wings dublin +minShouldMatch=4
Low4MinShouldMatch3: ref restored struck wings dublin +minShouldMatch=3
Low4MinShouldMatch2: ref restored struck wings dublin +minShouldMatch=2
Low4MinShouldMatch0: ref restored struck wings dublin
ConjHighMinShouldMatch4: +only ref http from name title +minShouldMatch=4
ConjHighMinShouldMatch3: +only ref http from name title +minShouldMatch=3
ConjHighMinShouldMatch2: +only ref http from name title +minShouldMatch=2
ConjHighMinShouldMatch0: +only ref http from name title
ConjLow1MinShouldMatch4: +only ref http from name dublin +minShouldMatch=4
ConjLow1MinShouldMatch3: +only ref http from name dublin +minShouldMatch=3
ConjLow1MinShouldMatch2: +only ref http from name dublin +minShouldMatch=2
ConjLow1MinShouldMatch0: +only ref http from name dublin
ConjLow2MinShouldMatch4: +only ref http from wings dublin +minShouldMatch=4
ConjLow2MinShouldMatch3: +only ref http from wings dublin +minShouldMatch=3
ConjLow2MinShouldMatch2: +only ref http from wings dublin +minShouldMatch=2
ConjLow2MinShouldMatch0: +only ref http from wings dublin
ConjLow3MinShouldMatch4: +only ref http struck wings dublin +minShouldMatch=4
ConjLow3MinShouldMatch3: +only ref http struck wings dublin +minShouldMatch=3
ConjLow3MinShouldMatch2: +only ref http struck wings dublin +minShouldMatch=2
ConjLow3MinShouldMatch0: +only ref http struck wings dublin
ConjLow4MinShouldMatch4: +only ref restored struck wings dublin 
+minShouldMatch=4
ConjLow4MinShouldMatch3: +only ref restored struck wings dublin 
+minShouldMatch=3
ConjLow4MinShouldMatch2: +only ref restored struck wings dublin 
+minShouldMatch=2
ConjLow4MinShouldMatch0: +only ref restored struck wings dublin
{noformat}

As you can see, there are two versions for each task, the original one and one 
that starts with {Conj} because the query is intersected with {{+only}}.

luceneutil gave me the following numbers on wikimedium10m:

{noformat}
TaskQPS baseline  StdDev   QPS patch  StdDev
Pct diff
 ConjLow4MinShouldMatch3  230.51  (2.8%)  223.38  (2.0%)   
-3.1% (  -7% -1%)
 Low2MinShouldMatch35.04  (2.6%)4.92  (2.0%)   
-2.3% (  -6% -2%)
 Low1MinShouldMatch33.80  (3.3%)3.76  (4.8%)   
-1.2% (  -8% -7%)
 HighMinShouldMatch33.27  (3.6%)3.23  (4.9%)   
-1.2% (  -9% -7%)
 Low1MinShouldMatch03.72  (4.7%)3.68  (6.0%)   
-1.1% ( -11% -   10%)
 HighMinShouldMatch03.24  (4.5%)3.21  (5.7%)   
-1.0% ( -10% -9%)
 Low2MinShouldMatch24.44  (3.8%)4.39  (4.9%)   
-1.0% (  -9% -7%)
 Low1MinShouldMatch23.63  (3.9%)3.60  (4.9%)   
-1.0% (  -9% -8%)
 Low2MinShouldMatch04.55  (5.1%)4.51  (5.9%)   
-0.9% ( -11% -   10%)
 HighMinShouldMatch23.17  (4.1%)3.14  (5.0%)   
-0.9% (  -9% -8%)
 Low1MinShouldMatch45.11  (2.2%)5.06  (2.1%)   
-0.8% (  -5% -3%)
 Low3MinShouldMatch26.23  (3.4%)6.18  (4.3%)   
-0.8% (  -8% -7%)
 HighMinShouldMatch43.42  (3.7%)3.40  (5.0%)   
-0.6% (  -8% -8%)
 Low4MinShouldMatch0   10.67  (6.1%)   10.61  (6.9%)   
-0.6% ( -12% -   13%)
 Low4MinShouldMatch2   42.49  (1.5%)   42.25  (1.4%)   
-0.6% (  -3% -2%)
 Low3MinShouldMatch06.32  (5.2%)6.29  (6.4%)   
-0.5% ( -11% -   11%)
 Low3MinShouldMatch3   38.64  (1.9%)   38.4

[JENKINS-EA] Lucene-Solr-6.6-Linux (64bit/jdk-9-ea+181) - Build # 76 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.6-Linux/76/
Java: 64bit/jdk-9-ea+181 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 
--illegal-access=deny

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestJmxIntegration

Error Message:
No JMX server found by monitor map

Stack Trace:
java.lang.AssertionError: No JMX server found by monitor map
at __randomizedtesting.SeedInfo.seed([30D29E49C16D8F36]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.core.TestJmxIntegration.beforeClass(TestJmxIntegration.java:75)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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)


FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Something is broken in the assert for no shards using the same indexDir - 
probably something was changed in the attributes published in the MBean of 
SolrCore : {}

Stack Trace:
java.lang.AssertionError: Something is broken in the assert for no shards using 
the same indexDir - probably something was changed in the attributes published 
in the MBean of SolrCore : {}
at 
__randomizedtesting.SeedInfo.seed([30D29E49C16D8F36:78A7EAFDC75EA0A3]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.checkNoTwoShardsUseTheSameIndexDir(CollectionsAPIDistributedZkTest.java:646)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:524)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 

[jira] [Created] (LUCENE-7939) Speed up MinShouldMatchSumScorer in conjunctions

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-7939:


 Summary: Speed up MinShouldMatchSumScorer in conjunctions
 Key: LUCENE-7939
 URL: https://issues.apache.org/jira/browse/LUCENE-7939
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor
 Fix For: master (8.0), 7.1


MinShouldMatchSumScorer has good iteration capabilities, but if it is not used 
as a lead for the iteration then the advance() call might make a lot of efforts 
in order to find the next match while we should instead let the lead iterator 
of the conjunction skip over non-matching documents. In this issue I'd like to 
explore changing MinShouldMatchSumScorer by giving it a two-phase iterator and 
making advance() return a candidate for the next match that is less good but 
much cheaper to compute.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Closed] (SOLR-8994) EmbeddedSolrServer does not provide the httpMethod to the handler

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev closed SOLR-8994.
--
Resolution: Duplicate

> EmbeddedSolrServer does not provide the httpMethod to the handler
> -
>
> Key: SOLR-8994
> URL: https://issues.apache.org/jira/browse/SOLR-8994
> Project: Solr
>  Issue Type: Bug
>Reporter: Nicolas Gavalda
>  Labels: embedded
> Attachments: SOLR-8994-EmbeddedSolrServer-httpMethod.patch
>
>
> The modification URIs of the schema API don't work when using an 
> EmbeddedSolrServer: the SchemaHandler verifies that modification requests are 
> POST, and the EmbeddedSolrServer doesn't transmit this information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

4 tests failed.
FAILED:  org.apache.solr.cloud.AliasIntegrationTest.testErrorChecks

Error Message:
Error from server at http://127.0.0.1:51427/solr: deletealias the collection 
time out:180s

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:51427/solr: deletealias the collection time 
out:180s
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:612)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:447)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:388)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1383)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1134)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1073)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:177)
at 
org.apache.solr.cloud.AliasIntegrationTest.testErrorChecks(AliasIntegrationTest.java:201)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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.Tes

Re: [JENKINS] Lucene-Solr-SmokeRelease-6.6 - Build # 22 - Still Failing

[Steve Rowe]

> On Aug 20, 2017, at 9:00 AM, Apache Jenkins Server 
>  wrote:
> 
> Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-6.6/22/
[…]
>   [smoker] RuntimeError: 
> file:///home/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-6.6/lucene/build/smokeTestRelease/dist/solr/changes/Changes.html
>  has duplicate section "Release 6.6.1 " under release "6.6.1"
> 
> BUILD FAILED

I removed the duplicate “6.6.1” header from solr/CHANGES.txt on branch_6_6.

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

[jira] [Commented] (SOLR-8689) bin/solr.cmd does not start with recent Verona builds of Java 9 because of version parsing issue

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-8689:


My thoughts in no particular order -- w/o having looked at /understood the 
patch (i'm not familar with most windows batch file syntax)...

bq. BTW, I set this as blocker, as we cannot release Solr 7 at the same time 
like Java 9 and it won't work.

I don't think "solr + windows + jdk9" is an important enough use case to 
warrant holding up lucene/solr 7.  We can release note that solr.cmd startup 
script doesn't work in that permutation and focus on fixing later (if anyone is 
really hardcore about using solr + windows + jdk9 they can probably work around 
using the solr.cmd script)

bq. The GC_LOG_OPTS used as it was before the change on Java <= 8, but for Java 
9 it is ignored. I have no better idea how to do this. IMHO, this is better 
than not working at all! I added documentation for this.

My personal opinion is that it would be better to continue to support things as 
best we can for existing solr users who may upgrade solr w/o caring about jdk9 
at all -- ie: keep supporting/using GC_LOG_OPTS -- but in the special in the 
case where they use jdk9 _and_ try to specify a value for the GC_LOG_OPTS ... 
we should hard fail w/message that solr can't support GC_LOG_OPTS  when using 
jdk9.  

I believe you said in your current patch you "ignored" GC_LOG_OPTS when using 
jdk9? ... i think that's a mistake, as existing solr users who may have already 
set GC_LOG_OPTS and then later upgrade to jdk9 will get confusing silently 
different behavior.  better to fail fast and be clear that they can't do that 
(unless/until we find a better solution)


> bin/solr.cmd does not start with recent Verona builds of Java 9 because of 
> version parsing issue
> 
>
> Key: SOLR-8689
> URL: https://issues.apache.org/jira/browse/SOLR-8689
> Project: Solr
>  Issue Type: Bug
>  Components: scripts and tools
>Affects Versions: 5.5, 6.0
> Environment: Windows 7
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Blocker
>  Labels: Java9
> Fix For: 7.0, master (8.0), 7.1
>
> Attachments: SOLR-8689.patch, SOLR-8689.patch, SOLR-8689.patch, 
> SOLR-8689.patch
>
>
> At least on Windows, Solr 5.5 does not start with the shell script using a 
> Verona-Java-9 JDK:
> {noformat}
> *
> JAVA_HOME = C:\Program Files\Java\jdk-9
> java version "9-ea"
> Java(TM) SE Runtime Environment (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 9-ea+105-2016-02-11-003336.javare.4433.nc, mixed mode)
> *
> C:\Users\Uwe Schindler\Desktop\solr-5.5.0\bin>solr start
> ERROR: Java 1.7 or later is required to run Solr. Current Java version is: 
> 9-ea
> {noformat}
> I don't know if this is better with Linux, but I assume the version parsing 
> is broken (e.g., String#startsWith, interpret as floating point number,...)
> We should fix this before Java 9 gets released! The version numbering scheme 
> changed completely: http://openjdk.java.net/jeps/223



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7935) Release .sha512 hash files with our artifacts

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on LUCENE-7935:
--

Just glanced through the patch. Looks good. Thanks Jan!

> Release .sha512 hash files with our artifacts
> -
>
> Key: LUCENE-7935
> URL: https://issues.apache.org/jira/browse/LUCENE-7935
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/build
>Reporter: Jan Høydahl
> Attachments: LUCENE-7935.patch
>
>
> Currently we are only required to release {{.md5}} hashes with our artifacts, 
> and we also include {{.sha1}} files. It is expected that {{.sha512}} will be 
> required in the future (see 
> https://www.apache.org/dev/release-signing.html#sha1), so why not start 
> generating them right away?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[JENKINS] Lucene-Solr-7.0-Linux (64bit/jdk1.8.0_144) - Build # 240 - Still Unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-7.0-Linux/240/
Java: 64bit/jdk1.8.0_144 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.analytics.facet.FieldFacetCloudTest

Error Message:
Could not find collection:collection1

Stack Trace:
java.lang.AssertionError: Could not find collection:collection1
at __randomizedtesting.SeedInfo.seed([78037E1024D95ED8]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:155)
at 
org.apache.solr.analytics.facet.AbstractAnalyticsFacetCloudTest.setupCluster(AbstractAnalyticsFacetCloudTest.java:59)
at 
org.apache.solr.analytics.facet.FieldFacetCloudTest.beforeClass(FieldFacetCloudTest.java:90)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:847)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 15900 lines...]
   [junit4] Suite: org.apache.solr.analytics.facet.FieldFacetCloudTest
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-7.0-Linux/solr/build/contrib/solr-analytics/test/J0/temp/solr.analytics.facet.FieldFacetCloudTest_78037E1024D95ED8-001/init-core-data-001
   [junit4]   2> log4j:WARN No appenders could be found for logger 
(org.apache.solr.SolrTestCaseJ4).
   [junit4]   2> log4j:WARN Please initialize the log4j system properly.
   [junit4]   2> log4j:WARN See 
http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
   [junit4]   2> Aug 21, 2017 3:47:56 PM 
com.carrotsearch.randomizedtesting.ThreadLeakControl checkThreadLeaks
   [junit4]   2> WARNING: Will linger awaiting termination of 4 leaked 
thread(s).
   [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70), 
sim=RandomSimilarity(queryNorm=false): {}, locale=sr-Latn-BA, 
timezone=SystemV/AST4ADT
   [junit4]   2> NOTE: Linux 4.10.0-27-generic amd64/Oracle Corporation 
1.8.0_144 (64-bit)/cpus=8,threads=1,free=367001600,total=536870912
   [junit4]   2> NOTE: All tests run in this JVM: [FieldFacetCloudTest]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=FieldFacetCloudTest 
-Dtests.seed=78037E1024D95ED8 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=sr-Latn-BA -Dtests.timezone=SystemV/AST4ADT -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.00s J0 | FieldFacetCloudTest (suite) <<<
   [junit4]> Throwable #1: java.lang.AssertionError: Could not find 
collection:collect

[JENKINS] Lucene-Solr-SmokeRelease-7.x - Build # 32 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.x/32/

No tests ran.

Build Log:
[...truncated 25630 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist
 [copy] Copying 476 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 215 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (17.9 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-7.1.0-src.tgz...
   [smoker] 29.5 MB in 0.02 sec (1189.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.1.0.tgz...
   [smoker] 69.1 MB in 0.06 sec (1179.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-7.1.0.zip...
   [smoker] 79.4 MB in 0.07 sec (1172.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-7.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6177 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.1.0.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.8...
   [smoker]   got 6177 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-7.1.0-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 213 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (30.5 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-7.1.0-src.tgz...
   [smoker] 51.2 MB in 1.02 sec (50.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.1.0.tgz...
   [smoker] 142.8 MB in 1.07 sec (133.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-7.1.0.zip...
   [smoker] 143.8 MB in 0.92 sec (156.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-7.1.0.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-7.1.0.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 8 ...
   [smoker] test solr example w/ Java 8...
   [smoker]   start Solr instance 
(log=/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0-java8/solr-example.log)...
   [smoker] No process found for Solr node running on port 8983
   [smoker]   Running techproducts example on port 8983 from 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0-java8
   [smoker] Creating Solr home directory 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.x/lucene/build/smokeTestRelease/tmp/unpack/solr-7.1.0-java8/example/techproducts/solr
   [smoker] 
   [smoker] Starting up Solr on port 8983 using command:
   [smoker] "bin/solr" start -p 8983 -s "example/techproducts/solr"
   [smoker] 
   [smoker] Waiting up to 180 seconds to see Solr running on port 8983 [|]  
 [/]   [-]   [\]  
   [smoker] Started Solr server on port 8983 (pid=11540). Happy searching!
   [smoker] 
   [smoker] 
 

[JENKINS-EA] Lucene-Solr-master-Windows (32bit/jdk-9-ea+181) - Build # 6837 - Still unstable!

[Policeman Jenkins Server]

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6837/
Java: 32bit/jdk-9-ea+181 -server -XX:+UseSerialGC --illegal-access=deny

3 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test

Error Message:
Timeout occured while waiting response from server at: 
http://127.0.0.1:53210/collection1

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: http://127.0.0.1:53210/collection1
at 
__randomizedtesting.SeedInfo.seed([5BF8008FB5EE3270:D3AC3F551B125F88]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:638)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:253)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:242)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:483)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:413)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1121)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:862)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:793)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:178)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:484)
at org.apache.solr.client.solrj.SolrClient.commit(SolrClient.java:463)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.commit(AbstractFullDistribZkTestBase.java:1583)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:213)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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.ra

[jira] [Commented] (SOLR-8994) EmbeddedSolrServer does not provide the httpMethod to the handler

[JIRA]

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

Cédric Damioli commented on SOLR-8994:
--

This issue has actually been fixed by SOLR-10134
You may close this one as duplicate

> EmbeddedSolrServer does not provide the httpMethod to the handler
> -
>
> Key: SOLR-8994
> URL: https://issues.apache.org/jira/browse/SOLR-8994
> Project: Solr
>  Issue Type: Bug
>Reporter: Nicolas Gavalda
>  Labels: embedded
> Attachments: SOLR-8994-EmbeddedSolrServer-httpMethod.patch
>
>
> The modification URIs of the schema API don't work when using an 
> EmbeddedSolrServer: the SchemaHandler verifies that modification requests are 
> POST, and the EmbeddedSolrServer doesn't transmit this information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7927) Add facets impl to count unique numeric values

[Michael McCandless (JIRA)]

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

Michael McCandless updated LUCENE-7927:
---
Attachment: LUCENE-7927.patch

Another iteration, also adding an option to count all facets from a 
{{LongValuesSource}}.

I made a simple artificial benchmark 
(https://github.com/mikemccand/luceneutil/blob/master/src/main/perf/NumericValueFacetBenchmark.java),
 indexing 50M docs with a numeric DV field with values 0 - 9, to test whether 
special casing small values (0-1023) is worthwhile:

Counting long values for all docs takes 99.0 msec (best of 100 iters), and 
153.4 msec if I turn off the opto, so ~35% faster.

The overall gains are less if I run an {{IntPoint.newRangeQuery}} matchin first 
50% of the index and compute facets on that: 255.3 msec and 279.4 if I turn off 
the optimization, so ~9% faster.  But net/net I think we should keep the 
opto... I think it's a common use case to count smallish ordinals.



> Add facets impl to count unique numeric values
> --
>
> Key: LUCENE-7927
> URL: https://issues.apache.org/jira/browse/LUCENE-7927
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 7.1
>
> Attachments: LUCENE-7927.patch, LUCENE-7927.patch, LUCENE-7927.patch
>
>
> The facets module has multiple facet methods for counting flat and 
> hierarchical fields, and also a method for counting numeric ranges.  I'd like 
> to also add a method that counts unique numeric (long) values, designed to be 
> used for fields that have only a few, typically low valued, numbers across 
> the index e.g. a "review" rating from 1 to 5.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7938) Bounds of bounding box are not equal to bounding box

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-7938:
-
Attachment: LUCENE-7938-test.patch
LUCENE-7938-fix.patch

Attached is a test showing the issue and a possible fix.


> Bounds of bounding box are not equal to bounding box
> 
>
> Key: LUCENE-7938
> URL: https://issues.apache.org/jira/browse/LUCENE-7938
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Priority: Minor
> Attachments: LUCENE-7938-fix.patch, LUCENE-7938-test.patch
>
>
> Hi,
> It seems if I get the bounds of a BBox and I create a new bounding box, 
> sometimes both bounding box are not equal. It is a problem with precision.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11245) Cloud native Dockerfile

[Martijn Koster (JIRA)]

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

Martijn Koster commented on SOLR-11245:
---

Most Docker users interact with docker through images hosted on Docker hub, and 
there is already a "solr" Solr image there, from the "official-images" repo 
managed by Docker Inc. That uses the image from 
https://github.com/docker-solr/docker-solr, which is managed by myself and 
committer [~shalinmangar] with help from [~dsmiley] and others, and gets 
reviewed by the Docker library team. It is setup as a github organisation, so 
that we can add users, and arrange for succession and so on.

This image itself is fairly straightforward; it's just Solr installed in an 
OpenJDK image, with some scripts to make it a little easier to work with, and 
some documentation to go along with it. Most of the work goes into setting up 
the build process for the official images builders, doing security 
verification, looking at our own Travis CI, maintaining multiple versions, 
keeping on top of new versions that are released, working with the Docker 
library team, dealing with github issues as they are raised, keeping up with 
the ever-changing Docker features and so on. We try to be careful about 
backwards compatibility; this image has been around for a couple of years now, 
and originally came from one I started in 2013. So far folks seem to be happy 
enough with how these things are working out. 
If you want to help out there, you're very welcome; there are often github 
issues asking for help and examples, and occasional new feature requests 
without PRs.

If there is an appetite for the Apache Solr committers/jira/infrastructure 
whatever to be more involved or take administrative responsibility or whatever, 
I'm open to discussing that.

> Cloud native Dockerfile
> ---
>
> Key: SOLR-11245
> URL: https://issues.apache.org/jira/browse/SOLR-11245
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6
>Reporter: jay vyas
> Fix For: master (8.0)
>
>
> SOLR Should have its own Dockerfile, ideally one that is cloud native (i.e. 
> doesn't expect anything special from the operating system in terms of user 
> IDs, etc), for deployment, that we can curate and submit changes to as part 
> of the official ASF process, rather then externally.  The idea here is that 
> testing SOLR regression, as a microservice, is something we should be doing 
> as part of our continuous integration, rather then something done externally.
> We have a team here that would be more then happy to do the work to port 
> whatever existing SOLR dockerfiles are out there into something that is ASF 
> maintainable, and cloud native, and easily testable, as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7938) Bounds of bounding box are not equal to bounding box

[Ignacio Vera (JIRA)]

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

Ignacio Vera updated LUCENE-7938:
-
Summary: Bounds of bounding box are not equal to bounding box  (was: 
Bounsds of boudingBox are not equal to Bounding Box)

> Bounds of bounding box are not equal to bounding box
> 
>
> Key: LUCENE-7938
> URL: https://issues.apache.org/jira/browse/LUCENE-7938
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Ignacio Vera
>Priority: Minor
>
> Hi,
> It seems if I get the bounds of a BBox and I create a new bounding box, 
> sometimes both bounding box are not equal. It is a problem with precision.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (LUCENE-7938) Bounsds of boudingBox are not equal to Bounding Box

[Ignacio Vera (JIRA)]

Ignacio Vera created LUCENE-7938:


 Summary: Bounsds of boudingBox are not equal to Bounding Box
 Key: LUCENE-7938
 URL: https://issues.apache.org/jira/browse/LUCENE-7938
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Ignacio Vera
Priority: Minor


Hi,

It seems if I get the bounds of a BBox and I create a new bounding box, 
sometimes both bounding box are not equal. It is a problem with precision.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Resolved] (SOLR-11255) ConcurrentModificationException when using SolrInfoMBeanHandler

[Andrzej Bialecki (JIRA)]

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

Andrzej Bialecki  resolved SOLR-11255.
--
   Resolution: Fixed
Fix Version/s: 7.1
   master (8.0)

> ConcurrentModificationException when using SolrInfoMBeanHandler
> ---
>
> Key: SOLR-11255
> URL: https://issues.apache.org/jira/browse/SOLR-11255
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.0, master (8.0), 7.1
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-11255.patch
>
>
> Recent jenkins build has the following failure:
> {code}
> FAILED:  org.apache.solr.handler.admin.MBeansHandlerTest.testDiff
> Error Message:
> Stack Trace:
> java.util.ConcurrentModificationException
>   at 
> __randomizedtesting.SeedInfo.seed([88A87D85742F51F2:4DBEB91E64996992]:0)
>   at 
> java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1604)
>   at 
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:591)
>   at 
> org.apache.solr.util.stats.MetricUtils.convertMetrics(MetricUtils.java:248)
>   at 
> org.apache.solr.util.stats.MetricUtils.convertMetrics(MetricUtils.java:226)
>   at 
> org.apache.solr.core.SolrInfoBean.getMetricsSnapshot(SolrInfoBean.java:62)
>   at 
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.addMBean(SolrInfoMBeanHandler.java:148)
>   at 
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.getMBeanInfo(SolrInfoMBeanHandler.java:130)
>   at 
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:61)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2483)
>   at org.apache.solr.util.TestHarness.query(TestHarness.java:337)
>   at org.apache.solr.util.TestHarness.query(TestHarness.java:319)
>   at 
> org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:43)
>   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:1713)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
>   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:916)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
>   at 
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
>   at 
> org.apache.

[jira] [Commented] (SOLR-11255) ConcurrentModificationException when using SolrInfoMBeanHandler

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-11255:


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

SOLR-11255: Use concurrent set for metric names.


> ConcurrentModificationException when using SolrInfoMBeanHandler
> ---
>
> Key: SOLR-11255
> URL: https://issues.apache.org/jira/browse/SOLR-11255
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.0, master (8.0), 7.1
>Reporter: Andrzej Bialecki 
>Assignee: Andrzej Bialecki 
> Attachments: SOLR-11255.patch
>
>
> Recent jenkins build has the following failure:
> {code}
> FAILED:  org.apache.solr.handler.admin.MBeansHandlerTest.testDiff
> Error Message:
> Stack Trace:
> java.util.ConcurrentModificationException
>   at 
> __randomizedtesting.SeedInfo.seed([88A87D85742F51F2:4DBEB91E64996992]:0)
>   at 
> java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1604)
>   at 
> java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:591)
>   at 
> org.apache.solr.util.stats.MetricUtils.convertMetrics(MetricUtils.java:248)
>   at 
> org.apache.solr.util.stats.MetricUtils.convertMetrics(MetricUtils.java:226)
>   at 
> org.apache.solr.core.SolrInfoBean.getMetricsSnapshot(SolrInfoBean.java:62)
>   at 
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.addMBean(SolrInfoMBeanHandler.java:148)
>   at 
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.getMBeanInfo(SolrInfoMBeanHandler.java:130)
>   at 
> org.apache.solr.handler.admin.SolrInfoMBeanHandler.handleRequestBody(SolrInfoMBeanHandler.java:61)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:177)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2483)
>   at org.apache.solr.util.TestHarness.query(TestHarness.java:337)
>   at org.apache.solr.util.TestHarness.query(TestHarness.java:319)
>   at 
> org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:43)
>   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:1713)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
>   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:916)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
>   at 
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
>   at 
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.ev

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth

Error Message:
2 threads leaked from SUITE scope at 
org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth: 1) 
Thread[id=21925, name=jetty-launcher-2664-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)   
 2) Thread[id=21929, name=jetty-launcher-2664-thread-2-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)  
   at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
 at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)  
   at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
 at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:41)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.readValue(SharedValue.java:244)
 at 
org.apache.curator.framework.recipes.shared.SharedValue.access$100(SharedValue.java:44)
 at 
org.apache.curator.framework.recipes.shared.SharedValue$1.process(SharedValue.java:61)
 at 
org.apache.curator.framework.imps.NamespaceWatcher.process(NamespaceWatcher.java:67)
 at 
org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:530)   
  at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:505)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 2 threads leaked from SUITE 
scope at org.apache.solr.security.hadoop.TestImpersonationWithHadoopAuth: 
   1) Thread[id=21925, name=jetty-launcher-2664-thread-1-EventThread, 
state=TIMED_WAITING, group=TGRP-TestImpersonationWithHadoopAuth]
at sun.misc.Unsafe.park(Native Method)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
at 
org.apache.curator.CuratorZookeeperClient.internalBlockUntilConnectedOrTimedOut(CuratorZookeeperClient.java:323)
at org.apache.curator.RetryLoop.callWithRetry(RetryLoop.java:105)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.pathInForeground(GetDataBuilderImpl.java:288)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(GetDataBuilderImpl.java:279)
at 
org.apache.curator.framework.imps.GetDataBuilderImpl.forPath(

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1378 - Still unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1378/

4 tests failed.
FAILED:  org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test

Error Message:
The Monkey ran for over 45 seconds and no jetties were stopped - this is worth 
investigating!

Stack Trace:
java.lang.AssertionError: The Monkey ran for over 45 seconds and no jetties 
were stopped - this is worth investigating!
at 
__randomizedtesting.SeedInfo.seed([D8359DE4DB9BC7F:85D76604E345D187]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.apache.solr.cloud.ChaosMonkey.stopTheMonkey(ChaosMonkey.java:587)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeWithPullReplicasTest.test(ChaosMonkeyNothingIsSafeWithPullReplicasTest.java:222)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:993)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:968)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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.carrotse

[jira] [Commented] (SOLR-11245) Cloud native Dockerfile

[JIRA]

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

Jan Høydahl commented on SOLR-11245:


Interesting. How would this fit in our source tree? Would there be a separate 
git repo, mirrored to github, which in turn ends up in docker-hub? How would 
our build and Jenkins be able to build and test the Dockerfile? 

> Cloud native Dockerfile
> ---
>
> Key: SOLR-11245
> URL: https://issues.apache.org/jira/browse/SOLR-11245
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Build
>Affects Versions: 6.6
>Reporter: jay vyas
> Fix For: master (8.0)
>
>
> SOLR Should have its own Dockerfile, ideally one that is cloud native (i.e. 
> doesn't expect anything special from the operating system in terms of user 
> IDs, etc), for deployment, that we can curate and submit changes to as part 
> of the official ASF process, rather then externally.  The idea here is that 
> testing SOLR regression, as a microservice, is something we should be doing 
> as part of our continuous integration, rather then something done externally.
> We have a team here that would be more then happy to do the work to port 
> whatever existing SOLR dockerfiles are out there into something that is ASF 
> maintainable, and cloud native, and easily testable, as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7937) Improve tests to play nicely w/IntelliJ IDE

[Dawid Weiss (JIRA)]

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

Dawid Weiss commented on LUCENE-7937:
-

Can you provide a screenshot of what you mean? Thanks. IDEs support selective 
test execution in a myriad of ways, so hard to tell what's happening here.

> Improve tests to play nicely w/IntelliJ IDE
> ---
>
> Key: LUCENE-7937
> URL: https://issues.apache.org/jira/browse/LUCENE-7937
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/test
>Affects Versions: 7.1
>Reporter: Mike Sokolov
>
> When running a single test in IntelliJ, something about the way the tests are 
> run causes the UI to display all the tests in the class *other than the one 
> that was run* as if they had been ignored. In contrast, running a single test 
> in a typical test case class not derived from LuceneTestCase shows only the 
> status of that test case method, not all the other methods in the class.
> This is somewhat irritating since it makes it hard to see what's going on 
> with the test of interest.
> This is with IntelliJ 2017.1.4, junit 4.12



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (LUCENE-7937) Improve tests to play nicely w/IntelliJ IDE

[Mike Sokolov (JIRA)]

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

Mike Sokolov updated LUCENE-7937:
-
Summary: Improve tests to play nicely w/IntelliJ IDE  (was: Improve tests 
to play nicely w/IntelliJ)

> Improve tests to play nicely w/IntelliJ IDE
> ---
>
> Key: LUCENE-7937
> URL: https://issues.apache.org/jira/browse/LUCENE-7937
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: general/test
>Affects Versions: 7.1
>Reporter: Mike Sokolov
>
> When running a single test in IntelliJ, something about the way the tests are 
> run causes the UI to display all the tests in the class *other than the one 
> that was run* as if they had been ignored. In contrast, running a single test 
> in a typical test case class not derived from LuceneTestCase shows only the 
> status of that test case method, not all the other methods in the class.
> This is somewhat irritating since it makes it hard to see what's going on 
> with the test of interest.
> This is with IntelliJ 2017.1.4, junit 4.12



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (LUCENE-7932) Search record with field value='a' or 'A' returns all records along with one more field value

[Steve Rowe (JIRA)]

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

Steve Rowe edited comment on LUCENE-7932 at 8/21/17 1:33 PM:
-

bq. Do you still suggest me to use: 
http://lucene.apache.org/core/discussion.html

Yes.  You should always start there, and if you don't get a response in a day 
or two, or if someone requests you to do so, only then create a JIRA issue.

It's still the case that you haven't provided enough information.  You haven't 
provided any code, and you haven't shown what your actual queries are.  Are you 
using Lucene directly, or are you using some other project that depends on 
Lucene?


was (Author: steve_rowe):
bq. Do you still suggest me to use: 
http://lucene.apache.org/core/discussion.html

Yes.  You should always start there, and if you don't get a response, or if 
someone requests you to do so, only then create a JIRA issue.

It's still the case that you haven't provided enough information.  You haven't 
provided any code, and you haven't shown what your actual queries are.  Are you 
using Lucene directly, or are you using some other project that depends on 
Lucene?

> Search record with field value='a' or 'A' returns all records along with one 
> more field value
> -
>
> Key: LUCENE-7932
> URL: https://issues.apache.org/jira/browse/LUCENE-7932
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.3, 6.6
> Environment: Windows and Linux
>Reporter: Rohit Balekundri
>  Labels: features
>
> Hi Lucene Team,
> I would like to explain more on about issue facing after querying using 
> QueryParser API.
> Here I am just giving examples of our project with field names (Not related 
> with Lucene):
> In our document which needs to be archived having key fields and non-key 
> fields.
> A> Key fields: 
> 1. LocationCode (DataType=long)
> 2. CollectionObjectID (DataType=long)
> B> Non-key fields
> Category (DataType=string)
> Steps we followed:
> 1. Step 1: We stored multiple document records with category values as below 
> in index files.
>  LocationCode = 1  Category =b
>  LocationCode = 2  Category =BC
>  LocationCode =3  Category =bcd
> 2. In Step 2: we query for records and we pass query parameters as below.
> a) LocationCode=1 and  Category =a  
>  Result= all records displayed
> b) LocationCode=1 and  Category =A  result= all records displayed
>  Result= all records displayed
> I faced above issue in Lucene 5.3.
> Llater I found even Lucene 6.6 is also having same issue.
> Kindly consider this bug on top priority.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7932) Search record with field value='a' or 'A' returns all records along with one more field value

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7932:


bq. Do you still suggest me to use: 
http://lucene.apache.org/core/discussion.html

Yes.  You should always start there, and if you don't get a response, or if 
someone requests you to do so, only then create a JIRA issue.

It's still the case that you haven't provided enough information.  You haven't 
provided any code, and you haven't shown what your actual queries are.  Are you 
using Lucene directly, or are you using some other project that depends on 
Lucene?

> Search record with field value='a' or 'A' returns all records along with one 
> more field value
> -
>
> Key: LUCENE-7932
> URL: https://issues.apache.org/jira/browse/LUCENE-7932
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.3, 6.6
> Environment: Windows and Linux
>Reporter: Rohit Balekundri
>  Labels: features
>
> Hi Lucene Team,
> I would like to explain more on about issue facing after querying using 
> QueryParser API.
> Here I am just giving examples of our project with field names (Not related 
> with Lucene):
> In our document which needs to be archived having key fields and non-key 
> fields.
> A> Key fields: 
> 1. LocationCode (DataType=long)
> 2. CollectionObjectID (DataType=long)
> B> Non-key fields
> Category (DataType=string)
> Steps we followed:
> 1. Step 1: We stored multiple document records with category values as below 
> in index files.
>  LocationCode = 1  Category =b
>  LocationCode = 2  Category =BC
>  LocationCode =3  Category =bcd
> 2. In Step 2: we query for records and we pass query parameters as below.
> a) LocationCode=1 and  Category =a  
>  Result= all records displayed
> b) LocationCode=1 and  Category =A  result= all records displayed
>  Result= all records displayed
> I faced above issue in Lucene 5.3.
> Llater I found even Lucene 6.6 is also having same issue.
> Kindly consider this bug on top priority.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.update.HardAutoCommitTest.testCommitWithin

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([72F3002819B4DAA:BDFD5F7A02B5A3BF]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:880)
at 
org.apache.solr.update.HardAutoCommitTest.testCommitWithin(HardAutoCommitTest.java:100)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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=id:529&qt=&start=0&rows=20&version=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:873)
... 40 more




Build Log:
[...truncated 11946 lines...]
   [junit4] Suite: org

[jira] [Created] (LUCENE-7937) Improve tests to play nicely w/IntelliJ

[Mike Sokolov (JIRA)]

Mike Sokolov created LUCENE-7937:


 Summary: Improve tests to play nicely w/IntelliJ
 Key: LUCENE-7937
 URL: https://issues.apache.org/jira/browse/LUCENE-7937
 Project: Lucene - Core
  Issue Type: Improvement
  Components: general/test
Affects Versions: 7.1
Reporter: Mike Sokolov


When running a single test in IntelliJ, something about the way the tests are 
run causes the UI to display all the tests in the class *other than the one 
that was run* as if they had been ignored. In contrast, running a single test 
in a typical test case class not derived from LuceneTestCase shows only the 
status of that test case method, not all the other methods in the class.

This is somewhat irritating since it makes it hard to see what's going on with 
the test of interest.

This is with IntelliJ 2017.1.4, junit 4.12



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (LUCENE-7936) Extend Geoshape interfaces so objects can be copied/serialized

[Ignacio Vera (JIRA)]

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

Ignacio Vera commented on LUCENE-7936:
--

Understood & Cheers!

> Extend Geoshape interfaces so objects can be copied/serialized
> --
>
> Key: LUCENE-7936
> URL: https://issues.apache.org/jira/browse/LUCENE-7936
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7936.patch
>
>
> Hi [~david.wri...@bksv.com],
> I would like to propose to extends the GeoShape interfaces to be able to 
> copy/serialized the objects. The current status and  propose change is as 
> following:
> GeoPoint: It can be serialized by using x, y, z
> GeoCircle:  It can be serialized by using getCenter() and getRadius() and 
> getPlanetModel()
> GeoCompositeShape: It can be serialized by accesing shapes using size() and 
> GetShape(int index)
> GeoPath: add methods to the interface getPoints() and getCutoffAngle()
> GeoPolygon: This is the most complicated one as we have different types:
>1.- GeoCompositePolygon is just a composite
>2.- GeoConcavePolygon and GeoConvexPolygon: Create a new interface for 
> those polygons which exposes the points, holes, internaledges and 
> concavity/convexity
>3.- GeoComplexPolygons: Do nothing, they are too complex to be serialize??
> I am intersested in accesing the discreatization of the polygons into convex 
> and concave ones for other reasons as well. I think this should be expose as 
> they end result can be used for other use cases.
> Cheers,
> I.
>   



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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