[jira] [Updated] (LUCENE-7430) Geo3d test failure

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-7430:

Description: 
Here's the error msg:

{code}
   [junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
   [junit4] IGNOR/A 0.02s J0 | TestGeo3DPoint.testRandomBig
   [junit4]> Assumption #1: 'nightly' test group is disabled (@Nightly())
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint 
-Dtests.method=testRandomMedium -Dtests.seed=B167D2C466D257A0 -Dtests.slow=true 
-Dtests.locale=pt -Dtests.timezone=Etc/GMT+5 -Dtests.asserts=true 
-Dtests.file.encoding=Cp1252
   [junit4] FAILURE 4.06s J0 | TestGeo3DPoint.testRandomMedium <<<
   [junit4]> Throwable #1: java.lang.AssertionError: FAIL: id=4546 should 
have matched but did not
   [junit4]>   shape=GeoWideNorthRectangle: {planetmodel=PlanetModel.WGS84, 
bottomlat=1.5707949696510948(89.2224138796), 
leftlon=3.141592653589793(180.0), 
rightlon=3.1140200112375265(178.42020396319145)}
   [junit4]>   bounds=XYZBounds: [xmin=-1.3551580601679786E-6 
xmax=1.3551580601679786E-6 ymin=-1.3551580601679786E-6 
ymax=1.3551580601679786E-6 zmin=0.9977622910211923 zmax=0.9977622930221051]
   [junit4]>   world bounds=( minX=-1.0011188539924791 
maxX=1.0011188539924791 minY=-1.0011188539924791 maxY=1.0011188539924791 
minZ=-0.9977622920221051 maxZ=0.9977622920221051
   [junit4]>   quantized point=[X=7.323492821176281E-6, 
Y=-2.3309121299774915E-10, Z=0.9977622921205215] within shape? true within 
bounds? false
   [junit4]>   unquantized point=[lat=1.570788986986606, 
lon=-1.0056566715747591E-117([X=7.323383942914017E-6, 
Y=-7.364809920694947E-123, Z=0.9977622919954089])] within shape? false within 
bounds? false
   [junit4]>   docID=4438 deleted?=false
   [junit4]>   query=PointInGeo3DShapeQuery: field=point: Shape: 
GeoWideNorthRectangle: {planetmodel=PlanetModel.WGS84, 
bottomlat=1.5707949696510948(89.2224138796), 
leftlon=3.141592653589793(180.0), 
rightlon=3.1140200112375265(178.42020396319145)}
...
{code}


  was:
Here's the error msg:

{code}
Error Message:
FAIL: id=4546 should have matched but did not   shape=GeoWideNorthRectangle: 
{planetmodel=PlanetModel.WGS84, 
bottomlat=1.5707949696510948(89.2224138796), 
leftlon=3.141592653589793(180.0), 
rightlon=3.1140200112375265(178.42020396319145)}   bounds=XYZBounds: 
[xmin=-1.3551580601679786E-6 xmax=1.3551580601679786E-6 
ymin=-1.3551580601679786E-6 ymax=1.3551580601679786E-6 zmin=0.9977622910211923 
zmax=0.9977622930221051]   world bounds=( minX=-1.0011188539924791 
maxX=1.0011188539924791 minY=-1.0011188539924791 maxY=1.0011188539924791 
minZ=-0.9977622920221051 maxZ=0.9977622920221051   quantized 
point=[X=7.323492821176281E-6, Y=-2.3309121299774915E-10, Z=0.9977622921205215] 
within shape? true within bounds? false   unquantized 
point=[lat=1.570788986986606, 
lon=-1.0056566715747591E-117([X=7.323383942914017E-6, 
Y=-7.364809920694947E-123, Z=0.9977622919954089])] within shape? false within 
bounds? false   docID=4438 deleted?=false   query=PointInGeo3DShapeQuery: 
field=point: Shape: GeoWideNorthRectangle: {planetmodel=PlanetModel.WGS84, 
bottomlat=1.5707949696510948(89.2224138796), 
leftlon=3.141592653589793(180.0), 
rightlon=3.1140200112375265(178.42020396319145)}   explanation: target is 
in leaf _1(7.0.0):C14521 of full reader StandardDirectoryReader(segments:5:nrt 
_1(7.0.0):C14521) full BKD path to target doc:   
Cell(x=-1.0011188543037526 TO 1.0011188543037524 y=-1.0011167835214163 TO 
1.0011082645037634 z=-0.9977622923536127 TO 0.9977622923536126); Shape 
relationship = WITHIN; Quantized point within cell = true; Unquantized point 
within cell = true   Cell(x=0.0 TO 1.0011188543037524 y=-1.0011167835214163 
TO 1.0011082645037634 z=-0.9977622923536127 TO 0.9977622923536126); Shape 
relationship = OVERLAPS; Quantized point within cell = true; Unquantized point 
within cell = true   Cell(x=0.0 TO 1.0011188543037524 y=-1.0011167835214163 
TO 4.661824259954982E-10 z=-0.9977622923536127 TO 0.9977622923536126); Shape 
relationship = OVERLAPS; Quantized point within cell = true; Unquantized point 
within cell = true   Cell(x=0.0 TO 1.0011188543037524 y=-1.0011167835214163 
TO 4.661824259954982E-10 z=0.0 TO 0.9977622923536126); Shape relationship = 
OVERLAPS; Quantized point within cell = true; Unquantized point within cell = 
true   Cell(x=0.0 TO 0.5921489289992575 y=-1.0011167835214163 TO 
4.661824259954982E-10 z=0.0 TO 0.9977622923536126); Shape relationship = 
OVERLAPS; Quantized point within cell = true; Unquantized point within cell = 
true on cell Cell(x=-1.0011188543037526 TO 1.0011188543037524 
y=-1.0011167835214163 TO 1.0011082645037634 z=-0.9977622923536127 TO 
0.9977622923536126); Shape relationship = WITHIN; Quantized point within cell = 
true; Unquantized point within cell = true, wrapped visitor 

[jira] [Created] (LUCENE-7430) Geo3d test failure

[Karl Wright (JIRA)]

Karl Wright created LUCENE-7430:
---

 Summary: Geo3d test failure
 Key: LUCENE-7430
 URL: https://issues.apache.org/jira/browse/LUCENE-7430
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Karl Wright
Assignee: Karl Wright


Here's the error msg:

{code}
Error Message:
FAIL: id=4546 should have matched but did not   shape=GeoWideNorthRectangle: 
{planetmodel=PlanetModel.WGS84, 
bottomlat=1.5707949696510948(89.2224138796), 
leftlon=3.141592653589793(180.0), 
rightlon=3.1140200112375265(178.42020396319145)}   bounds=XYZBounds: 
[xmin=-1.3551580601679786E-6 xmax=1.3551580601679786E-6 
ymin=-1.3551580601679786E-6 ymax=1.3551580601679786E-6 zmin=0.9977622910211923 
zmax=0.9977622930221051]   world bounds=( minX=-1.0011188539924791 
maxX=1.0011188539924791 minY=-1.0011188539924791 maxY=1.0011188539924791 
minZ=-0.9977622920221051 maxZ=0.9977622920221051   quantized 
point=[X=7.323492821176281E-6, Y=-2.3309121299774915E-10, Z=0.9977622921205215] 
within shape? true within bounds? false   unquantized 
point=[lat=1.570788986986606, 
lon=-1.0056566715747591E-117([X=7.323383942914017E-6, 
Y=-7.364809920694947E-123, Z=0.9977622919954089])] within shape? false within 
bounds? false   docID=4438 deleted?=false   query=PointInGeo3DShapeQuery: 
field=point: Shape: GeoWideNorthRectangle: {planetmodel=PlanetModel.WGS84, 
bottomlat=1.5707949696510948(89.2224138796), 
leftlon=3.141592653589793(180.0), 
rightlon=3.1140200112375265(178.42020396319145)}   explanation: target is 
in leaf _1(7.0.0):C14521 of full reader StandardDirectoryReader(segments:5:nrt 
_1(7.0.0):C14521) full BKD path to target doc:   
Cell(x=-1.0011188543037526 TO 1.0011188543037524 y=-1.0011167835214163 TO 
1.0011082645037634 z=-0.9977622923536127 TO 0.9977622923536126); Shape 
relationship = WITHIN; Quantized point within cell = true; Unquantized point 
within cell = true   Cell(x=0.0 TO 1.0011188543037524 y=-1.0011167835214163 
TO 1.0011082645037634 z=-0.9977622923536127 TO 0.9977622923536126); Shape 
relationship = OVERLAPS; Quantized point within cell = true; Unquantized point 
within cell = true   Cell(x=0.0 TO 1.0011188543037524 y=-1.0011167835214163 
TO 4.661824259954982E-10 z=-0.9977622923536127 TO 0.9977622923536126); Shape 
relationship = OVERLAPS; Quantized point within cell = true; Unquantized point 
within cell = true   Cell(x=0.0 TO 1.0011188543037524 y=-1.0011167835214163 
TO 4.661824259954982E-10 z=0.0 TO 0.9977622923536126); Shape relationship = 
OVERLAPS; Quantized point within cell = true; Unquantized point within cell = 
true   Cell(x=0.0 TO 0.5921489289992575 y=-1.0011167835214163 TO 
4.661824259954982E-10 z=0.0 TO 0.9977622923536126); Shape relationship = 
OVERLAPS; Quantized point within cell = true; Unquantized point within cell = 
true on cell Cell(x=-1.0011188543037526 TO 1.0011188543037524 
y=-1.0011167835214163 TO 1.0011082645037634 z=-0.9977622923536127 TO 
0.9977622923536126); Shape relationship = WITHIN; Quantized point within cell = 
true; Unquantized point within cell = true, wrapped visitor returned 
CELL_CROSSES_QUERY on cell Cell(x=0.0 TO 1.0011188543037524 
y=-1.0011167835214163 TO 1.0011082645037634 z=-0.9977622923536127 TO 
0.9977622923536126); Shape relationship = OVERLAPS; Quantized point within cell 
= true; Unquantized point within cell = true, wrapped visitor returned 
CELL_CROSSES_QUERY on cell Cell(x=0.0 TO 1.0011188543037524 
y=-1.0011167835214163 TO 4.661824259954982E-10 z=-0.9977622923536127 TO 
0.9977622923536126); Shape relationship = OVERLAPS; Quantized point within cell 
= true; Unquantized point within cell = true, wrapped visitor returned 
CELL_CROSSES_QUERY on cell Cell(x=0.0 TO 1.0011188543037524 
y=-1.0011167835214163 TO 4.661824259954982E-10 z=0.0 TO 0.9977622923536126); 
Shape relationship = OVERLAPS; Quantized point within cell = true; Unquantized 
point within cell = true, wrapped visitor returned CELL_CROSSES_QUERY on 
cell Cell(x=0.0 TO 0.5921489289992575 y=-1.0011167835214163 TO 
4.661824259954982E-10 z=0.0 TO 0.9977622923536126); Shape relationship = 
OVERLAPS; Quantized point within cell = true; Unquantized point within cell = 
true, wrapped visitor returned CELL_CROSSES_QUERY   leaf visit docID=4438 
x=7.323492821176281E-6 y=-2.3309121299774915E-10 z=0.9977622921205215

Stack Trace:
java.lang.AssertionError: FAIL: id=4546 should have matched but did not
  shape=GeoWideNorthRectangle: {planetmodel=PlanetModel.WGS84, 
bottomlat=1.5707949696510948(89.2224138796), 
leftlon=3.141592653589793(180.0), 
rightlon=3.1140200112375265(178.42020396319145)}
  bounds=XYZBounds: [xmin=-1.3551580601679786E-6 xmax=1.3551580601679786E-6 
ymin=-1.3551580601679786E-6 ymax=1.3551580601679786E-6 zmin=0.9977622910211923 
zmax=0.9977622930221051]
  world bounds=( minX=-1.0011188539924791 maxX=1.0011188539924791 

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6087/
Java: 64bit/jdk1.8.0_102 -XX:+UseCompressedOops -XX:+UseG1GC

4 tests failed.
FAILED:  org.apache.lucene.spatial3d.TestGeo3DPoint.testRandomMedium

Error Message:
FAIL: id=4546 should have matched but did not   shape=GeoWideNorthRectangle: 
{planetmodel=PlanetModel.WGS84, 
bottomlat=1.5707949696510948(89.2224138796), 
leftlon=3.141592653589793(180.0), 
rightlon=3.1140200112375265(178.42020396319145)}   bounds=XYZBounds: 
[xmin=-1.3551580601679786E-6 xmax=1.3551580601679786E-6 
ymin=-1.3551580601679786E-6 ymax=1.3551580601679786E-6 zmin=0.9977622910211923 
zmax=0.9977622930221051]   world bounds=( minX=-1.0011188539924791 
maxX=1.0011188539924791 minY=-1.0011188539924791 maxY=1.0011188539924791 
minZ=-0.9977622920221051 maxZ=0.9977622920221051   quantized 
point=[X=7.323492821176281E-6, Y=-2.3309121299774915E-10, Z=0.9977622921205215] 
within shape? true within bounds? false   unquantized 
point=[lat=1.570788986986606, 
lon=-1.0056566715747591E-117([X=7.323383942914017E-6, 
Y=-7.364809920694947E-123, Z=0.9977622919954089])] within shape? false within 
bounds? false   docID=4438 deleted?=false   query=PointInGeo3DShapeQuery: 
field=point: Shape: GeoWideNorthRectangle: {planetmodel=PlanetModel.WGS84, 
bottomlat=1.5707949696510948(89.2224138796), 
leftlon=3.141592653589793(180.0), 
rightlon=3.1140200112375265(178.42020396319145)}   explanation: target is 
in leaf _1(7.0.0):C14521 of full reader StandardDirectoryReader(segments:5:nrt 
_1(7.0.0):C14521) full BKD path to target doc:   
Cell(x=-1.0011188543037526 TO 1.0011188543037524 y=-1.0011167835214163 TO 
1.0011082645037634 z=-0.9977622923536127 TO 0.9977622923536126); Shape 
relationship = WITHIN; Quantized point within cell = true; Unquantized point 
within cell = true   Cell(x=0.0 TO 1.0011188543037524 y=-1.0011167835214163 
TO 1.0011082645037634 z=-0.9977622923536127 TO 0.9977622923536126); Shape 
relationship = OVERLAPS; Quantized point within cell = true; Unquantized point 
within cell = true   Cell(x=0.0 TO 1.0011188543037524 y=-1.0011167835214163 
TO 4.661824259954982E-10 z=-0.9977622923536127 TO 0.9977622923536126); Shape 
relationship = OVERLAPS; Quantized point within cell = true; Unquantized point 
within cell = true   Cell(x=0.0 TO 1.0011188543037524 y=-1.0011167835214163 
TO 4.661824259954982E-10 z=0.0 TO 0.9977622923536126); Shape relationship = 
OVERLAPS; Quantized point within cell = true; Unquantized point within cell = 
true   Cell(x=0.0 TO 0.5921489289992575 y=-1.0011167835214163 TO 
4.661824259954982E-10 z=0.0 TO 0.9977622923536126); Shape relationship = 
OVERLAPS; Quantized point within cell = true; Unquantized point within cell = 
true on cell Cell(x=-1.0011188543037526 TO 1.0011188543037524 
y=-1.0011167835214163 TO 1.0011082645037634 z=-0.9977622923536127 TO 
0.9977622923536126); Shape relationship = WITHIN; Quantized point within cell = 
true; Unquantized point within cell = true, wrapped visitor returned 
CELL_CROSSES_QUERY on cell Cell(x=0.0 TO 1.0011188543037524 
y=-1.0011167835214163 TO 1.0011082645037634 z=-0.9977622923536127 TO 
0.9977622923536126); Shape relationship = OVERLAPS; Quantized point within cell 
= true; Unquantized point within cell = true, wrapped visitor returned 
CELL_CROSSES_QUERY on cell Cell(x=0.0 TO 1.0011188543037524 
y=-1.0011167835214163 TO 4.661824259954982E-10 z=-0.9977622923536127 TO 
0.9977622923536126); Shape relationship = OVERLAPS; Quantized point within cell 
= true; Unquantized point within cell = true, wrapped visitor returned 
CELL_CROSSES_QUERY on cell Cell(x=0.0 TO 1.0011188543037524 
y=-1.0011167835214163 TO 4.661824259954982E-10 z=0.0 TO 0.9977622923536126); 
Shape relationship = OVERLAPS; Quantized point within cell = true; Unquantized 
point within cell = true, wrapped visitor returned CELL_CROSSES_QUERY on 
cell Cell(x=0.0 TO 0.5921489289992575 y=-1.0011167835214163 TO 
4.661824259954982E-10 z=0.0 TO 0.9977622923536126); Shape relationship = 
OVERLAPS; Quantized point within cell = true; Unquantized point within cell = 
true, wrapped visitor returned CELL_CROSSES_QUERY   leaf visit docID=4438 
x=7.323492821176281E-6 y=-2.3309121299774915E-10 z=0.9977622921205215   

Stack Trace:
java.lang.AssertionError: FAIL: id=4546 should have matched but did not
  shape=GeoWideNorthRectangle: {planetmodel=PlanetModel.WGS84, 
bottomlat=1.5707949696510948(89.2224138796), 
leftlon=3.141592653589793(180.0), 
rightlon=3.1140200112375265(178.42020396319145)}
  bounds=XYZBounds: [xmin=-1.3551580601679786E-6 xmax=1.3551580601679786E-6 
ymin=-1.3551580601679786E-6 ymax=1.3551580601679786E-6 zmin=0.9977622910211923 
zmax=0.9977622930221051]
  world bounds=( minX=-1.0011188539924791 maxX=1.0011188539924791 
minY=-1.0011188539924791 maxY=1.0011188539924791 minZ=-0.9977622920221051 
maxZ=0.9977622920221051
  quantized point=[X=7.323492821176281E-6, Y=-2.3309121299774915E-10, 

[jira] [Commented] (SOLR-9444) Fix path usage for cloud backup/restore

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-9444:


[~varunthacker] [~thetaphi] Could you please review the PR ? I have tested on 
Linux as well as Windows...

> Fix path usage for cloud backup/restore
> ---
>
> Key: SOLR-9444
> URL: https://issues.apache.org/jira/browse/SOLR-9444
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Varun Thacker
> Attachments: SOLR-9444.patch
>
>
> As noted by Uwe on 
> https://issues.apache.org/jira/browse/SOLR-9242?focusedCommentId=15438925=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15438925
>  the usage of URI#getPath is wrong. 
> Creating a Jira to track this better. More details to follow



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Reopened] (SOLR-9439) Shard split clean up logic for older failed splits is faulty

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reopened SOLR-9439:
-

The root cause of these test failures is that the deleteshard API is not 
resilient against non-existent cores. If it fails trying to delete a core which 
is already deleted then it fails to remove the slice from the cluster state.

> Shard split clean up logic for older failed splits is faulty
> 
>
> Key: SOLR-9439
> URL: https://issues.apache.org/jira/browse/SOLR-9439
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 4.10.4, 5.5.2, 6.1
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.3
>
> Attachments: Lucene-Solr-tests-master.8015.log.gz, SOLR-9439.patch, 
> SOLR-9439.patch, SOLR-9439.patch
>
>
> In case a split finds that previous sub-shards exist in construction or 
> recovery state. it tries to clean them up by invoking deleteshard API. 
> However, the clean up logic tries to invoke deleteshard on the same 
> sub-shards as many times as the requested number of sub-ranges. Such repeat 
> calls to deleteshard fail and therefore fail the entire shard split operation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/364/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MDCAwareThreadPoolExecutor, SolrCore, MockDirectoryWrapper, 
MockDirectoryWrapper, MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 5 object(s) that were not 
released!!! [MDCAwareThreadPoolExecutor, SolrCore, MockDirectoryWrapper, 
MockDirectoryWrapper, MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([235C3B8BFEB71E82]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:258)
at sun.reflect.GeneratedMethodAccessor54.invoke(Unknown Source)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestCoreDiscovery

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestCoreDiscovery: 
1) Thread[id=10927, name=searcherExecutor-3672-thread-1, state=WAITING, 
group=TGRP-TestCoreDiscovery] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)   
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestCoreDiscovery: 
   1) Thread[id=10927, name=searcherExecutor-3672-thread-1, state=WAITING, 
group=TGRP-TestCoreDiscovery]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
   

[JENKINS] Lucene-Solr-Tests-5.5 - Build # 2 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.5/2/

All tests passed

Build Log:
[...truncated 10514 lines...]
[javac] Compiling 626 source files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/build/solr-core/classes/test
[javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/core/src/test/org/apache/solr/cloud/PeerSyncReplicationTest.java:11:
 error: package java.util.stream does not exist
[javac] import java.util.stream.Collectors;
[javac]^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/build.xml:750: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/build.xml:694: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/build.xml:59: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/build.xml:233: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/common-build.xml:534:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/lucene/common-build.xml:841:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/lucene/common-build.xml:855:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/lucene/common-build.xml:1989:
 Compile failed; see the compiler error output for details.

Total time: 34 minutes 19 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
No prior successful build to compare, so performing full copy of artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any




-
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_102) - Build # 17719 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17719/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseParallelGC

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

Error Message:
ObjectTracker found 10 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper, 
MockDirectoryWrapper, TransactionLog, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 10 object(s) that were not 
released!!! [MockDirectoryWrapper, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, MockDirectoryWrapper, TransactionLog, 
MockDirectoryWrapper, MockDirectoryWrapper, TransactionLog, 
MDCAwareThreadPoolExecutor, MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([B79115BFAE76F5A9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousDeletesViaCloudClient

Error Message:
GC overhead limit exceeded

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: GC overhead 
limit exceeded
at 
__randomizedtesting.SeedInfo.seed([B79115BFAE76F5A9:CF7C9E02D8D52A5C]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:755)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:166)
at 
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousDeletes(TestTolerantUpdateProcessorCloud.java:331)
at 
org.apache.solr.cloud.TestTolerantUpdateProcessorCloud.testVariousDeletesViaCloudClient(TestTolerantUpdateProcessorCloud.java:285)
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 

[jira] [Commented] (SOLR-9447) Do not clone SolrInputDocument if update processor chain does not contain custom processors

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9447:


Oh; right I misread the diff.

> Do not clone SolrInputDocument if update processor chain does not contain 
> custom processors
> ---
>
> Key: SOLR-9447
> URL: https://issues.apache.org/jira/browse/SOLR-9447
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9447.patch
>
>
> In SOLR-3215 we started cloning documents before adding them locally and send 
> the cloned copy to replicas. This was done because processors after 
> DistributedUpdateProcessor can affect the docs before they are sent to the 
> replicas.
> However, we can avoid the deep copy if we know for sure that the processors 
> after DUP are one of (LogUpdateProcessor, RunUpdateProcessor, 
> TolerantUpdateProcessor) which definitely do not modify the document. This 
> ensures that the common case is optimized.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9447) Do not clone SolrInputDocument if update processor chain does not contain custom processors

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9447:
-

bq. Say why was it cloning it twice?

It doesn't. We clone only once before adding locally and send that clone to the 
replicas.

> Do not clone SolrInputDocument if update processor chain does not contain 
> custom processors
> ---
>
> Key: SOLR-9447
> URL: https://issues.apache.org/jira/browse/SOLR-9447
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9447.patch
>
>
> In SOLR-3215 we started cloning documents before adding them locally and send 
> the cloned copy to replicas. This was done because processors after 
> DistributedUpdateProcessor can affect the docs before they are sent to the 
> replicas.
> However, we can avoid the deep copy if we know for sure that the processors 
> after DUP are one of (LogUpdateProcessor, RunUpdateProcessor, 
> TolerantUpdateProcessor) which definitely do not modify the document. This 
> ensures that the common case is optimized.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9456) Freebase used in films example is no longer available

[Alexandre Rafalovitch (JIRA)]

Alexandre Rafalovitch created SOLR-9456:
---

 Summary: Freebase used in films example is no longer available
 Key: SOLR-9456
 URL: https://issues.apache.org/jira/browse/SOLR-9456
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: examples
Affects Versions: master (7.0)
Reporter: Alexandre Rafalovitch
Priority: Minor


Solr _films_ example comes with a script to regenerate content from Freebase 
database. That database and API (after it was acquired by Google) [has finally 
been 
shutdown|https://groups.google.com/forum/#!topic/freebase-discuss/WEnyO8f7xOQ]

Do we delete the regeneration script and just leave the original export as is? 
Or do we try switching to the [new Knowledge Graph search from 
Google|https://developers.google.com/knowledge-graph/] ?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/817/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper, SolrCore]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 5 object(s) that were not 
released!!! [MockDirectoryWrapper, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, MockDirectoryWrapper, SolrCore]
at __randomizedtesting.SeedInfo.seed([DB30D9921C7B020D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestCoreDiscovery

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestCoreDiscovery: 
1) Thread[id=2648, name=searcherExecutor-1287-thread-1, state=WAITING, 
group=TGRP-TestCoreDiscovery] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)   
  at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestCoreDiscovery: 
   1) Thread[id=2648, name=searcherExecutor-1287-thread-1, state=WAITING, 
group=TGRP-TestCoreDiscovery]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
  

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_102) - Build # 1622 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1622/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseSerialGC

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:33834/forceleader_test_collection_shard1_replica3]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:33834/forceleader_test_collection_shard1_replica3]
at 
__randomizedtesting.SeedInfo.seed([19CE27B6BFD77780:FF59137686558EE1]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:769)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.assertSendDocFails(ForceLeaderTest.java:315)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:110)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (SOLR-9447) Do not clone SolrInputDocument if update processor chain does not contain custom processors

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-9447:


+1.  Say why was it cloning it twice?

> Do not clone SolrInputDocument if update processor chain does not contain 
> custom processors
> ---
>
> Key: SOLR-9447
> URL: https://issues.apache.org/jira/browse/SOLR-9447
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9447.patch
>
>
> In SOLR-3215 we started cloning documents before adding them locally and send 
> the cloned copy to replicas. This was done because processors after 
> DistributedUpdateProcessor can affect the docs before they are sent to the 
> replicas.
> However, we can avoid the deep copy if we know for sure that the processors 
> after DUP are one of (LogUpdateProcessor, RunUpdateProcessor, 
> TolerantUpdateProcessor) which definitely do not modify the document. This 
> ensures that the common case is optimized.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Word stop list in examples (was Re: Default stop word list)

[Walter Underwood]

I’ve never removed stopwords and I started working on search in 1996 at 
Infoseek.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Aug 29, 2016, at 6:32 PM, Alexandre Rafalovitch  wrote:
> 
> On 30 August 2016 at 08:18, Walter Underwood 
> wrote (on Solr users list):
>> Stop word removal is a hack left over from when we were running search 
>> engines in 64 kbytes of memory.
> 
> If this is a leftover hack, should we start removing it from the
> official examples?
> 
> Or do they still have value even with latest ranking algorithms?
> 
> Regards,
>   Alex.
> 
> Newsletter and resources for Solr beginners and intermediates:
> http://www.solr-start.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Word stop list in examples (was Re: Default stop word list)

[Alexandre Rafalovitch]

On 30 August 2016 at 08:18, Walter Underwood 
wrote (on Solr users list):
> Stop word removal is a hack left over from when we were running search 
> engines in 64 kbytes of memory.

If this is a leftover hack, should we start removing it from the
official examples?

Or do they still have value even with latest ranking algorithms?

Regards,
   Alex.

Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/

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

[JENKINS] Lucene-Solr-SmokeRelease-5.5 - Build # 3 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.5/3/

No tests ran.

Build Log:
[...truncated 39773 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
   [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-5.5/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (18.7 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.5.3-src.tgz...
   [smoker] 28.8 MB in 0.03 sec (844.3 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.3.tgz...
   [smoker] 63.5 MB in 0.07 sec (856.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.3.zip...
   [smoker] 73.9 MB in 0.09 sec (866.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.5.3.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.3.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.3-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 220 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 220 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]   Backcompat testing not required for release 6.0.1 because 
it's not less than 5.5.3
   [smoker]   Backcompat testing not required for release 6.0.0 because 
it's not less than 5.5.3
   [smoker]   Backcompat testing not required for release 6.1.0 because 
it's not less than 5.5.3
   [smoker]   Backcompat testing not required for release 6.2.0 because 
it's not less than 5.5.3
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (159.1 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-5.5.3-src.tgz...
   [smoker] 37.6 MB in 0.08 sec (443.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.3.tgz...
   [smoker] 130.5 MB in 0.16 sec (813.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.3.zip...
   [smoker] 138.4 MB in 0.16 sec (847.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-5.5.3.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-5.5.3.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.3/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-5.5/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.3/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 7 ...
   

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-MacOSX/381/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

1 tests failed.
FAILED:  
org.apache.solr.cloud.DistributedVersionInfoTest.testReplicaVersionHandling

Error Message:
Captured an uncaught exception in thread: Thread[id=4853, name=Thread-858, 
state=RUNNABLE, group=TGRP-DistributedVersionInfoTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=4853, name=Thread-858, state=RUNNABLE, 
group=TGRP-DistributedVersionInfoTest]
at 
__randomizedtesting.SeedInfo.seed([2E9209C4B04AE112:F26BDE3E12312B53]:0)
Caused by: java.lang.IllegalArgumentException: bound must be positive
at __randomizedtesting.SeedInfo.seed([2E9209C4B04AE112]:0)
at java.util.Random.nextInt(Random.java:388)
at 
org.apache.solr.cloud.DistributedVersionInfoTest$3.run(DistributedVersionInfoTest.java:204)




Build Log:
[...truncated 10946 lines...]
   [junit4] Suite: org.apache.solr.cloud.DistributedVersionInfoTest
   [junit4]   2> Creating dataDir: 
/Users/jenkins/workspace/Lucene-Solr-6.x-MacOSX/solr/build/solr-core/test/J0/temp/solr.cloud.DistributedVersionInfoTest_2E9209C4B04AE112-001/init-core-data-001
   [junit4]   2> 932912 INFO  
(SUITE-DistributedVersionInfoTest-seed#[2E9209C4B04AE112]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=https://issues.apache.org/jira/browse/SOLR-5776)
 w/ MAC_OS_X supressed clientAuth
   [junit4]   2> 932918 INFO  
(SUITE-DistributedVersionInfoTest-seed#[2E9209C4B04AE112]-worker) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 932918 INFO  (Thread-824) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 932918 INFO  (Thread-824) [] o.a.s.c.ZkTestServer Starting 
server
   [junit4]   2> 933021 INFO  
(SUITE-DistributedVersionInfoTest-seed#[2E9209C4B04AE112]-worker) [] 
o.a.s.c.ZkTestServer start zk server on port:61042
   [junit4]   2> 933021 INFO  
(SUITE-DistributedVersionInfoTest-seed#[2E9209C4B04AE112]-worker) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 933022 INFO  
(SUITE-DistributedVersionInfoTest-seed#[2E9209C4B04AE112]-worker) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 933044 INFO  (zkCallback-849-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@7e046ae6 
name:ZooKeeperConnection Watcher:127.0.0.1:61042 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 933044 INFO  
(SUITE-DistributedVersionInfoTest-seed#[2E9209C4B04AE112]-worker) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 933044 INFO  
(SUITE-DistributedVersionInfoTest-seed#[2E9209C4B04AE112]-worker) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 933044 INFO  
(SUITE-DistributedVersionInfoTest-seed#[2E9209C4B04AE112]-worker) [] 
o.a.s.c.c.SolrZkClient makePath: /solr/solr.xml
   [junit4]   2> 933050 INFO  (jetty-launcher-848-thread-1) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   [junit4]   2> 933050 INFO  (jetty-launcher-848-thread-2) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   [junit4]   2> 933050 INFO  (jetty-launcher-848-thread-3) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   [junit4]   2> 933058 INFO  (jetty-launcher-848-thread-1) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@765b4edd{/solr,null,AVAILABLE}
   [junit4]   2> 933058 INFO  (jetty-launcher-848-thread-2) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@5d417a5{/solr,null,AVAILABLE}
   [junit4]   2> 933058 INFO  (jetty-launcher-848-thread-3) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@164142c1{/solr,null,AVAILABLE}
   [junit4]   2> 933059 INFO  (jetty-launcher-848-thread-2) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@b168e5b{HTTP/1.1,[http/1.1]}{127.0.0.1:61045}
   [junit4]   2> 933060 INFO  (jetty-launcher-848-thread-2) [] 
o.e.j.s.Server Started @938547ms
   [junit4]   2> 933060 INFO  (jetty-launcher-848-thread-1) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@2905b047{HTTP/1.1,[http/1.1]}{127.0.0.1:61044}
   [junit4]   2> 933060 INFO  (jetty-launcher-848-thread-3) [] 
o.e.j.s.ServerConnector Started 
ServerConnector@4eb33efa{HTTP/1.1,[http/1.1]}{127.0.0.1:61046}
   [junit4]   2> 933060 INFO  (jetty-launcher-848-thread-1) [] 
o.e.j.s.Server Started @938548ms
   [junit4]   2> 933061 INFO  (jetty-launcher-848-thread-3) [] 
o.e.j.s.Server Started @938548ms
   [junit4]   2> 933061 INFO  (jetty-launcher-848-thread-1) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr, 
hostPort=61044}
   [junit4]   2> 933061 INFO  (jetty-launcher-848-thread-3) [

[jira] [Commented] (SOLR-9284) The HDFS BlockDirectoryCache should not let it's keysToRelease or names maps grow indefinitely.

[Ben Manes (JIRA)]

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

Ben Manes commented on SOLR-9284:
-

[~michael.sun]: If you upgrade to Caffeine 2.x then it will take 
[advantage|https://github.com/ben-manes/caffeine/wiki/Efficiency] of frequency 
in addition to recency. A path is available in 
[SOLR-8241|https://issues.apache.org/jira/browse/SOLR-8241], but its been 
stalled due to Shawn not having the bandwidth to drive the changes forward.

> The HDFS BlockDirectoryCache should not let it's keysToRelease or names maps 
> grow indefinitely.
> ---
>
> Key: SOLR-9284
> URL: https://issues.apache.org/jira/browse/SOLR-9284
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: hdfs
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9284.patch, SOLR-9284.patch
>
>
> https://issues.apache.org/jira/browse/SOLR-9284



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9284) The HDFS BlockDirectoryCache should not let it's keysToRelease or names maps grow indefinitely.

[Michael Sun (JIRA)]

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

Michael Sun commented on SOLR-9284:
---

bq. Why does the underlying data in the cache need to be removed? The 
underlying cache locations should simply be reclaimed by the LRU cache 
replacement policy.

Ah, I see your question. I agree that inaccessible data can be removed by the 
LRU logic of block cache eventually. The main gain of my suggestion to help 
cache efficiency. For example, if cached data related to the name removed is 
newly cached, instead of pushing out them, the LRU cache may decide to push out 
some older cached data which may be still useful.

And releasing unused memory early is in general a good practice.

With that said, the name map implementation in patch is better than current 
implementation (using ConcurrentHashMap). I was hoping to make max use of 
memory by removing related items once a name is deleted. But if it's hard to 
achieve, the current patch is good to go IMO.

 

> The HDFS BlockDirectoryCache should not let it's keysToRelease or names maps 
> grow indefinitely.
> ---
>
> Key: SOLR-9284
> URL: https://issues.apache.org/jira/browse/SOLR-9284
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: hdfs
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9284.patch, SOLR-9284.patch
>
>
> https://issues.apache.org/jira/browse/SOLR-9284



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-Tests-6.x - Build # 438 - Still Unstable

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-6.x/438/

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:34039/j_k/t/c8n_1x3_lf_shard1_replica3]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:34039/j_k/t/c8n_1x3_lf_shard1_replica3]
at 
__randomizedtesting.SeedInfo.seed([B6F85D51BA15AFB5:3EAC628B14E9C24D]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:769)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:592)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:578)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:174)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

Re: [JENKINS] Lucene-Solr-Tests-5.5 - Build # 1 - Failure

[Uwe Schindler]

Hi,

Lucene and Solr 5 are still on Java 7, so please fix this.

Thanks,
Uwe

Am 30. August 2016 00:02:35 MESZ, schrieb Apache Jenkins Server 
:
>Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.5/1/
>
>All tests passed
>
>Build Log:
>[...truncated 10526 lines...]
>[javac] Compiling 626 source files to
>/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/build/solr-core/classes/test
>[javac]
>/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/core/src/test/org/apache/solr/cloud/PeerSyncReplicationTest.java:11:
>error: package java.util.stream does not exist
>[javac] import java.util.stream.Collectors;
>[javac]^
>[javac] Note: Some input files use or override a deprecated API.
>[javac] Note: Recompile with -Xlint:deprecation for details.
>[javac] Note: Some input files use unchecked or unsafe operations.
>[javac] Note: Recompile with -Xlint:unchecked for details.
>[javac] 1 error
>
>BUILD FAILED
>/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/build.xml:750:
>The following error occurred while executing this line:
>/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/build.xml:694:
>The following error occurred while executing this line:
>/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/build.xml:59:
>The following error occurred while executing this line:
>/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/build.xml:233:
>The following error occurred while executing this line:
>/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/common-build.xml:534:
>The following error occurred while executing this line:
>/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/lucene/common-build.xml:841:
>The following error occurred while executing this line:
>/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/lucene/common-build.xml:855:
>The following error occurred while executing this line:
>/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/lucene/common-build.xml:1989:
>Compile failed; see the compiler error output for details.
>
>Total time: 33 minutes 55 seconds
>Build step 'Invoke Ant' marked build as failure
>Archiving artifacts
>No prior successful build to compare, so performing full copy of
>artifacts
>Recording test results
>Email was triggered for: Failure - Any
>Sending email for trigger: Failure - Any

--
Uwe Schindler
H.-H.-Meier-Allee 63, 28213 Bremen
http://www.thetaphi.de

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

[JENKINS] Lucene-Solr-Tests-5.5 - Build # 1 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.5/1/

All tests passed

Build Log:
[...truncated 10526 lines...]
[javac] Compiling 626 source files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/build/solr-core/classes/test
[javac] 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/core/src/test/org/apache/solr/cloud/PeerSyncReplicationTest.java:11:
 error: package java.util.stream does not exist
[javac] import java.util.stream.Collectors;
[javac]^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

BUILD FAILED
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/build.xml:750: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/build.xml:694: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/build.xml:59: The 
following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/build.xml:233: 
The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/common-build.xml:534:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/lucene/common-build.xml:841:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/lucene/common-build.xml:855:
 The following error occurred while executing this line:
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/lucene/common-build.xml:1989:
 Compile failed; see the compiler error output for details.

Total time: 33 minutes 55 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
No prior successful build to compare, so performing full copy of artifacts
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any




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

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

[Apache Jenkins Server]

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

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

Error Message:
IOException occured when talking to server at: http://127.0.0.1:54742/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: http://127.0.0.1:54742/solr
at 
__randomizedtesting.SeedInfo.seed([970B0A463DEE020F:AAD3A46A05005C7F]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:622)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:415)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:367)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1280)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:116)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

Re: Release Solr 5.5.3

[Anshum Gupta]

Thanks Uwe.

On Mon, Aug 29, 2016 at 10:47 AM Uwe Schindler  wrote:

> Hi Anshum,
>
>
>
> I will now enable the tests for 5.5 branch on Jenkins!
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Anshum Gupta [mailto:ans...@anshumgupta.net]
> *Sent:* Monday, August 29, 2016 7:01 PM
> *To:* dev@lucene.apache.org
> *Subject:* Re: Release Solr 5.5.3
>
>
>
> With SOLR-9310 out of the door and 6.2.0 out, this is a good time to
> resume the 5.5.3 release. Unless any one has any objections, I'll have an
> RC out on Wednesday.
>
>
>
> -Anshum
>
>
>
> On Mon, Aug 1, 2016 at 12:08 PM Anshum Gupta 
> wrote:
>
> UPDATE: I'm just holding back to see if we can have a solution for
> SOLR-9310 and have # of upgrades for our users. If we don't have any
> clarity by Thursday, I'll start working on the release.
>
>
>
> On Thu, Jul 28, 2016 at 10:22 AM, Anshum Gupta 
> wrote:
>
> I plan on cutting the RC later tonight or tomorrow, unless there are
> objections.
>
>
>
> @Noble: Can you comment on the status of SOLR-9310 (on the JIRA) and if it
> makes sense to hold 5.5.3 ?
>
>
>
> On Thu, Jul 21, 2016 at 5:00 AM, Pushkar Raste 
> wrote:
>
> Can we also get SOLR-9310 in as well
>
> On Jul 20, 2016 6:28 PM, "Erick Erickson"  wrote:
>
> I also would like to get SOLR-7280 in, Noble and I just checked it in
> to that branch as well.
>
> Erick
>
> On Wed, Jul 20, 2016 at 3:02 PM, Anshum Gupta 
> wrote:
> > As Shai mentioned, it is actually about SSL + indexing requests leading
> to
> > unstable state in Solr.
> >
> > How quickly that state is reached is a function of # indexing requests.
> > Thanks for correcting me on that one :-).
> >
> > On Wed, Jul 20, 2016 at 1:35 PM, David Smiley 
> > wrote:
> >>
> >> Okay.  BTW SOLR-9290 isn't "Just" high indexing rates, but it's for
> those
> >> using SSL too -- correct me if I'm wrong.  We don't want to raise alarm
> >> bells too loudly :-)
> >>
> >> On Wed, Jul 20, 2016 at 4:18 PM Anshum Gupta 
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> With SOLR-9290 fixed, I think it calls for a bug fix release as it
> >>> impacts all users with high indexing rates.
> >>>
> >>> If someone else wants to work on the release, I am fine with it else,
> >>> I'll be happy to be the RM and cut an RC a week from now.
> >>>
> >>> --
> >>> Anshum Gupta
> >>
> >> --
> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >> http://www.solrenterprisesearchserver.com
> >
> >
> >
> >
> > --
> > Anshum Gupta
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
>
>
> --
>
> Anshum Gupta
>
>
>
>
>
> --
>
> Anshum Gupta
>
>

Re: Status of Solr Ref Guide for 6.2

[Joel Bernstein]

Hi Varun,

I didn't get a chance yet to document the new streaming expressions. I'm on
vacation this week. I'm planning on updating the docs early next week. If
the docs release before then, people can read about the new streaming
expressions online.

On Aug 29, 2016 10:13 AM, "Varun Thacker"  wrote:

> Hi Everyone,
>
> I think the majority of the changes are in place. I will try to make the
> necessary changes required for SOLR-9187/SOLR-9038/SOLR-9243 later today.
>
> I'm not sure where in https://cwiki.apache.org/
> confluence/display/solr/Using+SolrJ can we document SOLR-9090  . It seems
> like we need to beef up the SolrJ page in general?
>
> Joel, have you been able to add the new features in streaming expressions
> to the ref guide? I can help review it
>
> I will aim to create an RC tomorrow morning in IST hours.
>
> On Thu, Aug 25, 2016 at 12:30 PM, Varun Thacker  wrote:
>
>> Hi Cassandra,
>>
>> I can volunteer to be the RM for the ref guide.
>>
>> We probably won't get to all the TODOs but I think let's start working on
>> it for the next few days.
>>
>> If its fine we can cut an RC on Monday 29th August and then have the ref
>> guide released later in the week.
>>
>> On Thu, Aug 25, 2016 at 11:23 AM, Noble Paul 
>> wrote:
>>
>>> I shall document my changes today itself
>>>
>>> On Thu, Aug 25, 2016 at 3:39 AM, Joel Bernstein 
>>> wrote:
>>> > Hi Cassandra,
>>> >
>>> > I'm also behind on documentation for this release and on vacation next
>>> week.
>>> > But I will attempt to make progress on the docs this week and do some
>>> > documentation while on vacation as well.
>>> >
>>> > Joel Bernstein
>>> > http://joelsolr.blogspot.com/
>>> >
>>> > On Wed, Aug 24, 2016 at 5:49 PM, Cassandra Targett <
>>> casstarg...@gmail.com>
>>> > wrote:
>>> >>
>>> >> The vote for Lucene/Solr 6.2 has passed already, but the release
>>> >> process for the Ref Guide has barely started.
>>> >>
>>> >> I'm in an offsite meeting this week, and next week have another
>>> >> project to focus on. Hoss is offline until early September. So...the 2
>>> >> people who normally do the majority of the work to prepare and publish
>>> >> the Ref Guide aren't available.
>>> >>
>>> >> I've made a rather barebones TODO list, pulled only from the New
>>> >> Features section of CHANGES (other sections should be reviewed also,
>>> >> however. I won't really have time to do much more, and can't be the
>>> >> Release Manager right now.
>>> >>
>>> >> Essentially, if you care to have a 6.2 Ref Guide, I'm asking for
>>> >> volunteers for any/all of the following:
>>> >>
>>> >> - document the changes you committed
>>> >> - help document changes someone else committed
>>> >> - offer to be the RM and shepherd the publication process, which is
>>> >> fully documented
>>> >>
>>> >> If no one steps up to help get it published soon, it's going to be at
>>> >> least a few weeks until I'll have time to devote much time on it.
>>> >>
>>> >> Cassandra
>>> >>
>>> >> -
>>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> -
>>> Noble Paul
>>>
>>> -
>>> 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_102) - Build # 6086 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6086/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseG1GC

3 tests failed.
FAILED:  org.apache.solr.security.BasicAuthIntegrationTest.testBasics

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:50644/solr/testSolrCloudCollection_shard1_replica2

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
occured when talking to server at: 
http://127.0.0.1:50644/solr/testSolrCloudCollection_shard1_replica2
at 
__randomizedtesting.SeedInfo.seed([357B7FD39643C4D2:8A3D1FFAEAD9AA2]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:755)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[JENKINS] Lucene-Solr-SmokeRelease-5.5 - Build # 2 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.5/2/

No tests ran.

Build Log:
[...truncated 40065 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
   [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-5.5/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (18.7 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.5.3-src.tgz...
   [smoker] 28.8 MB in 0.03 sec (866.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.3.tgz...
   [smoker] 63.5 MB in 0.07 sec (866.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.3.zip...
   [smoker] 73.9 MB in 0.09 sec (835.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.5.3.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.3.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.3-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 220 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 220 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]   Backcompat testing not required for release 6.0.1 because 
it's not less than 5.5.3
   [smoker]   Backcompat testing not required for release 6.0.0 because 
it's not less than 5.5.3
   [smoker]   Backcompat testing not required for release 6.1.0 because 
it's not less than 5.5.3
   [smoker]   Backcompat testing not required for release 6.2.0 because 
it's not less than 5.5.3
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (25.1 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-5.5.3-src.tgz...
   [smoker] 37.6 MB in 0.89 sec (42.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.3.tgz...
   [smoker] 130.5 MB in 1.87 sec (70.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.3.zip...
   [smoker] 138.4 MB in 2.68 sec (51.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-5.5.3.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-5.5.3.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.3/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-5.5/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.3/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 7 ...
   [smoker]   

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17716/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseSerialGC

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

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:37379/solr/testSolrCloudCollection_shard1_replica1

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
occured when talking to server at: 
http://127.0.0.1:37379/solr/testSolrCloudCollection_shard1_replica1
at 
__randomizedtesting.SeedInfo.seed([D92FD8A0EF60BDC:304A53A6361855AC]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:755)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Updated] (SOLR-9142) JSON Facet, add hash table method for terms

[David Smiley (JIRA)]

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

David Smiley updated SOLR-9142:
---
Attachment: SOLR_9412_FacetFieldProcessorByHashDV.patch

Updated Patch:
* The default facet method is now held in a package-accessible static field 
that is toggled by a test.  (similar to existing default hash table size).  I 
modified TestJsonFacets to use a feature of RandomizedTesting called 
\@ParameterFactory that allows all of them to be tested for the same test 
class. Admittedly this approach can be a little awkward when reproducing a case 
(particularly in an IDE).  I tend to go about it by edit the file temporarily 
to work around that while debugging a test.
* Currently, it has effectively been the case that if you set method=stream, 
that the sort order is ignored.   I think that's bad; method should be a hint 
(or at the very least resulting in an error). I changed this so that 
method=stream only has an effect when sort=index asc (in addition to the 
existing requirement of having an index). *this is a back-compat break* for 
anyone using method=stream who forgot to explicitly set sort=index asc.  Given 
it's not common to set this and the “experimental” nature of this 
module/feature, I think this change is okay to do in a point-release, provided 
we're explicit in the release notes.
* Made method=enum work as an alias to method=stream. Some day we can add 
support for this distinction — which is when we can do enum faceting that is 
_not_ index ascending
* Some day this will support SortedSetDocValues so I adjusted TermOrdCalc to 
not contain SortedDocValues, and instead take a Function that does the ord to 
BytesRef resolution.  Although annoyingly this is initialized in collectDocs().
* I refactored findTopDocs() between the Array & Hash based impls to a common 
implementation in FacetFieldProcessor.  Java 8 Functional methods proved 
convenient to make this possible.

I think this is now committable.  There is one nocommit to remind myself to 
rename this class after I commit it.  Also, it's tempting to consider breaking 
up some of the portions of this into discrete commits (or separate issue even, 
like for method=stream)... but that would be a pain and so if nobody asks me to 
then I probably won't.

I plan to commit this Wednesday morning.

> JSON Facet, add hash table method for terms
> ---
>
> Key: SOLR-9142
> URL: https://issues.apache.org/jira/browse/SOLR-9142
> Project: Solr
>  Issue Type: Improvement
>  Components: Facet Module
>Reporter: Varun Thacker
>Assignee: David Smiley
> Fix For: 6.3
>
> Attachments: SOLR_9412_FacetFieldProcessorByHashDV.patch, 
> SOLR_9412_FacetFieldProcessorByHashDV.patch, 
> SOLR_9412_FacetFieldProcessorByHashDV.patch
>
>
> I indexed a dataset of 2M docs
> {{top_facet_s}} has a cardinality of 1000 which is the top level facet.
> For nested facets it has two fields {{sub_facet_unique_s}} and 
> {{sub_facet_unique_td}} which are string and double and have cardinality 2M
> The nested query for the double field returns in the 1s mark always. The 
> nested query for the string field takes roughly 10s to execute.
> {code:title=nested string facet|borderStyle=solid}
> q=*:*=0=
>   {
>   "top_facet_s": {
>   "type": "terms",
>   "limit": -1,
>   "field": "top_facet_s",
>   "mincount": 1,
>   "excludeTags": "ANY",
>   "facet": {
>   "sub_facet_unique_s": {
>   "type": "terms",
>   "limit": 1,
>   "field": "sub_facet_unique_s",
>   "mincount": 1
>   }
>   }
>   }
>   }
> {code}
> {code:title=nested double facet|borderStyle=solid}
> q=*:*=0=
>   {
>   "top_facet_s": {
>   "type": "terms",
>   "limit": -1,
>   "field": "top_facet_s",
>   "mincount": 1,
>   "excludeTags": "ANY",
>   "facet": {
>   "sub_facet_unique_s": {
>   "type": "terms",
>   "limit": 1,
>   "field": "sub_facet_unique_td",
>   "mincount": 1
>   }
>   }
>   }
>   }
> {code}
> I tried to dig deeper to understand why are string nested faceting that slow 
> compared to numeric field
> Since the top facet has a cardinality of 1000 we 

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_102) - Build # 1619 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1619/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseG1GC

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:43279/_vs/c8n_1x3_lf_shard1_replica3]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[http://127.0.0.1:43279/_vs/c8n_1x3_lf_shard1_replica3]
at 
__randomizedtesting.SeedInfo.seed([7AB93AB2E8D17591:F2ED0568462D1869]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:769)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:592)
at 
org.apache.solr.cloud.HttpPartitionTest.sendDoc(HttpPartitionTest.java:578)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.testRf3WithLeaderFailover(LeaderFailoverAfterPartitionTest.java:174)
at 
org.apache.solr.cloud.LeaderFailoverAfterPartitionTest.test(LeaderFailoverAfterPartitionTest.java:55)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (SOLR-9455) Deleting a sub-shard in recovery state can mark parent shard as inactive

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9455: Deleting a sub-shard in recovery state can mark parent shard as 
inactive
(cherry picked from commit 2700b95)


> Deleting a sub-shard in recovery state can mark parent shard as inactive
> 
>
> Key: SOLR-9455
> URL: https://issues.apache.org/jira/browse/SOLR-9455
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 4.10.4, 5.5.2, 6.2
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9455.patch
>
>
> When deleting a sub-shard after a failed split operation, the delete shard 
> API unloads the replica cores and then deletes the shard state. But, say 
> there were 2 replicas, if the following sequence occurs:
> # 1st replica got deleted
> # for any reason, the other replica published "state=active"
> Then the overseer can switch slice states and put parent shard as inactive 
> and the sub-shards as active. 
> We should defensively update sub-shard state back to "construction" and only 
> then invoke the unload action on replica cores.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-9455) Deleting a sub-shard in recovery state can mark parent shard as inactive

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-9455.
-
Resolution: Fixed

> Deleting a sub-shard in recovery state can mark parent shard as inactive
> 
>
> Key: SOLR-9455
> URL: https://issues.apache.org/jira/browse/SOLR-9455
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 4.10.4, 5.5.2, 6.2
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9455.patch
>
>
> When deleting a sub-shard after a failed split operation, the delete shard 
> API unloads the replica cores and then deletes the shard state. But, say 
> there were 2 replicas, if the following sequence occurs:
> # 1st replica got deleted
> # for any reason, the other replica published "state=active"
> Then the overseer can switch slice states and put parent shard as inactive 
> and the sub-shards as active. 
> We should defensively update sub-shard state back to "construction" and only 
> then invoke the unload action on replica cores.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9455) Deleting a sub-shard in recovery state can mark parent shard as inactive

[ASF subversion and git services (JIRA)]

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

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

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

SOLR-9455: Deleting a sub-shard in recovery state can mark parent shard as 
inactive


> Deleting a sub-shard in recovery state can mark parent shard as inactive
> 
>
> Key: SOLR-9455
> URL: https://issues.apache.org/jira/browse/SOLR-9455
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 4.10.4, 5.5.2, 6.2
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9455.patch
>
>
> When deleting a sub-shard after a failed split operation, the delete shard 
> API unloads the replica cores and then deletes the shard state. But, say 
> there were 2 replicas, if the following sequence occurs:
> # 1st replica got deleted
> # for any reason, the other replica published "state=active"
> Then the overseer can switch slice states and put parent shard as inactive 
> and the sub-shards as active. 
> We should defensively update sub-shard state back to "construction" and only 
> then invoke the unload action on replica cores.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9455) Deleting a sub-shard in recovery state can mark parent shard as inactive

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9455:

Attachment: SOLR-9455.patch

DeleteShardCmd now updates shard state to "construction" if it was in 
"recovery".

> Deleting a sub-shard in recovery state can mark parent shard as inactive
> 
>
> Key: SOLR-9455
> URL: https://issues.apache.org/jira/browse/SOLR-9455
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 4.10.4, 5.5.2, 6.2
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9455.patch
>
>
> When deleting a sub-shard after a failed split operation, the delete shard 
> API unloads the replica cores and then deletes the shard state. But, say 
> there were 2 replicas, if the following sequence occurs:
> # 1st replica got deleted
> # for any reason, the other replica published "state=active"
> Then the overseer can switch slice states and put parent shard as inactive 
> and the sub-shards as active. 
> We should defensively update sub-shard state back to "construction" and only 
> then invoke the unload action on replica cores.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-8589) Add aliases to the LIST action results in the Collections API

[Mike Drob (JIRA)]

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

Mike Drob updated SOLR-8589:

Attachment: SOLR-8589.patch

[~janhoy], thanks for the review. A couple questions based on your feedback -

bq. There are a few string constants that could be moved to 
{{CollectionAdminParams}}
If we do this, do you think there is going to be confusion between when to use 
{{CollectionAdminParams.COLLECTION}} and {{CollectionAdminParams.COLLECTIONS}}? 
That's the only potential downside that I can see.

bq. Also, I think we should return aliases by default.
I don't know if there is anybody out there that has some kind of monitoring 
script set up to parse the result of {{LIST}}, and in general I try to be super 
conservative about changing APIs. Maybe we default to returning them in 7.0, 
and not returning them in 6.x? That sounds like a fair compromise to me.

bq. This patch should also update related LIST tests in 
{{CollectionsAPISolrJTest}}.
Sure. I'm wary of scope creep, but it also makes sense to expand 
{{CollectionAdminRequest.List}} capabilities to allow toggling for collection 
and aliases as well.

bq. Also it should update JavaDoc comments where they say that the LIST command 
lists collections to include that it also lists aliases...
I think I got all of these, let me know if I missed some.

> Add aliases to the LIST action results in the Collections API
> -
>
> Key: SOLR-8589
> URL: https://issues.apache.org/jira/browse/SOLR-8589
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.4.1
>Reporter: Shawn Heisey
>Assignee: Shawn Heisey
>Priority: Minor
> Attachments: SOLR-8589.patch, SOLR-8589.patch, SOLR-8589.patch, 
> SOLR-8589.patch, solr-8589-new-list-details-aliases.png
>
>
> Although it is possible to get a list of SolrCloud aliases vi an HTTP API, it 
> is not available as a typical query response, I believe it is only available 
> via the http API for zookeeper.
> The results from the LIST action in the Collections API is well-situated to 
> handle this. The current results are contained in a "collections" node, we 
> can simply add an "aliases" node if there are any aliases defined.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-SmokeRelease-5.5 - Build # 1 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-5.5/1/

No tests ran.

Build Log:
[...truncated 34 lines...]



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

RE: Release Solr 5.5.3

[Uwe Schindler]

Hi Anshum,

 

I will now enable the tests for 5.5 branch on Jenkins!

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Anshum Gupta [mailto:ans...@anshumgupta.net] 
Sent: Monday, August 29, 2016 7:01 PM
To: dev@lucene.apache.org
Subject: Re: Release Solr 5.5.3

 

With SOLR-9310 out of the door and 6.2.0 out, this is a good time to resume the 
5.5.3 release. Unless any one has any objections, I'll have an RC out on 
Wednesday.

 

-Anshum

 

On Mon, Aug 1, 2016 at 12:08 PM Anshum Gupta  > wrote:

UPDATE: I'm just holding back to see if we can have a solution for SOLR-9310 
and have # of upgrades for our users. If we don't have any clarity by Thursday, 
I'll start working on the release.

 

On Thu, Jul 28, 2016 at 10:22 AM, Anshum Gupta  > wrote:

I plan on cutting the RC later tonight or tomorrow, unless there are objections.

 

@Noble: Can you comment on the status of SOLR-9310 (on the JIRA) and if it 
makes sense to hold 5.5.3 ?

 

On Thu, Jul 21, 2016 at 5:00 AM, Pushkar Raste  > wrote:

Can we also get SOLR-9310 in as well

On Jul 20, 2016 6:28 PM, "Erick Erickson"  > wrote:

I also would like to get SOLR-7280 in, Noble and I just checked it in
to that branch as well.

Erick

On Wed, Jul 20, 2016 at 3:02 PM, Anshum Gupta  > wrote:
> As Shai mentioned, it is actually about SSL + indexing requests leading to
> unstable state in Solr.
>
> How quickly that state is reached is a function of # indexing requests.
> Thanks for correcting me on that one :-).
>
> On Wed, Jul 20, 2016 at 1:35 PM, David Smiley   >
> wrote:
>>
>> Okay.  BTW SOLR-9290 isn't "Just" high indexing rates, but it's for those
>> using SSL too -- correct me if I'm wrong.  We don't want to raise alarm
>> bells too loudly :-)
>>
>> On Wed, Jul 20, 2016 at 4:18 PM Anshum Gupta >  >
>> wrote:
>>>
>>> Hi,
>>>
>>> With SOLR-9290 fixed, I think it calls for a bug fix release as it
>>> impacts all users with high indexing rates.
>>>
>>> If someone else wants to work on the release, I am fine with it else,
>>> I'll be happy to be the RM and cut an RC a week from now.
>>>
>>> --
>>> Anshum Gupta
>>
>> --
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>
>
>
>
> --
> Anshum Gupta

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





 

-- 

Anshum Gupta





 

-- 

Anshum Gupta

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17715/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseG1GC

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

Error Message:
ObjectTracker found 3 object(s) that were not released!!! [NRTCachingDirectory, 
NRTCachingDirectory, NRTCachingDirectory]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 3 object(s) that were not 
released!!! [NRTCachingDirectory, NRTCachingDirectory, NRTCachingDirectory]
at __randomizedtesting.SeedInfo.seed([863A93BEA0CEDBAE]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

Error Message:
Could not get expected value  'X val' for path 'x' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"/mf_/w", "path":"/test1", 
"httpMethod":"GET"},   
"class":"org.apache.solr.core.BlobStoreTestRequestHandler",   "x":null},  from 
server:  null

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val' for path 'x' 
full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"/mf_/w",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":null},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([863A93BEA0CEDBAE:5E77BEE957137E0E]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:535)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:232)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 

Re: Release Solr 5.5.3

[Anshum Gupta]

With SOLR-9310 out of the door and 6.2.0 out, this is a good time to resume
the 5.5.3 release. Unless any one has any objections, I'll have an RC out
on Wednesday.

-Anshum

On Mon, Aug 1, 2016 at 12:08 PM Anshum Gupta  wrote:

> UPDATE: I'm just holding back to see if we can have a solution for
> SOLR-9310 and have # of upgrades for our users. If we don't have any
> clarity by Thursday, I'll start working on the release.
>
> On Thu, Jul 28, 2016 at 10:22 AM, Anshum Gupta 
> wrote:
>
>> I plan on cutting the RC later tonight or tomorrow, unless there are
>> objections.
>>
>> @Noble: Can you comment on the status of SOLR-9310 (on the JIRA) and if
>> it makes sense to hold 5.5.3 ?
>>
>> On Thu, Jul 21, 2016 at 5:00 AM, Pushkar Raste 
>> wrote:
>>
>>> Can we also get SOLR-9310 in as well
>>> On Jul 20, 2016 6:28 PM, "Erick Erickson" 
>>> wrote:
>>>
 I also would like to get SOLR-7280 in, Noble and I just checked it in
 to that branch as well.

 Erick

 On Wed, Jul 20, 2016 at 3:02 PM, Anshum Gupta 
 wrote:
 > As Shai mentioned, it is actually about SSL + indexing requests
 leading to
 > unstable state in Solr.
 >
 > How quickly that state is reached is a function of # indexing
 requests.
 > Thanks for correcting me on that one :-).
 >
 > On Wed, Jul 20, 2016 at 1:35 PM, David Smiley <
 david.w.smi...@gmail.com>
 > wrote:
 >>
 >> Okay.  BTW SOLR-9290 isn't "Just" high indexing rates, but it's for
 those
 >> using SSL too -- correct me if I'm wrong.  We don't want to raise
 alarm
 >> bells too loudly :-)
 >>
 >> On Wed, Jul 20, 2016 at 4:18 PM Anshum Gupta 
 >> wrote:
 >>>
 >>> Hi,
 >>>
 >>> With SOLR-9290 fixed, I think it calls for a bug fix release as it
 >>> impacts all users with high indexing rates.
 >>>
 >>> If someone else wants to work on the release, I am fine with it
 else,
 >>> I'll be happy to be the RM and cut an RC a week from now.
 >>>
 >>> --
 >>> Anshum Gupta
 >>
 >> --
 >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
 >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
 >> http://www.solrenterprisesearchserver.com
 >
 >
 >
 >
 > --
 > Anshum Gupta

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


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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/816/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
ObjectTracker found 5 object(s) that were not released!!! 
[MDCAwareThreadPoolExecutor, MockDirectoryWrapper, SolrCore, 
MockDirectoryWrapper, MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 5 object(s) that were not 
released!!! [MDCAwareThreadPoolExecutor, MockDirectoryWrapper, SolrCore, 
MockDirectoryWrapper, MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([1B0F6C24D9A50137]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestLazyCores

Error Message:
1 thread leaked from SUITE scope at org.apache.solr.core.TestLazyCores: 1) 
Thread[id=14413, name=searcherExecutor-5428-thread-1, state=WAITING, 
group=TGRP-TestLazyCores] at sun.misc.Unsafe.park(Native Method)
 at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.core.TestLazyCores: 
   1) Thread[id=14413, name=searcherExecutor-5428-thread-1, state=WAITING, 
group=TGRP-TestLazyCores]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 

[jira] [Commented] (SOLR-9439) Shard split clean up logic for older failed splits is faulty

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9439:
-

Thanks Steve, that is very helpful. I'm seeing related failures in SOLR-9438 so 
this might have a clue.

> Shard split clean up logic for older failed splits is faulty
> 
>
> Key: SOLR-9439
> URL: https://issues.apache.org/jira/browse/SOLR-9439
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 4.10.4, 5.5.2, 6.1
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.3
>
> Attachments: Lucene-Solr-tests-master.8015.log.gz, SOLR-9439.patch, 
> SOLR-9439.patch, SOLR-9439.patch
>
>
> In case a split finds that previous sub-shards exist in construction or 
> recovery state. it tries to clean them up by invoking deleteshard API. 
> However, the clean up logic tries to invoke deleteshard on the same 
> sub-shards as many times as the requested number of sub-ranges. Such repeat 
> calls to deleteshard fail and therefore fail the entire shard split operation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9455) Deleting a sub-shard in recovery state can mark parent shard as inactive

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-9455:
---

 Summary: Deleting a sub-shard in recovery state can mark parent 
shard as inactive
 Key: SOLR-9455
 URL: https://issues.apache.org/jira/browse/SOLR-9455
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud
Affects Versions: 6.2, 5.5.2, 4.10.4
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
 Fix For: master (7.0), 6.3


When deleting a sub-shard after a failed split operation, the delete shard API 
unloads the replica cores and then deletes the shard state. But, say there were 
2 replicas, if the following sequence occurs:
# 1st replica got deleted
# for any reason, the other replica published "state=active"

Then the overseer can switch slice states and put parent shard as inactive and 
the sub-shards as active. 

We should defensively update sub-shard state back to "construction" and only 
then invoke the unload action on replica cores.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-Linux (64bit/jdk1.8.0_102) - Build # 1618 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1618/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
ObjectTracker found 4 object(s) that were not released!!! 
[MockDirectoryWrapper, SolrCore, MockDirectoryWrapper, MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 4 object(s) that were not 
released!!! [MockDirectoryWrapper, SolrCore, MockDirectoryWrapper, 
MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([BD79689EDF0D9636]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:258)
at sun.reflect.GeneratedMethodAccessor18.invoke(Unknown Source)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11490 lines...]
   [junit4] Suite: org.apache.solr.util.TestSolrCLIRunExample
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.util.TestSolrCLIRunExample_BD79689EDF0D9636-001/init-core-data-001
   [junit4]   2> 1034414 INFO  
(SUITE-TestSolrCLIRunExample-seed#[BD79689EDF0D9636]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=https://issues.apache.org/jira/browse/SOLR-5776)
   [junit4]   2> 1034415 INFO  
(TEST-TestSolrCLIRunExample.testSchemalessExample-seed#[BD79689EDF0D9636]) [
] o.a.s.SolrTestCaseJ4 ###Starting testSchemalessExample
   [junit4]   2> 1034415 INFO  
(TEST-TestSolrCLIRunExample.testSchemalessExample-seed#[BD79689EDF0D9636]) [
] o.a.s.u.TestSolrCLIRunExample Selected port 42814 to start schemaless example 
Solr instance on ...
   [junit4]   2> 1034452 INFO  (Thread-1114) [] o.e.j.s.Server 
jetty-9.3.8.v20160314
   [junit4]   2> 1034454 INFO  (Thread-1114) [] o.e.j.s.h.ContextHandler 
Started o.e.j.s.ServletContextHandler@1e0700be{/solr,null,AVAILABLE}
   [junit4]   2> 1034456 INFO  (Thread-1114) [] o.e.j.s.ServerConnector 
Started ServerConnector@9360b4b{HTTP/1.1,[http/1.1]}{127.0.0.1:42814}
   [junit4]   2> 1034456 INFO  (Thread-1114) [] o.e.j.s.Server Started 
@1036117ms
   [junit4]   2> 1034456 INFO  (Thread-1114) [] o.a.s.c.s.e.JettySolrRunner 
Jetty properties: {hostContext=/solr, hostPort=42814}
   [junit4]   2> 1034456 INFO  (Thread-1114) [] o.a.s.s.SolrDispatchFilter 
SolrDispatchFilter.init(): sun.misc.Launcher$AppClassLoader@73d16e93
   [junit4]   2> 1034456 INFO  (Thread-1114) [] o.a.s.c.SolrResourceLoader 
new SolrResourceLoader for directory: 

[jira] [Updated] (SOLR-9439) Shard split clean up logic for older failed splits is faulty

[Steve Rowe (JIRA)]

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

Steve Rowe updated SOLR-9439:
-
Attachment: Lucene-Solr-tests-master.8015.log.gz

My Jenkins has seen {{TestShardSplit.testSplitAfterFailedSplit()}} (new test 
committed under this issue) fail 4 times (links below).  I tried a couple of 
the repro lines and they did not reproduce for me (on the same machine where my 
Jenkins runs).

One of the failures - I'm also attaching a gzipped excerpt from the build log 
for this run ({{Lucene-Solr-tests-master.8015.log.gz}}):

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=ShardSplitTest 
-Dtests.method=testSplitAfterFailedSplit -Dtests.seed=F8621B62A68543EC 
-Dtests.slow=true -Dtests.locale=mt-MT -Dtests.timezone=America/Costa_Rica 
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
   [junit4] FAILURE 34.6s J10 | ShardSplitTest.testSplitAfterFailedSplit <<<
   [junit4]> Throwable #1: java.lang.AssertionError: Shard split did not 
succeed after a previous failed split attempt left sub-shards in construction 
state
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([F8621B62A68543EC:12F88CD9AF00E66]:0)
   [junit4]>at 
org.apache.solr.cloud.ShardSplitTest.testSplitAfterFailedSplit(ShardSplitTest.java:138)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
{noformat}

Links to all 4 failing runs (in case more logs would be helpful):

http://jenkins.sarowe.net/job/Lucene-Solr-tests-6.x/2194/
http://jenkins.sarowe.net/job/Lucene-Solr-tests-master/8015/
http://jenkins.sarowe.net/job/Lucene-Solr-tests-6.x/2207/
http://jenkins.sarowe.net/job/Lucene-Solr-tests-6.x/2214/


> Shard split clean up logic for older failed splits is faulty
> 
>
> Key: SOLR-9439
> URL: https://issues.apache.org/jira/browse/SOLR-9439
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 4.10.4, 5.5.2, 6.1
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.3
>
> Attachments: Lucene-Solr-tests-master.8015.log.gz, SOLR-9439.patch, 
> SOLR-9439.patch, SOLR-9439.patch
>
>
> In case a split finds that previous sub-shards exist in construction or 
> recovery state. it tries to clean them up by invoking deleteshard API. 
> However, the clean up logic tries to invoke deleteshard on the same 
> sub-shards as many times as the requested number of sub-ranges. Such repeat 
> calls to deleteshard fail and therefore fail the entire shard split operation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-9310) PeerSync fails on a node restart due to IndexFingerPrint mismatch

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-9310.
--
Resolution: Fixed

> PeerSync fails on a node restart due to IndexFingerPrint mismatch
> -
>
> Key: SOLR-9310
> URL: https://issues.apache.org/jira/browse/SOLR-9310
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Pushkar Raste
>Assignee: Noble Paul
> Fix For: trunk, 6.3
>
> Attachments: PeerSync_3Node_Setup.jpg, PeerSync_Experiment.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, SOLR-9310.patch, 
> SOLR-9310.patch, SOLR-9310.patch, SOLR-9310_3ReplicaTest.patch, 
> SOLR-9310_5x.patch, SOLR-9310_final.patch
>
>
> I found that Peer Sync fails if a node restarts and documents were indexed 
> while node was down. IndexFingerPrint check fails after recovering node 
> applies updates. 
> This happens only when node restarts and not if node just misses updates due 
> reason other than it being down.
> Please check attached patch for the test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-9453) NullPointerException on PeerSync recovery

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reassigned SOLR-9453:
---

Assignee: Shalin Shekhar Mangar

> NullPointerException on PeerSync recovery
> -
>
> Key: SOLR-9453
> URL: https://issues.apache.org/jira/browse/SOLR-9453
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Michael Braun
>Assignee: Shalin Shekhar Mangar
>
> Just updated to 6.2.0 (previously using 6.1.0) and we restarted the cluster a 
> few times - for one replica trying to sync on a shard, we got this on a 
> bootup and it's seemingly stuck. Cluster has 96 shards, 2 replicas per shard. 
> Shard 51 is where this issue occurred for us. It looks like the replica 
> eventually recovers, but we probably shouldn't see a NullPointerException.
> {code}
> java.lang.NullPointerException
>   at org.apache.solr.update.PeerSync.handleUpdates(PeerSync.java:605)
>   at org.apache.solr.update.PeerSync.handleResponse(PeerSync.java:344)
>   at org.apache.solr.update.PeerSync.sync(PeerSync.java:257)
>   at 
> org.apache.solr.handler.component.RealTimeGetComponent.processSync(RealTimeGetComponent.java:658)
>   at 
> org.apache.solr.handler.component.RealTimeGetComponent.processGetVersions(RealTimeGetComponent.java:623)
>   at 
> org.apache.solr.handler.component.RealTimeGetComponent.process(RealTimeGetComponent.java:117)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:154)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2089)
>   at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:459)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
>   at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
>   at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
>   at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
>   at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
>   at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
>   at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
>   at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
>   at org.eclipse.jetty.server.Server.handle(Server.java:518)
>   at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>   at 
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
>   at 
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
>   at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
>   at 
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
>   at 
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
>   at 
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> Before it in the log , pasting some relevant lines with full IPs redacted:
> {code}ERROR - 2016-08-29 15:10:28.940; org.apache.solr.common.SolrException; 
> Error while trying to recover. 
> core=ourcollection_shard51_replica2:org.apache.solr.common.SolrException: No 
> registered leader was found after waiting for 4000ms , collection: 
> ourcollection slice: shard51
> at 
> org.apache.solr.common.cloud.ZkStateReader.getLeaderRetry(ZkStateReader.java:746)

[jira] [Commented] (SOLR-8029) Modernize and standardize Solr APIs

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8029:
--



> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: 6.0
>
> Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch, 
> SOLR-8029.patch
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 4 types of requests in the new API 
> * {{/v2//*}} : Hit a collection directly or manage 
> collections/shards/replicas 
> * {{/v2//*}} : Hit a core directly or manage cores 
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection 
> or core. e.g: security, overseer ops etc
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8029) Modernize and standardize Solr APIs

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-8029:
--



> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: 6.0
>
> Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch, 
> SOLR-8029.patch
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 4 types of requests in the new API 
> * {{/v2//*}} : Hit a collection directly or manage 
> collections/shards/replicas 
> * {{/v2//*}} : Hit a core directly or manage cores 
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection 
> or core. e.g: security, overseer ops etc
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9454) Reduce object allocation during indexing because of JavaBinCodec.writeExternString()

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9454:

Attachment: HashMapNode_Allocations.png
HashMapNodeArray_Allocations.png

Screenshots from the java flight recorder showing allocations for HashMap$Node 
and HashMap$Node[].

> Reduce object allocation during indexing because of 
> JavaBinCodec.writeExternString()
> 
>
> Key: SOLR-9454
> URL: https://issues.apache.org/jira/browse/SOLR-9454
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, update
>Reporter: Shalin Shekhar Mangar
>  Labels: difficulty-medium, impact-medium
> Fix For: master (7.0), 6.3
>
> Attachments: HashMapNodeArray_Allocations.png, 
> HashMapNode_Allocations.png, SOLR-9454.patch
>
>
> I setup Java Flight Recorder to profile indexing a 650MB JSON file using 
> bin/post on 2 shard, 2 replica setup. It shows that the 
> JavaBinCodec.writeExternString(String) method contributes a lot of garbage 
> during indexing in SolrCloud. More specifically, it contributes ~1GB of 
> HashMap$Node objects and ~450MB of HashMap$Node[] objects.
> Most of this allocation is because every request is serialized using a new 
> instance of JavaBinUpdateRequestCodec which internally allocates a new 
> HashMap for storing the extern strings.
> We should explore keeping a global extern string map to eliminate redundant 
> allocations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9454) Reduce object allocation during indexing because of JavaBinCodec.writeExternString()

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9454:
--

Here is an implementation which uses a global string cache and use a local  
int[] instead of a map

> Reduce object allocation during indexing because of 
> JavaBinCodec.writeExternString()
> 
>
> Key: SOLR-9454
> URL: https://issues.apache.org/jira/browse/SOLR-9454
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, update
>Reporter: Shalin Shekhar Mangar
>  Labels: difficulty-medium, impact-medium
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9454.patch
>
>
> I setup Java Flight Recorder to profile indexing a 650MB JSON file using 
> bin/post on 2 shard, 2 replica setup. It shows that the 
> JavaBinCodec.writeExternString(String) method contributes a lot of garbage 
> during indexing in SolrCloud. More specifically, it contributes ~1GB of 
> HashMap$Node objects and ~450MB of HashMap$Node[] objects.
> Most of this allocation is because every request is serialized using a new 
> instance of JavaBinUpdateRequestCodec which internally allocates a new 
> HashMap for storing the extern strings.
> We should explore keeping a global extern string map to eliminate redundant 
> allocations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9454) Reduce object allocation during indexing because of JavaBinCodec.writeExternString()

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-9454:
-
Attachment: SOLR-9454.patch

> Reduce object allocation during indexing because of 
> JavaBinCodec.writeExternString()
> 
>
> Key: SOLR-9454
> URL: https://issues.apache.org/jira/browse/SOLR-9454
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud, update
>Reporter: Shalin Shekhar Mangar
>  Labels: difficulty-medium, impact-medium
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9454.patch
>
>
> I setup Java Flight Recorder to profile indexing a 650MB JSON file using 
> bin/post on 2 shard, 2 replica setup. It shows that the 
> JavaBinCodec.writeExternString(String) method contributes a lot of garbage 
> during indexing in SolrCloud. More specifically, it contributes ~1GB of 
> HashMap$Node objects and ~450MB of HashMap$Node[] objects.
> Most of this allocation is because every request is serialized using a new 
> instance of JavaBinUpdateRequestCodec which internally allocates a new 
> HashMap for storing the extern strings.
> We should explore keeping a global extern string map to eliminate redundant 
> allocations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9438) Shard split can lose data

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9438:

Attachment: SOLR-9438.patch

Patch with the test updated to master.

> Shard split can lose data
> -
>
> Key: SOLR-9438
> URL: https://issues.apache.org/jira/browse/SOLR-9438
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 4.10.4, 5.5.2, 6.1
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
>  Labels: difficulty-medium, impact-high
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9438.patch, SOLR-9438.patch
>
>
> Solr’s shard split can lose documents if the parent/sub-shard leader is 
> killed (or crashes) between the time that the new sub-shard replica is 
> created and before it recovers. In such a case the slice has already been set 
> to ‘recovery’ state, the sub-shard replica comes up, finds that no other 
> replica is up, waits until the leader vote wait time and then proceeds to 
> become the leader as well as publish itself as active. Once that happens the 
> overseer seeing that all replicas of the sub-shard are now ‘active’, sets the 
> parent slice as ‘inactive’ and the new sub-shard as ‘active’.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Closed] (SOLR-9000) New Admin UI hardcodes /solr context and fails when it changes

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch closed SOLR-9000.
---
Resolution: Won't Fix

Latest Solr is a blackbox with a fixed URL (/solr). Any other configuration 
should be achieved through external means (e.g. proxy).

> New Admin UI hardcodes /solr context and fails when it changes
> --
>
> Key: SOLR-9000
> URL: https://issues.apache.org/jira/browse/SOLR-9000
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
> Attachments: solr-wrong-urls-screenshot.png
>
>
> If the solr context is changed from */solr* to any other value (e.g. 
> */solr6_0/instance/solr1*), the new Admin UI does not work as it still tries 
> to load resources from */solr* prefix:
> The context is changed by editing server/contexts/solr-jetty-context.xml:
>  bq.  default="/solr6_0/instance/solr1"/>
> and by changing redirect in the server/etc/jetty.xml
> {quote}
> 
>   ^/$
>   /solr6_0/instance/solr1/
>  
> {quote}
> This affects New Admin UI, as well as both links between the UIs.
> The old Admin UI seems to work with the changed context, once it is manually 
> loaded.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9454) Reduce object allocation during indexing because of JavaBinCodec.writeExternString()

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-9454:
---

 Summary: Reduce object allocation during indexing because of 
JavaBinCodec.writeExternString()
 Key: SOLR-9454
 URL: https://issues.apache.org/jira/browse/SOLR-9454
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: SolrCloud, update
Reporter: Shalin Shekhar Mangar
 Fix For: master (7.0), 6.3


I setup Java Flight Recorder to profile indexing a 650MB JSON file using 
bin/post on 2 shard, 2 replica setup. It shows that the 
JavaBinCodec.writeExternString(String) method contributes a lot of garbage 
during indexing in SolrCloud. More specifically, it contributes ~1GB of 
HashMap$Node objects and ~450MB of HashMap$Node[] objects.

Most of this allocation is because every request is serialized using a new 
instance of JavaBinUpdateRequestCodec which internally allocates a new HashMap 
for storing the extern strings.

We should explore keeping a global extern string map to eliminate redundant 
allocations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9453) NullPointerException on PeerSync recovery

[Michael Braun (JIRA)]

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

Michael Braun updated SOLR-9453:

Description: 
Just updated to 6.2.0 (previously using 6.1.0) and we restarted the cluster a 
few times - for one replica trying to sync on a shard, we got this on a bootup 
and it's seemingly stuck. Cluster has 96 shards, 2 replicas per shard. Shard 51 
is where this issue occurred for us. It looks like the replica eventually 
recovers, but we probably shouldn't see a NullPointerException.

{code}
java.lang.NullPointerException
at org.apache.solr.update.PeerSync.handleUpdates(PeerSync.java:605)
at org.apache.solr.update.PeerSync.handleResponse(PeerSync.java:344)
at org.apache.solr.update.PeerSync.sync(PeerSync.java:257)
at 
org.apache.solr.handler.component.RealTimeGetComponent.processSync(RealTimeGetComponent.java:658)
at 
org.apache.solr.handler.component.RealTimeGetComponent.processGetVersions(RealTimeGetComponent.java:623)
at 
org.apache.solr.handler.component.RealTimeGetComponent.process(RealTimeGetComponent.java:117)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:154)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2089)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:459)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:518)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
at java.lang.Thread.run(Thread.java:745)
{code}

