[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60-ea-b24) - Build # 13593 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13593/
Java: 32bit/jdk1.8.0_60-ea-b24 -server -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([B7B2104B13C17FA2:10F6A8EF7E7A6C1B]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319)
at 
org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplication(CdcrReplicationHandlerTest.java:86)
at 
org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:51)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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

[CI] Lucene 5x Linux 64 Test Only - Build # 57226 - Failure!

[build]

  
  BUILD FAILURE
  
  Build URLhttp://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/57226/
  Project:lucene_linux_java8_64_test_only

  Randomization:

JDK8,local,heap[621m],-server +UseSerialGC +UseCompressedOops,sec manager on


  Date of build:Sat, 25 Jul 2015 02:49:37 +0200
  Build duration:9 min 35 sec





	
CHANGES
	
No Changes

  





  
BUILD ARTIFACTS

  
		
  	  
  	checkout/lucene/build/spatial/test/temp/junit4-J0-20150725_025856_578.events
  	  
		
  	  
  	checkout/lucene/build/spatial/test/temp/junit4-J1-20150725_025856_579.events
  	  
		
  	  
  	checkout/lucene/build/spatial/test/temp/junit4-J2-20150725_025856_579.events
  	  
		
  	  
  	checkout/lucene/build/spatial/test/temp/junit4-J3-20150725_025856_579.events
  	  
		
  	  
  	checkout/lucene/build/spatial/test/temp/junit4-J4-20150725_025856_579.events
  	  
		
  	  
  	checkout/lucene/build/spatial/test/temp/junit4-J5-20150725_025856_579.events
  	  
		
  	  
  	checkout/lucene/build/spatial/test/temp/junit4-J6-20150725_025856_580.events
  	  
		
  	  
  	checkout/lucene/build/spatial/test/temp/junit4-J7-20150725_025856_580.events
  	  

  

  
  








  
FAILED JUNIT TESTS

Name: org.apache.lucene.spatial.composite Failed: 1 test(s), Passed: 19 test(s), Skipped: 0 test(s), Total: 20 test(s)
   
 Failed: org.apache.lucene.spatial.composite.CompositeStrategyTest.testOperations {#1 seed=[7A112ED39E509942:BC6C4FB9C63AD976]} 
   
  





CONSOLE OUTPUT

	[...truncated 11258 lines...]

	   [junit4] 

	   [junit4] 

	   [junit4] JVM J0: 0.85 .. 9.05 = 8.20s

	   [junit4] JVM J1: 0.86 .. 8.96 = 8.10s

	   [junit4] JVM J2: 1.09 ..11.68 =10.59s

	   [junit4] JVM J3: 0.86 .. 7.97 = 7.11s

	   [junit4] JVM J4: 0.86 ..11.93 =11.07s

	   [junit4] JVM J5: 0.85 ..11.75 =10.90s

	   [junit4] JVM J6: 0.86 .. 8.00 = 7.14s

	   [junit4] JVM J7: 0.86 ..11.02 =10.16s

	   [junit4] Execution time total: 11 seconds

	   [junit4] Tests summary: 23 suites, 235 tests, 1 failure, 3 ignored (2 assumptions)

	

	BUILD FAILED

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/build.xml:470: The following error occurred while executing this line:

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:2243: The following error occurred while executing this line:

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/module-build.xml:58: The following error occurred while executing this line:

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1447: The following error occurred while executing this line:

	/home/jenkins/workspace/lucene_linux_java8_64_test_only/checkout/lucene/common-build.xml:1002: There were test failures: 23 suites, 235 tests, 1 failure, 3 ignored (2 assumptions)

	

	Total time: 9 minutes 14 seconds

	Build step 'Invoke Ant' marked build as failure

	Archiving artifacts

	Recording test results

	[description-setter] Description set: JDK8,local,heap[621m],-server +UseSerialGC +UseCompressedOops,sec manager on

	Email was triggered for: Failure - 1st

	Trigger Failure - Any was overridden by another trigger and will not send an email.

	Trigger Failure - Still was overridden by another trigger and will not send an email.

	Sending email for trigger: Failure - 1st








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

[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.7.0_80) - Build # 13413 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13413/
Java: 32bit/jdk1.7.0_80 -server -XX:+UseSerialGC

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

Error Message:
document count mismatch.  control=267 sum(shards)=266 cloudClient=266

Stack Trace:
java.lang.AssertionError: document count mismatch.  control=267 sum(shards)=266 
cloudClient=266
at 
__randomizedtesting.SeedInfo.seed([7A6AA91FA914F66B:F23E96C507E89B93]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.checkShardConsistency(AbstractFullDistribZkTestBase.java:1296)
at 
org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest.test(ChaosMonkeyNothingIsSafeTest.java:233)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.rando

[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.8.0_51) - Build # 5065 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5065/
Java: 32bit/jdk1.8.0_51 -client -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests

Error Message:
Timeout while trying to assert update logs @ collection=source_collection

Stack Trace:
java.lang.AssertionError: Timeout while trying to assert update logs @ 
collection=source_collection
at 
__randomizedtesting.SeedInfo.seed([3302A4C0C32F5D18:3B62D1ECCC217513]:0)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.assertNumberOfTlogFiles(CdcrReplicationDistributedZkTest.java:644)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestUpdateLogSynchronisation(CdcrReplicationDistributedZkTest.java:384)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:50)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.

[jira] [Updated] (SOLR-7831) Allow a configurable stack size (-Xss)

[Steve Davids (JIRA)]

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

Steve Davids updated SOLR-7831:
---
Attachment: SOLR-7831.patch

Added patch that preserves the previously set -Xss256k value in the appropriate 
solr.in.sh and solr.in.cmd files.

> Allow a configurable stack size (-Xss)
> --
>
> Key: SOLR-7831
> URL: https://issues.apache.org/jira/browse/SOLR-7831
> Project: Solr
>  Issue Type: Improvement
>Reporter: Steve Davids
>  Labels: easyfix, patch
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7831.patch
>
>
> The Java stack size should be a configuration option in the solr.in.sh and 
> solr.in.cmd instead of being set specifically within the startup script.



--
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-7831) Allow a configurable stack size (-Xss)

[Steve Davids (JIRA)]

Steve Davids created SOLR-7831:
--

 Summary: Allow a configurable stack size (-Xss)
 Key: SOLR-7831
 URL: https://issues.apache.org/jira/browse/SOLR-7831
 Project: Solr
  Issue Type: Improvement
Reporter: Steve Davids
 Fix For: 5.3, Trunk


The Java stack size should be a configuration option in the solr.in.sh and 
solr.in.cmd instead of being set specifically within the startup script.



--
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-7829) Pivot Facet Bug: facet.missing=true + facet.sort=index facet.pivot.mincount > ? == incorrect "missing" count

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-7829:
---
Attachment: SOLR-7829.patch

Huh.

Well apparently the pivot refinement code has incorrectly never bothered to 
refining the "missing" count ... weird.

Because the missing count isn't affected by the facet.limit, this only affects 
indexes & queries where facet.sort=index and at least one shard has a missing 
count that falls below the "per shard" mincount (facet.mincount / numShards).

The attached patch has...

* DistributedFacetPivotSmallTest
** trivially little change that i made the harden that test -- doesn't catch 
this error because the number of docs is too small
* DistributedFacetPivotLargeTest
** non-randomized test that demonstrates the problem
* PivotFacetField
** fix for the bug to do proper refinement of the missing count

I'll let my laptop hammer on this over the weekend and plan to commit monday.