Before it in the log , pasting some relevant lines with full IPs redacted:

{code}ERROR - 2016-08-29 15:10:28.940; org.apache.solr.common.SolrException; 
Error while trying to recover. 
core=ourcollection_shard51_replica2:org.apache.solr.common.SolrException: No 
registered leader was found after waiting for 4000ms , collection: 
ourcollection slice: shard51
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderRetry(ZkStateReader.java:746)
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderRetry(ZkStateReader.java:732)
at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:305)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:221)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 

[jira] [Updated] (SOLR-9453) NullPointerException on PeerSync recovery

[Michael Braun (JIRA)]

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

Michael Braun updated SOLR-9453:

Description: 
Just updated to 6.2.0 (previously using 6.1.0) and we restarted the cluster a 
few times - for one replica trying to sync on a shard, we got this on a bootup 
and it's seemingly stuck. Cluster has 96 shards, 2 replicas per shard. Shard 51 
is where this issue occurred for us.

{code}
java.lang.NullPointerException
at org.apache.solr.update.PeerSync.handleUpdates(PeerSync.java:605)
at org.apache.solr.update.PeerSync.handleResponse(PeerSync.java:344)
at org.apache.solr.update.PeerSync.sync(PeerSync.java:257)
at 
org.apache.solr.handler.component.RealTimeGetComponent.processSync(RealTimeGetComponent.java:658)
at 
org.apache.solr.handler.component.RealTimeGetComponent.processGetVersions(RealTimeGetComponent.java:623)
at 
org.apache.solr.handler.component.RealTimeGetComponent.process(RealTimeGetComponent.java:117)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:154)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2089)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:459)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:518)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
at java.lang.Thread.run(Thread.java:745)
{code}