> Pivot Facet Bug: facet.missing=true + facet.sort=index facet.pivot.mincount > 
> ? == incorrect "missing" count
> 
>
> Key: SOLR-7829
> URL: https://issues.apache.org/jira/browse/SOLR-7829
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-7829.patch
>
>
> Following up on SOLR-7804 lead to this error which i'm splitting off into 
> it's own issue.  the nuthsell is that if you combine facet.missing, 
> facet.pivot.mincount, and facet.sort=index you might get incorrect counts (or 
> no counts at all) for the missing value of a pivot.
> fairly easy to reproduce the most extreme aspect of the problem (not getting 
> a missing count back even though it's above the minumum)...
> {noformat}
> bin/solr -e cloud -noprompt
> bin/post -c gettingstarted example/exampledocs/*.xml
> http://localhost:8983/solr/gettingstarted/query?rows=0&q=*:*&facet=true&facet.pivot=inStock&facet.missing=true
> ...
> "facet_pivot":{
>   "inStock":[{
>   "field":"inStock",
>   "value":true,
>   "count":17},
> {
>   "field":"inStock",
>   "value":false,
>   "count":4},
> {
>   "field":"inStock",
>   "value":null,
>   "count":11}]}}}
> http://localhost:8983/solr/gettingstarted/query?rows=0&q=*:*&facet=true&facet.pivot=inStock&facet.missing=true&facet.pivot.mincount=10
> ...
> "facet_pivot":{
>   "inStock":[{
>   "field":"inStock",
>   "value":true,
>   "count":17},
> {
>   "field":"inStock",
>   "value":null,
>   "count":11}]}}}
> http://localhost:8983/solr/gettingstarted/query?rows=0&q=*:*&facet=true&facet.pivot=inStock&facet.missing=true&facet.pivot.mincount=10&facet.sort=index
> ...
> "facet_pivot":{
>   "inStock":[{
>   "field":"inStock",
>   "value":true,
>   "count":17}]}}}
> {noformat}
> ...note that in the last example, the 'null' count is gone (even though it's 
> above the minimum) just because we changed the facet.sort.



--
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: Welcome Christine Poerschke as Lucene/Solr committer

[Jan Høydahl]

Welcome, Christine!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 24. jul. 2015 kl. 09.27 skrev Adrien Grand :
> 
> I'm pleased to announce that Christine Poerschke has accepted the PMC's
> invitation to become a committer.
> 
> Christine, it's tradition that you introduce yourself with a brief bio.
> 
> Your account is not entirely ready yet. We will let you know when it is 
> created
> and karma has been granted so that you can add yourself to the committers
> section of the Who We Are page on the website:
> .
> 
> Congratulations and welcome!
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[JENKINS] Lucene-Solr-5.x-Windows (64bit/jdk1.8.0_51) - Build # 4937 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4937/
Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

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

Error Message:
[index.20150725062247601, index.20150725062249396, index.properties, 
replication.properties] expected:<1> but was:<2>

Stack Trace:
java.lang.AssertionError: [index.20150725062247601, index.20150725062249396, 
index.properties, replication.properties] expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([15A48FFF3CCD8E0D:CE0F8F3939E5E7BE]: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:818)
at 
org.apache.solr.handler.TestReplicationHandler.doTestStressReplication(TestReplicationHandler.java:785)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carr

[GitHub] lucene-solr pull request: Fix incorrect link to Levenshtein distan...

[asfgit]

Github user asfgit closed the pull request at:

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


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

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

Possible deadlock in DefaultSolrCoreState?

[Erick Erickson]

I was looking at a report from the field where apparently writerFree
and pauseWriter get out of sync. Looking at the code in
DefaultSolrCoreState I saw something and wondered if I'm off "chasing
an untamed ornithoid". The precursor was a "RELOAD" operation on the
collection.

In closeIndexWriter, pauseWriter is set to true and never set back to
false under any circumstances.

In newIndexWriter, this bit:

pauseWriter = true;
.
.
.
while (!writerFree) {
  try {
writerPauseLock.wait(100);
  } catch (InterruptedException e) {}

  if (closed) {
throw new SolrException(ErrorCode.SERVICE_UNAVAILABLE,
"SolrCoreState already closed");
  }
}

Could conceivably leave pauseWriter set to true in the if (closed) case.

Opinions?

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

Re: Welcome Christine Poerschke as Lucene/Solr committer

[david.w.smi...@gmail.com]

Welcome Christine!

~ David

On Fri, Jul 24, 2015 at 8:43 PM Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

>
> Thanks for the invitation and all the welcomes!
>
> super brief bio:
>  * based in the UK (originally from Germany)
>  * software developer in the News Search team at Bloomberg in London
> (joined
>Bloomberg R&D more than 10 years ago, directly after BSc and PhD time at
>university)
>  * hobby beekeeper and folding bike cyclist (not concurrently!)
>
> - Original Message -
> From: dev@lucene.apache.org
> To: Christine Poerschke (BLOOMBERG/ LONDON), dev@lucene.apache.org
> At: Jul 24 2015 08:28:23
>
> I'm pleased to announce that Christine Poerschke has accepted the PMC's
> invitation to become a committer.
>
> Christine, it's tradition that you introduce yourself with a brief bio.
>
> Your account is not entirely ready yet. We will let you know when it is
> created
> and karma has been granted so that you can add yourself to the committers
> section of the Who We Are page on the website:
> .
>
> Congratulations and welcome!
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[jira] [Commented] (SOLR-7804) TestCloudPivotFacet failures: expected: but was:

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-7804:
--

About the OOM failure mode: I don't have time to fully investigate ATM (and 
it's not clear that this is directly as a result of TestCloudPivotFacet or 
pivot faceting), but here's the only Jenkins job I still have (the other one 
was removed after X builds had been run) - one of these two (forget which one) 
reproduced for me, even with {{-Xmx2g}} : 
[http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/744/]

{noformat}
   [junit4]   2> 604839 ERROR (qtp1541684701-1973) [n:127.0.0.1:52056_i%2Fi 
c:collection1 s:shard1 r:core_node4 x:collection1] o.a.s.s.SolrDispatchFilter 
null:java.lang.RuntimeException: java.lang.OutOfMemoryError: GC overhead limit 
exceeded
[...]
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestCloudPivotFacet 
-Dtests.method=test -Dtests.seed=758FAB738FCA688C -Dtests.slow=true 
-Dtests.locale=in -Dtests.timezone=Africa/Libreville -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] ERROR471s J2  | TestCloudPivotFacet.test <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: init query failed: 
{main(facet=true&facet.pivot=%7B%21stats%3Dst2%7Dpivot_f1%2Cpivot_tdt%2Cpivot_tl&facet.pivot=%7B%21stats%3Dst2%7Dpivot_tdt%2Cpivot_y_s%2Cdense_pivot_i1&facet.limit=17&facet.offset=7&facet.missing=true&facet.overrequest.count=5),extra(rows=0&q=id%3A%5B*+TO+351%5D&fq=id%3A%5B*+TO+717%5D&stats=true&stats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Ddense_pivot_y_s1&stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Ddense_pivot_y_s1&stats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Dpivot_tdt&_test_miss=true)}:
 No live SolrServers available to handle this 
request:[http://127.0.0.1:55265/i/i/collection1, 
http://127.0.0.1:52056/i/i/collection1]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([758FAB738FCA688C:FDDB94A921360574]:0)
   [junit4]>at 
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:255)
   [junit4]>at 
org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:228)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]> Caused by: org.apache.solr.client.solrj.SolrServerException: 
No live SolrServers available to handle this 
request:[http://127.0.0.1:55265/i/i/collection1, 
http://127.0.0.1:52056/i/i/collection1]
{noformat}

The other one I only have an email from Jenkins, which doesn't include the 
repro line, but has the seed in the stack trace:

{noformat}
java.lang.RuntimeException: init query failed: 
{main(facet=true&facet.pivot=%7B%21stats%3Dst3%7Dpivot_dt1%2Cpivot_x_s%2Cpivot_i&facet.pivot=%7B%21stats%3Dst1%7Dpivot_z_s%2Cpivot_y_s%2Cpivot_x_s&facet.limit=17&facet.offset=5&facet.pivot.mincount=314&facet.missing=false&facet.sort=count&facet.overrequest.ratio=1.4131997),extra(rows=0&q=*%3A*&fq=id%3A%5B*+TO+235%5D&stats=true&stats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_z_s&stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dbogus_not_in_any_doc_s&stats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Dpivot_l1&_test_min=314&_test_miss=false&_test_sort=count)}:
 No live SolrServers available to handle this 
request:[http://127.0.0.1:56936/collection1, http://127.0.0.1:50452/collection1]
at 
__randomizedtesting.SeedInfo.seed([2CA9EAEEE4A8D506:A4FDD5344A54B8FE]:0)
at 
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:255)
{noformat}

> TestCloudPivotFacet failures: expected: but was:
> --
>
> Key: SOLR-7804
> URL: https://issues.apache.org/jira/browse/SOLR-7804
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.3, Trunk
>Reporter: Steve Rowe
>Assignee: Hoss Man
>
> A couple failures recently on my Jenkins (Linux), both on branch_5x and trunk 
> - here's one on trunk: 
> [http://jenkins.sarowe.net/job/Lucene-Solr-tests-trunk/766/], and another on 
> branch_5x: [http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/546/].
> I reproduced another branch_5x failure from a few days ago (Jenkins job has 
> been removed already) on OS X, using both java7 and java8:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestCloudPivotFacet -Dtests.method=test 
> -Dtests.seed=D8E5204E25B3DB16 -Dtests.slow=true -Dtests.locale=es_PA 
> -Dtests.time

[jira] [Updated] (SOLR-7227) Solr distribution archive should have the WAR file extracted already

[Timothy Potter (JIRA)]

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

Timothy Potter updated SOLR-7227:
-
Attachment: SOLR-7227.patch

Updated patch that removes the server/webapps directory as well; there's no 
sense in shipping Solr with an empty webapps directory esp. since we're trying 
to dispel the idea that Solr is a Web application.

This is ready for commit from where I sit.

> Solr distribution archive should have the WAR file extracted already
> 
>
> Key: SOLR-7227
> URL: https://issues.apache.org/jira/browse/SOLR-7227
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 5.0
>Reporter: Timothy Potter
>Assignee: Timothy Potter
> Fix For: 5.3, Trunk
>
> Attachments: SOLR-7227.patch, SOLR-7227.patch
>
>
> Currently, there is still the solr.war file in the server/webapps directory, 
> which gets extracted upon first startup of Solr. It would be better to ship 
> Solr with the WAR already extracted, thus taking us one step closer to truly 
> not shipping a WAR file. Moreover, some users have reported not being able to 
> make /opt/solr truly read-only because of the need to extract the WAR 
> on-the-fly upon first startup.



--
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-7804) TestCloudPivotFacet failures: expected: but was:

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-7804:
--

I looked through recent failures on my Jenkins for more seeds, and found no 
more seeds for the previously identified failure modes (I don't think anyway).  
I found two that look like they trigger an OOM (I'll give info in a following 
comment), and one that looks like another test bug (rounding/no epsilon?) - 
branch_5x / r1692571 / Java8:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestCloudPivotFacet 
-Dtests.method=test -Dtests.seed=2701C0115CD1BF95 -Dtests.slow=true 
-Dtests.locale=ja_JP -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 46.9s | TestCloudPivotFacet.test <<<
   [junit4]> Throwable #1: java.lang.AssertionError: 
{main(facet=true&facet.pivot=%7B%21stats%3Dst1%7Dpivot_y_s1%2Cdense_pivot_y_s%2Cdense_pivot_ti1&facet.limit=9&facet.sort=index),extra(rows=0&q=id%3A%5B*+TO+304%5D&stats=true&stats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_tf1&stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_x_s&stats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Ddense_pivot_ti1&_test_sort=index)}
 ==> Sum of sk1 => pivot_y_s1,dense_pivot_y_s,dense_pivot_ti1: 
{params(rows=0),defaults({main(rows=0&q=id%3A%5B*+TO+304%5D&stats=true&stats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_tf1&stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_x_s&stats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Ddense_pivot_ti1&_test_sort=index),extra(fq=%7B%21term+f%3Dpivot_y_s1%7Dh)})}
 expected:<-1.272258246444E9> but was:<-1.272258246442E9>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([2701C0115CD1BF95:AF55FFCBF22DD26D]:0)
   [junit4]>at 
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:286)
   [junit4]>at 
org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:233)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
   [junit4]>at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
   [junit4]> Caused by: java.lang.AssertionError: Sum of sk1 => 
pivot_y_s1,dense_pivot_y_s,dense_pivot_ti1: 
{params(rows=0),defaults({main(rows=0&q=id%3A%5B*+TO+304%5D&stats=true&stats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_tf1&stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_x_s&stats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Ddense_pivot_ti1&_test_sort=index),extra(fq=%7B%21term+f%3Dpivot_y_s1%7Dh)})}
 expected:<-1.272258246444E9> but was:<-1.272258246442E9>
   [junit4]>at 
org.apache.solr.cloud.TestCloudPivotFacet.assertNumerics(TestCloudPivotFacet.java:738)
   [junit4]>at 
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotStats(TestCloudPivotFacet.java:394)
   [junit4]>at 
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotData(TestCloudPivotFacet.java:344)
   [junit4]>at 
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:307)
   [junit4]>at 
org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:276)
   [junit4]>... 42 more
{noformat}


> TestCloudPivotFacet failures: expected: but was:
> --
>
> Key: SOLR-7804
> URL: https://issues.apache.org/jira/browse/SOLR-7804
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.3, Trunk
>Reporter: Steve Rowe
>Assignee: Hoss Man
>
> A couple failures recently on my Jenkins (Linux), both on branch_5x and trunk 
> - here's one on trunk: 
> [http://jenkins.sarowe.net/job/Lucene-Solr-tests-trunk/766/], and another on 
> branch_5x: [http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/546/].
> I reproduced another branch_5x failure from a few days ago (Jenkins job has 
> been removed already) on OS X, using both java7 and java8:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestCloudPivotFacet -Dtests.method=test 
> -Dtests.seed=D8E5204E25B3DB16 -Dtests.slow=true -Dtests.locale=es_PA 
> -Dtests.timezone=America/El_Salvador -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 46.6s | TestCloudPivotFacet.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> {main(facet=true&facet.pivot=%7B%21stats%3Dst0%7Dpivot_ti1&facet.pivot=%7B%21stats%3Dst0%7Dpivot_ti1&facet.limit=4&facet.offset=6&facet.missing=true&facet.ove

[jira] [Commented] (LUCENE-6693) Permgen errors in 5.x on Jenkins builds with JDK 1.7

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6693:
---

After analyzing Jenkins build logs, I added few more pass-throughs and 
early-init of Ant plugins.

> Permgen errors in 5.x on Jenkins builds with JDK 1.7
> 
>
> Key: LUCENE-6693
> URL: https://issues.apache.org/jira/browse/LUCENE-6693
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6693.patch, LUCENE-6693.patch
>
>
> Since I updated Groovy and other tools, 5.x builds fail with permgen errors 
> in Jenkins. During the build, Groovy (which is large) is loaded three times 
> and this sums up.
> See Revision: 1692103
> I reverted the Groovy update in 5.x for now. The fix is to make the top-level 
> build.xml also load common-build.xml and resolve groovy before the build 
> starts.



--
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] (LUCENE-6693) Permgen errors in 5.x on Jenkins builds with JDK 1.7

[ASF subversion and git services (JIRA)]

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

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

Commit 1692573 from [~thetaphi] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1692573 ]

Merged revision(s) 1692572 from lucene/dev/trunk:
LUCENE-6693: Add one more parameter-pass-through #4

> Permgen errors in 5.x on Jenkins builds with JDK 1.7
> 
>
> Key: LUCENE-6693
> URL: https://issues.apache.org/jira/browse/LUCENE-6693
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6693.patch, LUCENE-6693.patch
>
>
> Since I updated Groovy and other tools, 5.x builds fail with permgen errors 
> in Jenkins. During the build, Groovy (which is large) is loaded three times 
> and this sums up.
> See Revision: 1692103
> I reverted the Groovy update in 5.x for now. The fix is to make the top-level 
> build.xml also load common-build.xml and resolve groovy before the build 
> starts.



--
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] (LUCENE-6693) Permgen errors in 5.x on Jenkins builds with JDK 1.7

[ASF subversion and git services (JIRA)]

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

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

Commit 1692572 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1692572 ]

LUCENE-6693: Add one more parameter-pass-through #4

> Permgen errors in 5.x on Jenkins builds with JDK 1.7
> 
>
> Key: LUCENE-6693
> URL: https://issues.apache.org/jira/browse/LUCENE-6693
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6693.patch, LUCENE-6693.patch
>
>
> Since I updated Groovy and other tools, 5.x builds fail with permgen errors 
> in Jenkins. During the build, Groovy (which is large) is loaded three times 
> and this sums up.
> See Revision: 1692103
> I reverted the Groovy update in 5.x for now. The fix is to make the top-level 
> build.xml also load common-build.xml and resolve groovy before the build 
> starts.



--
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-7830) topdocs facet function

[Yonik Seeley (JIRA)]

Yonik Seeley created SOLR-7830:
--

 Summary: topdocs facet function
 Key: SOLR-7830
 URL: https://issues.apache.org/jira/browse/SOLR-7830
 Project: Solr
  Issue Type: New Feature
  Components: Facet Module
Reporter: Yonik Seeley


A topdocs() facet function would return the top N documents per facet bucket.
This would be a big step toward unifying grouping and the new facet module.




--
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-7804) TestCloudPivotFacet failures: expected: but was:

[Hoss Man (JIRA)]

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

Hoss Man reassigned SOLR-7804:
--

Assignee: Hoss Man

> TestCloudPivotFacet failures: expected: but was:
> --
>
> Key: SOLR-7804
> URL: https://issues.apache.org/jira/browse/SOLR-7804
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.3, Trunk
>Reporter: Steve Rowe
>Assignee: Hoss Man
>
> A couple failures recently on my Jenkins (Linux), both on branch_5x and trunk 
> - here's one on trunk: 
> [http://jenkins.sarowe.net/job/Lucene-Solr-tests-trunk/766/], and another on 
> branch_5x: [http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/546/].
> I reproduced another branch_5x failure from a few days ago (Jenkins job has 
> been removed already) on OS X, using both java7 and java8:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestCloudPivotFacet -Dtests.method=test 
> -Dtests.seed=D8E5204E25B3DB16 -Dtests.slow=true -Dtests.locale=es_PA 
> -Dtests.timezone=America/El_Salvador -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 46.6s | TestCloudPivotFacet.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> {main(facet=true&facet.pivot=%7B%21stats%3Dst0%7Dpivot_ti1&facet.pivot=%7B%21stats%3Dst0%7Dpivot_ti1&facet.limit=4&facet.offset=6&facet.missing=true&facet.overrequest.ratio=-0.9744149),extra(rows=0&q=id%3A%5B*+TO+448%5D&fq=id%3A%5B*+TO+516%5D&_test_miss=true)}
>  num pivots expected:<2> but was:<1>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([D8E5204E25B3DB16:50B11F948B4FB6EE]:0)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:251)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:228)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
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-7828) add a facet function to pick one result's value

[Gary Yang (JIRA)]

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

Gary Yang updated SOLR-7828:

Description: 
The facet functions and analytics working great, especially with json API !

As a developer, I would like a facet function to get a field value from one 
record from a group, please see this facet query:

{
"schema": {
"slide_id": {
"type": "long"
},
"slide_name": {
"type": "string"
},
"slide_create_time": {
"type": "timestamp"
}
},

"facet.query": {
"slide_viewed": {
"type": "terms",
"field": "slide_id",
"facet": {
"avg_viewed_time": "avg(slide_viewed_time)",
"created_time": "max(slide_create_time)",
"slide_name": 
"*{color:red}ANY_FIRST_LAST_OR_FILTER{color}*(slide_name)"
}
},
"total": {
"type": "query",
"q": "*:*",
"facet": {
"slide_num": "unique(slide_id)"
}
}
}
}

when grouping by slide_id, I would love to have the a function that can pick a 
slide name from each group of slides with the same slide_id.

I know I can get the name by using sub facet, but it will be in one level deep, 
and I can't sort by it, it would be great to be in one flat level, so they can 
be sorted.

thanks!

  was:
The facet functions and analytics working great, especially with json API !

As a developer, I would like a facet function to get a field value from one 
record from a group, please see this facet query:

{
"schema": {
"slide_id": {
"type": "long"
},
"slide_name": {
"type": "string"
},
"slide_create_time": {
"type": "timestamp"
}
},

"facet.query": {
"slide_viewed": {
"type": "terms",
"field": "slide_id",
"facet": {
"avg_viewed_time": "avg(slide_viewed_time)",
"created_time": "max(slide_create_time)",
"slide_name": 
"*{color:red}ANY_FIRST_LAST_OR_FILTER{color}*(slide_name)"
}
},
"total": {
"type": "query",
"q": "*:*",
"facet": {
"slide_num": "unique(slide_id)"
}
}
}
}

when grouping by slide_id, I would love to have the a function that can pick a 
slide name from each group of slides with the same slide_id.

thanks!


> add a facet function to pick one result's value
> ---
>
> Key: SOLR-7828
> URL: https://issues.apache.org/jira/browse/SOLR-7828
> Project: Solr
>  Issue Type: New Feature
>  Components: faceting
>Affects Versions: 5x
>Reporter: Gary Yang
>
> The facet functions and analytics working great, especially with json API !
> As a developer, I would like a facet function to get a field value from one 
> record from a group, please see this facet query:
> {
> "schema": {
> "slide_id": {
> "type": "long"
> },
> "slide_name": {
> "type": "string"
> },
> "slide_create_time": {
> "type": "timestamp"
> }
> },
> 
> "facet.query": {
> "slide_viewed": {
> "type": "terms",
> "field": "slide_id",
> "facet": {
> "avg_viewed_time": "avg(slide_viewed_time)",
> "created_time": "max(slide_create_time)",
> "slide_name": 
> "*{color:red}ANY_FIRST_LAST_OR_FILTER{color}*(slide_name)"
> }
> },
> "total": {
> "type": "query",
> "q": "*:*",
> "facet": {
> "slide_num": "unique(slide_id)"
> }
> }
> }
> }
> when grouping by slide_id, I would love to have the a function that can pick 
> a slide name from each group of slides with the same slide_id.
> I know I can get the name by using sub facet, but it will be in one level 
> deep, and I can't sort by it, it would be great to be in one flat level, so 
> they can be sorted.
> thanks!



--
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-7804) TestCloudPivotFacet failures: expected: but was:

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-7804:


Confirmed the facet.missing count discrepency is a definite code bug, and split 
it off into it's own issue (SOLR-7829)

Will resolve this issue once that fix is in place and i confirm these seeds 
start working again.

> TestCloudPivotFacet failures: expected: but was:
> --
>
> Key: SOLR-7804
> URL: https://issues.apache.org/jira/browse/SOLR-7804
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.3, Trunk
>Reporter: Steve Rowe
>
> A couple failures recently on my Jenkins (Linux), both on branch_5x and trunk 
> - here's one on trunk: 
> [http://jenkins.sarowe.net/job/Lucene-Solr-tests-trunk/766/], and another on 
> branch_5x: [http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/546/].
> I reproduced another branch_5x failure from a few days ago (Jenkins job has 
> been removed already) on OS X, using both java7 and java8:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestCloudPivotFacet -Dtests.method=test 
> -Dtests.seed=D8E5204E25B3DB16 -Dtests.slow=true -Dtests.locale=es_PA 
> -Dtests.timezone=America/El_Salvador -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 46.6s | TestCloudPivotFacet.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> {main(facet=true&facet.pivot=%7B%21stats%3Dst0%7Dpivot_ti1&facet.pivot=%7B%21stats%3Dst0%7Dpivot_ti1&facet.limit=4&facet.offset=6&facet.missing=true&facet.overrequest.ratio=-0.9744149),extra(rows=0&q=id%3A%5B*+TO+448%5D&fq=id%3A%5B*+TO+516%5D&_test_miss=true)}
>  num pivots expected:<2> but was:<1>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([D8E5204E25B3DB16:50B11F948B4FB6EE]:0)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:251)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:228)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
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-7829) Pivot Facet Bug: facet.missing=true + facet.sort=index facet.pivot.mincount > ? == incorrect "missing" count

[Hoss Man (JIRA)]

Hoss Man created SOLR-7829:
--

 Summary: Pivot Facet Bug: facet.missing=true + facet.sort=index 
facet.pivot.mincount > ? == incorrect "missing" count
 Key: SOLR-7829
 URL: https://issues.apache.org/jira/browse/SOLR-7829
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man


Following up on SOLR-7804 lead to this error which i'm splitting off into it's 
own issue.  the nuthsell is that if you combine facet.missing, 
facet.pivot.mincount, and facet.sort=index you might get incorrect counts (or 
no counts at all) for the missing value of a pivot.

fairly easy to reproduce the most extreme aspect of the problem (not getting a 
missing count back even though it's above the minumum)...

{noformat}
bin/solr -e cloud -noprompt
bin/post -c gettingstarted example/exampledocs/*.xml

http://localhost:8983/solr/gettingstarted/query?rows=0&q=*:*&facet=true&facet.pivot=inStock&facet.missing=true
...
"facet_pivot":{
  "inStock":[{
  "field":"inStock",
  "value":true,
  "count":17},
{
  "field":"inStock",
  "value":false,
  "count":4},
{
  "field":"inStock",
  "value":null,
  "count":11}]}}}

http://localhost:8983/solr/gettingstarted/query?rows=0&q=*:*&facet=true&facet.pivot=inStock&facet.missing=true&facet.pivot.mincount=10
...
"facet_pivot":{
  "inStock":[{
  "field":"inStock",
  "value":true,
  "count":17},
{
  "field":"inStock",
  "value":null,
  "count":11}]}}}

http://localhost:8983/solr/gettingstarted/query?rows=0&q=*:*&facet=true&facet.pivot=inStock&facet.missing=true&facet.pivot.mincount=10&facet.sort=index
...
"facet_pivot":{
  "inStock":[{
  "field":"inStock",
  "value":true,
  "count":17}]}}}

{noformat}

...note that in the last example, the 'null' count is gone (even though it's 
above the minimum) just because we changed the facet.sort.




--
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: Welcome Christine Poerschke as Lucene/Solr committer

[Michael McCandless]

Welcome Christine!

Mike McCandless

http://blog.mikemccandless.com


On Fri, Jul 24, 2015 at 3:27 AM, Adrien Grand  wrote:
> I'm pleased to announce that Christine Poerschke has accepted the PMC's
> invitation to become a committer.
>
> Christine, it's tradition that you introduce yourself with a brief bio.
>
> Your account is not entirely ready yet. We will let you know when it is 
> created
> and karma has been granted so that you can add yourself to the committers
> section of the Who We Are page on the website:
> .
>
> Congratulations and welcome!
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Updated] (SOLR-7825) Use slf4j consistently

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-7825:

Attachment: SOLR-7825.patch

Thanks for reviewing, Uwe! This patch incorporates both of your suggestions.

> Use slf4j consistently
> --
>
> Key: SOLR-7825
> URL: https://issues.apache.org/jira/browse/SOLR-7825
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.2.1
>Reporter: Oliver Schrenk
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Attachments: SOLR-7825.patch, SOLR-7825.patch, slf4j.patch
>
>
> There are a few classes that directly rely on log4j to be on the classpath 
> instead and don't use the slf4j logging facade. This creates problems when 
> trying to switch the logging implementation. 
> 1. org.apache.solr.core.ZkContainer
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/core/ZkContainer.java#L218
> I don't know the impact of this change, but shouldn't this call 
> `org.apache.solr.logging.MDCLoggingContext.clear()` ?
> 2. org.apache.solr.handler.component.RangeFacetProcessor and 
> org.apache.solr.handler.component.RangeFacetRequest
> should use slf4j instead of log4j
> I had a stab at it at
> https://github.com/oschrenk/lucene-solr/commit/025b4802caf0360c63a3554af82e9ed4c94ff5a3#diff-7d822e8ff8ff21d88437652bbc894739R28



--
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-7825) Use slf4j consistently

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on SOLR-7825 at 7/24/15 6:10 PM:
--

Some comments:
- MapReduceIndexertool still imports the log4j class (leftover), it also 
imports SuppressForbidden but does not use it -> cleanup
- In the solr.txt sigatures file i would truncate with {{\*\*}} instead of 
{{\*}}. {{\*\*}} is like Ant/Maven's fileset includes and spawn several 
packages. So {{org.apache.log4j.\*\*}} would also match possible sub-packages.


was (Author: thetaphi):
Some comments:
- MapReduceIndexertool still imports the log4j class (leftover), it also 
imports SuppressForbidden but does not use it -> cleanup
- In the solr.txt sigatures file i would truncate with {{**}} instead of {{*}}. 
** is like Ant/Maven's fileset includes and spawn several packages. So 
{{org.apache.log4j.**}} would also match possible sub-packages.

> Use slf4j consistently
> --
>
> Key: SOLR-7825
> URL: https://issues.apache.org/jira/browse/SOLR-7825
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.2.1
>Reporter: Oliver Schrenk
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Attachments: SOLR-7825.patch, slf4j.patch
>
>
> There are a few classes that directly rely on log4j to be on the classpath 
> instead and don't use the slf4j logging facade. This creates problems when 
> trying to switch the logging implementation. 
> 1. org.apache.solr.core.ZkContainer
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/core/ZkContainer.java#L218
> I don't know the impact of this change, but shouldn't this call 
> `org.apache.solr.logging.MDCLoggingContext.clear()` ?
> 2. org.apache.solr.handler.component.RangeFacetProcessor and 
> org.apache.solr.handler.component.RangeFacetRequest
> should use slf4j instead of log4j
> I had a stab at it at
> https://github.com/oschrenk/lucene-solr/commit/025b4802caf0360c63a3554af82e9ed4c94ff5a3#diff-7d822e8ff8ff21d88437652bbc894739R28



--
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-7825) Use slf4j consistently

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-7825:
-

Some comments:
- MapReduceIndexertool still imports the log4j class (leftover), it also 
imports SuppressForbidden but does not use it -> cleanup
- In the solr.txt sigatures file i would truncate with {{**}} instead of {{*}}. 
** is like Ant/Maven's fileset includes and spawn several packages. So 
{{org.apache.log4j.**}} would also match possible sub-packages.

> Use slf4j consistently
> --
>
> Key: SOLR-7825
> URL: https://issues.apache.org/jira/browse/SOLR-7825
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.2.1
>Reporter: Oliver Schrenk
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Attachments: SOLR-7825.patch, slf4j.patch
>
>
> There are a few classes that directly rely on log4j to be on the classpath 
> instead and don't use the slf4j logging facade. This creates problems when 
> trying to switch the logging implementation. 
> 1. org.apache.solr.core.ZkContainer
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/core/ZkContainer.java#L218
> I don't know the impact of this change, but shouldn't this call 
> `org.apache.solr.logging.MDCLoggingContext.clear()` ?
> 2. org.apache.solr.handler.component.RangeFacetProcessor and 
> org.apache.solr.handler.component.RangeFacetRequest
> should use slf4j instead of log4j
> I had a stab at it at
> https://github.com/oschrenk/lucene-solr/commit/025b4802caf0360c63a3554af82e9ed4c94ff5a3#diff-7d822e8ff8ff21d88437652bbc894739R28



--
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-NightlyTests-5.x - Build # 909 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.x/909/

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

Error Message:
Captured an uncaught exception in thread: Thread[id=6896, name=collection5, 
state=RUNNABLE, group=TGRP-CollectionsAPIDistributedZkTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=6896, name=collection5, state=RUNNABLE, 
group=TGRP-CollectionsAPIDistributedZkTest]
Caused by: java.lang.RuntimeException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this request:[https://127.0.0.1:43345/fy, https://127.0.0.1:48150/fy, 
https://127.0.0.1:48564/fy, https://127.0.0.1:51273/fy, 
https://127.0.0.1:43360/fy]
at __randomizedtesting.SeedInfo.seed([8E1638E083B2DD4D]:0)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:897)
Caused by: org.apache.solr.client.solrj.SolrServerException: No live 
SolrServers available to handle this request:[https://127.0.0.1:43345/fy, 
https://127.0.0.1:48150/fy, https://127.0.0.1:48564/fy, 
https://127.0.0.1:51273/fy, https://127.0.0.1:43360/fy]
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:355)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1086)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:856)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:799)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1572)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1593)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest$1CollectionThread.run(CollectionsAPIDistributedZkTest.java:887)
Caused by: 
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:43345/fy: KeeperErrorCode = Session expired 
for /overseer/collection-queue-work/qn-
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:560)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:376)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:328)
... 7 more




Build Log:
[...truncated 11107 lines...]
   [junit4] Suite: org.apache.solr.cloud.CollectionsAPIDistributedZkTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-5.x/solr/build/solr-core/test/J2/temp/solr.cloud.CollectionsAPIDistributedZkTest_8E1638E083B2DD4D-001/init-core-data-001
   [junit4]   2> 1062025 INFO  
(SUITE-CollectionsAPIDistributedZkTest-seed#[8E1638E083B2DD4D]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false)
   [junit4]   2> 1062025 INFO  
(SUITE-CollectionsAPIDistributedZkTest-seed#[8E1638E083B2DD4D]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /fy/
   [junit4]   2> 1062041 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[8E1638E083B2DD4D]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1062042 INFO  (Thread-2410) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1062042 INFO  (Thread-2410) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1062142 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[8E1638E083B2DD4D]) [] 
o.a.s.c.ZkTestServer start zk server on port:39208
   [junit4]   2> 1062142 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[8E1638E083B2DD4D]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1062162 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[8E1638E083B2DD4D]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1062172 INFO  (zkCallback-762-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@6b69ddc0 
name:ZooKeeperConnection Watcher:127.0.0.1:39208 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 1062172 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[8E1638E083B2DD4D]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 1062173 INFO  
(TEST-CollectionsAPIDistributedZkTest.test-seed#[8E1638E083B2DD4D]) [] 
o.a.s.c.c.SolrZkClient Using defaul

Re:Welcome Christine Poerschke as Lucene/Solr committer

[Christine Poerschke (BLOOMBERG/ LONDON)]

Thanks for the invitation and all the welcomes!

super brief bio:
 * based in the UK (originally from Germany)
 * software developer in the News Search team at Bloomberg in London (joined
   Bloomberg R&D more than 10 years ago, directly after BSc and PhD time at
   university)
 * hobby beekeeper and folding bike cyclist (not concurrently!)

- Original Message -
From: dev@lucene.apache.org
To: Christine Poerschke (BLOOMBERG/ LONDON), dev@lucene.apache.org
At: Jul 24 2015 08:28:23

I'm pleased to announce that Christine Poerschke has accepted the PMC's
invitation to become a committer.

Christine, it's tradition that you introduce yourself with a brief bio.

Your account is not entirely ready yet. We will let you know when it is created
and karma has been granted so that you can add yourself to the committers
section of the Who We Are page on the website:
.

Congratulations and welcome!

-- 
Adrien

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

[jira] [Commented] (SOLR-7804) TestCloudPivotFacet failures: expected: but was:

[ASF subversion and git services (JIRA)]

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

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

Commit 1692554 from hoss...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1692554 ]

SOLR-7804: Fix test bug where it was randomly generating 2 identical 
facet.pivot params w/o realizing it (merge r1692552)

> TestCloudPivotFacet failures: expected: but was:
> --
>
> Key: SOLR-7804
> URL: https://issues.apache.org/jira/browse/SOLR-7804
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.3, Trunk
>Reporter: Steve Rowe
>
> A couple failures recently on my Jenkins (Linux), both on branch_5x and trunk 
> - here's one on trunk: 
> [http://jenkins.sarowe.net/job/Lucene-Solr-tests-trunk/766/], and another on 
> branch_5x: [http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/546/].
> I reproduced another branch_5x failure from a few days ago (Jenkins job has 
> been removed already) on OS X, using both java7 and java8:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestCloudPivotFacet -Dtests.method=test 
> -Dtests.seed=D8E5204E25B3DB16 -Dtests.slow=true -Dtests.locale=es_PA 
> -Dtests.timezone=America/El_Salvador -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 46.6s | TestCloudPivotFacet.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> {main(facet=true&facet.pivot=%7B%21stats%3Dst0%7Dpivot_ti1&facet.pivot=%7B%21stats%3Dst0%7Dpivot_ti1&facet.limit=4&facet.offset=6&facet.missing=true&facet.overrequest.ratio=-0.9744149),extra(rows=0&q=id%3A%5B*+TO+448%5D&fq=id%3A%5B*+TO+516%5D&_test_miss=true)}
>  num pivots expected:<2> but was:<1>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([D8E5204E25B3DB16:50B11F948B4FB6EE]:0)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:251)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:228)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
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-7804) TestCloudPivotFacet failures: expected: but was:

[ASF subversion and git services (JIRA)]

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

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

Commit 1692552 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1692552 ]

SOLR-7804: Fix test bug where it was randomly generating 2 identical 
facet.pivot params w/o realizing it

> TestCloudPivotFacet failures: expected: but was:
> --
>
> Key: SOLR-7804
> URL: https://issues.apache.org/jira/browse/SOLR-7804
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.3, Trunk
>Reporter: Steve Rowe
>
> A couple failures recently on my Jenkins (Linux), both on branch_5x and trunk 
> - here's one on trunk: 
> [http://jenkins.sarowe.net/job/Lucene-Solr-tests-trunk/766/], and another on 
> branch_5x: [http://jenkins.sarowe.net/job/Lucene-Solr-tests-5.x-Java8/546/].
> I reproduced another branch_5x failure from a few days ago (Jenkins job has 
> been removed already) on OS X, using both java7 and java8:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestCloudPivotFacet -Dtests.method=test 
> -Dtests.seed=D8E5204E25B3DB16 -Dtests.slow=true -Dtests.locale=es_PA 
> -Dtests.timezone=America/El_Salvador -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 46.6s | TestCloudPivotFacet.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: 
> {main(facet=true&facet.pivot=%7B%21stats%3Dst0%7Dpivot_ti1&facet.pivot=%7B%21stats%3Dst0%7Dpivot_ti1&facet.limit=4&facet.offset=6&facet.missing=true&facet.overrequest.ratio=-0.9744149),extra(rows=0&q=id%3A%5B*+TO+448%5D&fq=id%3A%5B*+TO+516%5D&_test_miss=true)}
>  num pivots expected:<2> but was:<1>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([D8E5204E25B3DB16:50B11F948B4FB6EE]:0)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudPivotFacet.assertPivotCountsAreCorrect(TestCloudPivotFacet.java:251)
>[junit4]>  at 
> org.apache.solr.cloud.TestCloudPivotFacet.test(TestCloudPivotFacet.java:228)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:935)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
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-7828) add a facet function to pick one result's value

[Gary Yang (JIRA)]

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

Gary Yang updated SOLR-7828:

Summary: add a facet function to pick one result's value  (was: add a new 
facet function to pick one result's value)

> add a facet function to pick one result's value
> ---
>
> Key: SOLR-7828
> URL: https://issues.apache.org/jira/browse/SOLR-7828
> Project: Solr
>  Issue Type: New Feature
>  Components: faceting
>Affects Versions: 5x
>Reporter: Gary Yang
>
> The facet functions and analytics working great, especially with json API !
> As a developer, I would like a facet function to get a field value from one 
> record from a group, please see this facet query:
> {
> "schema": {
> "slide_id": {
> "type": "long"
> },
> "slide_name": {
> "type": "string"
> },
> "slide_create_time": {
> "type": "timestamp"
> }
> },
> 
> "facet.query": {
> "slide_viewed": {
> "type": "terms",
> "field": "slide_id",
> "facet": {
> "avg_viewed_time": "avg(slide_viewed_time)",
> "created_time": "max(slide_create_time)",
> "slide_name": 
> "*{color:red}ANY_FIRST_LAST_OR_FILTER{color}*(slide_name)"
> }
> },
> "total": {
> "type": "query",
> "q": "*:*",
> "facet": {
> "slide_num": "unique(slide_id)"
> }
> }
> }
> }
> when grouping by slide_id, I would love to have the a function that can pick 
> a slide name from each group of slides with the same slide_id.
> thanks!



--
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-7804) TestCloudPivotFacet failures: expected: but was:

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-7804:


There's two distinct types of failures here..

* assertPivotCountsAreCorrect fails directly (and very early in it's cycle) 
because {{num pivots expected: but was:}}
** this is a straightforward test bug - it's not accounting for the 1 in ~1000 
chance that it will generate the exact same "facet.pivot" param twice in a 
single request
* assertNumFound fails with {{expected: but was:
** this is ... something else.  it's not immediately obvious to me why these 
are failing
*** in both of the examples give so far, the specific failure msg indicates 
that it's trying to verify the count from a "missing" constraint (ie: dos that 
do not have a pivot constrain value) and when adding an {{fq=-fieldname:[* TO 
*]}} to the original query, it gets _more_ documents then the facet said it 
should.
*** besides the fact that they are both the "missing" counts, the only other 
commonality that jumps out at me is that facet.mincount is used in both 
queries, and in both cases the facet.mincount is just slightly below the count 
returned -- making me wonder if there is a bug in how the we're dealing with 
counts from individual shards below the mincount? (pure speculation)
*** i should not explicitly that in one of the failures, the facet.limit=5 and 
the incorrect count is from a boolean field which is the very first field in 
the pivot -- so refinement shouldn't be a factor in whatever is going wrong.



I've got a trivial patch for the first problem that i'll commit soon -- it 
doens't affect the entropy of the randomized test, so the other seeds (for the 
second problem) still fail and can be used to continue to test that remaining 
problem...

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestCloudPivotFacet 
-Dtests.method=test -Dtests.seed=957BC6861F510BE -Dtests.slow=true 
-Dtests.locale=sr_BA -Dtests.timezone=America/Guadeloupe -Dtests.asserts=true 
-Dtests.file.encoding=UTF-8
   [junit4] FAILURE 36.2s J3  | TestCloudPivotFacet.test <<<
   [junit4]> Throwable #1: java.lang.AssertionError: 
{main(facet=true&facet.pivot=pivot_b%2Cpivot_f%2Cpivot_dt1&facet.pivot=%7B%21stats%3Dst3%7Dpivot_td%2Cpivot_z_s1&facet.limit=5&facet.pivot.mincount=16&facet.missing=true&facet.sort=index&facet.overrequest.ratio=1.1832508),extra(rows=0&q=*%3A*&stats=true&stats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_tl&stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_tdt1&stats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Ddense_pivot_y_s&_test_min=16&_test_miss=true&_test_sort=index)}
 ==> pivot_b,pivot_f,pivot_dt1: 
{params(rows=0),defaults({main(rows=0&q=*%3A*&stats=true&stats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_tl&stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_tdt1&stats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Ddense_pivot_y_s&_test_min=16&_test_miss=true&_test_sort=index),extra(fq=-pivot_b%3A%5B*+TO+*%5D)})}
 expected:<17> but was:<22>


   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestCloudPivotFacet 
-Dtests.method=test -Dtests.seed=4FE0B7EDE128DBAA -Dtests.slow=true 
-Dtests.locale=ga -Dtests.timezone=America/Detroit -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] FAILURE 34.7s J10 | TestCloudPivotFacet.test <<<
   [junit4]> Throwable #1: java.lang.AssertionError: 
{main(facet=true&facet.pivot=%7B%21stats%3Dst2%7Dpivot_f%2Cdense_pivot_i1&facet.pivot=pivot_f%2Cdense_pivot_x_s1%2Cbogus_not_in_any_doc_s&facet.limit=13&facet.pivot.mincount=5&facet.missing=true&facet.sort=index&facet.overrequest.count=0&facet.overrequest.ratio=0),extra(rows=0&q=*%3A*&stats=true&stats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_x_s1&stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_i1&stats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Dpivot_dt1&_test_min=5&_test_miss=true&_test_sort=index)}
 ==> pivot_f,dense_pivot_i1: 
{params(rows=0),defaults({main({main(rows=0&q=*%3A*&stats=true&stats.field=%7B%21key%3Dsk1+tag%3Dst1%2Cst2%7Dpivot_x_s1&stats.field=%7B%21key%3Dsk2+tag%3Dst2%2Cst3%7Dpivot_i1&stats.field=%7B%21key%3Dsk3+tag%3Dst3%2Cst4%7Dpivot_dt1&_test_min=5&_test_miss=true&_test_sort=index),extra(fq=%7B%21term+f%3Dpivot_f%7D0.3334)}),extra(fq=-dense_pivot_i1%3A%5B*+TO+*%5D)})}
 expected:<6> but was:<7>
{noformat}



> TestCloudPivotFacet failures: expected: but was:
> --
>
> Key: SOLR-7804
> URL: https://issues.apache.org/jira/browse/SOLR-7804
> Project: Solr
>  Issue Type: Bug
>  Components: faceting
>Affects Versions: 5.3, Trunk
>Reporter: Steve Rowe
>
> A couple failures recently on my Jenkins (Linux), both on branch_5x and trunk 
> - here's one on trunk: 
> [http://jenkins.sarowe.net/job/Lucene-Solr-tests-t

[jira] [Created] (SOLR-7828) add a new facet function to pick one result's value

[Gary Yang (JIRA)]

Gary Yang created SOLR-7828:
---

 Summary: add a new facet function to pick one result's value
 Key: SOLR-7828
 URL: https://issues.apache.org/jira/browse/SOLR-7828
 Project: Solr
  Issue Type: New Feature
  Components: faceting
Affects Versions: 5x
Reporter: Gary Yang


The facet functions and analytics working great, especially with json API !

As a developer, I would like a facet function to get a field value from one 
record from a group, please see this facet query:

{
"schema": {
"slide_id": {
"type": "long"
},
"slide_name": {
"type": "string"
},
"slide_create_time": {
"type": "timestamp"
}
},

"facet.query": {
"slide_viewed": {
"type": "terms",
"field": "slide_id",
"facet": {
"avg_viewed_time": "avg(slide_viewed_time)",
"created_time": "max(slide_create_time)",
"slide_name": 
"*{color:red}ANY_FIRST_LAST_OR_FILTER{color}*(slide_name)"
}
},
"total": {
"type": "query",
"q": "*:*",
"facet": {
"slide_num": "unique(slide_id)"
}
}
}
}

when grouping by slide_id, I would love to have the a function that can pick a 
slide name from each group of slides with the same slide_id.

thanks!



--
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-7825) Use slf4j consistently

[Shai Erera (JIRA)]

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

Shai Erera commented on SOLR-7825:
--

[~shalinmangar] I think I left it there by mistake, probably when I debugged 
the issue I added this test for, and forgot to remove it :). Thanks!

> Use slf4j consistently
> --
>
> Key: SOLR-7825
> URL: https://issues.apache.org/jira/browse/SOLR-7825
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.2.1
>Reporter: Oliver Schrenk
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Attachments: SOLR-7825.patch, slf4j.patch
>
>
> There are a few classes that directly rely on log4j to be on the classpath 
> instead and don't use the slf4j logging facade. This creates problems when 
> trying to switch the logging implementation. 
> 1. org.apache.solr.core.ZkContainer
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/core/ZkContainer.java#L218
> I don't know the impact of this change, but shouldn't this call 
> `org.apache.solr.logging.MDCLoggingContext.clear()` ?
> 2. org.apache.solr.handler.component.RangeFacetProcessor and 
> org.apache.solr.handler.component.RangeFacetRequest
> should use slf4j instead of log4j
> I had a stab at it at
> https://github.com/oschrenk/lucene-solr/commit/025b4802caf0360c63a3554af82e9ed4c94ff5a3#diff-7d822e8ff8ff21d88437652bbc894739R28



--
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] (LUCENE-6590) Explore different ways to apply boosts

[Yonik Seeley (JIRA)]

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

Yonik Seeley commented on LUCENE-6590:
--

bq. That's an interesting idea but I think this only applies to 
DefaultSimilarity? Other Similarities tend to handle boosts as multiplicative 
factors to the scores (because they return 1 in queryNorm instead of 
1/sqrt(sumOfSquaredWeights))?

If you're talking about a single query being boosted?  That edge case could be 
handled via a boolean query with a single clause (with that clause holding the 
boost).

bq. Also this might be an issue for DisjunctionMaxQuery which could not have 
different boosts per sub query anymore?

Yeah, that would also need clauses (and boosts on those clauses.)
Just throwing the idea out there... you're the one doing the work!


> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
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: Welcome Christine Poerschke as Lucene/Solr committer

[Joel Bernstein]

Welcome Christine!

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

On Fri, Jul 24, 2015 at 12:41 PM, Erik Hatcher 
wrote:

> Welcome aboard, Christine!
>
> > On Jul 24, 2015, at 03:27, Adrien Grand  wrote:
> >
> > I'm pleased to announce that Christine Poerschke has accepted the PMC's
> > invitation to become a committer.
> >
> > Christine, it's tradition that you introduce yourself with a brief bio.
> >
> > Your account is not entirely ready yet. We will let you know when it is
> created
> > and karma has been granted so that you can add yourself to the committers
> > section of the Who We Are page on the website:
> > .
> >
> > Congratulations and welcome!
> >
> > --
> > Adrien
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Christine Poerschke as Lucene/Solr committer

[Erik Hatcher]

Welcome aboard, Christine!

> On Jul 24, 2015, at 03:27, Adrien Grand  wrote:
> 
> I'm pleased to announce that Christine Poerschke has accepted the PMC's
> invitation to become a committer.
> 
> Christine, it's tradition that you introduce yourself with a brief bio.
> 
> Your account is not entirely ready yet. We will let you know when it is 
> created
> and karma has been granted so that you can add yourself to the committers
> section of the Who We Are page on the website:
> .
> 
> Congratulations and welcome!
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

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

[jira] [Updated] (SOLR-7825) Use slf4j consistently

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-7825:

Attachment: SOLR-7825.patch

Thanks Oliver.

This patch:
# Fixes almost all places except the classes which are specific to log4j or 
java.util.logging.
# Forbids usage of all log4j and java.util.logging classes across the entire 
Solr code base so that such mistakes do not occur again.
# The property configurator use inside MapReduceIndexerTool and Utils is 
refactored to a single method which is excluded from forbidden-apis check
# I don't know why ConcurrentDeleteAndCreateCollectionTest was trying to set 
logging levels directly but it doesn't seem useful and I removed it. [~shaie] - 
is this okay?
# The usage inside SolrCLI was only because it changed log levels for ZK and 
solrj to reduce noise. On [~thelabdude]'s suggestion, I set the log levels 
inside solr/server/scripts/cloud-scripts/log4j.properties instead of code. Also 
the default log level for org.apache.zookeeper is changed to WARN instead of 
ERROR. This is because if ZK is not running, the ZK client retries a few times 
and this activity is logged in WARN. If we set the log level to ERROR then the 
zkcli script just hangs for a while (more than a minute).

> Use slf4j consistently
> --
>
> Key: SOLR-7825
> URL: https://issues.apache.org/jira/browse/SOLR-7825
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.2.1
>Reporter: Oliver Schrenk
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Attachments: SOLR-7825.patch, slf4j.patch
>
>
> There are a few classes that directly rely on log4j to be on the classpath 
> instead and don't use the slf4j logging facade. This creates problems when 
> trying to switch the logging implementation. 
> 1. org.apache.solr.core.ZkContainer
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/core/ZkContainer.java#L218
> I don't know the impact of this change, but shouldn't this call 
> `org.apache.solr.logging.MDCLoggingContext.clear()` ?
> 2. org.apache.solr.handler.component.RangeFacetProcessor and 
> org.apache.solr.handler.component.RangeFacetRequest
> should use slf4j instead of log4j
> I had a stab at it at
> https://github.com/oschrenk/lucene-solr/commit/025b4802caf0360c63a3554af82e9ed4c94ff5a3#diff-7d822e8ff8ff21d88437652bbc894739R28



--
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: Welcome Christine Poerschke as Lucene/Solr committer

[Mark Miller]

Welcome!


On Fri, Jul 24, 2015 at 11:09 AM Erick Erickson 
wrote:

> Glad to have you aboard!
>
> Erick
>
> On Fri, Jul 24, 2015 at 6:12 AM, Stefan Matheis  wrote:
> > Congratulations, Christine!
> >
> > -Stefan
> >
> > On Friday, July 24, 2015 at 9:27 AM, Adrien Grand wrote:
> >
> > I'm pleased to announce that Christine Poerschke has accepted the PMC's
> > invitation to become a committer.
> >
> > Christine, it's tradition that you introduce yourself with a brief bio.
> >
> > Your account is not entirely ready yet. We will let you know when it is
> > created
> > and karma has been granted so that you can add yourself to the committers
> > section of the Who We Are page on the website:
> > .
> >
> > Congratulations and welcome!
> >
> > --
> > Adrien
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
- Mark
about.me/markrmiller

[jira] [Commented] (LUCENE-6694) Snowball stemmer for Lithuanian language

[ASF subversion and git services (JIRA)]

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

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

Commit 1692547 from [~rcmuir] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1692547 ]

LUCENE-6694: Add LithuanianAnalyzer and LithuanianStemmer

> Snowball stemmer for Lithuanian language
> 
>
> Key: LUCENE-6694
> URL: https://issues.apache.org/jira/browse/LUCENE-6694
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Dainius Jocas
>Priority: Minor
>  Labels: language, snowball, stemmer
> Fix For: 5.3
>
> Attachments: LUCENE-6694.patch, LUCENE-6694.patch, stem_ISO_8859_1.sbl
>
>
> Snowball stemmer for Lithuanian language.  



--
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] (LUCENE-6694) Snowball stemmer for Lithuanian language

[Robert Muir (JIRA)]

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

Robert Muir resolved LUCENE-6694.
-
Resolution: Fixed

Thanks Dainius!

> Snowball stemmer for Lithuanian language
> 
>
> Key: LUCENE-6694
> URL: https://issues.apache.org/jira/browse/LUCENE-6694
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Dainius Jocas
>Priority: Minor
>  Labels: language, snowball, stemmer
> Fix For: 5.3
>
> Attachments: LUCENE-6694.patch, LUCENE-6694.patch, stem_ISO_8859_1.sbl
>
>
> Snowball stemmer for Lithuanian language.  



--
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] (LUCENE-6694) Snowball stemmer for Lithuanian language

[ASF subversion and git services (JIRA)]

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

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

Commit 1692544 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1692544 ]

LUCENE-6694: Add LithuanianAnalyzer and LithuanianStemmer

> Snowball stemmer for Lithuanian language
> 
>
> Key: LUCENE-6694
> URL: https://issues.apache.org/jira/browse/LUCENE-6694
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Dainius Jocas
>Priority: Minor
>  Labels: language, snowball, stemmer
> Fix For: 5.3
>
> Attachments: LUCENE-6694.patch, LUCENE-6694.patch, stem_ISO_8859_1.sbl
>
>
> Snowball stemmer for Lithuanian language.  



--
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-5.x-Linux (32bit/jdk1.7.0_80) - Build # 13407 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13407/
Java: 32bit/jdk1.7.0_80 -server -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 26839 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.7
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.7
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/tools/forbiddenApis/lucene.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning for API signatures and dependencies...
[forbidden-apis] Forbidden method invocation: 
java.util.Collections#shuffle(java.util.List) [Use shuffle(List, Random) 
instead so that it can be reproduced]
[forbidden-apis]   in org.apache.lucene.index.TestFilterDirectoryReader 
(TestFilterDirectoryReader.java:67)
[forbidden-apis] Scanned 2575 (and 509 related) class file(s) for forbidden API 
invocations (in 1.09s), 1 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:723: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build.xml:107: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:2475: 
Check for forbidden API calls failed, see log.

Total time: 54 minutes 38 seconds
Build step 'Invoke Ant' marked build as failure
Archiving 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-trunk-Windows (32bit/jdk1.8.0_51) - Build # 5063 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5063/
Java: 32bit/jdk1.8.0_51 -client -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 26241 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading API signatures: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\tools\forbiddenApis\base.txt
[forbidden-apis] Reading API signatures: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\tools\forbiddenApis\lucene.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning for API signatures and dependencies...
[forbidden-apis] Forbidden method invocation: 
java.util.Collections#shuffle(java.util.List) [Use shuffle(List, Random) 
instead so that it can be reproduced]
[forbidden-apis]   in org.apache.lucene.index.TestFilterDirectoryReader 
(TestFilterDirectoryReader.java:67)
[forbidden-apis] Scanned 2503 (and 536 related) class file(s) for forbidden API 
invocations (in 0.91s), 1 error(s).

BUILD FAILED
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:713: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:117: The 
following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:107: 
The following error occurred while executing this line:
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:2391:
 Check for forbidden API calls failed, see log.

Total time: 80 minutes 24 seconds
Build step 'Invoke Ant' marked build as failure
Archiving 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

[jira] [Commented] (SOLR-7820) IndexFetcher should delete the current index directory before downloading the new index when isFullCopyNeeded==true

[Timothy Potter (JIRA)]

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

Timothy Potter commented on SOLR-7820:
--

Thanks for the feedback ... this actually came up in a production installation 
I worked on ... they had 1.4TB of indexes (oversharded on a node) and that node 
went down. When it came back, Solr decided all shards had to be fully copied 
over because they were too far out-of-date with the leader. The node could 
never recover because they didn't have another 1.4TB of SSD allocated on that 
node. Granted this is an extreme case. The interesting thing here is that node 
wasn't offline for very long, so I was surprised to see it need a full copy.

Part of this is bad design in that they shouldn't have oversharded the nodes as 
much given their space limitations.

I'm wondering if we can compute the necessary space needed for an incoming 
full-index for a shard and if that isn't available, then don't do it. Of course 
that's harder to do when oversharding. But to me that's better than running the 
disk out of space just to keep failing to recover.

I also want to put some more energy into trying to avoid a full copy because in 
my case, the node that went down wasn't out of sync with the leader by more 
than a couple thousand docs per shard, so the fact that Solr wanted to do a 
full copy of 1.4TB of indexes because a few thousand docs were missing sounds 
like the real culprit in my case.

> IndexFetcher should delete the current index directory before downloading the 
> new index when isFullCopyNeeded==true
> ---
>
> Key: SOLR-7820
> URL: https://issues.apache.org/jira/browse/SOLR-7820
> Project: Solr
>  Issue Type: Improvement
>  Components: replication (java)
>Reporter: Timothy Potter
>
> When a replica is trying to recover and it's IndexFetcher decides it needs to 
> pull the full index from a peer (isFullCopyNeeded == true), then the existing 
> index directory should be deleted before the full copy is started to free up 
> disk to pull a fresh index, otherwise the server will potentially need 2x the 
> disk space (old + incoming new). Currently, the IndexFetcher removes the 
> index directory after the new is downloaded; however, once the fetcher 
> decides a full copy is needed, what is the value of the existing index? It's 
> clearly out-of-date and should not serve queries. Since we're deleting data 
> preemptively, maybe this should be an advanced configuration property, only 
> to be used by those that are disk-space constrained (which I'm seeing more 
> and more with people deploying high-end SSDs - they typically don't have 2x 
> the disk capacity required by an index).



--
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: Welcome Christine Poerschke as Lucene/Solr committer

[Erick Erickson]

Glad to have you aboard!

Erick

On Fri, Jul 24, 2015 at 6:12 AM, Stefan Matheis  wrote:
> Congratulations, Christine!
>
> -Stefan
>
> On Friday, July 24, 2015 at 9:27 AM, Adrien Grand wrote:
>
> I'm pleased to announce that Christine Poerschke has accepted the PMC's
> invitation to become a committer.
>
> Christine, it's tradition that you introduce yourself with a brief bio.
>
> Your account is not entirely ready yet. We will let you know when it is
> created
> and karma has been granted so that you can add yourself to the committers
> section of the Who We Are page on the website:
> .
>
> Congratulations and welcome!
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

[jira] [Commented] (LUCENE-6696) FilterDirectoryReader.doClose() should call in.close() not in.doClose()

[ASF subversion and git services (JIRA)]

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

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

Commit 1692535 from [~jpountz] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1692535 ]

LUCENE-6696: Don't use the forbidden API Collections.shuffle(List).

> FilterDirectoryReader.doClose() should call in.close() not in.doClose()
> ---
>
> Key: LUCENE-6696
> URL: https://issues.apache.org/jira/browse/LUCENE-6696
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.3
>
> Attachments: LUCENE-6696.patch
>
>
> FilterDirectoryReader.doClose() calls in.doClose(). This is wrong because if 
> you call close() on both the underlying reader and a wrapper around it, then 
> doClose() will have been called several times, which will break ref counting.
> Instead, FilterDirectoryReader.doClose() should call in.close() so that it is 
> a no-op if the underlying reader is already closed, or so that calling 
> close() on the underlying reader afterwards will be a no-op.



--
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] (LUCENE-6696) FilterDirectoryReader.doClose() should call in.close() not in.doClose()

[ASF subversion and git services (JIRA)]

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

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

Commit 1692533 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1692533 ]

LUCENE-6696: Don't use the forbidden API Collections.shuffle(List).

> FilterDirectoryReader.doClose() should call in.close() not in.doClose()
> ---
>
> Key: LUCENE-6696
> URL: https://issues.apache.org/jira/browse/LUCENE-6696
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.3
>
> Attachments: LUCENE-6696.patch
>
>
> FilterDirectoryReader.doClose() calls in.doClose(). This is wrong because if 
> you call close() on both the underlying reader and a wrapper around it, then 
> doClose() will have been called several times, which will break ref counting.
> Instead, FilterDirectoryReader.doClose() should call in.close() so that it is 
> a no-op if the underlying reader is already closed, or so that calling 
> close() on the underlying reader afterwards will be a no-op.



--
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: [JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_51) - Build # 13586 - Failure!

[Adrien Grand]

I'll fix, sorry for the noise.

On Fri, Jul 24, 2015 at 4:47 PM, Policeman Jenkins Server
 wrote:
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13586/
> Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseParallelGC
>
> All tests passed
>
> Build Log:
> [...truncated 26369 lines...]
> -check-forbidden-all:
> [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
> [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
> [forbidden-apis] Reading API signatures: 
> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/base.txt
> [forbidden-apis] Reading API signatures: 
> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/lucene.txt
> [forbidden-apis] Loading classes to check...
> [forbidden-apis] Scanning for API signatures and dependencies...
> [forbidden-apis] Forbidden method invocation: 
> java.util.Collections#shuffle(java.util.List) [Use shuffle(List, Random) 
> instead so that it can be reproduced]
> [forbidden-apis]   in org.apache.lucene.index.TestFilterDirectoryReader 
> (TestFilterDirectoryReader.java:67)
> [forbidden-apis] Scanned 2503 (and 536 related) class file(s) for forbidden 
> API invocations (in 0.95s), 1 error(s).
>
> BUILD FAILED
> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:713: The following 
> error occurred while executing this line:
> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:117: The following 
> error occurred while executing this line:
> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:107: The 
> following error occurred while executing this line:
> /home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2391: 
> Check for forbidden API calls failed, see log.
>
> Total time: 49 minutes 48 seconds
> Build step 'Invoke Ant' marked build as failure
> Archiving 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



-- 
Adrien

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

[jira] [Commented] (SOLR-6688) There should be no error about a non-required file admin-extra.html

[Tramel Jones (JIRA)]

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

Tramel Jones commented on SOLR-6688:


Is this still the preferred solution to the admin-extra errors?

Should I keep the  block commented out, or remove it completely?

I am still experiencing the errors with the block commented out. 

> There should be no error about a non-required file admin-extra.html
> ---
>
> Key: SOLR-6688
> URL: https://issues.apache.org/jira/browse/SOLR-6688
> Project: Solr
>  Issue Type: Bug
>Reporter: Arkadiusz Robiński
>Priority: Minor
>
> I am using SOLR 4.10.1. I have a simple configuration with 2 cores. Every 
> time I open the SOLR admin interface, I get the following errors:
> {noformat}
> Can not find: admin-extra.html
> Can not find: admin-extra.menu-top.html
> Can not find: admin-extra.menu-bottom.html
> {noformat}
> As far as I know, the files are optional. Therefore I should not get any 
> error, not even a warning.
> I do not want to create the files because I do not need them. The error 
> should simply not be there.



--
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: Solr 5.x tests sometimes fail with PermGen error

[Uwe Schindler]

FYI: Windows does not fail, although it uses 2 JVMs to run tests, because it 
excludes HDFS/Hadoop.

Uwe

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


> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Friday, July 24, 2015 4:47 PM
> To: dev@lucene.apache.org
> Subject: RE: Solr 5.x tests sometimes fail with PermGen error
> 
> I reopened https://issues.apache.org/jira/browse/SOLR-5022.
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> 
> > -Original Message-
> > From: Uwe Schindler [mailto:u...@thetaphi.de]
> > Sent: Friday, July 24, 2015 4:14 PM
> > To: dev@lucene.apache.org
> > Subject: RE: Solr 5.x tests sometimes fail with PermGen error
> >
> > Next failure:
> > http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2493/console
> >
> > Had to kill manually. We should really fix that! No build with JDK 1.7
> > succeeds anymore! So something must have changed that uses tons of
> permgen!
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >
> > > -Original Message-
> > > From: Uwe Schindler [mailto:u...@thetaphi.de]
> > > Sent: Friday, July 24, 2015 9:35 AM
> > > To: dev@lucene.apache.org
> > > Subject: RE: Solr 5.x tests sometimes fail with PermGen error
> > >
> > > Hi,
> > >
> > > > Permgens are like JVM hanging completely -- there's not much the
> > > > test runner can do (because everything is typically and
> > > > effectively dead on the Java side of things).
> > > >
> > > > It needs to be solved in the code; there's very likely multiple
> > > > classloaders being loaded and something prevents them from being
> > > released.
> > >
> > > SolrResourceLoader... Maybe one of the test creates too many cores
> > > in parallel. As said, this only happened recently, and you can
> > > reproduce it. The reason why it mainly happens with MacOSX is the
> > > fact that this one runs on Policeman Jenkins with -Dtests.jvms=2, so
> > > each JVM has to run longer and each one fills permgen with more classes.
> > >
> > > So to debug, ideally run the tests with -Dtests.jvms=1, then it
> > > permgen- oom's  almost certainly!
> > >
> > > > Dawid
> > > >
> > > > On Fri, Jul 24, 2015 at 9:23 AM, Uwe Schindler 
> > wrote:
> > > > > Hi,
> > > > >
> > > > > (this is unrelated to my permgen improvements yesterday about
> > > > > the Ant
> > > > build). This mail is about the test runners. I had to kill builds
> > > > on MacOSX quite often because the test runner went into a permgen
> error.
> > > The problem:
> > > > Killing the jenkins job was not enough, because the test runners
> > > > not even reponsed to sigterm. You had to kill them (kill -9) it,
> > > > otherwise it never
> > > dies.
> > > > There is nothing the test runner can do, because it died completely.
> > > > >
> > > > > The reason is that on JDK 1.7 there is still permgen used and
> > > > > the test seem
> > > > to load too many classes or whatever, no idea:
> > > > > http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2492/
> > > > > (search for permgen n the logs).
> > > > >
> > > > > Please fix this before release, this happened quite often the
> > > > > last
> > > > > 2
> > > weeks!
> > > > > Uwe
> > > > >
> > > > > -
> > > > > Uwe Schindler
> > > > > H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de
> > > > > eMail: u...@thetaphi.de
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 
> > > > > --
> > > > > --- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > > > >
> > > >
> > > > --
> > > > --
> > > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
> > > > additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> > >
> > > 
> > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
> > > additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
> > additional commands, e-mail: dev-h...@lucene.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org


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

[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 3368 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/3368/

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest

Error Message:
ObjectTracker found 1 object(s) that were not released!!! [TransactionLog]

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [TransactionLog]
at __randomizedtesting.SeedInfo.seed([FB1C7E5482A49065]: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.afterClass(SolrTestCaseJ4.java:235)
at sun.reflect.GeneratedMethodAccessor34.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:799)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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:54)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 10642 lines...]
   [junit4] Suite: org.apache.solr.cloud.HttpPartitionTest
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.x-Java7/solr/build/solr-core/test/J0/temp/solr.cloud.HttpPartitionTest_FB1C7E5482A49065-001/init-core-data-001
   [junit4]   2> 534367 INFO  
(SUITE-HttpPartitionTest-seed#[FB1C7E5482A49065]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /v/vs
   [junit4]   2> 534371 INFO  
(TEST-HttpPartitionTest.test-seed#[FB1C7E5482A49065]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 534372 INFO  (Thread-1641) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 534372 INFO  (Thread-1641) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 534472 INFO  
(TEST-HttpPartitionTest.test-seed#[FB1C7E5482A49065]) [] 
o.a.s.c.ZkTestServer start zk server on port:48367
   [junit4]   2> 534472 INFO  
(TEST-HttpPartitionTest.test-seed#[FB1C7E5482A49065]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 534473 INFO  
(TEST-HttpPartitionTest.test-seed#[FB1C7E5482A49065]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 534475 INFO  (zkCallback-337-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@59a9829a 
name:ZooKeeperConnection Watcher:127.0.0.1:48367 got event WatchedEvent 
state:SyncConnected type:None path:null path:null type:None
   [junit4]   2> 534475 INFO  
(TEST-HttpPartitionTest.test-seed#[FB1C7E5482A49065]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 534476 INFO  
(TEST-HttpPartitionTest.test-seed#[FB1C7E5482A49065]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 534476 INFO  
(TEST-HttpPartitionTest.test-seed#[FB1C7E5482A49065]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 534478 INFO  
(TEST-HttpPartitionTest.test

[jira] [Updated] (SOLR-5022) PermGen exhausted test failures on Jenkins.

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-5022:

Priority: Critical  (was: Major)

> PermGen exhausted test failures on Jenkins.
> ---
>
> Key: SOLR-5022
> URL: https://issues.apache.org/jira/browse/SOLR-5022
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Uwe Schindler
>Priority: Critical
> Fix For: 5.3
>
> Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, 
> SOLR-5022.patch, intern-count-win.txt
>
>




--
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-5022) PermGen exhausted test failures on Jenkins.

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on SOLR-5022:
-

See: 
http://mail-archives.apache.org/mod_mbox/lucene-dev/201507.mbox/%3C05bb01d0c5e3%2442ed9960%24c8c8cc20%24%40thetaphi.de%3E

> PermGen exhausted test failures on Jenkins.
> ---
>
> Key: SOLR-5022
> URL: https://issues.apache.org/jira/browse/SOLR-5022
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Uwe Schindler
> Fix For: 5.3
>
> Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, 
> SOLR-5022.patch, intern-count-win.txt
>
>




--
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-trunk-Linux (64bit/jdk1.8.0_51) - Build # 13586 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13586/
Java: 64bit/jdk1.8.0_51 -XX:+UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 26369 lines...]
-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/base.txt
[forbidden-apis] Reading API signatures: 
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/lucene.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning for API signatures and dependencies...
[forbidden-apis] Forbidden method invocation: 
java.util.Collections#shuffle(java.util.List) [Use shuffle(List, Random) 
instead so that it can be reproduced]
[forbidden-apis]   in org.apache.lucene.index.TestFilterDirectoryReader 
(TestFilterDirectoryReader.java:67)
[forbidden-apis] Scanned 2503 (and 536 related) class file(s) for forbidden API 
invocations (in 0.95s), 1 error(s).

BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:713: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:117: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:107: The 
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2391: 
Check for forbidden API calls failed, see log.

Total time: 49 minutes 48 seconds
Build step 'Invoke Ant' marked build as failure
Archiving 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

RE: Solr 5.x tests sometimes fail with PermGen error

[Uwe Schindler]

I reopened https://issues.apache.org/jira/browse/SOLR-5022.

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


> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Friday, July 24, 2015 4:14 PM
> To: dev@lucene.apache.org
> Subject: RE: Solr 5.x tests sometimes fail with PermGen error
> 
> Next failure:
> http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2493/console
> 
> Had to kill manually. We should really fix that! No build with JDK 1.7 
> succeeds
> anymore! So something must have changed that uses tons of permgen!
> 
> Uwe
> 
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> 
> > -Original Message-
> > From: Uwe Schindler [mailto:u...@thetaphi.de]
> > Sent: Friday, July 24, 2015 9:35 AM
> > To: dev@lucene.apache.org
> > Subject: RE: Solr 5.x tests sometimes fail with PermGen error
> >
> > Hi,
> >
> > > Permgens are like JVM hanging completely -- there's not much the
> > > test runner can do (because everything is typically and effectively
> > > dead on the Java side of things).
> > >
> > > It needs to be solved in the code; there's very likely multiple
> > > classloaders being loaded and something prevents them from being
> > released.
> >
> > SolrResourceLoader... Maybe one of the test creates too many cores in
> > parallel. As said, this only happened recently, and you can reproduce
> > it. The reason why it mainly happens with MacOSX is the fact that this
> > one runs on Policeman Jenkins with -Dtests.jvms=2, so each JVM has to
> > run longer and each one fills permgen with more classes.
> >
> > So to debug, ideally run the tests with -Dtests.jvms=1, then it
> > permgen- oom's  almost certainly!
> >
> > > Dawid
> > >
> > > On Fri, Jul 24, 2015 at 9:23 AM, Uwe Schindler 
> wrote:
> > > > Hi,
> > > >
> > > > (this is unrelated to my permgen improvements yesterday about the
> > > > Ant
> > > build). This mail is about the test runners. I had to kill builds on
> > > MacOSX quite often because the test runner went into a permgen error.
> > The problem:
> > > Killing the jenkins job was not enough, because the test runners not
> > > even reponsed to sigterm. You had to kill them (kill -9) it,
> > > otherwise it never
> > dies.
> > > There is nothing the test runner can do, because it died completely.
> > > >
> > > > The reason is that on JDK 1.7 there is still permgen used and the
> > > > test seem
> > > to load too many classes or whatever, no idea:
> > > > http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2492/
> > > > (search for permgen n the logs).
> > > >
> > > > Please fix this before release, this happened quite often the last
> > > > 2
> > weeks!
> > > > Uwe
> > > >
> > > > -
> > > > Uwe Schindler
> > > > H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de
> > > > eMail: u...@thetaphi.de
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > --- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
> > > > additional commands, e-mail: dev-h...@lucene.apache.org
> > > >
> > >
> > > 
> > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
> > > additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
> > additional commands, e-mail: dev-h...@lucene.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org


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

[jira] [Updated] (SOLR-5022) PermGen exhausted test failures on Jenkins.

[Uwe Schindler (JIRA)]

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

Uwe Schindler updated SOLR-5022:

Fix Version/s: (was: 5.0)
   (was: Trunk)
   5.3

> PermGen exhausted test failures on Jenkins.
> ---
>
> Key: SOLR-5022
> URL: https://issues.apache.org/jira/browse/SOLR-5022
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Uwe Schindler
> Fix For: 5.3
>
> Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, 
> SOLR-5022.patch, intern-count-win.txt
>
>




--
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-5022) PermGen exhausted test failures on Jenkins.

[Uwe Schindler (JIRA)]

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

Uwe Schindler reopened SOLR-5022:
-

I want to reopen this. Recently because there were more and more libraries 
added to Solr's core, the tests are hanging (kill -9 required) more often in 
branch_5x. This is no longer an issue in trunk.

I would propose to apply the provided patch, but only set permgen for Java 7 
(Oracle variant)

> PermGen exhausted test failures on Jenkins.
> ---
>
> Key: SOLR-5022
> URL: https://issues.apache.org/jira/browse/SOLR-5022
> Project: Solr
>  Issue Type: Test
>  Components: Tests
>Reporter: Mark Miller
>Assignee: Uwe Schindler
> Fix For: 5.3
>
> Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, 
> SOLR-5022.patch, intern-count-win.txt
>
>




--
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-7825) Use slf4j consistently

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar reassigned SOLR-7825:
---

Assignee: Shalin Shekhar Mangar

> Use slf4j consistently
> --
>
> Key: SOLR-7825
> URL: https://issues.apache.org/jira/browse/SOLR-7825
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.2.1
>Reporter: Oliver Schrenk
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Attachments: slf4j.patch
>
>
> There are a few classes that directly rely on log4j to be on the classpath 
> instead and don't use the slf4j logging facade. This creates problems when 
> trying to switch the logging implementation. 
> 1. org.apache.solr.core.ZkContainer
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/core/ZkContainer.java#L218
> I don't know the impact of this change, but shouldn't this call 
> `org.apache.solr.logging.MDCLoggingContext.clear()` ?
> 2. org.apache.solr.handler.component.RangeFacetProcessor and 
> org.apache.solr.handler.component.RangeFacetRequest
> should use slf4j instead of log4j
> I had a stab at it at
> https://github.com/oschrenk/lucene-solr/commit/025b4802caf0360c63a3554af82e9ed4c94ff5a3#diff-7d822e8ff8ff21d88437652bbc894739R28



--
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-7819) ZkController.ensureReplicaInLeaderInitiatedRecovery does not respect retryOnConnLoss

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar commented on SOLR-7819:
-

bq. I think we already do this, look at DistributedUpdateProcessor.java around 
line 883, if we are unable to set the LIR node, we start a thread to keep 
retrying the node set.

Umm, it looks the reverse to me. If we are unable to set the LIR node or if 
there is an exception then sendRecoveryCommand=false and we do not create the 
LeaderInitiatedRecoveryThread at all?

> ZkController.ensureReplicaInLeaderInitiatedRecovery does not respect 
> retryOnConnLoss
> 
>
> Key: SOLR-7819
> URL: https://issues.apache.org/jira/browse/SOLR-7819
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.2, 5.2.1
>Reporter: Shalin Shekhar Mangar
>  Labels: Jepsen
> Fix For: 5.3, Trunk
>
>
> SOLR-7245 added a retryOnConnLoss parameter to 
> ZkController.ensureReplicaInLeaderInitiatedRecovery so that indexing threads 
> do not hang during a partition on ZK operations. However, some of those 
> changes were unintentionally reverted by SOLR-7336 in 5.2.
> I found this while running Jepsen tests on 5.2.1 where a hung update managed 
> to put a leader into a 'down' state (I'm still investigating and will open a 
> separate issue about this problem).



--
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-7825) Use slf4j consistently

[Oliver Schrenk (JIRA)]

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

Oliver Schrenk updated SOLR-7825:
-
Attachment: slf4j.patch

> Use slf4j consistently
> --
>
> Key: SOLR-7825
> URL: https://issues.apache.org/jira/browse/SOLR-7825
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.2.1
>Reporter: Oliver Schrenk
>Priority: Minor
> Attachments: slf4j.patch
>
>
> There are a few classes that directly rely on log4j to be on the classpath 
> instead and don't use the slf4j logging facade. This creates problems when 
> trying to switch the logging implementation. 
> 1. org.apache.solr.core.ZkContainer
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/core/ZkContainer.java#L218
> I don't know the impact of this change, but shouldn't this call 
> `org.apache.solr.logging.MDCLoggingContext.clear()` ?
> 2. org.apache.solr.handler.component.RangeFacetProcessor and 
> org.apache.solr.handler.component.RangeFacetRequest
> should use slf4j instead of log4j
> I had a stab at it at
> https://github.com/oschrenk/lucene-solr/commit/025b4802caf0360c63a3554af82e9ed4c94ff5a3#diff-7d822e8ff8ff21d88437652bbc894739R28



--
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-7825) Use slf4j consistently

[Oliver Schrenk (JIRA)]

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

Oliver Schrenk commented on SOLR-7825:
--

The logging implementations of dependencies can't be changed. As you mentioned 
though, not all is lost and these calls can be intercepted. I felt though that 
at least core should strive for consistency in its logging usage. There are 
actually not so many usages throughout the project

There are some instances in contrib

{code}
contrib/map-reduce/src/java/org/apache/solr/hadoop/MapReduceIndexerTool.java
contrib/map-reduce/src/java/org/apache/solr/hadoop/SolrRecordWriter.java
contrib/map-reduce/src/java/org/apache/solr/hadoop/Utils.java
{code}

or just used by contrib

{code}
core/src/java/org/apache/solr/util/SolrLogLayout.java
{code}

Then there are that are specific to log4j. Im not sure how they are used.

{code}
core/src/java/org/apache/solr/logging/log4j/EventAppender.java
core/src/java/org/apache/solr/logging/log4j/Log4jInfo.java:22
core/src/java/org/apache/solr/logging/log4j/Log4jWatcher.java
{code}

This is standalone

{code}
core/src/java/org/apache/solr/util/SolrCLI.java
{code}

Usages in test

{code}
core/src/test/org/apache/solr/cloud/ConcurrentDeleteAndCreateCollectionTest.java
core/src/test/org/apache/solr/handler/admin/LoggingHandlerTest.java
core/src/test/org/apache/solr/handler/RequestLoggingTest.java
{code}


I just thought I start because the one in ZkContainer was actually a nuisance 
to me (because I wasn't aware of {{log4j-over-slf4}}




> Use slf4j consistently
> --
>
> Key: SOLR-7825
> URL: https://issues.apache.org/jira/browse/SOLR-7825
> Project: Solr
>  Issue Type: Improvement
>  Components: Server
>Affects Versions: 5.2.1
>Reporter: Oliver Schrenk
>Priority: Minor
> Attachments: slf4j.patch
>
>
> There are a few classes that directly rely on log4j to be on the classpath 
> instead and don't use the slf4j logging facade. This creates problems when 
> trying to switch the logging implementation. 
> 1. org.apache.solr.core.ZkContainer
> https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/core/ZkContainer.java#L218
> I don't know the impact of this change, but shouldn't this call 
> `org.apache.solr.logging.MDCLoggingContext.clear()` ?
> 2. org.apache.solr.handler.component.RangeFacetProcessor and 
> org.apache.solr.handler.component.RangeFacetRequest
> should use slf4j instead of log4j
> I had a stab at it at
> https://github.com/oschrenk/lucene-solr/commit/025b4802caf0360c63a3554af82e9ed4c94ff5a3#diff-7d822e8ff8ff21d88437652bbc894739R28



--
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: Solr 5.x tests sometimes fail with PermGen error

[Uwe Schindler]

Next failure:
http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2493/console

Had to kill manually. We should really fix that! No build with JDK 1.7 succeeds 
anymore! So something must have changed that uses tons of permgen!

Uwe

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


> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Friday, July 24, 2015 9:35 AM
> To: dev@lucene.apache.org
> Subject: RE: Solr 5.x tests sometimes fail with PermGen error
> 
> Hi,
> 
> > Permgens are like JVM hanging completely -- there's not much the test
> > runner can do (because everything is typically and effectively dead on
> > the Java side of things).
> >
> > It needs to be solved in the code; there's very likely multiple
> > classloaders being loaded and something prevents them from being
> released.
> 
> SolrResourceLoader... Maybe one of the test creates too many cores in
> parallel. As said, this only happened recently, and you can reproduce it. The
> reason why it mainly happens with MacOSX is the fact that this one runs on
> Policeman Jenkins with -Dtests.jvms=2, so each JVM has to run longer and
> each one fills permgen with more classes.
> 
> So to debug, ideally run the tests with -Dtests.jvms=1, then it permgen-
> oom's  almost certainly!
> 
> > Dawid
> >
> > On Fri, Jul 24, 2015 at 9:23 AM, Uwe Schindler  wrote:
> > > Hi,
> > >
> > > (this is unrelated to my permgen improvements yesterday about the
> > > Ant
> > build). This mail is about the test runners. I had to kill builds on
> > MacOSX quite often because the test runner went into a permgen error.
> The problem:
> > Killing the jenkins job was not enough, because the test runners not
> > even reponsed to sigterm. You had to kill them (kill -9) it, otherwise it 
> > never
> dies.
> > There is nothing the test runner can do, because it died completely.
> > >
> > > The reason is that on JDK 1.7 there is still permgen used and the
> > > test seem
> > to load too many classes or whatever, no idea:
> > > http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2492/
> > > (search for permgen n the logs).
> > >
> > > Please fix this before release, this happened quite often the last 2
> weeks!
> > > Uwe
> > >
> > > -
> > > Uwe Schindler
> > > H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de
> > > eMail: u...@thetaphi.de
> > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
> > > additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> > commands, e-mail: dev-h...@lucene.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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

[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 2493 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/2493/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.TestDistributedSearch.test

Error Message:
Error from server at https://127.0.0.1:57406//collection1: 
java.lang.NullPointerException  at 
org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:102)
  at 
org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:747)
  at 
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:730)
  at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:410)
  at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)  at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:649)  at 
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:453)  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
  at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
  at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:106)
  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
  at 
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)  
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)  at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
  at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) 
 at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
  at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)  
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
  at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)  
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)  
at org.eclipse.jetty.server.Server.handle(Server.java:499)  at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)  at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)  at 
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)  at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
  at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) 
 at java.lang.Thread.run(Thread.java:745) 

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:57406//collection1: 
java.lang.NullPointerException
at 
org.apache.solr.search.grouping.distributed.responseprocessor.TopGroupsShardResponseProcessor.process(TopGroupsShardResponseProcessor.java:102)
at 
org.apache.solr.handler.component.QueryComponent.handleGroupedResponses(QueryComponent.java:747)
at 
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:730)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:410)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2068)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:649)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:453)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at 
org.apache.solr.client.solrj.embedded.JettySolrRunner$DebugFilter.doFilter(JettySolrRunner.java:106)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at 
org.eclipse.jetty.servlets.UserAgentFilter.doFilter(UserAgentFilter.java:83)
at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:364)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at 
org.eclipse.jetty.

[jira] [Resolved] (LUCENE-6696) FilterDirectoryReader.doClose() should call in.close() not in.doClose()

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-6696.
--
   Resolution: Fixed
Fix Version/s: 5.3

> FilterDirectoryReader.doClose() should call in.close() not in.doClose()
> ---
>
> Key: LUCENE-6696
> URL: https://issues.apache.org/jira/browse/LUCENE-6696
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: 5.3
>
> Attachments: LUCENE-6696.patch
>
>
> FilterDirectoryReader.doClose() calls in.doClose(). This is wrong because if 
> you call close() on both the underlying reader and a wrapper around it, then 
> doClose() will have been called several times, which will break ref counting.
> Instead, FilterDirectoryReader.doClose() should call in.close() so that it is 
> a no-op if the underlying reader is already closed, or so that calling 
> close() on the underlying reader afterwards will be a no-op.



--
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-trunk-Java8 - Build # 230 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java8/230/

1 tests failed.
REGRESSION:  org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest

Error Message:
There are still nodes recoverying - waited for 330 seconds

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 330 
seconds
at 
__randomizedtesting.SeedInfo.seed([5F6FAB1BA0960AE4:F82B13BFCD2D195D]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319)
at 
org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplicationAfterPeerSync(CdcrReplicationHandlerTest.java:158)
at 
org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:53)
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:497)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:845)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792)
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:46)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
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

[jira] [Comment Edited] (SOLR-7760) Fix method and field visibility for UIMAUpdateRequestProcessor and SolrUIMAConfiguration

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili edited comment on SOLR-7760 at 7/24/15 1:54 PM:


I remember myself having the same need some time ago but I cannot remember what 
was the rationale. [~aaronlab] can you clarify the use case for that ?


was (Author: teofili):
I remember myself having the same need some time ago but I cannot remember what 
was the rationale. [~aaronlab] you clarify the use case for that ?

> Fix method and field visibility for UIMAUpdateRequestProcessor and 
> SolrUIMAConfiguration
> 
>
> Key: SOLR-7760
> URL: https://issues.apache.org/jira/browse/SOLR-7760
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - UIMA
>Affects Versions: 5x
>Reporter: Aaron LaBella
>Priority: Critical
> Fix For: 5.3
>
> Attachments: SOLR-7760.patch
>
>
> The methods in 
> {{solr/contrib/uima/src/java/org/apache/solr/uima/processor/SolrUIMAConfiguration.java}}
>  are not public and they need to be for other code to be able to make use of 
> the configuration data, ie: mapped fields.   Likewise, 
> {{solr/contrib/uima/src/java/org/apache/solr/uima/processor/UIMAUpdateRequestProcessor.java}}
>  does not have an accessor for the SolrUIMAConfiguration object



--
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-7760) Fix method and field visibility for UIMAUpdateRequestProcessor and SolrUIMAConfiguration

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili commented on SOLR-7760:
---

I remember myself having the same need some time ago but I cannot remember what 
was the rationale. [~aaronlab] you clarify the use case for that ?

> Fix method and field visibility for UIMAUpdateRequestProcessor and 
> SolrUIMAConfiguration
> 
>
> Key: SOLR-7760
> URL: https://issues.apache.org/jira/browse/SOLR-7760
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - UIMA
>Affects Versions: 5x
>Reporter: Aaron LaBella
>Priority: Critical
> Fix For: 5.3
>
> Attachments: SOLR-7760.patch
>
>
> The methods in 
> {{solr/contrib/uima/src/java/org/apache/solr/uima/processor/SolrUIMAConfiguration.java}}
>  are not public and they need to be for other code to be able to make use of 
> the configuration data, ie: mapped fields.   Likewise, 
> {{solr/contrib/uima/src/java/org/apache/solr/uima/processor/UIMAUpdateRequestProcessor.java}}
>  does not have an accessor for the SolrUIMAConfiguration object



--
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] (LUCENE-6696) FilterDirectoryReader.doClose() should call in.close() not in.doClose()

[ASF subversion and git services (JIRA)]

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

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

Commit 1692512 from [~jpountz] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1692512 ]

LUCENE-6696: Fix FilterDirectoryReader.doClose to call in.close() instead of 
in.doClose().

> FilterDirectoryReader.doClose() should call in.close() not in.doClose()
> ---
>
> Key: LUCENE-6696
> URL: https://issues.apache.org/jira/browse/LUCENE-6696
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6696.patch
>
>
> FilterDirectoryReader.doClose() calls in.doClose(). This is wrong because if 
> you call close() on both the underlying reader and a wrapper around it, then 
> doClose() will have been called several times, which will break ref counting.
> Instead, FilterDirectoryReader.doClose() should call in.close() so that it is 
> a no-op if the underlying reader is already closed, or so that calling 
> close() on the underlying reader afterwards will be a no-op.



--
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] (LUCENE-6696) FilterDirectoryReader.doClose() should call in.close() not in.doClose()

[ASF subversion and git services (JIRA)]

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

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

Commit 1692505 from [~jpountz] in branch 'dev/trunk'
[ https://svn.apache.org/r1692505 ]

LUCENE-6696: Fix FilterDirectoryReader.doClose to call in.close() instead of 
in.doClose().

> FilterDirectoryReader.doClose() should call in.close() not in.doClose()
> ---
>
> Key: LUCENE-6696
> URL: https://issues.apache.org/jira/browse/LUCENE-6696
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6696.patch
>
>
> FilterDirectoryReader.doClose() calls in.doClose(). This is wrong because if 
> you call close() on both the underlying reader and a wrapper around it, then 
> doClose() will have been called several times, which will break ref counting.
> Instead, FilterDirectoryReader.doClose() should call in.close() so that it is 
> a no-op if the underlying reader is already closed, or so that calling 
> close() on the underlying reader afterwards will be a no-op.



--
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] (LUCENE-6696) FilterDirectoryReader.doClose() should call in.close() not in.doClose()

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6696:
-

+1

> FilterDirectoryReader.doClose() should call in.close() not in.doClose()
> ---
>
> Key: LUCENE-6696
> URL: https://issues.apache.org/jira/browse/LUCENE-6696
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6696.patch
>
>
> FilterDirectoryReader.doClose() calls in.doClose(). This is wrong because if 
> you call close() on both the underlying reader and a wrapper around it, then 
> doClose() will have been called several times, which will break ref counting.
> Instead, FilterDirectoryReader.doClose() should call in.close() so that it is 
> a no-op if the underlying reader is already closed, or so that calling 
> close() on the underlying reader afterwards will be a no-op.



--
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] (LUCENE-6696) FilterDirectoryReader.doClose() should call in.close() not in.doClose()

[Adrien Grand (JIRA)]

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

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

Here is a patch.

> FilterDirectoryReader.doClose() should call in.close() not in.doClose()
> ---
>
> Key: LUCENE-6696
> URL: https://issues.apache.org/jira/browse/LUCENE-6696
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6696.patch
>
>
> FilterDirectoryReader.doClose() calls in.doClose(). This is wrong because if 
> you call close() on both the underlying reader and a wrapper around it, then 
> doClose() will have been called several times, which will break ref counting.
> Instead, FilterDirectoryReader.doClose() should call in.close() so that it is 
> a no-op if the underlying reader is already closed, or so that calling 
> close() on the underlying reader afterwards will be a no-op.



--
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: Welcome Christine Poerschke as Lucene/Solr committer

[Stefan Matheis]

Congratulations, Christine! 

-Stefan 


On Friday, July 24, 2015 at 9:27 AM, Adrien Grand wrote:

> I'm pleased to announce that Christine Poerschke has accepted the PMC's
> invitation to become a committer.
> 
> Christine, it's tradition that you introduce yourself with a brief bio.
> 
> Your account is not entirely ready yet. We will let you know when it is 
> created
> and karma has been granted so that you can add yourself to the committers
> section of the Who We Are page on the website:
> .
> 
> Congratulations and welcome!
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> (mailto:dev-unsubscr...@lucene.apache.org)
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> (mailto:dev-h...@lucene.apache.org)
> 
> 

[jira] [Updated] (LUCENE-6695) BlendedTermQuery

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-6695:
-
Attachment: (was: LUCENE-6695.patch)

> BlendedTermQuery
> 
>
> Key: LUCENE-6695
> URL: https://issues.apache.org/jira/browse/LUCENE-6695
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6695.patch, LUCENE-6695.patch
>
>
> It is sometimes desirable to ignore differences between index statistics of 
> several terms so that they produce the same scores, for instance if you 
> resolve synonyms at search time or if you want to search across several 
> fields. Elasticsearch has been using this approach for its multi_match query 
> for some time now.
> We already blend statistics in TopTermsBlendedFreqScoringRewrite (used by 
> FuzzyQuery) but it could be helpful to have a dedicated query to choose 
> manually which terms to blend stats from.



--
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] (LUCENE-6695) BlendedTermQuery

[Adrien Grand (JIRA)]

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

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

Here is a patch.

> BlendedTermQuery
> 
>
> Key: LUCENE-6695
> URL: https://issues.apache.org/jira/browse/LUCENE-6695
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6695.patch, LUCENE-6695.patch
>
>
> It is sometimes desirable to ignore differences between index statistics of 
> several terms so that they produce the same scores, for instance if you 
> resolve synonyms at search time or if you want to search across several 
> fields. Elasticsearch has been using this approach for its multi_match query 
> for some time now.
> We already blend statistics in TopTermsBlendedFreqScoringRewrite (used by 
> FuzzyQuery) but it could be helpful to have a dedicated query to choose 
> manually which terms to blend stats from.



--
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] [Issue Comment Deleted] (LUCENE-6695) BlendedTermQuery

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-6695:
-
Comment: was deleted

(was: Here is a patch.)

> BlendedTermQuery
> 
>
> Key: LUCENE-6695
> URL: https://issues.apache.org/jira/browse/LUCENE-6695
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6695.patch, LUCENE-6695.patch
>
>
> It is sometimes desirable to ignore differences between index statistics of 
> several terms so that they produce the same scores, for instance if you 
> resolve synonyms at search time or if you want to search across several 
> fields. Elasticsearch has been using this approach for its multi_match query 
> for some time now.
> We already blend statistics in TopTermsBlendedFreqScoringRewrite (used by 
> FuzzyQuery) but it could be helpful to have a dedicated query to choose 
> manually which terms to blend stats from.



--
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: Welcome Christine Poerschke as Lucene/Solr committer

[Steve Rowe]

Welcome Christine!

Steve
www.lucidworks.com

On Friday, July 24, 2015, Adrien Grand  wrote:

> I'm pleased to announce that Christine Poerschke has accepted the PMC's
> invitation to become a committer.
>
> Christine, it's tradition that you introduce yourself with a brief bio.
>
> Your account is not entirely ready yet. We will let you know when it is
> created
> and karma has been granted so that you can add yourself to the committers
> section of the Who We Are page on the website:
> .
>
> Congratulations and welcome!
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
>
>

[jira] [Created] (LUCENE-6696) FilterDirectoryReader.doClose() should call in.close() not in.doClose()

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6696:


 Summary: FilterDirectoryReader.doClose() should call in.close() 
not in.doClose()
 Key: LUCENE-6696
 URL: https://issues.apache.org/jira/browse/LUCENE-6696
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor


FilterDirectoryReader.doClose() calls in.doClose(). This is wrong because if 
you call close() on both the underlying reader and a wrapper around it, then 
doClose() will have been called several times, which will break ref counting.

Instead, FilterDirectoryReader.doClose() should call in.close() so that it is a 
no-op if the underlying reader is already closed, or so that calling close() on 
the underlying reader afterwards will be a no-op.



--
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] (LUCENE-6694) Snowball stemmer for Lithuanian language

[Robert Muir (JIRA)]

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

Robert Muir updated LUCENE-6694:

Fix Version/s: 5.3

> Snowball stemmer for Lithuanian language
> 
>
> Key: LUCENE-6694
> URL: https://issues.apache.org/jira/browse/LUCENE-6694
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Dainius Jocas
>Priority: Minor
>  Labels: language, snowball, stemmer
> Fix For: 5.3
>
> Attachments: LUCENE-6694.patch, LUCENE-6694.patch, stem_ISO_8859_1.sbl
>
>
> Snowball stemmer for Lithuanian language.  



--
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] (LUCENE-6694) Snowball stemmer for Lithuanian language

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-6694:
-

Thanks for checking! I plan to commit this later today.

> Snowball stemmer for Lithuanian language
> 
>
> Key: LUCENE-6694
> URL: https://issues.apache.org/jira/browse/LUCENE-6694
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Dainius Jocas
>Priority: Minor
>  Labels: language, snowball, stemmer
> Fix For: 5.3
>
> Attachments: LUCENE-6694.patch, LUCENE-6694.patch, stem_ISO_8859_1.sbl
>
>
> Snowball stemmer for Lithuanian language.  



--
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: Welcome Christine Poerschke as Lucene/Solr committer

[Yonik Seeley]

Congrats and welcome Christine!

-Yonik

On Fri, Jul 24, 2015 at 3:27 AM, Adrien Grand  wrote:
> I'm pleased to announce that Christine Poerschke has accepted the PMC's
> invitation to become a committer.
>
> Christine, it's tradition that you introduce yourself with a brief bio.
>
> Your account is not entirely ready yet. We will let you know when it is 
> created
> and karma has been granted so that you can add yourself to the committers
> section of the Who We Are page on the website:
> .
>
> Congratulations and welcome!
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

[jira] [Commented] (LUCENE-6012) AnalyzingSuggester exception because of length restriction: java.lang.IllegalArgumentException: len must be <= 32767; got 38751

[Michael Aleythe (JIRA)]

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

Michael Aleythe commented on LUCENE-6012:
-

does this limitation mean that the main text-field from the index should not be 
used as the base field for the suggestion component?

> AnalyzingSuggester exception because of length restriction: 
> java.lang.IllegalArgumentException: len must be <= 32767; got 38751
> ---
>
> Key: LUCENE-6012
> URL: https://issues.apache.org/jira/browse/LUCENE-6012
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 4.10.1
>Reporter: Daniel Aschauer
>  Labels: length, short, suggest
>
> I want to use a suggester but every time i want to build the index I get an 
> exception.
> As the exception comes from AnalyzingSuggester all kind of suggesters that 
> are subclasses fail to build.
> By now I don't understand the code for the suggester well and thus was not 
> able to track the error further down.
> OfflineSorter$ByteSequencesWriter tries to write the length of the bytearray 
> which not exceed 32767 because it is a short.
> 6877 [http-bio-8080-exec-2] ERROR org.apache.solr.core.SolrCore  - 
> java.lang.IllegalArgumentException: len must be <= 32767; got 38751
> at 
> org.apache.lucene.util.OfflineSorter$ByteSequencesWriter.write(OfflineSorter.java:479)
> at 
> org.apache.lucene.search.suggest.analyzing.AnalyzingSuggester.build(AnalyzingSuggester.java:496)
> at org.apache.lucene.search.suggest.Lookup.build(Lookup.java:190)



--
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] (LUCENE-6695) BlendedTermQuery

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6695:
--

Oops my bad, I thought we could still rewrite sub queries if the method was 
protected, but it would only work for queries defined in the oal.search package.

> BlendedTermQuery
> 
>
> Key: LUCENE-6695
> URL: https://issues.apache.org/jira/browse/LUCENE-6695
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6695.patch, LUCENE-6695.patch
>
>
> It is sometimes desirable to ignore differences between index statistics of 
> several terms so that they produce the same scores, for instance if you 
> resolve synonyms at search time or if you want to search across several 
> fields. Elasticsearch has been using this approach for its multi_match query 
> for some time now.
> We already blend statistics in TopTermsBlendedFreqScoringRewrite (used by 
> FuzzyQuery) but it could be helpful to have a dedicated query to choose 
> manually which terms to blend stats from.



--
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] (LUCENE-6695) BlendedTermQuery

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6695:
--

bq. I would make rewrite() a protected method

I think we should do that. The only purpose of rewriting a query is to create a 
Weight, so we need to reduce the visibility of this method or remove it 
(trickier). Also I think it's very trappy today that createWeight is not 
functional unless you have a rewritten query.

I think there are several issues with RewriteableQuery, for instance compound 
queries would not be able anymore to rewrite their inner queries, and also we 
have several queries that implement both rewrite() and createWeight().

> BlendedTermQuery
> 
>
> Key: LUCENE-6695
> URL: https://issues.apache.org/jira/browse/LUCENE-6695
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6695.patch, LUCENE-6695.patch
>
>
> It is sometimes desirable to ignore differences between index statistics of 
> several terms so that they produce the same scores, for instance if you 
> resolve synonyms at search time or if you want to search across several 
> fields. Elasticsearch has been using this approach for its multi_match query 
> for some time now.
> We already blend statistics in TopTermsBlendedFreqScoringRewrite (used by 
> FuzzyQuery) but it could be helpful to have a dedicated query to choose 
> manually which terms to blend stats from.



--
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] (LUCENE-6695) BlendedTermQuery

[Uwe Schindler (JIRA)]

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

Uwe Schindler edited comment on LUCENE-6695 at 7/24/15 11:47 AM:
-

bq. Eventually I would like to remove this rewrite() method from the public API 
of Query, it should really be an implementation detail of createWeight!

I would make rewrite() a protected method in Query and let the default impl of 
createWeight() call it. If a query does not implement createWeight (therefore, 
default impl is used), that one does the rewrite loop and calls createWeight on 
the final one. Currently createWeight throws UOE, this would also repair that. 
Of course default rewrite impl would need to be fixed (and rewrite should throw 
UOE by default). A query that implement createWeight, would not call rewrite.

Alternatively add a "RewriteableQuery" with a final createWeight doing the 
loop) that has an abstract rewrite() method...

By that no "consumer" of the query would ever call rewrite, they just call 
createWeight() before execution.

(this are just ideas, maybe let's create separate issue)


was (Author: thetaphi):
bq. Eventually I would like to remove this rewrite() method from the public API 
of Query, it should really be an implementation detail of createWeight!

I would make rewrite() a protected method in Query and let the default impl of 
createWeight() call it. If a query does not implement createWeight (therefore, 
default impl is used), that one does the rewrite loop and calls createWeight on 
the final one. Currently createWeight throws UOE, this would also repair that. 
Of course default rewrite impl would need to be fixed (and rewrite should throw 
UOE by default). A query that implement createWeight, would not call rewrite.

By that no "consumer" of the query would ever call rewrite, they just call 
createWeight() before execution.

(this are just ideas, maybe let's create separate issue)

> BlendedTermQuery
> 
>
> Key: LUCENE-6695
> URL: https://issues.apache.org/jira/browse/LUCENE-6695
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6695.patch, LUCENE-6695.patch
>
>
> It is sometimes desirable to ignore differences between index statistics of 
> several terms so that they produce the same scores, for instance if you 
> resolve synonyms at search time or if you want to search across several 
> fields. Elasticsearch has been using this approach for its multi_match query 
> for some time now.
> We already blend statistics in TopTermsBlendedFreqScoringRewrite (used by 
> FuzzyQuery) but it could be helpful to have a dedicated query to choose 
> manually which terms to blend stats from.



--
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] (LUCENE-6694) Snowball stemmer for Lithuanian language

[Dainius Jocas (JIRA)]

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

Dainius Jocas commented on LUCENE-6694:
---

Thanks! When designing the stemmer, I've put emphasis on improving noun 
stemming because majority of complaints from our clients were mistakes in noun 
stemming. Of course, Lithuanian language is complicated and there are enough 
space for improvements.

I've checked the latest patch and found no problems.

> Snowball stemmer for Lithuanian language
> 
>
> Key: LUCENE-6694
> URL: https://issues.apache.org/jira/browse/LUCENE-6694
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Dainius Jocas
>Priority: Minor
>  Labels: language, snowball, stemmer
> Attachments: LUCENE-6694.patch, LUCENE-6694.patch, stem_ISO_8859_1.sbl
>
>
> Snowball stemmer for Lithuanian language.  



--
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] (LUCENE-6695) BlendedTermQuery

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6695:
---

bq. Eventually I would like to remove this rewrite() method from the public API 
of Query, it should really be an implementation detail of createWeight!

I would make rewrite() a protected method in Query and let the default impl of 
createWeight() call it. If a query does not implement createWeight (therefore, 
default impl is used), that one does the rewrite loop and calls createWeight on 
the final one. Currently createWeight throws UOE, this would also repair that. 
Of course default rewrite impl would need to be fixed (and rewrite should throw 
UOE by default). A query that implement createWeight, would not call rewrite.

By that no "consumer" of the query would ever call rewrite, they just call 
createWeight() before execution.

(this are just ideas, maybe let's create separate issue)

> BlendedTermQuery
> 
>
> Key: LUCENE-6695
> URL: https://issues.apache.org/jira/browse/LUCENE-6695
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6695.patch, LUCENE-6695.patch
>
>
> It is sometimes desirable to ignore differences between index statistics of 
> several terms so that they produce the same scores, for instance if you 
> resolve synonyms at search time or if you want to search across several 
> fields. Elasticsearch has been using this approach for its multi_match query 
> for some time now.
> We already blend statistics in TopTermsBlendedFreqScoringRewrite (used by 
> FuzzyQuery) but it could be helpful to have a dedicated query to choose 
> manually which terms to blend stats from.



--
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] (LUCENE-6695) BlendedTermQuery

[Adrien Grand (JIRA)]

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

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

Updated patch to apply Uwe's suggestion.

By the way, the funny loop is the same in IndexSearcher.rewrite. ;-)

> BlendedTermQuery
> 
>
> Key: LUCENE-6695
> URL: https://issues.apache.org/jira/browse/LUCENE-6695
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6695.patch, LUCENE-6695.patch
>
>
> It is sometimes desirable to ignore differences between index statistics of 
> several terms so that they produce the same scores, for instance if you 
> resolve synonyms at search time or if you want to search across several 
> fields. Elasticsearch has been using this approach for its multi_match query 
> for some time now.
> We already blend statistics in TopTermsBlendedFreqScoringRewrite (used by 
> FuzzyQuery) but it could be helpful to have a dedicated query to choose 
> manually which terms to blend stats from.



--
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] (LUCENE-6695) BlendedTermQuery

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6695:
--

Thanks Uwe, I'll do that. Eventually I would like to remove this rewrite() 
method from the public API of Query, it should really be an implementation 
detail of createWeight!

> BlendedTermQuery
> 
>
> Key: LUCENE-6695
> URL: https://issues.apache.org/jira/browse/LUCENE-6695
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6695.patch
>
>
> It is sometimes desirable to ignore differences between index statistics of 
> several terms so that they produce the same scores, for instance if you 
> resolve synonyms at search time or if you want to search across several 
> fields. Elasticsearch has been using this approach for its multi_match query 
> for some time now.
> We already blend statistics in TopTermsBlendedFreqScoringRewrite (used by 
> FuzzyQuery) but it could be helpful to have a dedicated query to choose 
> manually which terms to blend stats from.



--
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: Welcome Christine Poerschke as Lucene/Solr committer

[Shalin Shekhar Mangar]

Welcome Christine!

On Fri, Jul 24, 2015 at 12:57 PM, Adrien Grand  wrote:
> I'm pleased to announce that Christine Poerschke has accepted the PMC's
> invitation to become a committer.
>
> Christine, it's tradition that you introduce yourself with a brief bio.
>
> Your account is not entirely ready yet. We will let you know when it is 
> created
> and karma has been granted so that you can add yourself to the committers
> section of the Who We Are page on the website:
> .
>
> Congratulations and welcome!
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>



-- 
Regards,
Shalin Shekhar Mangar.

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

[jira] [Commented] (LUCENE-6695) BlendedTermQuery

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-6695:
---

Would it be not better to use IndexSearcher.rewrite() inside 
ComplexPhraseQueryParser? This one does the rewrite loop correctly, so we don't 
duplicate code: {{Query rewritten= new IndexSearcher(reader).rewrite(query);}}

But I like your funny for-loop :-)

Otherwise I am fine to have it in core (we have the logic already there, so 
your proposal to replace the fuzzy rewrite is fine).

> BlendedTermQuery
> 
>
> Key: LUCENE-6695
> URL: https://issues.apache.org/jira/browse/LUCENE-6695
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6695.patch
>
>
> It is sometimes desirable to ignore differences between index statistics of 
> several terms so that they produce the same scores, for instance if you 
> resolve synonyms at search time or if you want to search across several 
> fields. Elasticsearch has been using this approach for its multi_match query 
> for some time now.
> We already blend statistics in TopTermsBlendedFreqScoringRewrite (used by 
> FuzzyQuery) but it could be helpful to have a dedicated query to choose 
> manually which terms to blend stats from.



--
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] (LUCENE-6695) BlendedTermQuery

[Adrien Grand (JIRA)]

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

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

Here is a patch: it computes the aggregated doc freq from several terms as the 
maximum doc freq, and the total term freq as the sum of the total term freqs of 
individual terms.

I put the query in lucene/core so that TopTermsBlendedFreqScoringRewrite could 
reuse it and marked it as experimental, but if someone is not comfortable with 
it I can revert the changes to TopTermsBlendedFreqScoringRewrite and move this 
query to the sandbox.

> BlendedTermQuery
> 
>
> Key: LUCENE-6695
> URL: https://issues.apache.org/jira/browse/LUCENE-6695
> Project: Lucene - Core
>  Issue Type: New Feature
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6695.patch
>
>
> It is sometimes desirable to ignore differences between index statistics of 
> several terms so that they produce the same scores, for instance if you 
> resolve synonyms at search time or if you want to search across several 
> fields. Elasticsearch has been using this approach for its multi_match query 
> for some time now.
> We already blend statistics in TopTermsBlendedFreqScoringRewrite (used by 
> FuzzyQuery) but it could be helpful to have a dedicated query to choose 
> manually which terms to blend stats from.



--
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] (LUCENE-6590) Explore different ways to apply boosts

[Adrien Grand (JIRA)]

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

Adrien Grand commented on LUCENE-6590:
--

bq. What do you think is possible in terms of updating 5.x to make the 
transition easier?

My plan was to backport the change, make Query.clone/setBoost/getBoost 
deprecated, change the default rewrite implementation to something like:

{code}
  public Query rewrite(IndexReader reader) throws IOException {
if (boost != 1f) {
  Query rewritten = clone();
  rewritten.setBoost(1f);
  rewritten = new BoostQuery(rewritten, boost);
  return rewritten;
}
return this;
  }
{code}
and then review our existing queries to make sure they always end up delegating 
to super.rewrite (I know some of them, like DisjunctionMaxQuery, end up just 
returning "this", so that would have to be fixed to return super.rewrite() 
instead.)
I think that should work?

bq. Another thought... boosts really only make sense for boosting one clause 
over another. so another approach that might be less invasive (and won't break 
"instanceof" checks and current unwrapping code) is to just add boost to 
BooleanClause.

That's an interesting idea but I think this only applies to DefaultSimilarity? 
Other Similarities tend to handle boosts as multiplicative factors to the 
scores (because they return 1 in queryNorm instead of 
1/sqrt(sumOfSquaredWeights))? Also this might be an issue for 
DisjunctionMaxQuery which could not have different boosts per sub query anymore?

bq. This might have some influence on weighting in the surround (span) queries, 
but that can be fixed later if it is needed at all.

I'm curious what issues you are foreseeing? (I'm not very familiar with 
surround queries...)

> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
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] (LUCENE-6695) BlendedTermQuery

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-6695:


 Summary: BlendedTermQuery
 Key: LUCENE-6695
 URL: https://issues.apache.org/jira/browse/LUCENE-6695
 Project: Lucene - Core
  Issue Type: New Feature
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor


It is sometimes desirable to ignore differences between index statistics of 
several terms so that they produce the same scores, for instance if you resolve 
synonyms at search time or if you want to search across several fields. 
Elasticsearch has been using this approach for its multi_match query for some 
time now.

We already blend statistics in TopTermsBlendedFreqScoringRewrite (used by 
FuzzyQuery) but it could be helpful to have a dedicated query to choose 
manually which terms to blend stats from.



--
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: Welcome Christine Poerschke as Lucene/Solr committer

[Mike Drob]

Well done!

On Fri, Jul 24, 2015 at 4:46 AM, Koji Sekiguchi  wrote:

> Congratulations, Christine!
>
> Koji
>
> On 2015/07/24 16:27, Adrien Grand wrote:
>
>> I'm pleased to announce that Christine Poerschke has accepted the PMC's
>> invitation to become a committer.
>>
>> Christine, it's tradition that you introduce yourself with a brief bio.
>>
>> Your account is not entirely ready yet. We will let you know when it is
>> created
>> and karma has been granted so that you can add yourself to the committers
>> section of the Who We Are page on the website:
>> .
>>
>> Congratulations and welcome!
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (LUCENE-6693) Permgen errors in 5.x on Jenkins builds with JDK 1.7

[ASF subversion and git services (JIRA)]

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

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

Commit 1692475 from [~thetaphi] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1692475 ]

Merged revision(s) 1692474 from lucene/dev/trunk:
LUCENE-6693: Add one more parameter-pass-through #3

> Permgen errors in 5.x on Jenkins builds with JDK 1.7
> 
>
> Key: LUCENE-6693
> URL: https://issues.apache.org/jira/browse/LUCENE-6693
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6693.patch, LUCENE-6693.patch
>
>
> Since I updated Groovy and other tools, 5.x builds fail with permgen errors 
> in Jenkins. During the build, Groovy (which is large) is loaded three times 
> and this sums up.
> See Revision: 1692103
> I reverted the Groovy update in 5.x for now. The fix is to make the top-level 
> build.xml also load common-build.xml and resolve groovy before the build 
> starts.



--
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] (LUCENE-6693) Permgen errors in 5.x on Jenkins builds with JDK 1.7

[ASF subversion and git services (JIRA)]

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

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

Commit 1692474 from [~thetaphi] in branch 'dev/trunk'
[ https://svn.apache.org/r1692474 ]

LUCENE-6693: Add one more parameter-pass-through #3

> Permgen errors in 5.x on Jenkins builds with JDK 1.7
> 
>
> Key: LUCENE-6693
> URL: https://issues.apache.org/jira/browse/LUCENE-6693
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
> Fix For: 5.3, Trunk
>
> Attachments: LUCENE-6693.patch, LUCENE-6693.patch
>
>
> Since I updated Groovy and other tools, 5.x builds fail with permgen errors 
> in Jenkins. During the build, Groovy (which is large) is loaded three times 
> and this sums up.
> See Revision: 1692103
> I reverted the Groovy update in 5.x for now. The fix is to make the top-level 
> build.xml also load common-build.xml and resolve groovy before the build 
> starts.



--
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: Welcome Christine Poerschke as Lucene/Solr committer

[Koji Sekiguchi]

Congratulations, Christine!

Koji

On 2015/07/24 16:27, Adrien Grand wrote:

I'm pleased to announce that Christine Poerschke has accepted the PMC's
invitation to become a committer.

Christine, it's tradition that you introduce yourself with a brief bio.

Your account is not entirely ready yet. We will let you know when it is created
and karma has been granted so that you can add yourself to the committers
section of the Who We Are page on the website:
.

Congratulations and welcome!




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

RE: [JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b73) - Build # 13391 - Failure!

[Uwe Schindler]

I agree with that. I could change the prefix [JENKINS] to [JENKINS-EA] for 
EA-Builds by script/pattern.

 

Uwe

 

-

Uwe Schindler

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

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Dawid Weiss [mailto:dawid.we...@gmail.com] 
Sent: Friday, July 24, 2015 8:48 AM
To: dev@lucene.apache.org
Subject: Re: [JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b73) - Build # 
13391 - Failure!

 

 

> Uwe: perhaps you could change your JDK9 jenkins job to run but not send 
> emails on failures?

 

I'm for prefixing title somehow so that uninterested people can filter out 
those e-mails, but leaving them as e-mails. I am interested in those failures 
and it's push-style notification that suits me much better than periodic 
checking of jenkins' logs. 

 

One can pick what he's interested in (Solr, Lucene, java-ea, etc.), but I think 
it's still fully relevant to know if Lucene/ Solr works on an anticipated new 
release of Java, even if it's fairly early.

 

Please leave those e-mails coming to the mailing list. 

 

Dawid