Before it in the log , pasting some relevant lines with full IPs redacted:

{code}ERROR - 2016-08-29 15:10:28.940; org.apache.solr.common.SolrException; 
Error while trying to recover. 
core=ourcollection_shard51_replica2:org.apache.solr.common.SolrException: No 
registered leader was found after waiting for 4000ms , collection: 
ourcollection slice: shard51
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderRetry(ZkStateReader.java:746)
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderRetry(ZkStateReader.java:732)
at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:305)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:221)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:229)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 

[jira] [Created] (SOLR-9453) NullPointerException on PeerSync recovery

[Michael Braun (JIRA)]

Michael Braun created SOLR-9453:
---

 Summary: NullPointerException on PeerSync recovery
 Key: SOLR-9453
 URL: https://issues.apache.org/jira/browse/SOLR-9453
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.2
Reporter: Michael Braun


Just updated to 6.2.0 (previously using 6.1.0) and we restarted the cluster a 
few times - for one replica trying to sync on a shard, we got this on a bootup 
and it's seemingly stuck. Cluster has 96 shards, 2 replicas per shard.

{code}
java.lang.NullPointerException
at org.apache.solr.update.PeerSync.handleUpdates(PeerSync.java:605)
at org.apache.solr.update.PeerSync.handleResponse(PeerSync.java:344)
at org.apache.solr.update.PeerSync.sync(PeerSync.java:257)
at 
org.apache.solr.handler.component.RealTimeGetComponent.processSync(RealTimeGetComponent.java:658)
at 
org.apache.solr.handler.component.RealTimeGetComponent.processGetVersions(RealTimeGetComponent.java:623)
at 
org.apache.solr.handler.component.RealTimeGetComponent.process(RealTimeGetComponent.java:117)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:154)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2089)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:652)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:459)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
at org.eclipse.jetty.server.Server.handle(Server.java:518)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:244)
at 
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at 
org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:246)
at 
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:156)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
at java.lang.Thread.run(Thread.java:745)
{code}

Before it in the log , pasting some relevant lines with full IPs redacted:

{code}ERROR - 2016-08-29 15:10:28.940; org.apache.solr.common.SolrException; 
Error while trying to recover. 
core=ourcollection_shard51_replica2:org.apache.solr.common.SolrException: No 
registered leader was found after waiting for 4000ms , collection: 
ourcollection slice: shard51
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderRetry(ZkStateReader.java:746)
at 
org.apache.solr.common.cloud.ZkStateReader.getLeaderRetry(ZkStateReader.java:732)
at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:305)
at org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:221)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 

[jira] [Updated] (SOLR-5944) Support updates of numeric DocValues

[Ishan Chattopadhyaya (JIRA)]

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

Ishan Chattopadhyaya updated SOLR-5944:
---
Attachment: SOLR-5944.patch

New patch.
# Fixed the DBQ by updated value, as per Yonik's suggestion. (Thus working 
around LUCENE-7344)
# With reordered DBQs, [~shalinmangar] pointed out a scenario whereby a 
document that needs in-place update cannot be "resurrected" if it has been 
deleted by an out of order DBQ. TODO: I'm working on the fix and the test for 
this.
# TODO: Fix a few nocommits in this patch.
# TODO: In-line reply to Hoss' suggestions.

> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Shalin Shekhar Mangar
> Attachments: DUP.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.62D328FA1DEA57FD.fail2.txt, 
> hoss.62D328FA1DEA57FD.fail3.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17714/
Java: 64bit/jdk1.8.0_102 -XX:+UseCompressedOops -XX:+UseSerialGC

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

Error Message:
IOException occured when talking to server at: 
http://127.0.0.1:42680/solr/testSolrCloudCollection_shard1_replica1

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: IOException 
occured when talking to server at: 
http://127.0.0.1:42680/solr/testSolrCloudCollection_shard1_replica1
at 
__randomizedtesting.SeedInfo.seed([6971DE905E644878:54A970BC668A1608]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:755)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.doExtraTests(BasicAuthIntegrationTest.java:193)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testCollectionCreateSearchDelete(TestMiniSolrCloudClusterBase.java:196)
at 
org.apache.solr.cloud.TestMiniSolrCloudClusterBase.testBasics(TestMiniSolrCloudClusterBase.java:79)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[JIRA]

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

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

I have a version of the patch which instead depends on {{lucene.javadoc.url}} 
and simply replaces /core/ => /solr/. That avoids modifying Jenkins jobs, and 
keeps the patch slightly smaller. Do you see any downsides to this approach?

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[JIRA]

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

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

bq. It would be good to also refer to lucene.javadoc.url

Do you mean to add a clickable link to the Lucene docs, or to use 
lucene.javadoc.url as source for generating solr.javadoc.url?

bq. The release manager now needs to build the docs separately, because of this 
I suggest to really build the online-only version in a separate folder

Will do... New patch coming up

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-9389) HDFS Transaction logs stay open for writes which leaks Xceivers

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-9389.
---
   Resolution: Fixed
Fix Version/s: 6.3
   master (7.0)

Thanks Tim!

> HDFS Transaction logs stay open for writes which leaks Xceivers
> ---
>
> Key: SOLR-9389
> URL: https://issues.apache.org/jira/browse/SOLR-9389
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs
>Affects Versions: 6.1, master (7.0)
>Reporter: Tim Owen
>Assignee: Mark Miller
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9389.patch
>
>
> The HdfsTransactionLog implementation keeps a Hadoop FSDataOutputStream open 
> for its whole lifetime, which consumes two threads on the HDFS data node 
> server (dataXceiver and packetresponder) even once the Solr tlog has finished 
> being written to.
> This means for a cluster with many indexes on HDFS, the number of Xceivers 
> can keep growing and eventually hit the limit of 4096 on the data nodes. It's 
> especially likely for indexes that have low write rates, because Solr keeps 
> enough tlogs around to contain 100 documents (up to a limit of 10 tlogs). 
> There's also the issue that attempting to write to a finished tlog would be a 
> major bug, so closing it for writes helps catch that.
> Our cluster during testing had 100+ collections with 100 shards each, spread 
> across 8 boxes (each running 4 solr nodes and 1 hdfs data node) and with 3x 
> replication for the tlog files, this meant we hit the xceiver limit fairly 
> easily and had to use the attached patch to ensure tlogs were closed for 
> writes once finished.
> The patch introduces an extra lifecycle state for the tlog, so it can be 
> closed for writes and free up the HDFS resources, while still being available 
> for reading. I've tried to make it as unobtrusive as I could, but there's 
> probably a better way. I have not changed the behaviour of the local disk 
> tlog implementation, because it only consumes a file descriptor regardless of 
> read or write.
> nb We have decided not to use Solr-on-HDFS now, we're using local disk (for 
> various reasons). So I don't have a HDFS cluster to do further testing on 
> this, I'm just contributing the patch which worked for us.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: Status of Solr Ref Guide for 6.2

[Varun Thacker]

Hi Everyone,

I think the majority of the changes are in place. I will try to make the
necessary changes required for SOLR-9187/SOLR-9038/SOLR-9243 later today.

I'm not sure where in
https://cwiki.apache.org/confluence/display/solr/Using+SolrJ can we
document SOLR-9090  . It seems like we need to beef up the SolrJ page in
general?

Joel, have you been able to add the new features in streaming expressions
to the ref guide? I can help review it

I will aim to create an RC tomorrow morning in IST hours.

On Thu, Aug 25, 2016 at 12:30 PM, Varun Thacker  wrote:

> Hi Cassandra,
>
> I can volunteer to be the RM for the ref guide.
>
> We probably won't get to all the TODOs but I think let's start working on
> it for the next few days.
>
> If its fine we can cut an RC on Monday 29th August and then have the ref
> guide released later in the week.
>
> On Thu, Aug 25, 2016 at 11:23 AM, Noble Paul  wrote:
>
>> I shall document my changes today itself
>>
>> On Thu, Aug 25, 2016 at 3:39 AM, Joel Bernstein 
>> wrote:
>> > Hi Cassandra,
>> >
>> > I'm also behind on documentation for this release and on vacation next
>> week.
>> > But I will attempt to make progress on the docs this week and do some
>> > documentation while on vacation as well.
>> >
>> > Joel Bernstein
>> > http://joelsolr.blogspot.com/
>> >
>> > On Wed, Aug 24, 2016 at 5:49 PM, Cassandra Targett <
>> casstarg...@gmail.com>
>> > wrote:
>> >>
>> >> The vote for Lucene/Solr 6.2 has passed already, but the release
>> >> process for the Ref Guide has barely started.
>> >>
>> >> I'm in an offsite meeting this week, and next week have another
>> >> project to focus on. Hoss is offline until early September. So...the 2
>> >> people who normally do the majority of the work to prepare and publish
>> >> the Ref Guide aren't available.
>> >>
>> >> I've made a rather barebones TODO list, pulled only from the New
>> >> Features section of CHANGES (other sections should be reviewed also,
>> >> however. I won't really have time to do much more, and can't be the
>> >> Release Manager right now.
>> >>
>> >> Essentially, if you care to have a 6.2 Ref Guide, I'm asking for
>> >> volunteers for any/all of the following:
>> >>
>> >> - document the changes you committed
>> >> - help document changes someone else committed
>> >> - offer to be the RM and shepherd the publication process, which is
>> >> fully documented
>> >>
>> >> If no one steps up to help get it published soon, it's going to be at
>> >> least a few weeks until I'll have time to devote much time on it.
>> >>
>> >> Cassandra
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>> >
>>
>>
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>

[jira] [Commented] (SOLR-9090) solrj CloudSolrClient: add directUpdatesToLeadersOnly support

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-9090:
-

Sorry for being late here but I think directUpdatesToLeadersOnly should be the 
default. There is little advantage in sending requests to other nodes in the 
hope that even if we didn't see a leader, someone else might.

> solrj CloudSolrClient: add directUpdatesToLeadersOnly support
> -
>
> Key: SOLR-9090
> URL: https://issues.apache.org/jira/browse/SOLR-9090
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrJ
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9090.patch, SOLR-9090.patch
>
>
> solrj CloudSolrClient: add directUpdatesToLeadersOnly support
> (Marvin Justice, Christine Poerschke)
> Proposed change:
> * Addition of a {{directUpdatesToLeadersOnly}} flag to allow clients to 
> request that direct updates be sent to the shard leaders and only to the 
> shard leaders.
> Motivation:
> * In a scenario where there is temporarily no shard leader the update request 
> will 'fail fast' allowing the client to handle retry logic.
> Related tickets:
> * SOLR-6312 concerns the ((currently) no longer used) {{updatesToLeaders}} 
> flag. The updatesToLeaders logic however appears to be slightly different 
> from the proposed directUpdatesToLeadersOnly logic: {{updatesToLeaders}} 
> indicates that sending to leaders is preferred but not mandatory whereas 
> {{directUpdatesToLeadersOnly}} mandates sending to leaders only.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9450:
-

bq. On my laptop, build time for binary distro was reduced from 7 minutes 28 
seconds to 4 minutes 58 seconds 

That does not help the release manager, because he now has to build Solr two 
times, otherwise he can't publish the docs.

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-9450:
-

In general, this looks good, but might need some imrpovements:
- On Jenkins the nightly builds (Solr-Artifacts) have a real version number 
(with datecode), so the generated link in the Groovy code might be wrong. Like 
for the lucene.javadoc.url the Jenkins jobs need to be changed to define 
{{$solr.javadoc.url}} in the ant properties to show something useful. It 
already does this for Solr jobs, to refer to Lucene links correctly.
- It would be good to also refer to lucene.javadoc.url
- It does not build the documentation of the package at all, but if you have 
them in checkout before, you may need to ant clean. This is not documented.  
Maybe build the "online only" documentation in a separate folder. This would 
also allow Jenkins task to publish them online, too
- The release manager now needs to build the docs separately, because of this I 
suggest to really build the online-only version in a separate folder (see 
prvious item). This allows to publish the Javadocs after building artifacts, 
although they are not part of the tarball.

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9389) HDFS Transaction logs stay open for writes which leaks Xceivers

[ASF subversion and git services (JIRA)]

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

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

Commit aaee4c820556ca0f62d51f939e907864e4262a32 in lucene-solr's branch 
refs/heads/branch_6x from markrmiller
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=aaee4c8 ]

SOLR-9389: HDFS Transaction logs stay open for writes which leaks Xceivers.


> HDFS Transaction logs stay open for writes which leaks Xceivers
> ---
>
> Key: SOLR-9389
> URL: https://issues.apache.org/jira/browse/SOLR-9389
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Hadoop Integration, hdfs
>Affects Versions: 6.1, master (7.0)
>Reporter: Tim Owen
>Assignee: Mark Miller
> Attachments: SOLR-9389.patch
>
>
> The HdfsTransactionLog implementation keeps a Hadoop FSDataOutputStream open 
> for its whole lifetime, which consumes two threads on the HDFS data node 
> server (dataXceiver and packetresponder) even once the Solr tlog has finished 
> being written to.
> This means for a cluster with many indexes on HDFS, the number of Xceivers 
> can keep growing and eventually hit the limit of 4096 on the data nodes. It's 
> especially likely for indexes that have low write rates, because Solr keeps 
> enough tlogs around to contain 100 documents (up to a limit of 10 tlogs). 
> There's also the issue that attempting to write to a finished tlog would be a 
> major bug, so closing it for writes helps catch that.
> Our cluster during testing had 100+ collections with 100 shards each, spread 
> across 8 boxes (each running 4 solr nodes and 1 hdfs data node) and with 3x 
> replication for the tlog files, this meant we hit the xceiver limit fairly 
> easily and had to use the attached patch to ensure tlogs were closed for 
> writes once finished.
> The patch introduces an extra lifecycle state for the tlog, so it can be 
> closed for writes and free up the HDFS resources, while still being available 
> for reading. I've tried to make it as unobtrusive as I could, but there's 
> probably a better way. I have not changed the behaviour of the local disk 
> tlog implementation, because it only consumes a file descriptor regardless of 
> read or write.
> nb We have decided not to use Solr-on-HDFS now, we're using local disk (for 
> various reasons). So I don't have a HDFS cluster to do further testing on 
> this, I'm just contributing the patch which worked for us.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[JIRA]

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

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

I don't think we need to provide a downloadable archive with the docs. Instead 
we can tell people to download the source distro and run {{ant documentation}} 
locally, no?

The solr-7.0.0 tgz artefact size is 148979967 before the patch and 143403689 
after, thus saving (only) 5,3Mb.
On my laptop, build time for binary distro was reduced from {{7 minutes 28 
seconds}} to {{4 minutes 58 seconds}} :-)


> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9452) JsonRecordReader should not deep copy before handler.handle()

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9452:

Attachment: SOLR-9452.patch

Fix which moves the deep copy to the getAllRecords() method. Also, I removed 
the getDeepCopy method inside JsonRecordReader.Node and switched to using 
Utils.getDeepCopy method.

> JsonRecordReader should not deep copy before handler.handle()
> -
>
> Key: SOLR-9452
> URL: https://issues.apache.org/jira/browse/SOLR-9452
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Shalin Shekhar Mangar
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9452.patch
>
>
> JsonRecordReader does a deep copy of the document map before calling 
> handler.handle() method but it is not required because it is consumed in the 
> same thread and not stored anywhere. The only place which needs a deep copy 
> is the JsonRecordReader#getAllRecords method (used mostly for testing). Any 
> such method can perform deep copy itself so that the common case is not 
> penalized.
> This will save allocation of one copy of the map for each document.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
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 # 3512 - Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
No live SolrServers available to handle this 
request:[http://127.0.0.1:59580/forceleader_test_collection_shard1_replica2]

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: No live 
SolrServers available to handle this 
request:[http://127.0.0.1:59580/forceleader_test_collection_shard1_replica2]
at 
__randomizedtesting.SeedInfo.seed([A833A8C555D503CE:4EA49C056C57FAAF]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:755)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:131)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Updated] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[JIRA]

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

Jan Høydahl updated SOLR-9450:
--
Attachment: SOLR-9450.patch

Attaching patch.
This patch defines a new build target {{documentation-online}} which gets 
called only for {{create-package}}. It builds a single index.html file in 
{{docs/}}, which contains a link to online docs folder:

{code}
Follow this link to view online documentation for Solr x.y.z
{code}

In case of local SNAPSHOT build, the text in that HTML file is instead:

{code}
No online documentation available for SNAPSHOT versions. Run ant documentation 
to build docs locally.
{code}

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-9450.patch
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9065) Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-9065:


[~romseygeek], can you consult me about distributed search testing? There is 
{{BaseDistributedSearchTestCase}} subclass in SOLR-5725.patch. It doesn't need 
Zookeeper, certainly, it's quite beneficial from _ "comparing things against 
(single core) control collections"_. Is it worth to move it to 
{{SolrCloudTestCase}}?? 

> Migrate solrj tests from AbstractDistribZkTestBase to SolrCloudTestCase
> ---
>
> Key: SOLR-9065
> URL: https://issues.apache.org/jira/browse/SOLR-9065
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0, 6.1
>Reporter: Alan Woodward
>Assignee: Alan Woodward
> Attachments: SOLR-9065.patch
>
>
> AbstractDistribZkTestBase sets up collections using the legacy core-based 
> system, and does a lot of comparing things against control collections that 
> the SolrJ tests really don't require.  We should migrate these tests to using 
> SolrCloudTestCase instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-5725) Efficient facets without counts for enum method

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-5725:
---
Attachment: SOLR-5725.patch

new patch with better distributed search coverage.
however it's worth to be considered for moving to {{SolrCloudTestCase}} like 
it's suggested at SOLR-9065. TBC

> Efficient facets without counts for enum method
> ---
>
> Key: SOLR-5725
> URL: https://issues.apache.org/jira/browse/SOLR-5725
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Alexey Kozhemiakin
>Assignee: Mikhail Khludnev
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-5725-5x.patch, SOLR-5725-master.patch, 
> SOLR-5725.patch, SOLR-5725.patch, SOLR-5725.patch
>
>
> Shot version:
> This improves performance for facet.method=enum when it's enough to know that 
> facet count>0, for example when you it's when you dynamically populate 
> filters on search form. New method checks if two bitsets intersect instead of 
> counting intersection size.
> Long version:
> We have a dataset containing hundreds of millions of records, we facet by 
> dozens of fields with many of facet-excludes and have relatively small number 
> of unique values in fields, around thousands.
> Before executing search, users work with "advanced search" form, our  goal is 
> to populate dozens of filters with values which are applicable with other 
> selected values, so basically this is a use case for facets with mincount=1, 
> but without need in actual counts.
> Our performance tests showed that facet.method=enum works much better than 
> fc\fcs, probably due to a specific ratio of "docset"\"unique terms count". 
> For example average execution of query time with method fc=1500ms, fcs=2600ms 
> and with enum=280ms. Profiling indicated the majority time for enum was spent 
> on intersecting docsets.
> Hers's a patch that introduces an extension to facet calculation for 
> method=enum. Basically it uses docSetA.intersects(docSetB) instead of 
> docSetA. intersectionSize (docSetB).
> As a result we were able to reduce our average query time from 280ms to 60ms.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8029) Modernize and standardize Solr APIs

[Varun Thacker (JIRA)]

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

Varun Thacker commented on SOLR-8029:
-

Hi Noble,

One suggestion regarding a param in the ADDREPLICA Collections API

We currently have a param called "node" which basically can be used to tell 
Solr which node to create the replica. 
In the cluster state , the param gets stored as "node_name" . So for a user who 
calls {{CLUSTERSTATUS}} he now sees the value as "node_name" . It would be 
nicer if ADDREPLICA command renamed the param from "node" to "node_name" just 
to make it more consistent I believe.

Similarly Add Role / Delete node takes "node" as well. 

> Modernize and standardize Solr APIs
> ---
>
> Key: SOLR-8029
> URL: https://issues.apache.org/jira/browse/SOLR-8029
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Noble Paul
>Assignee: Noble Paul
>  Labels: API, EaseOfUse
> Fix For: 6.0
>
> Attachments: SOLR-8029.patch, SOLR-8029.patch, SOLR-8029.patch, 
> SOLR-8029.patch
>
>
> Solr APIs have organically evolved and they are sometimes inconsistent with 
> each other or not in sync with the widely followed conventions of HTTP 
> protocol. Trying to make incremental changes to make them modern is like 
> applying band-aid. So, we have done a complete rethink of what the APIs 
> should be. The most notable aspects of the API are as follows:
> The new set of APIs will be placed under a new path {{/solr2}}. The legacy 
> APIs will continue to work under the {{/solr}} path as they used to and they 
> will be eventually deprecated.
> There are 4 types of requests in the new API 
> * {{/v2//*}} : Hit a collection directly or manage 
> collections/shards/replicas 
> * {{/v2//*}} : Hit a core directly or manage cores 
> * {{/v2/cluster/*}} : Operations on cluster not pertaining to any collection 
> or core. e.g: security, overseer ops etc
> This will be released as part of a major release. Check the link given below 
> for the full specification.  Your comments are welcome
> [Solr API version 2 Specification | http://bit.ly/1JYsBMQ]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9188) BlockUnknown property makes inter-node communication impossible

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-9188:
--

Barking up the wrong tree. The tests were failing in master even before the fix

> BlockUnknown property makes inter-node communication impossible
> ---
>
> Key: SOLR-9188
> URL: https://issues.apache.org/jira/browse/SOLR-9188
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 6.0
>Reporter: Piotr Tempes
>Assignee: Noble Paul
>Priority: Critical
>  Labels: BasicAuth, Security
> Fix For: master (7.0), 6.3
>
> Attachments: solr9188-errorlog.txt
>
>
> When I setup my solr cloud without blockUnknown property it works as 
> expected. When I want to block non authenticated requests I get following 
> stacktrace during startup (see attached file).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-9188) BlockUnknown property makes inter-node communication impossible

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-9188.
--
   Resolution: Fixed
Fix Version/s: 6.3
   master (7.0)

> BlockUnknown property makes inter-node communication impossible
> ---
>
> Key: SOLR-9188
> URL: https://issues.apache.org/jira/browse/SOLR-9188
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 6.0
>Reporter: Piotr Tempes
>Assignee: Noble Paul
>Priority: Critical
>  Labels: BasicAuth, Security
> Fix For: master (7.0), 6.3
>
> Attachments: solr9188-errorlog.txt
>
>
> When I setup my solr cloud without blockUnknown property it works as 
> expected. When I want to block non authenticated requests I get following 
> stacktrace during startup (see attached file).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9188) BlockUnknown property makes inter-node communication impossible

[ASF subversion and git services (JIRA)]

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

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

Commit b3526c568ca03b7eb2d043a21373689413fa2e7f in lucene-solr's branch 
refs/heads/branch_6x from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b3526c5 ]

SOLR-9188: blockUnknown property makes inter-node communication impossible


> BlockUnknown property makes inter-node communication impossible
> ---
>
> Key: SOLR-9188
> URL: https://issues.apache.org/jira/browse/SOLR-9188
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 6.0
>Reporter: Piotr Tempes
>Assignee: Noble Paul
>Priority: Critical
>  Labels: BasicAuth, Security
> Attachments: solr9188-errorlog.txt
>
>
> When I setup my solr cloud without blockUnknown property it works as 
> expected. When I want to block non authenticated requests I get following 
> stacktrace during startup (see attached file).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9000) New Admin UI hardcodes /solr context and fails when it changes

[JIRA]

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

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

It is a regression if we have official documentation stating that Solr supports 
multiple installs per app server, but we have explicitly removed any such docs 
as far as I know.
It is not Solr's responsibility to provide Proxy functionality. I have 
successfully used nginx to proxy multiple Solrs on another public facing URL, 
but those use cases are outside the boundaries of Solr in my opinion.

> New Admin UI hardcodes /solr context and fails when it changes
> --
>
> Key: SOLR-9000
> URL: https://issues.apache.org/jira/browse/SOLR-9000
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
> Attachments: solr-wrong-urls-screenshot.png
>
>
> If the solr context is changed from */solr* to any other value (e.g. 
> */solr6_0/instance/solr1*), the new Admin UI does not work as it still tries 
> to load resources from */solr* prefix:
> The context is changed by editing server/contexts/solr-jetty-context.xml:
>  bq.  default="/solr6_0/instance/solr1"/>
> and by changing redirect in the server/etc/jetty.xml
> {quote}
> 
>   ^/$
>   /solr6_0/instance/solr1/
>  
> {quote}
> This affects New Admin UI, as well as both links between the UIs.
> The old Admin UI seems to work with the changed context, once it is manually 
> loaded.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9000) New Admin UI hardcodes /solr context and fails when it changes

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch commented on SOLR-9000:
-

I think the main use-case I can think of is having multiple Solr instances 
behind a proxy on different path. E.g. /solr62, /solr61. Being able to have 
each one accessible with its own Admin UI would be easy if the new UI support 
the path like the old UI does. But if it does not, it is nearly impossible (URL 
rewriting by proxy is messy).

An alternative, is to put each instance on its own port, but that could have 
issues with not all ports being open.

But the main issue is whether this is a regression. If we treat it as one, it 
should probably be fixed (I can look into what that takes). If we treat it as 
non-regression, the reasons to implement it are limited. 

> New Admin UI hardcodes /solr context and fails when it changes
> --
>
> Key: SOLR-9000
> URL: https://issues.apache.org/jira/browse/SOLR-9000
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
> Attachments: solr-wrong-urls-screenshot.png
>
>
> If the solr context is changed from */solr* to any other value (e.g. 
> */solr6_0/instance/solr1*), the new Admin UI does not work as it still tries 
> to load resources from */solr* prefix:
> The context is changed by editing server/contexts/solr-jetty-context.xml:
>  bq.  default="/solr6_0/instance/solr1"/>
> and by changing redirect in the server/etc/jetty.xml
> {quote}
> 
>   ^/$
>   /solr6_0/instance/solr1/
>  
> {quote}
> This affects New Admin UI, as well as both links between the UIs.
> The old Admin UI seems to work with the changed context, once it is manually 
> loaded.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9452) JsonRecordReader should not deep copy before handler.handle()

[Shalin Shekhar Mangar (JIRA)]

Shalin Shekhar Mangar created SOLR-9452:
---

 Summary: JsonRecordReader should not deep copy before 
handler.handle()
 Key: SOLR-9452
 URL: https://issues.apache.org/jira/browse/SOLR-9452
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
  Components: update
Reporter: Shalin Shekhar Mangar
 Fix For: master (7.0), 6.3


JsonRecordReader does a deep copy of the document map before calling 
handler.handle() method but it is not required because it is consumed in the 
same thread and not stored anywhere. The only place which needs a deep copy is 
the JsonRecordReader#getAllRecords method (used mostly for testing). Any such 
method can perform deep copy itself so that the common case is not penalized.

This will save allocation of one copy of the map for each document.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9451) Make clusterstatus command logging less verbose

[Varun Thacker (JIRA)]

Varun Thacker created SOLR-9451:
---

 Summary: Make clusterstatus command logging less verbose
 Key: SOLR-9451
 URL: https://issues.apache.org/jira/browse/SOLR-9451
 Project: Solr
  Issue Type: Improvement
  Security Level: Public (Default Security Level. Issues are Public)
Reporter: Varun Thacker
Priority: Minor


Today when we run a cluster status call, the logs get filled up with 
ZkStateReader messages like this. If a user has a lot of collections this can 
get quite verbose and likely not useful.

{code}
INFO  - 2016-08-29 12:10:55.533; [   ] 
org.apache.solr.handler.admin.CollectionsHandler; Invoked Collection Action 
:clusterstatus with params json.nl=map=true=CLUSTERSTATUS=json 
and sendToOCPQueue=true
INFO  - 2016-08-29 12:10:55.535; [   ] 
org.apache.solr.common.cloud.ZkStateReader; Load collection config from: 
[/collections/test1]
INFO  - 2016-08-29 12:10:55.535; [   ] 
org.apache.solr.common.cloud.ZkStateReader; path=[/collections/test1] 
[configName]=[test1] specified config exists in ZooKeeper
INFO  - 2016-08-29 12:10:55.536; [   ] 
org.apache.solr.common.cloud.ZkStateReader; Load collection config from: 
[/collections/gettingstarted]
INFO  - 2016-08-29 12:10:55.537; [   ] 
org.apache.solr.common.cloud.ZkStateReader; path=[/collections/gettingstarted] 
[configName]=[gettingstarted] specified config exists in ZooKeeper
..
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-8757) Swap + unload does not work

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-8757:


please provide a patch with testcase. 

> Swap + unload does not work
> ---
>
> Key: SOLR-8757
> URL: https://issues.apache.org/jira/browse/SOLR-8757
> Project: Solr
>  Issue Type: Bug
>  Components: multicore
>Affects Versions: 5.5
>Reporter: Fabrizio Fortino
>
> I have created a Solr CoreAdminHandler extension with the goal to swap two 
> cores and remove the old one.
> My code looks like this:
> SolrCore core = coreContainer.create("newcore", coreProps)
> coreContainer.swap("newcore", "livecore")
> // the old livecore is now newcore, so unload it and remove all the related 
> dirs
> coreContainer.unload("newcore", true, true, true)
> After the last statement get executed the Solr log starts printing the 
> following messages forever
> 61424 INFO (pool-1-thread-1) [ x:newcore] o.a.s.c.SolrCore Core newcore is 
> not yet closed, waiting 100 ms before checking again.
> I tried to call the close() method on the SolrCore instance before and after 
> the unload but the result is the same.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9000) New Admin UI hardcodes /solr context and fails when it changes

[JIRA]

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

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

-1 to support this now that Solr is a standalone app and being a servlet is 
just an impl. detail.
Lots of Solr config relies on the fact that there is only one Solr in the 
container, such as the use of Java properties for {{solr.solr.home}}, 
{{solr.data.dir}} etc.
We should close this with "Won't fix". 

I will probably be easier to achieve embedding Solr in various ways once we 
re-package Solr and get rid of the Jetty coupling we have today.

> New Admin UI hardcodes /solr context and fails when it changes
> --
>
> Key: SOLR-9000
> URL: https://issues.apache.org/jira/browse/SOLR-9000
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
> Attachments: solr-wrong-urls-screenshot.png
>
>
> If the solr context is changed from */solr* to any other value (e.g. 
> */solr6_0/instance/solr1*), the new Admin UI does not work as it still tries 
> to load resources from */solr* prefix:
> The context is changed by editing server/contexts/solr-jetty-context.xml:
>  bq.  default="/solr6_0/instance/solr1"/>
> and by changing redirect in the server/etc/jetty.xml
> {quote}
> 
>   ^/$
>   /solr6_0/instance/solr1/
>  
> {quote}
> This affects New Admin UI, as well as both links between the UIs.
> The old Admin UI seems to work with the changed context, once it is manually 
> loaded.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_102) - Build # 421 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/421/
Java: 32bit/jdk1.8.0_102 -client -XX:+UseG1GC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.schema.TestManagedSchemaAPI

Error Message:
ObjectTracker found 3 object(s) that were not released!!! 
[MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 3 object(s) that were not 
released!!! [MockDirectoryWrapper, MockDirectoryWrapper, MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([C28001A3B47E77DF]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:258)
at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
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:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11275 lines...]
   [junit4] Suite: org.apache.solr.schema.TestManagedSchemaAPI
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_C28001A3B47E77DF-001\init-core-data-001
   [junit4]   2> 906929 INFO  
(SUITE-TestManagedSchemaAPI-seed#[C28001A3B47E77DF]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 906931 INFO  
(SUITE-TestManagedSchemaAPI-seed#[C28001A3B47E77DF]-worker) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 906931 INFO  (Thread-1552) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 906931 INFO  (Thread-1552) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 907032 INFO  
(SUITE-TestManagedSchemaAPI-seed#[C28001A3B47E77DF]-worker) [] 
o.a.s.c.ZkTestServer start zk server on port:55600
   [junit4]   2> 907032 INFO  
(SUITE-TestManagedSchemaAPI-seed#[C28001A3B47E77DF]-worker) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 907033 INFO  
(SUITE-TestManagedSchemaAPI-seed#[C28001A3B47E77DF]-worker) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 907038 INFO  (zkCallback-1003-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@b62de2 name:ZooKeeperConnection 
Watcher:127.0.0.1:55600 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 907038 INFO  
(SUITE-TestManagedSchemaAPI-seed#[C28001A3B47E77DF]-worker) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 907038 INFO  

[jira] [Assigned] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[JIRA]

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

Jan Høydahl reassigned SOLR-9450:
-

Assignee: Jan Høydahl

> Link to online Javadocs instead of distributing with binary download
> 
>
> Key: SOLR-9450
> URL: https://issues.apache.org/jira/browse/SOLR-9450
> Project: Solr
>  Issue Type: Sub-task
>  Components: Build
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: master (7.0), 6.3
>
>
> Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} 
> in the binary download with a link to the online JavaDocs. The build should 
> make sure to generate a link to the correct version. I believe this is the 
> correct tamplate: http://lucene.apache.org/solr/6_2_0/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9000) New Admin UI hardcodes /solr context and fails when it changes

[Upayavira (JIRA)]

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

Upayavira commented on SOLR-9000:
-

See here: https://wiki.apache.org/solr/WhyNoWar

Solr does not support being used as a war in a different servlet container. It 
may work, it may not.

Therefore, as started above, the additional complexity required to support 
multiple roots has not been added to the UI.

If someone took the time to make it work, i wouldn't object, but i would be 
concerned if that led to people thinking Solr would work as a war. If it isn't 
this preventing it, it may soon be something else. And that something else 
could occur at any time.

I'd suggest you rearchitect your system to use the inbuilt jetty, as you will 
be following Standard practice at that point. If that requires two JVMs, so be 
it.

> New Admin UI hardcodes /solr context and fails when it changes
> --
>
> Key: SOLR-9000
> URL: https://issues.apache.org/jira/browse/SOLR-9000
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
> Attachments: solr-wrong-urls-screenshot.png
>
>
> If the solr context is changed from */solr* to any other value (e.g. 
> */solr6_0/instance/solr1*), the new Admin UI does not work as it still tries 
> to load resources from */solr* prefix:
> The context is changed by editing server/contexts/solr-jetty-context.xml:
>  bq.  default="/solr6_0/instance/solr1"/>
> and by changing redirect in the server/etc/jetty.xml
> {quote}
> 
>   ^/$
>   /solr6_0/instance/solr1/
>  
> {quote}
> This affects New Admin UI, as well as both links between the UIs.
> The old Admin UI seems to work with the changed context, once it is manually 
> loaded.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6806) Reduce the size of the main Solr binary download

[JIRA]

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

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

Opened sub task SOLR-9450 for this

> Reduce the size of the main Solr binary download
> 
>
> Key: SOLR-6806
> URL: https://issues.apache.org/jira/browse/SOLR-6806
> Project: Solr
>  Issue Type: Task
>  Components: Build
>Affects Versions: 5.0
>Reporter: Shawn Heisey
> Attachments: solr-zip-docs-extracted.png, solr-zip-extract-graph.png
>
>
> There has been a lot of recent discussion about how large the Solr download 
> is, and how to reduce its size.  The last release (4.10.2) weighs in at 143MB 
> for the tar and 149MB for the zip.
> Most users do not need the full download.  They may never need contrib 
> features, or they may only need one or two, with DIH being the most likely 
> choice.  They could likely get by with a download that's less than 40 MB.
> Our primary competition has a 29MB zip download for the release that's 
> current right now, and not too long ago, that was about 20MB.  I didn't look 
> very deep, but any additional features that might be available for download 
> were not immediately apparent on their website.  I'm sure they exist, but I 
> would guess that most users never need those features, so most users never 
> even see them.
> Solr, by contrast, has everything included ... a "kitchen sink" approach. 
> Once you get past the long download time and fire up the example, you're 
> presented with configs that include features you're likely to never use.
> Although this offers maximum flexibility, I think it also serves to cause 
> confusion in a new user.
> A much better option would be to create a core download that includes only a 
> minimum set of features, probably just the war, the example servlet 
> container, and an example config that only uses the functionality present in 
> the war.  We can create additional downloads that offer additional 
> functionality and configs ... DIH would be a very small addon that would 
> likely be downloaded frequently.
> SOLR-5103 describes a plugin infrastructure which would make it very easy to 
> offer a small core download and then let the user download additional 
> functionality using scripts or the UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-9450) Link to online Javadocs instead of distributing with binary download

[JIRA]

Jan Høydahl created SOLR-9450:
-

 Summary: Link to online Javadocs instead of distributing with 
binary download
 Key: SOLR-9450
 URL: https://issues.apache.org/jira/browse/SOLR-9450
 Project: Solr
  Issue Type: Sub-task
  Components: Build
Reporter: Jan Høydahl
 Fix For: master (7.0), 6.3


Spinoff from SOLR-6806. This sub task will replace the contents of {{docs}} in 
the binary download with a link to the online JavaDocs. The build should make 
sure to generate a link to the correct version. I believe this is the correct 
tamplate: http://lucene.apache.org/solr/6_2_0/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6085/
Java: 64bit/jdk1.8.0_102 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:59535/forceleader_test_collection_shard1_replica1]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:59535/forceleader_test_collection_shard1_replica1]
at 
__randomizedtesting.SeedInfo.seed([534B6471BC1CA2F1:B5DC50B1859E5B90]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:769)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.assertSendDocFails(ForceLeaderTest.java:315)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:110)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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 

[jira] [Commented] (SOLR-9000) New Admin UI hardcodes /solr context and fails when it changes

[JIRA]

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

Johan Sjöberg commented on SOLR-9000:
-

To try and be helpful and clear up some confusion

Is contextPath a user configurable property? Yes and in the above example it is 
imposed by the application server as part of the servlet standard. The issue is 
that Solr doesn't respect it. 
Is there a need? Yes, for instance to deploy multiple Solr instances to the 
same application server. 
Can javascript be contextPath aware? Yes. Any server-side html rendering 
mechanism should allow this. Consider a simple JSP snippet with 

[jira] [Updated] (LUCENE-7429) DelegatingAnalyzerWrapper should delegate normalization too

[Adrien Grand (JIRA)]

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

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

New patch that also makes sure to use the same attribute factory as the wrapped 
analyzer and adds more tests. I think it's ready.

> DelegatingAnalyzerWrapper should delegate normalization too
> ---
>
> Key: LUCENE-7429
> URL: https://issues.apache.org/jira/browse/LUCENE-7429
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.2
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7355.patch, LUCENE-7429.patch
>
>
> This is something that I overlooked in LUCENE-7355: 
> (Delegating)AnalyzerWrapper uses the default implementation of 
> initReaderForNormalization and normalize, meaning that by default the 
> normalization is a no-op. It should delegate to the wrapped analyzer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Solaris/362/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
Document mismatch on target after sync expected:<2> but was:<14082>

Stack Trace:
java.lang.AssertionError: Document mismatch on target after sync 
expected:<2> but was:<14082>
at 
__randomizedtesting.SeedInfo.seed([30E4F58E55247E2D:E4A1BED7B272CDD6]: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:334)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
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:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  

[jira] [Commented] (SOLR-9188) BlockUnknown property makes inter-node communication impossible

[ASF subversion and git services (JIRA)]

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

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

Commit 757c245bee057b899107be113fcfc0e4cce3b4a2 in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=757c245 ]

SOLR-9188: Trying revert a change and  fix the unexpected IOException in 
jenkins failure.


> BlockUnknown property makes inter-node communication impossible
> ---
>
> Key: SOLR-9188
> URL: https://issues.apache.org/jira/browse/SOLR-9188
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 6.0
>Reporter: Piotr Tempes
>Assignee: Noble Paul
>Priority: Critical
>  Labels: BasicAuth, Security
> Attachments: solr9188-errorlog.txt
>
>
> When I setup my solr cloud without blockUnknown property it works as 
> expected. When I want to block non authenticated requests I get following 
> stacktrace during startup (see attached file).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-5725) Efficient facets without counts for enum method

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev edited comment on SOLR-5725 at 8/29/16 7:30 AM:
-

squashed commits, tweaked tests - especially {{TestRandomFaceting}} for 
{{facet.sort=counts}} with this method it's pain. 
I will work on it, mostly checking new tests and case w/o filterCache 
({{facet.enum.cache.minDf>0}}).
*Colleagues*, please confirm that you are happy to have a new 
{{facet.method=enumprobing}}, otherwise chime in! 


was (Author: mkhludnev):
squashed commits, tweaked tests - especially {{TestRandomFaceting}} for 
{{facet.sort=counts}} with this method it's pain. 
I will work on it, mostly checking new tests and case w/o filterCache.
*Colleagues*, please confirm that you are happy to have a new 
{{facet.method=enumprobing}}, otherwise chime in! 

> Efficient facets without counts for enum method
> ---
>
> Key: SOLR-5725
> URL: https://issues.apache.org/jira/browse/SOLR-5725
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Alexey Kozhemiakin
>Assignee: Mikhail Khludnev
> Fix For: master (7.0), 6.3
>
> Attachments: SOLR-5725-5x.patch, SOLR-5725-master.patch, 
> SOLR-5725.patch, SOLR-5725.patch
>
>
> Shot version:
> This improves performance for facet.method=enum when it's enough to know that 
> facet count>0, for example when you it's when you dynamically populate 
> filters on search form. New method checks if two bitsets intersect instead of 
> counting intersection size.
> Long version:
> We have a dataset containing hundreds of millions of records, we facet by 
> dozens of fields with many of facet-excludes and have relatively small number 
> of unique values in fields, around thousands.
> Before executing search, users work with "advanced search" form, our  goal is 
> to populate dozens of filters with values which are applicable with other 
> selected values, so basically this is a use case for facets with mincount=1, 
> but without need in actual counts.
> Our performance tests showed that facet.method=enum works much better than 
> fc\fcs, probably due to a specific ratio of "docset"\"unique terms count". 
> For example average execution of query time with method fc=1500ms, fcs=2600ms 
> and with enum=280ms. Profiling indicated the majority time for enum was spent 
> on intersecting docsets.
> Hers's a patch that introduces an extension to facet calculation for 
> method=enum. Basically it uses docSetA.intersects(docSetB) instead of 
> docSetA. intersectionSize (docSetB).
> As a result we were able to reduce our average query time from 280ms to 60ms.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-9448) [subquery] can't pull fields from SolrCloud collection if it has a differently named uniqueKey

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated SOLR-9448:
---
Description: 
straightforward \[subquery] implementation executes requests on a caller 
collection, but just hitting another one with 
{{caller/select?q=..=callee }}. The problem is that for 
{{GET_FIELDS}} it uses uniqKey from a caller collection but not a callee one. 
Another observation, at that case both single sharded collections are 
collocated at the same instance. Then, subquery can't be parsed if it queries a 
field which are absent in caller schema. All of this seems pretty strange like 
hitting an edge case. 

h2. workaround
Perhaps you can collocate secondary index and call it {{fromIndex=callee}}.
Or you can name uniqKey the same, keeping the different app semantic.
 

  was:
straightforward \[subquery] implementation executes requests on a caller 
collection, but just hitting another one with 
{{caller/select?q=..=callee }}. The problem is that for 
{{GET_FIELDS}} it uses uniqKey from a caller collection but not a callee one. 

h2. workaround
Perhaps you can collocate secondary index and call it {{fromIndex=callee}}.
Or you can name uniqKey the same, keeping the different app semantic.
 


> [subquery] can't pull fields from SolrCloud collection if it has a 
> differently named uniqueKey
> --
>
> Key: SOLR-9448
> URL: https://issues.apache.org/jira/browse/SOLR-9448
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: SolrCloud
>Affects Versions: 6.1, 6.2
>Reporter: Mikhail Khludnev
>Assignee: Mikhail Khludnev
>
> straightforward \[subquery] implementation executes requests on a caller 
> collection, but just hitting another one with 
> {{caller/select?q=..=callee }}. The problem is that for 
> {{GET_FIELDS}} it uses uniqKey from a caller collection but not a callee one. 
> Another observation, at that case both single sharded collections are 
> collocated at the same instance. Then, subquery can't be parsed if it queries 
> a field which are absent in caller schema. All of this seems pretty strange 
> like hitting an edge case. 
> h2. workaround
> Perhaps you can collocate secondary index and call it {{fromIndex=callee}}.
> Or you can name uniqKey the same, keeping the different app semantic.
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-9188) BlockUnknown property makes inter-node communication impossible

[ASF subversion and git services (JIRA)]

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

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

Commit 0ed8c2a7ad7038f99bff3322b06edf948a61dfe0 in lucene-solr's branch 
refs/heads/master from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0ed8c2a ]

SOLR-9188: Trying revert a change and  fix the unexpected IOException in 
jenkins failure.


> BlockUnknown property makes inter-node communication impossible
> ---
>
> Key: SOLR-9188
> URL: https://issues.apache.org/jira/browse/SOLR-9188
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 6.0
>Reporter: Piotr Tempes
>Assignee: Noble Paul
>Priority: Critical
>  Labels: BasicAuth, Security
> Attachments: solr9188-errorlog.txt
>
>
> When I setup my solr cloud without blockUnknown property it works as 
> expected. When I want to block non authenticated requests I get following 
> stacktrace during startup (see attached file).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Solaris/815/
Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication

Error Message:
[/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_24D1489ACF60370E-001/solr-instance-012/./collection1/data/index.20160829031823277,
 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_24D1489ACF60370E-001/solr-instance-012/./collection1/data/index.20160829031823334,
 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_24D1489ACF60370E-001/solr-instance-012/./collection1/data/snapshot_metadata,
 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_24D1489ACF60370E-001/solr-instance-012/./collection1/data]
 expected:<3> but was:<4>

Stack Trace:
java.lang.AssertionError: 
[/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_24D1489ACF60370E-001/solr-instance-012/./collection1/data/index.20160829031823277,
 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_24D1489ACF60370E-001/solr-instance-012/./collection1/data/index.20160829031823334,
 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_24D1489ACF60370E-001/solr-instance-012/./collection1/data/snapshot_metadata,
 
/export/home/jenkins/workspace/Lucene-Solr-master-Solaris/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_24D1489ACF60370E-001/solr-instance-012/./collection1/data]
 expected:<3> but was:<4>
at 
__randomizedtesting.SeedInfo.seed([24D1489ACF60370E:D3A2A6C2098898E8]: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.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:902)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1334)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
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:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at