[jira] [Updated] (SOLR-9245) docBoost is still compounded on copyField

[Daiki Ikawa (JIRA)]

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

Daiki Ikawa updated SOLR-9245:
--
Description: 
in some cases, the issue [SOLR-3981] is still unresolved.

schema.xml 
{noformat}
  
  
{noformat}

and MyLocalApplicationSampleWrong.java
{noformat}
doc.addfield("source_text","foo");
doc.addfield("hoge_text", "bar");
doc.setDocumentBoost(10);
{noformat}

then I got fieldNorm value which greater than 1E9 (docboot is still 
compounded), 
because the "compoundBoost" is applied twice when copyFileds generated
faster than destinationField generated.


  was:
in some cases, the issue [SOLR-3981] is still unresolved.

schema.xml 
{noformat}
  
  
{noformat}

and MyLocalApplicationSampleWrong.java
{noformat}
doc.addfield("source_text","foo");
doc.addfield("hoge_text", "bar");
doc.setDocumentBoost(10);
{noformat}

then I got fieldNorm value which greater than 1E9 (docboot is still 
compounded), 
because the "compoundBoost" is applied twice when copyFileds generated
faster than destinationField generated.

MyLocalApplicationSampleOK.java
{noformat}
doc.addfield("hoge_text", "bar");
doc.addfield("source_text","foo");
doc.setDocumentBoost(10);
{noformat}
then I got fieldNorm value which less than 1E5.


> docBoost is still compounded on copyField
> -
>
> Key: SOLR-9245
> URL: https://issues.apache.org/jira/browse/SOLR-9245
> Project: Solr
>  Issue Type: Bug
>Reporter: Daiki Ikawa
>
> in some cases, the issue [SOLR-3981] is still unresolved.
> schema.xml 
> {noformat}
>stored="false" multiValued="true" />
>   
> {noformat}
> and MyLocalApplicationSampleWrong.java
> {noformat}
> doc.addfield("source_text","foo");
> doc.addfield("hoge_text", "bar");
> doc.setDocumentBoost(10);
> {noformat}
> then I got fieldNorm value which greater than 1E9 (docboot is still 
> compounded), 
> because the "compoundBoost" is applied twice when copyFileds generated
> faster than destinationField generated.



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

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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 666 - Failure!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.solr.client.solrj.impl.CloudSolrClientTest.checkCollectionParameters

Error Message:
Could not load collection from ZK: collection1

Stack Trace:
org.apache.solr.common.SolrException: Could not load collection from ZK: 
collection1
at 
__randomizedtesting.SeedInfo.seed([3FF957BEE0628B84:C4EEC40EB9355C33]:0)
at 
org.apache.solr.common.cloud.ZkStateReader.getCollectionLive(ZkStateReader.java:1047)
at 
org.apache.solr.common.cloud.ZkStateReader$LazyCollectionRef.get(ZkStateReader.java:610)
at 
org.apache.solr.common.cloud.ClusterState.getCollectionOrNull(ClusterState.java:211)
at 
org.apache.solr.common.cloud.ClusterState.hasCollection(ClusterState.java:113)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.getCollectionNames(CloudSolrClient.java:1239)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:961)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at 
org.apache.solr.client.solrj.request.UpdateRequest.commit(UpdateRequest.java:225)
at 
org.apache.solr.client.solrj.impl.CloudSolrClientTest.cleanIndex(CloudSolrClientTest.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:905)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 

[jira] [Resolved] (SOLR-8238) Make Solr respect preferredLeader at startup

[Erick Erickson (JIRA)]

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

Erick Erickson resolved SOLR-8238.
--
Resolution: Won't Fix

Resolving as "won' fix" since there's no "working as designed". We can re-open 
if it's urgent.

One can always issue the REBALANCELEADERS API command after the cluster is up 
if necessary.

> Make Solr respect preferredLeader at startup
> 
>
> Key: SOLR-8238
> URL: https://issues.apache.org/jira/browse/SOLR-8238
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.2.1
>Reporter: Peter Morgan
>Priority: Minor
>
> After setting preferredLeader property, noticed that upon restarting leaders 
> revert to wherever they were previously running before REBALANCE was called.  
>  I would expect the preferredLeader to influence the startup election, but it 
> appears it is not observed.



--
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-9245) docBoost is still compounded on copyField

[Daiki Ikawa (JIRA)]

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

Daiki Ikawa commented on SOLR-9245:
---

Sorry but I have no ideas to solve this problem simply.
( I think SolrInputDocument.iterator must be topologically sorted, but it is 
difficult to implement it. )

> docBoost is still compounded on copyField
> -
>
> Key: SOLR-9245
> URL: https://issues.apache.org/jira/browse/SOLR-9245
> Project: Solr
>  Issue Type: Bug
>Reporter: Daiki Ikawa
>
> in some cases, the issue [SOLR-3981] is still unresolved.
> schema.xml 
> {noformat}
>stored="false" multiValued="true" />
>   
> {noformat}
> and MyLocalApplicationSampleWrong.java
> {noformat}
> doc.addfield("source_text","foo");
> doc.addfield("hoge_text", "bar");
> doc.setDocumentBoost(10);
> {noformat}
> then I got fieldNorm value which greater than 1E9 (docboot is still 
> compounded), 
> because the "compoundBoost" is applied twice when copyFileds generated
> faster than destinationField generated.
> MyLocalApplicationSampleOK.java
> {noformat}
> doc.addfield("hoge_text", "bar");
> doc.addfield("source_text","foo");
> doc.setDocumentBoost(10);
> {noformat}
> then I got fieldNorm value which less than 1E5.



--
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-9245) docBoost is still compounded on copyField

[Daiki Ikawa (JIRA)]

Daiki Ikawa created SOLR-9245:
-

 Summary: docBoost is still compounded on copyField
 Key: SOLR-9245
 URL: https://issues.apache.org/jira/browse/SOLR-9245
 Project: Solr
  Issue Type: Bug
Reporter: Daiki Ikawa


in some cases, the issue [SOLR-3981] is still unresolved.

schema.xml 
{noformat}
  
  
{noformat}

and MyLocalApplicationSampleWrong.java
{noformat}
doc.addfield("source_text","foo");
doc.addfield("hoge_text", "bar");
doc.setDocumentBoost(10);
{noformat}

then I got fieldNorm value which greater than 1E9 (docboot is still 
compounded), 
because the "compoundBoost" is applied twice when copyFileds generated
faster than destinationField generated.

MyLocalApplicationSampleOK.java
{noformat}
doc.addfield("hoge_text", "bar");
doc.addfield("source_text","foo");
doc.setDocumentBoost(10);
{noformat}
then I got fieldNorm value which less than 1E5.



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

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

[JENKINS] Lucene-Solr-master-Linux (64bit/jdk1.8.0_92) - Build # 17040 - Failure!

[Policeman Jenkins Server]

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

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

Error Message:
6 threads leaked from SUITE scope at 
org.apache.solr.cloud.SaslZkACLProviderTest: 1) Thread[id=473, 
name=groupCache.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)2) Thread[id=475, 
name=kdcReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)3) Thread[id=474, 
name=ou=system.data, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest] 
at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)4) Thread[id=472, 
name=apacheds, state=WAITING, group=TGRP-SaslZkACLProviderTest] at 
java.lang.Object.wait(Native Method) at 
java.lang.Object.wait(Object.java:502) at 
java.util.TimerThread.mainLoop(Timer.java:526) at 
java.util.TimerThread.run(Timer.java:505)5) Thread[id=476, 
name=changePwdReplayCache.data, state=TIMED_WAITING, 
group=TGRP-SaslZkACLProviderTest] at sun.misc.Unsafe.park(Native 
Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
 at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)6) Thread[id=477, 
name=pool-3-thread-1, state=TIMED_WAITING, group=TGRP-SaslZkACLProviderTest]
 at sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) 
at 
java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
 at 
java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
 at 
java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:941) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)   
  at 

[jira] [Updated] (SOLR-9194) Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-9194:
-
Attachment: SOLR-9194.patch

Sorry about that. My Git mojo is evolving very slowly.

This should be a better patch, I produced it with IntelliJ and applied it 
against a fresh trunk with "patch -p0 patchfile".

Also changed the echo line to NOT mention the -up/downconfig and added in rm, 
mv and cp.

Thanks!

> Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper
> 
>
> Key: SOLR-9194
> URL: https://issues.apache.org/jira/browse/SOLR-9194
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-9194.patch, SOLR-9194.patch
>
>
> There are a few other files that can reasonably be pushed to Zookeeper, e.g. 
> solr.xml, security.json, clusterprops.json. Who knows? Even 
> /state.json for the brave.
> This could reduce further the need for bouncing out to zkcli.
> Assigning to myself just so I don't lose track, but I would _love_ it if 
> someone else wanted to take it...
> I'm thinking the commands would be 
> bin/solr zk -putfile -z  -p  -f 
> bin/solr zk -getfile -z  -p  -f 
> but I'm not wedded to those, all suggestions welcome.



--
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-6.x - Build # 99 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-6.x/99/

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

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [NRTCachingDirectory]
at __randomizedtesting.SeedInfo.seed([CA05DA6A71CA6C63]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11759 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/solr/build/solr-core/test/temp/junit4-J1-20160622_224607_544.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: GC overhead limit exceeded
   [junit4] Dumping heap to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/heapdumps/java_pid4684.hprof
 ...
   [junit4] Heap dump file created [711994539 bytes in 8.576 secs]
   [junit4] <<< JVM J1: EOF 

   [junit4] JVM J1: stderr was not empty, see: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/solr/build/solr-core/test/temp/junit4-J1-20160622_224607_544.syserr
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] WARN: Unhandled exception in event serialization. -> 
java.lang.OutOfMemoryError: GC overhead limit exceeded
   [junit4] <<< JVM J1: EOF 

[...truncated 352 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4]   2> Creating dataDir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-6.x/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_CA05DA6A71CA6C63-001/init-core-data-001
   [junit4]   2> 2975789 INFO  
(SUITE-TestReplicationHandler-seed#[CA05DA6A71CA6C63]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: 
@org.apache.solr.SolrTestCaseJ4$SuppressSSL(bugUrl=None)
   [junit4]   2> 2975791 INFO  
(TEST-TestReplicationHandler.doTestReplicateAfterWrite2Slave-seed#[CA05DA6A71CA6C63])
 [] o.a.s.SolrTestCaseJ4 ###Starting doTestReplicateAfterWrite2Slave
   [junit4]   2> 2975791 INFO  
(TEST-TestReplicationHandler.doTestReplicateAfterWrite2Slave-seed#[CA05DA6A71CA6C63])
 [] o.a.s.SolrTestCaseJ4 Writing core.properties file to 

[jira] [Updated] (SOLR-9076) Update to Hadoop 2.7.2

[Gregory Chanan (JIRA)]

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

Gregory Chanan updated SOLR-9076:
-
Attachment: SOLR-9076.patch

rebased patch -- looks like the TestRecoveryHdfs.java change already went in.

> Update to Hadoop 2.7.2
> --
>
> Key: SOLR-9076
> URL: https://issues.apache.org/jira/browse/SOLR-9076
> Project: Solr
>  Issue Type: Improvement
>Reporter: Mark Miller
>Assignee: Mark Miller
> Attachments: SOLR-9076.patch, SOLR-9076.patch, SOLR-9076.patch, 
> SOLR-9076.patch, SOLR-9076.patch
>
>




--
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.5-Windows (64bit/jdk1.8.0_92) - Build # 97 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Windows/97/
Java: 64bit/jdk1.8.0_92 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

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

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

Stack Trace:
java.lang.AssertionError: There are still nodes recoverying - waited for 45 
seconds
at 
__randomizedtesting.SeedInfo.seed([F3717DA310E33CD6:7B254279BE1F512E]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:174)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForRecoveriesToFinish(AbstractFullDistribZkTestBase.java:838)
at 
org.apache.solr.cloud.DistribDocExpirationUpdateProcessorTest.test(DistribDocExpirationUpdateProcessorTest.java:74)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Commented] (SOLR-9194) Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper

[JIRA]

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

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

You patch does not apply to master. Are you sure you don't have any local 
commits that you git diff against?
patch cannot find file 
{{solr/core/src/test/org/apache/solr/cloud/SolrCLIZkUtilsTest.java}}, isn't it 
a new file?
Try e.g. {{git diff ece9d85cbea962fd7d327010f1ba184cefdfa8ed}} to diff against 
last master commit?

Also, there is a help print in your patch that says

bq. +echo "Zookeeper operation (one of 'upconfig', 'downconfig', 
'-upconfig' or  '-downconfig') is required!"

You should probably mention cp, rm, mv there as well?

> Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper
> 
>
> Key: SOLR-9194
> URL: https://issues.apache.org/jira/browse/SOLR-9194
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-9194.patch
>
>
> There are a few other files that can reasonably be pushed to Zookeeper, e.g. 
> solr.xml, security.json, clusterprops.json. Who knows? Even 
> /state.json for the brave.
> This could reduce further the need for bouncing out to zkcli.
> Assigning to myself just so I don't lose track, but I would _love_ it if 
> someone else wanted to take it...
> I'm thinking the commands would be 
> bin/solr zk -putfile -z  -p  -f 
> bin/solr zk -getfile -z  -p  -f 
> but I'm not wedded to those, all suggestions welcome.



--
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-9200) Add Delegation Token Support to Solr

[Gregory Chanan (JIRA)]

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

Gregory Chanan commented on SOLR-9200:
--

Did some more work on this.  Currently blocked because we need HADOOP-11492, 
which is only available in hadoop 2.7.0+.  Upgrading to hadoop 2.7.2 is 
currently being tracked in SOLR-9076.

> Add Delegation Token Support to Solr
> 
>
> Key: SOLR-9200
> URL: https://issues.apache.org/jira/browse/SOLR-9200
> Project: Solr
>  Issue Type: New Feature
>  Components: security
>Reporter: Gregory Chanan
>Assignee: Gregory Chanan
>
> SOLR-7468 added support for kerberos authentication via the hadoop 
> authentication filter.  Hadoop also has support for an authentication filter 
> that supports delegation tokens, which allow authenticated users the ability 
> to grab/renew/delete a token that can be used to bypass the normal 
> authentication path for a time.  This is useful in a variety of use cases:
> 1) distributed clients (e.g. MapReduce) where each client may not have access 
> to the user's kerberos credentials.  Instead, the job runner can grab a 
> delegation token and use that during task execution.
> 2) If the load on the kerberos server is too high, delegation tokens can 
> avoid hitting the kerberos server after the first request
> 3) If requests/permissions need to be delegated to another user: the more 
> privileged user can request a delegation token that can be passed to the less 
> privileged user.
> Note to self:
> In 
> https://issues.apache.org/jira/browse/SOLR-7468?focusedCommentId=14579636=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14579636
>  I made the following comment which I need to investigate further, since I 
> don't know if anything changed in this area:
> {quote}3) I'm a little concerned with the "NoContext" code in KerberosPlugin 
> moving forward (I understand this is more a generic auth question than 
> kerberos specific). For example, in the latest version of the filter we are 
> using at Cloudera, we play around with the ServletContext in order to pass 
> information around 
> (https://github.com/cloudera/lucene-solr/blob/cdh5-4.10.3_5.4.2/solr/core/src/java/org/apache/solr/servlet/SolrHadoopAuthenticationFilter.java#L106).
>  Is there any way we can get the actual ServletContext in a plugin?{quote}



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

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

[JENKINS] Lucene-Solr-6.x-Windows (64bit/jdk1.8.0_92) - Build # 266 - Still Failing!

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest.testConsistencyOnExceptions

Error Message:
Captured an uncaught exception in thread: Thread[id=17, 
name=ReplicationThread-indexAndTaxo, state=RUNNABLE, 
group=TGRP-IndexAndTaxonomyReplicationClientTest]

Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=17, name=ReplicationThread-indexAndTaxo, 
state=RUNNABLE, group=TGRP-IndexAndTaxonomyReplicationClientTest]
at 
__randomizedtesting.SeedInfo.seed([598F000B1D83302E:D601E7AB0FEFC3D1]:0)
Caused by: java.lang.AssertionError: handler failed too many times: -1
at __randomizedtesting.SeedInfo.seed([598F000B1D83302E]:0)
at 
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest$4.handleUpdateException(IndexAndTaxonomyReplicationClientTest.java:422)
at 
org.apache.lucene.replicator.ReplicationClient$ReplicationThread.run(ReplicationClient.java:77)




Build Log:
[...truncated 8186 lines...]
   [junit4] Suite: 
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest
   [junit4]   2> ?? 23, 2016 10:17:06 ?? 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2> ??: Uncaught exception in thread: 
Thread[ReplicationThread-indexAndTaxo,5,TGRP-IndexAndTaxonomyReplicationClientTest]
   [junit4]   2> java.lang.AssertionError: handler failed too many times: -1
   [junit4]   2>at 
__randomizedtesting.SeedInfo.seed([598F000B1D83302E]:0)
   [junit4]   2>at 
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest$4.handleUpdateException(IndexAndTaxonomyReplicationClientTest.java:422)
   [junit4]   2>at 
org.apache.lucene.replicator.ReplicationClient$ReplicationThread.run(ReplicationClient.java:77)
   [junit4]   2> 
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=IndexAndTaxonomyReplicationClientTest 
-Dtests.method=testConsistencyOnExceptions -Dtests.seed=598F000B1D83302E 
-Dtests.slow=true -Dtests.locale=zh-TW -Dtests.timezone=Pacific/Majuro 
-Dtests.asserts=true -Dtests.file.encoding=Cp1252
   [junit4] ERROR   3.98s J1 | 
IndexAndTaxonomyReplicationClientTest.testConsistencyOnExceptions <<<
   [junit4]> Throwable #1: 
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught 
exception in thread: Thread[id=17, name=ReplicationThread-indexAndTaxo, 
state=RUNNABLE, group=TGRP-IndexAndTaxonomyReplicationClientTest]
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([598F000B1D83302E:D601E7AB0FEFC3D1]:0)
   [junit4]> Caused by: java.lang.AssertionError: handler failed too many 
times: -1
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([598F000B1D83302E]:0)
   [junit4]>at 
org.apache.lucene.replicator.IndexAndTaxonomyReplicationClientTest$4.handleUpdateException(IndexAndTaxonomyReplicationClientTest.java:422)
   [junit4]>at 
org.apache.lucene.replicator.ReplicationClient$ReplicationThread.run(ReplicationClient.java:77)
   [junit4]   2> NOTE: test params are: codec=Lucene62, sim=ClassicSimilarity, 
locale=zh-TW, timezone=Pacific/Majuro
   [junit4]   2> NOTE: Windows 10 10.0 amd64/Oracle Corporation 1.8.0_92 
(64-bit)/cpus=3,threads=1,free=58970120,total=76546048
   [junit4]   2> NOTE: All tests run in this JVM: [IndexRevisionTest, 
IndexAndTaxonomyRevisionTest, IndexAndTaxonomyReplicationClientTest]
   [junit4] Completed [7/9 (1!)] on J1 in 5.98s, 5 tests, 1 error <<< FAILURES!

[...truncated 38 lines...]
BUILD FAILED
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\build.xml:740: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\build.xml:684: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\build.xml:59: The following 
error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\build.xml:476: The 
following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\common-build.xml:2161:
 The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\module-build.xml:58: 
The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\common-build.xml:1427:
 The following error occurred while executing this line:
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\lucene\common-build.xml:984: 
There were test failures: 9 suites, 43 tests, 1 error, 11 ignored (11 
assumptions) [seed: 598F000B1D83302E]

Total time: 19 minutes 5 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build 

[jira] [Created] (SOLR-9244) Lots of "Previous SolrRequestInfo was not closed" in Solr log

[Gary Lee (JIRA)]

Gary Lee created SOLR-9244:
--

 Summary: Lots of "Previous SolrRequestInfo was not closed" in Solr 
log
 Key: SOLR-9244
 URL: https://issues.apache.org/jira/browse/SOLR-9244
 Project: Solr
  Issue Type: Bug
  Components: Server
Affects Versions: 5.3.1
Reporter: Gary Lee
Priority: Minor
 Fix For: 5.3.1


After upgrading to Solr 5.3.1, we started seeing a lot of "Previous 
SolrRequestInfo was not closed" ERROR level messages in the logs. Upon further 
inspection, it appears this is a sanity check and not an error that needs 
attention. It appears that the SolrRequestInfo isn't freed in one particular 
path (no corresponding call to SolrRequestInfo.clearRequestInfo in 
HttpSolrCall.call), which often leads to a lot of these messages.



--
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-6492) Solr field type that supports multiple, dynamic analyzers

[Kranti Parisa (JIRA)]

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

Kranti Parisa commented on SOLR-6492:
-

[~solrtrey] awesome, looking fwd to it.

> Solr field type that supports multiple, dynamic analyzers
> -
>
> Key: SOLR-6492
> URL: https://issues.apache.org/jira/browse/SOLR-6492
> Project: Solr
>  Issue Type: New Feature
>  Components: Schema and Analysis
>Reporter: Trey Grainger
> Fix For: 5.0
>
>
> A common request - particularly for multilingual search - is to be able to 
> support one or more dynamically-selected analyzers for a field. For example, 
> someone may have a "content" field and pass in a document in Greek (using an 
> Analyzer with Tokenizer/Filters for German), a separate document in English 
> (using an English Analyzer), and possibly even a field with mixed-language 
> content in Greek and English. This latter case could pass the content 
> separately through both an analyzer defined for Greek and another Analyzer 
> defined for English, stacking or concatenating the token streams based upon 
> the use-case.
> There are some distinct advantages in terms of index size and query 
> performance which can be obtained by stacking terms from multiple analyzers 
> in the same field instead of duplicating content in separate fields and 
> searching across multiple fields. 
> Other non-multilingual use cases may include things like switching to a 
> different analyzer for the same field to remove a feature (i.e. turning 
> on/off query-time synonyms against the same field on a per-query basis).



--
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-7352) TestSimpleExplanationsWithFillerDocs failures

[Steve Rowe (JIRA)]

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

Steve Rowe commented on LUCENE-7352:


This suite was added under LUCENE-7132.

> TestSimpleExplanationsWithFillerDocs failures
> -
>
> Key: LUCENE-7352
> URL: https://issues.apache.org/jira/browse/LUCENE-7352
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Steve Rowe
>
> Policeman Jenkins found reproducible {{testDMQ8()}} and {{testDMQ9()}} 
> failures on master 
> [http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17037/]:
> {noformat}
> Checking out Revision ece9d85cbea962fd7d327010f1ba184cefdfa8ed 
> (refs/remotes/origin/master)
> [...]
> [junit4] Suite: org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestSimpleExplanationsWithFillerDocs -Dtests.method=testDMQ8 
> -Dtests.seed=882B619046E7216B -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=fo -Dtests.timezone=Asia/Ashgabat -Dtests.asserts=true 
> -Dtests.file.encoding=US-ASCII
>[junit4] FAILURE 0.10s J2 | TestSimpleExplanationsWithFillerDocs.testDMQ8 
> <<<
>[junit4]> Throwable #1: junit.framework.AssertionFailedError: 
> (+((field:yy (field:w5)^100.0) | (field:xx)^10.0)~0.5 -extra:extra) 
> NEVER:MATCH: score(doc=713)=-1.9956312E-6 != explanationScore=-3.9912625E-6 
> Explanation: -3.9912625E-6 = sum of:
>[junit4]>   -3.9912625E-6 = weight(field:w5 in 713) 
> [RandomSimilarity], result of:
>[junit4]> -3.9912625E-6 = score(IBSimilarity, doc=713, freq=1.0), 
> computed from:
>[junit4]>   100.0 = boost
>[junit4]>   0.0 = NormalizationH2, computed from: 
>[junit4]> 1.0 = tf
>[junit4]> 5.502638 = avgFieldLength
>[junit4]> 5.6493154E19 = len
>[junit4]>   0.2533109 = LambdaTTF, computed from: 
>[junit4]> 2256.0 = totalTermFreq
>[junit4]> 8909.0 = numberOfDocuments
>[junit4]>   -3.9912624E-8 = DistributionSPL
>[junit4]>  expected:<-1.9956312E-6> but was:<-3.9912625E-6>
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([882B619046E7216B:D4118BC551735775]:0)
>[junit4]>  at junit.framework.Assert.fail(Assert.java:50)
>[junit4]>  at junit.framework.Assert.failNotEquals(Assert.java:287)
>[junit4]>  at junit.framework.Assert.assertEquals(Assert.java:120)
>[junit4]>  at 
> org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:338)
>[junit4]>  at 
> org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:358)
>[junit4]>  at 
> org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:358)
>[junit4]>  at 
> org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:358)
>[junit4]>  at 
> org.apache.lucene.search.CheckHits$ExplanationAsserter.collect(CheckHits.java:501)
>[junit4]>  at 
> org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
>[junit4]>  at 
> org.apache.lucene.search.AssertingCollector$1.collect(AssertingCollector.java:56)
>[junit4]>  at 
> org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
>[junit4]>  at 
> org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreRange(Weight.java:196)
>[junit4]>  at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:183)
>[junit4]>  at 
> org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:79)
>[junit4]>  at 
> org.apache.lucene.search.ReqExclBulkScorer.score(ReqExclBulkScorer.java:48)
>[junit4]>  at 
> org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
>[junit4]>  at 
> org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:69)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
>[junit4]>  at 
> org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:91)
>[junit4]>  at 
> org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
>[junit4]>  at 
> org.apache.lucene.search.CheckHits.checkExplanations(CheckHits.java:310)
>[junit4]>  at 
> org.apache.lucene.search.QueryUtils.checkExplanations(QueryUtils.java:104)
>[junit4]>  at 
> org.apache.lucene.search.QueryUtils.check(QueryUtils.java:132)
>[junit4]>  at 
> 

Re: [JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+122) - Build # 17037 - Failure!

[Steve Rowe]

These reproduce for me using Java8 - I created 
.

--
Steve
www.lucidworks.com

> On Jun 22, 2016, at 10:38 AM, Policeman Jenkins Server  
> wrote:
> 
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17037/
> Java: 32bit/jdk-9-ea+122 -server -XX:+UseSerialGC
> 
> 2 tests failed.
> FAILED:  
> org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs.testDMQ8
> 
> Error Message:
> (+((field:yy (field:w5)^100.0) | (field:xx)^10.0)~0.5 -extra:extra) 
> NEVER:MATCH: score(doc=713)=-1.9956312E-6 != explanationScore=-3.9912625E-6 
> Explanation: -3.9912625E-6 = sum of:   -3.9912625E-6 = weight(field:w5 in 
> 713) [RandomSimilarity], result of: -3.9912625E-6 = score(IBSimilarity, 
> doc=713, freq=1.0), computed from:   100.0 = boost   0.0 = 
> NormalizationH2, computed from:  1.0 = tf 5.502638 = 
> avgFieldLength 5.6493154E19 = len   0.2533109 = LambdaTTF, 
> computed from:  2256.0 = totalTermFreq 8909.0 = 
> numberOfDocuments   -3.9912624E-8 = DistributionSPL  
> expected:<-1.9956312E-6> but was:<-3.9912625E-6>
> 
> Stack Trace:
> junit.framework.AssertionFailedError: (+((field:yy (field:w5)^100.0) | 
> (field:xx)^10.0)~0.5 -extra:extra) NEVER:MATCH: 
> score(doc=713)=-1.9956312E-6 != explanationScore=-3.9912625E-6 Explanation: 
> -3.9912625E-6 = sum of:
>  -3.9912625E-6 = weight(field:w5 in 713) [RandomSimilarity], result of:
>-3.9912625E-6 = score(IBSimilarity, doc=713, freq=1.0), computed from:
>  100.0 = boost
>  0.0 = NormalizationH2, computed from: 
>1.0 = tf
>5.502638 = avgFieldLength
>5.6493154E19 = len
>  0.2533109 = LambdaTTF, computed from: 
>2256.0 = totalTermFreq
>8909.0 = numberOfDocuments
>  -3.9912624E-8 = DistributionSPL
> expected:<-1.9956312E-6> but was:<-3.9912625E-6>
>   at 
> __randomizedtesting.SeedInfo.seed([882B619046E7216B:D4118BC551735775]:0)
>   at junit.framework.Assert.fail(Assert.java:50)
>   at junit.framework.Assert.failNotEquals(Assert.java:287)
>   at junit.framework.Assert.assertEquals(Assert.java:120)
>   at 
> org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:338)
>   at 
> org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:358)
>   at 
> org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:358)
>   at 
> org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:358)
>   at 
> org.apache.lucene.search.CheckHits$ExplanationAsserter.collect(CheckHits.java:501)
>   at 
> org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
>   at 
> org.apache.lucene.search.AssertingCollector$1.collect(AssertingCollector.java:56)
>   at 
> org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
>   at 
> org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreRange(Weight.java:196)
>   at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:183)
>   at 
> org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:79)
>   at 
> org.apache.lucene.search.ReqExclBulkScorer.score(ReqExclBulkScorer.java:48)
>   at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
>   at 
> org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:69)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
>   at 
> org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:91)
>   at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
>   at 
> org.apache.lucene.search.CheckHits.checkExplanations(CheckHits.java:310)
>   at 
> org.apache.lucene.search.QueryUtils.checkExplanations(QueryUtils.java:104)
>   at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:132)
>   at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:128)
>   at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:118)
>   at 
> org.apache.lucene.search.CheckHits.checkHitCollector(CheckHits.java:98)
>   at 
> org.apache.lucene.search.BaseExplanationTestCase.qtest(BaseExplanationTestCase.java:114)
>   at 
> org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs.qtest(TestSimpleExplanationsWithFillerDocs.java:113)
>   at 
> org.apache.lucene.search.TestSimpleExplanations.testDMQ8(TestSimpleExplanations.java:182)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
> Method)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
>   at 
> 

[jira] [Created] (LUCENE-7352) TestSimpleExplanationsWithFillerDocs failures

[Steve Rowe (JIRA)]

Steve Rowe created LUCENE-7352:
--

 Summary: TestSimpleExplanationsWithFillerDocs failures
 Key: LUCENE-7352
 URL: https://issues.apache.org/jira/browse/LUCENE-7352
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Affects Versions: master (7.0)
Reporter: Steve Rowe


Policeman Jenkins found reproducible {{testDMQ8()}} and {{testDMQ9()}} failures 
on master [http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17037/]:

{noformat}
Checking out Revision ece9d85cbea962fd7d327010f1ba184cefdfa8ed 
(refs/remotes/origin/master)
[...]
[junit4] Suite: org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs
   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestSimpleExplanationsWithFillerDocs -Dtests.method=testDMQ8 
-Dtests.seed=882B619046E7216B -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=fo -Dtests.timezone=Asia/Ashgabat -Dtests.asserts=true 
-Dtests.file.encoding=US-ASCII
   [junit4] FAILURE 0.10s J2 | TestSimpleExplanationsWithFillerDocs.testDMQ8 <<<
   [junit4]> Throwable #1: junit.framework.AssertionFailedError: 
(+((field:yy (field:w5)^100.0) | (field:xx)^10.0)~0.5 -extra:extra) 
NEVER:MATCH: score(doc=713)=-1.9956312E-6 != explanationScore=-3.9912625E-6 
Explanation: -3.9912625E-6 = sum of:
   [junit4]>   -3.9912625E-6 = weight(field:w5 in 713) [RandomSimilarity], 
result of:
   [junit4]> -3.9912625E-6 = score(IBSimilarity, doc=713, freq=1.0), 
computed from:
   [junit4]>   100.0 = boost
   [junit4]>   0.0 = NormalizationH2, computed from: 
   [junit4]> 1.0 = tf
   [junit4]> 5.502638 = avgFieldLength
   [junit4]> 5.6493154E19 = len
   [junit4]>   0.2533109 = LambdaTTF, computed from: 
   [junit4]> 2256.0 = totalTermFreq
   [junit4]> 8909.0 = numberOfDocuments
   [junit4]>   -3.9912624E-8 = DistributionSPL
   [junit4]>  expected:<-1.9956312E-6> but was:<-3.9912625E-6>
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([882B619046E7216B:D4118BC551735775]:0)
   [junit4]>at junit.framework.Assert.fail(Assert.java:50)
   [junit4]>at junit.framework.Assert.failNotEquals(Assert.java:287)
   [junit4]>at junit.framework.Assert.assertEquals(Assert.java:120)
   [junit4]>at 
org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:338)
   [junit4]>at 
org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:358)
   [junit4]>at 
org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:358)
   [junit4]>at 
org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:358)
   [junit4]>at 
org.apache.lucene.search.CheckHits$ExplanationAsserter.collect(CheckHits.java:501)
   [junit4]>at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
   [junit4]>at 
org.apache.lucene.search.AssertingCollector$1.collect(AssertingCollector.java:56)
   [junit4]>at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
   [junit4]>at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
   [junit4]>at 
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreRange(Weight.java:196)
   [junit4]>at 
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:183)
   [junit4]>at 
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:79)
   [junit4]>at 
org.apache.lucene.search.ReqExclBulkScorer.score(ReqExclBulkScorer.java:48)
   [junit4]>at 
org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
   [junit4]>at 
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:69)
   [junit4]>at 
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
   [junit4]>at 
org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:91)
   [junit4]>at 
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
   [junit4]>at 
org.apache.lucene.search.CheckHits.checkExplanations(CheckHits.java:310)
   [junit4]>at 
org.apache.lucene.search.QueryUtils.checkExplanations(QueryUtils.java:104)
   [junit4]>at 
org.apache.lucene.search.QueryUtils.check(QueryUtils.java:132)
   [junit4]>at 
org.apache.lucene.search.QueryUtils.check(QueryUtils.java:128)
   [junit4]>at 
org.apache.lucene.search.QueryUtils.check(QueryUtils.java:118)
   [junit4]>at 
org.apache.lucene.search.CheckHits.checkHitCollector(CheckHits.java:98)
   [junit4]>at 

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+122) - Build # 17038 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17038/
Java: 64bit/jdk-9-ea+122 -XX:-UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:36380/solr/testschemaapi_shard1_replica1: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:36380/solr/testschemaapi_shard1_replica1: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([7C3544226B3F324C:F4617BF8C5C35FB4]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:697)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1109)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:998)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:934)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:86)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:55)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 

[jira] [Comment Edited] (SOLR-9243) Add ability for the TermsComponent to fetch the docFreq for a list of terms

[Joel Bernstein (JIRA)]

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

Joel Bernstein edited comment on SOLR-9243 at 6/22/16 6:32 PM:
---

The initial implementation is looking fairly good.

It provides the following simple but useful behavior:

If the terms.list parameter is provided it will return the terms and docFreqs 
for each term in the list. The list will always be sorted in index order.





was (Author: joel.bernstein):
The initial implementation is looking fairly good.

If provides the following simple but useful behavior:

If the terms.list parameter is provided it will return the terms and docFreqs 
for each term in the list. The list will always be sorted in index order.




> Add ability for the TermsComponent to fetch the docFreq for a list of terms
> ---
>
> Key: SOLR-9243
> URL: https://issues.apache.org/jira/browse/SOLR-9243
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-9243.patch, SOLR-9243.patch, SOLR-9243.patch, 
> SOLR-9243.patch, SOLR-9243.patch
>
>
> Currently the TermsComponent is used to retrieve Terms given a set of 
> parameters.
> This ticket will add the ability to retrieve Terms and docFreq for a specific 
> list of Terms.
> This is needed to support SOLR-9193 which needs to fetch the docFreq for a 
> list of Terms.
> This should also be useful as a general tool for fetching docFreq given a 
> list of Terms.



--
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: VOTE: Apache Solr Ref Guide for 6.1

[Kevin Risden]

+1 the resized images for the SQL clients look great.

Kevin Risden

On Wed, Jun 22, 2016 at 1:38 AM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> +1
>
> On Tue, Jun 21, 2016 at 11:49 PM, Cassandra Targett 
> wrote:
>
>> Please VOTE to release the Apache Solr Ref Guide for 6.1.
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.1-RC0/
>>
>> $ more /apache-solr-ref-guide-6.1.pdf.sha1
>> 5929b03039e99644bc4ef23b37088b343e2ff0c8  apache-solr-ref-guide-6.1.pdf
>>
>> Here's my +1.
>>
>> Thanks,
>> Cassandra
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>

[jira] [Commented] (SOLR-8521) Add documentation for how to use Solr JDBC driver with SQL client like DB Visualizer

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-8521:


[~ctargett] Thanks for the heads up and agree the screenshots might have been 
too big. Feel free to adjust/modify as you see fit. I can take a stab at moving 
the images to the wiki and out of the reference guide in the next few weeks if 
that helps.

> Add documentation for how to use Solr JDBC driver with SQL client like DB 
> Visualizer
> 
>
> Key: SOLR-8521
> URL: https://issues.apache.org/jira/browse/SOLR-8521
> Project: Solr
>  Issue Type: Sub-task
>  Components: documentation, SolrJ
>Affects Versions: 6.0
>Reporter: Kevin Risden
>Assignee: Kevin Risden
> Attachments: dbvisualizer_solrjdbc.zip, 
> solr_jdbc_dbvisualizer_20160203.pdf
>
>
> Currently this requires the following:
> * a JDBC SQL client program (like DBVisualizer or SQuirrelSQL)
> * all jars from solr/dist/solrj-lib/* to be on the SQL client classpath
> * solr/dist/solr-solrj-6.0.0-SNAPSHOT.jar on the SQL client classpath
> * a valid JDBC connection string (like 
> jdbc:solr://SOLR_ZK_CONNECTION_STRING?collection=COLLECTION_NAME)
> * without SOLR-8213, the username/password supplied by the SQL client will be 
> ignored.



--
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-9167) Unable to connect to solr via solrj jdbc driver

[Kevin Risden (JIRA)]

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

Kevin Risden commented on SOLR-9167:


[~christian.schwarzin...@proclos.com] - jdbc:solr://localhost:8983 shouldn't 
this be jdbc:solr://localhost:9983? You should be pointing to ZK not to the 
Solr server address.

> Unable to connect to solr via solrj jdbc driver 
> 
>
> Key: SOLR-9167
> URL: https://issues.apache.org/jira/browse/SOLR-9167
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud, SolrJ
>Affects Versions: 6.0
> Environment: java.version=1.8.0_77
> java.vendor=Oracle Corporation
> os.name=Mac OS X
> os.arch=x86_64
> os.version=10.11.5
>Reporter: Christian Schwarzinger
>Priority: Minor
>
> Getting the following error, when trying to connect to solr via jdbc driver.
> {panel:title=client 
> error|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> (ClientCnxn.java:1102) - Session 0x0 for server 
> fe80:0:0:0:0:0:0:1%1/fe80:0:0:0:0:0:0:1%1:8983, unexpected error, closing 
> socket connection and attempting reconnect
> java.io.IOException: Packet len1213486160 is out of range!
>   at 
> org.apache.zookeeper.ClientCnxnSocket.readLength(ClientCnxnSocket.java:112) 
> ~[zookeeper-3.4.6.jar:3.4.6-1569965]
>   at 
> org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:79) 
> ~[zookeeper-3.4.6.jar:3.4.6-1569965]
>   at 
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:366)
>  ~[zookeeper-3.4.6.jar:3.4.6-1569965]
>   at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081) 
> [zookeeper-3.4.6.jar:3.4.6-1569965]
> {panel}
> This is imho. caused by the following server error:
> {panel:title=server 
> error|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
> Illegal character 0x0 in state=START for buffer 
> HeapByteBuffer@5cc6fe87[p=1,l=49,c=8192,r=48]={\x00<<<\x00\x00-\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00>>>charset=UTF-8\r\nCo...\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00}
> {panel}
> Using http interface for sql via curl works however:
> {code}
> bin/solr start -cloud
> bin/solr create -c test
> curl -X POST -H 'Content-Type: application/json' 
> 'http://localhost:8983/solr/test/update/json/docs' --data-binary '
> {
>   "id": "1",
>   "title": "Doc 1"
> }'
> curl 'http://localhost:8983/solr/test/update?commit=true'
> curl --data-urlencode 'stmt=SELECT count(*) FROM test' 
> http://localhost:8983/solr/test/sql?aggregationMode=facet
> {code}
> This is the code, that fails:
> {code}
> Connection con = 
> DriverManager.getConnection("jdbc:solr://localhost:8983?collection=test=map_reduce=2");
> {code}
> taken from: 
> https://cwiki.apache.org/confluence/display/solr/Parallel+SQL+Interface
> Same error also occurs in 6.1.0-68 developer snapshot.
> Background: I'm trying to write a solr sql connector for Jedox BI Suite, 
> which should allow for better integration of solr into BI processes. Any 
> advice / help appreciated.



--
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-7374) Backup/Restore should provide a param for specifying the directory implementation it should use

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-7374:
---

bq. So developers end up diagnosing and fixing such issues after committing the 
code

This is a common issue, and usually it comes down to what the developers judge 
at commit. There is so much random testing going on, if we did it all in one 
run, the test run would take forever. At the same time, you want common paths 
to be fairly well tested every run.

At the end of the day, I generally do it based on how painful it is in extra 
test time vs how core the functionality being tested is.

If you are writing or changing tests, you generally run them many times before 
committing (at least you probably should in many cases - there is a beasting 
target and scripts to help with this), and you will find most things. The many 
Jenkins machines that are running tests all the time will find them otherwise, 
and that is okay too.

We have a fairly lax commit then review policy and following up with a fix or 
two based on jenkins random fails is common.

I'll leave this one for you and Varun to figure out, just giving some context.

> Backup/Restore should provide a param for specifying the directory 
> implementation it should use
> ---
>
> Key: SOLR-7374
> URL: https://issues.apache.org/jira/browse/SOLR-7374
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Assignee: Mark Miller
> Fix For: 6.2
>
> Attachments: SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch, 
> SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch, 
> SOLR-7374.patch, SOLR-7374.patch
>
>
> Currently when we create a backup we use SimpleFSDirectory to write the 
> backup indexes. Similarly during a restore we open the index using 
> FSDirectory.open . 
> We should provide a param called {{directoryImpl}} or {{type}} which will be 
> used to specify the Directory implementation to backup the index. 
> Likewise during a restore you would need to specify the directory impl which 
> was used during backup so that the index can be opened correctly.
> This param will address the problem that currently if a user is running Solr 
> on HDFS there is no way to use the backup/restore functionality as the 
> directory is hardcoded.
> With this one could be running Solr on a local FS but backup the index on 
> HDFS etc.



--
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-master - Build # 1049 - Still Failing

[Apache Jenkins Server]

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

10 tests failed.
FAILED:  org.apache.solr.core.TestDynamicLoading.testDynamicLoading

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

Stack Trace:
java.lang.AssertionError: Could not get expected value  'X val' for path 'x' 
full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"/_xd/lc",
"path":"/test1",
"httpMethod":"GET"},
  "class":"org.apache.solr.core.BlobStoreTestRequestHandler",
  "x":null},  from server:  null
at 
__randomizedtesting.SeedInfo.seed([7BD1F753BCAF05E0:A39CDA044B72A040]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:481)
at 
org.apache.solr.core.TestDynamicLoading.testDynamicLoading(TestDynamicLoading.java:232)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

[jira] [Commented] (SOLR-9243) Add ability for the TermsComponent to fetch the docFreq for a list of terms

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9243:
--

The initial implementation is looking fairly good.

If provides the following simple but useful behavior:

If the terms.list parameter is provided it will return the terms and docFreqs 
for each term in the list. The list will always be sorted in index order.




> Add ability for the TermsComponent to fetch the docFreq for a list of terms
> ---
>
> Key: SOLR-9243
> URL: https://issues.apache.org/jira/browse/SOLR-9243
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-9243.patch, SOLR-9243.patch, SOLR-9243.patch, 
> SOLR-9243.patch, SOLR-9243.patch
>
>
> Currently the TermsComponent is used to retrieve Terms given a set of 
> parameters.
> This ticket will add the ability to retrieve Terms and docFreq for a specific 
> list of Terms.
> This is needed to support SOLR-9193 which needs to fetch the docFreq for a 
> list of Terms.
> This should also be useful as a general tool for fetching docFreq given a 
> list of Terms.



--
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-9241) Rebalance API for SolrCloud

[Nitin Sharma (JIRA)]

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

Nitin Sharma commented on SOLR-9241:


I am in parallel trying to port my patch to master and testing out the API. I 
will update the jira either if I am successful or if I run into issues in 
porting. Thanks for the feedback! 

Joel: I will update the patch with the right naming convention too. 

> Rebalance API for SolrCloud
> ---
>
> Key: SOLR-9241
> URL: https://issues.apache.org/jira/browse/SOLR-9241
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Affects Versions: 4.6.1
> Environment: Ubuntu, Mac OsX
>Reporter: Nitin Sharma
>  Labels: Cluster, SolrCloud
> Fix For: 4.6.1
>
> Attachments: rebalance.diff
>
>   Original Estimate: 2,016h
>  Remaining Estimate: 2,016h
>
> This is the v1 of the patch for Solrcloud Rebalance api (as described in 
> http://engineering.bloomreach.com/solrcloud-rebalance-api/) , built at 
> Bloomreach by Nitin Sharma and Suruchi Shah. The goal of the API  is to 
> provide a zero downtime mechanism to perform data manipulation and  efficient 
> core allocation in solrcloud. This API was envisioned to be the base layer 
> that enables Solrcloud to be an auto scaling platform. (and work in unison 
> with other complementing monitoring and scaling features).
> Patch Status:
> ===
> The patch is work in progress and incremental. We have done a few rounds of 
> code clean up. We wanted to get the patch going first to get initial feed 
> back.  We will continue to work on making it more open source friendly and 
> easily testable.
>  Deployment Status:
> 
> The platform is deployed in production at bloomreach and has been battle 
> tested for large scale load. (millions of documents and hundreds of 
> collections).
>  Internals:
> =
> The internals of the API and performance : 
> http://engineering.bloomreach.com/solrcloud-rebalance-api/
> It is built on top of the admin collections API as an action (with various 
> flavors). At a high level, the rebalance api provides 2 constructs:
> Scaling Strategy:  Decides how to move the data.  Every flavor has multiple 
> options which can be reviewed in the api spec.
> Re-distribute  - Move around data in the cluster based on capacity/allocation.
> Auto Shard  - Dynamically shard a collection to any size.
> Smart Merge - Distributed Mode - Helps merging data from a larger shard setup 
> into smaller one.  (the source should be divisible by destination)
> Scale up -  Add replicas on the fly
> Scale Down - Remove replicas on the fly
> Allocation Strategy:  Decides where to put the data.  (Nodes with least 
> cores, Nodes that do not have this collection etc). Custom implementations 
> can be built on top as well. One other example is Availability Zone aware. 
> Distribute data such that every replica is placed on different availability 
> zone to support HA.
>  Detailed API Spec:
> 
>   https://github.com/bloomreach/solrcloud-rebalance-api
>  Contributors:
> =
>   Nitin Sharma
>   Suruchi Shah
>  Questions/Comments:
> =
>   You can reach me at nitin.sha...@bloomreach.com



--
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-9243) Add ability for the TermsComponent to fetch the docFreq for a list of terms

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9243:
-
Attachment: SOLR-9243.patch

Added distributed tests.

> Add ability for the TermsComponent to fetch the docFreq for a list of terms
> ---
>
> Key: SOLR-9243
> URL: https://issues.apache.org/jira/browse/SOLR-9243
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-9243.patch, SOLR-9243.patch, SOLR-9243.patch, 
> SOLR-9243.patch, SOLR-9243.patch
>
>
> Currently the TermsComponent is used to retrieve Terms given a set of 
> parameters.
> This ticket will add the ability to retrieve Terms and docFreq for a specific 
> list of Terms.
> This is needed to support SOLR-9193 which needs to fetch the docFreq for a 
> list of Terms.
> This should also be useful as a general tool for fetching docFreq given a 
> list of Terms.



--
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-7374) Backup/Restore should provide a param for specifying the directory implementation it should use

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-7374:


[~varunthacker] Oh BTW let's not hold up the patch for this. This is more of a 
question than a review comment :)

> Backup/Restore should provide a param for specifying the directory 
> implementation it should use
> ---
>
> Key: SOLR-7374
> URL: https://issues.apache.org/jira/browse/SOLR-7374
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Assignee: Mark Miller
> Fix For: 6.2
>
> Attachments: SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch, 
> SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch, 
> SOLR-7374.patch, SOLR-7374.patch
>
>
> Currently when we create a backup we use SimpleFSDirectory to write the 
> backup indexes. Similarly during a restore we open the index using 
> FSDirectory.open . 
> We should provide a param called {{directoryImpl}} or {{type}} which will be 
> used to specify the Directory implementation to backup the index. 
> Likewise during a restore you would need to specify the directory impl which 
> was used during backup so that the index can be opened correctly.
> This param will address the problem that currently if a user is running Solr 
> on HDFS there is no way to use the backup/restore functionality as the 
> directory is hardcoded.
> With this one could be running Solr on a local FS but backup the index on 
> HDFS etc.



--
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-9194) Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper

[Erick Erickson (JIRA)]

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

Erick Erickson updated SOLR-9194:
-
Attachment: SOLR-9194.patch

Here's a pretty complete patch for the Unix side, I'd appreciate anyone who 
wants to give it a whirl and provide feedback. There are several things I'd 
like people to look at if they have an opinion:

> First checking if my Git mojo is improved enough to create a complete patch 
> when adding new files.

> I added a configsets/cloud-subdirs directory so I'd have something concise to 
> copy around to test recursive copy and move. I'm a bit reluctant to actually 
> include this, any better suggestions? All I really care about is that there's 
> a place with subdirectories that isn't huge. Maybe just cloud-robust or 
> something so we have a place to create more complete configset examples? I 
> don't want there to be a zillion configsets is all.

> ZkConfigManager already has recursive methods that the 'cp -r' and 'mv -r' zk 
> commands could use if they were public (I've made them so temporarily with 
> nocommits). This seems kind of A Bad Thing though since they're now 
> mis-placed; the cp command has nothing to do with configuration management. 
> Should these be moved to some new ZkUtil class or some such?

> Copying and moving when the destination is ZK is a bit strange in that parent 
> znodes can have data too. So you get different behavior when copying, say, 
> schema.xml -> 'zk:/configsets/myconfigs' as opposed to 
> 'zk:/configests/myconfigs/' (notice trailing slash). This can lead to odd 
> situations where you have content associated with, say, 
> /configsets/myconfigs. On the one hand "that's just the way Zookeeper works". 
> On the other it'll be surprising. Any suggestions on how to handle? I tried 
> to be smart about making the decision based on whether the znode had 
> children, but there's no reason one can't copy to 
> 'zk:/wherever/something.txt' which has no children so relying on presence of 
> children on the ZK nodes to figure out whether to put data in the node 
> specified or a child breaks copying individual files to individual (new) 
> files. And relying on data in a node precludes copying data to an empty 
> ZNode. Perhaps provide a rmdata command to make it easy for people to recover 
> the mistake?

> I don't yet have access to a Windows machine so anyone who wants to 
> incorporate the changes to the bin/solr script to solr.cmd feel free ;). I'll 
> get around to it "sometime", but sure would appreciate somebody who is more 
> experienced than me with Windows programming taking it on. All that _should_ 
> have to be done is reflect the changes in bin/solr then run the new ... BTW, 
> I did glance at that before my battery ran out on the plane and the use of 
> '@echo' as opposed to 'echo' seems inconsistent.

> Speaking of Windows there's code around looking for a trailing slash. Can I 
> rely on the Windows script to make sure the Java code only sees forward 
> slashes or do I need to normalize that in the Java code? This is important to 
> the point above about copying.

Thanks!

> Enhance the bin/solr script to put and get arbitrary files to/from Zookeeper
> 
>
> Key: SOLR-9194
> URL: https://issues.apache.org/jira/browse/SOLR-9194
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-9194.patch
>
>
> There are a few other files that can reasonably be pushed to Zookeeper, e.g. 
> solr.xml, security.json, clusterprops.json. Who knows? Even 
> /state.json for the brave.
> This could reduce further the need for bouncing out to zkcli.
> Assigning to myself just so I don't lose track, but I would _love_ it if 
> someone else wanted to take it...
> I'm thinking the commands would be 
> bin/solr zk -putfile -z  -p  -f 
> bin/solr zk -getfile -z  -p  -f 
> but I'm not wedded to those, all suggestions welcome.



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

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

[JENKINS] Lucene-Solr-6.x-Linux (32bit/jdk1.8.0_92) - Build # 943 - Failure!

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 8 object(s) that were not 
released!!! [MockDirectoryWrapper, MDCAwareThreadPoolExecutor, 
MDCAwareThreadPoolExecutor, MockDirectoryWrapper, TransactionLog, 
MockDirectoryWrapper, TransactionLog, MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([7E1169537886F2EA]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:257)
at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11311 lines...]
   [junit4] Suite: org.apache.solr.schema.TestManagedSchemaAPI
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/J0/temp/solr.schema.TestManagedSchemaAPI_7E1169537886F2EA-001/init-core-data-001
   [junit4]   2> 1149526 INFO  
(SUITE-TestManagedSchemaAPI-seed#[7E1169537886F2EA]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 1149528 INFO  
(SUITE-TestManagedSchemaAPI-seed#[7E1169537886F2EA]-worker) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1149528 INFO  (Thread-3018) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1149528 INFO  (Thread-3018) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1149628 INFO  
(SUITE-TestManagedSchemaAPI-seed#[7E1169537886F2EA]-worker) [] 
o.a.s.c.ZkTestServer start zk server on port:44875
   [junit4]   2> 1149628 INFO  
(SUITE-TestManagedSchemaAPI-seed#[7E1169537886F2EA]-worker) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1149629 INFO  
(SUITE-TestManagedSchemaAPI-seed#[7E1169537886F2EA]-worker) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1149634 INFO  (zkCallback-1136-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@1baab3 name:ZooKeeperConnection 
Watcher:127.0.0.1:44875 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4] 

[jira] [Commented] (SOLR-7374) Backup/Restore should provide a param for specifying the directory implementation it should use

[Hrishikesh Gadre (JIRA)]

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

Hrishikesh Gadre commented on SOLR-7374:


[~varunthacker] Thanks for the review. I think the changes look good. I have 
one question though.

bq. 4. Merged the replication handler and core admin handler test in 
TestHdfsBackupRestoreCore to one. We test it randomly

Wouldn't it be better to test both ways every time? I see that this pattern is 
used extensively in other tests too. My main concern is that the probability of 
one of the test not being executed in multiple iterations is > 0.  If someone 
makes any subsequent changes to this code, this unit test doesn't provide a 
strong assurance that these changes are correct since one of the tests may not 
have been executed at all. So developers end up diagnosing and fixing such 
issues after committing the code (which could have been done before the first 
commit itself). 

I do think that random tests are very useful to test the Solr cloud behavior 
(e.g. chaos monkey tests). But in this case, I am not sure if we need 
randomness. Any thoughts?


> Backup/Restore should provide a param for specifying the directory 
> implementation it should use
> ---
>
> Key: SOLR-7374
> URL: https://issues.apache.org/jira/browse/SOLR-7374
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Assignee: Mark Miller
> Fix For: 6.2
>
> Attachments: SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch, 
> SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch, 
> SOLR-7374.patch, SOLR-7374.patch
>
>
> Currently when we create a backup we use SimpleFSDirectory to write the 
> backup indexes. Similarly during a restore we open the index using 
> FSDirectory.open . 
> We should provide a param called {{directoryImpl}} or {{type}} which will be 
> used to specify the Directory implementation to backup the index. 
> Likewise during a restore you would need to specify the directory impl which 
> was used during backup so that the index can be opened correctly.
> This param will address the problem that currently if a user is running Solr 
> on HDFS there is no way to use the backup/restore functionality as the 
> directory is hardcoded.
> With this one could be running Solr on a local FS but backup the index on 
> HDFS etc.



--
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-9243) Add ability for the TermsComponent to fetch the docFreq for a list of terms

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9243:
-
Attachment: SOLR-9243.patch

Added some simple tests. Distributed test still to come.

> Add ability for the TermsComponent to fetch the docFreq for a list of terms
> ---
>
> Key: SOLR-9243
> URL: https://issues.apache.org/jira/browse/SOLR-9243
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-9243.patch, SOLR-9243.patch, SOLR-9243.patch, 
> SOLR-9243.patch
>
>
> Currently the TermsComponent is used to retrieve Terms given a set of 
> parameters.
> This ticket will add the ability to retrieve Terms and docFreq for a specific 
> list of Terms.
> This is needed to support SOLR-9193 which needs to fetch the docFreq for a 
> list of Terms.
> This should also be useful as a general tool for fetching docFreq given a 
> list of Terms.



--
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-4584) Request proxy mechanism not work if rows param is equal to zero

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-4584:
--

[~anshumg], this issue got caught up in Hoss'ss master->6.0 fixVersion change.  
I think we can just remove 6.0?

> Request proxy mechanism not work if rows param is equal to zero
> ---
>
> Key: SOLR-4584
> URL: https://issues.apache.org/jira/browse/SOLR-4584
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.2
> Environment: Linux Centos 6, Tomcat 7
>Reporter: Yago Riveiro
>Assignee: Mark Miller
> Fix For: 4.3, 6.0
>
> Attachments: Screen Shot 00.png, Screen Shot 01.png, Screen Shot 
> 02.png, Screen Shot 03.png, select
>
>
> If I try to do a request like:
> http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select?q=*:*=0
> The request fail. The solr UI logging has this error:
> {code:java} 
> null:org.apache.solr.common.SolrException: Error trying to proxy request for 
> url: http://192.168.20.47:8983/solr/ST-3A856BBCA3_12/select
> {code} 
> Chrome says:
> This webpage is not available
> The webpage at 
> http://192.168.20.47:8983/solr/ST-038412DCC2_0612/query?q=id:*=0 might 
> be temporarily down or it may have moved permanently to a new web address.
> Error 321 (net::ERR_INVALID_CHUNKED_ENCODING): Unknown error.
> If the param rows is set to rows=4 or superior the query return data as 
> expected.



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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/332/
Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:41563/solr/testschemaapi_shard1_replica2: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:41563/solr/testschemaapi_shard1_replica2: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([7D53338C3FD3A340:F5070C56912FCEB8]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:632)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:981)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:101)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:69)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Comment Edited] (LUCENE-7287) New lemma-tizer plugin for ukrainian language.

[Cassandra Targett (JIRA)]

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

Cassandra Targett edited comment on LUCENE-7287 at 6/22/16 3:44 PM:


If you do that (make a comment on the page with some text), I'll make sure it 
gets into the Solr Ref Guide. Just so you know, since this is for 6.2, I won't 
be able to add the content until after the current Ref Guide for 6.1 is 
released (vote going on now).

_edit_: removed some of my earlier comment, I got this confused with SOLR-7739.


was (Author: ctargett):
If you do that (make a comment on the page with some text), I'll make sure it 
gets into the Solr Ref Guide. Just so you know, since this is for 6.2, I won't 
be able to add the content until after the current Ref Guide for 6.1 is 
released (vote going on now).

_edit_: removed some of my earlier comment, I got this confused with 
LUCENE-7739.

> New lemma-tizer plugin for ukrainian language.
> --
>
> Key: LUCENE-7287
> URL: https://issues.apache.org/jira/browse/LUCENE-7287
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Dmytro Hambal
>Priority: Minor
>  Labels: analysis, language, plugin
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7287.patch
>
>
> Hi all,
> I wonder whether you are interested in supporting a plugin which provides a 
> mapping between ukrainian word forms and their lemmas. Some tests and docs go 
> out-of-the-box =) .
> https://github.com/mrgambal/elasticsearch-ukrainian-lemmatizer
> It's really simple but still works and generates some value for its users.
> More: https://github.com/elastic/elasticsearch/issues/18303



--
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-7739) Lucene Classification Integration - UpdateRequestProcessor

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on SOLR-7739:
-

We can add this to the Ref Guide, but it's too late for the 6.1 version. The 
existing documentation to be added to the Solr Ref Guide is in the 
above-referenced blog post? Even though it's too late for 6.1, I can put this 
in the draft area to be included for the next release in 6.2; people would be 
able to access it online until formal publication in the PDF.

> Lucene Classification Integration - UpdateRequestProcessor
> --
>
> Key: SOLR-7739
> URL: https://issues.apache.org/jira/browse/SOLR-7739
> Project: Solr
>  Issue Type: New Feature
>  Components: update
>Reporter: Alessandro Benedetti
>Assignee: Tommaso Teofili
>Priority: Minor
>  Labels: classification, index-time, update.chain, 
> updateProperties
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-7739.1.patch, SOLR-7739.patch, SOLR-7739.patch, 
> SOLR-7739.patch
>
>
> It would be nice to have an UpdateRequestProcessor to interact with the 
> Lucene Classification Module and provide an easy way of auto classifying Solr 
> Documents on indexing.
> Documentation will be provided with the patch
> A first design will be provided soon.



--
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] (SOLR-9237) DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be overidden

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9237:
-
Comment: was deleted

(was: Oops attached patch to the wrong ticket.)

> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be 
> overidden
> ---
>
> Key: SOLR-9237
> URL: https://issues.apache.org/jira/browse/SOLR-9237
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 6.1
>Reporter: Gethin James
>Assignee: Jan Høydahl
> Fix For: 6.1.1, 6.2, master (7.0)
>
> Attachments: SOLR-9237.patch
>
>
> With *6.1.0* the *protected* method 
> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter passes in a 
> *private* class called FvhContainer which makes it very difficult to extend.
> I have code that extends DefaultSolrHighlighter which I can't fix due to this 
> issue.
> Could you consider making FvhContainer  "protected" and use a constructor?



--
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-9243) Add ability for the TermsComponent to fetch the docFreq for a list of terms

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9243:
-
Attachment: SOLR-9243.patch

> Add ability for the TermsComponent to fetch the docFreq for a list of terms
> ---
>
> Key: SOLR-9243
> URL: https://issues.apache.org/jira/browse/SOLR-9243
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-9243.patch, SOLR-9243.patch, SOLR-9243.patch
>
>
> Currently the TermsComponent is used to retrieve Terms given a set of 
> parameters.
> This ticket will add the ability to retrieve Terms and docFreq for a specific 
> list of Terms.
> This is needed to support SOLR-9193 which needs to fetch the docFreq for a 
> list of Terms.
> This should also be useful as a general tool for fetching docFreq given a 
> list of Terms.



--
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] (SOLR-9237) DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be overidden

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9237:
-
Comment: was deleted

(was: New patch fixes compilation error.)

> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be 
> overidden
> ---
>
> Key: SOLR-9237
> URL: https://issues.apache.org/jira/browse/SOLR-9237
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 6.1
>Reporter: Gethin James
>Assignee: Jan Høydahl
> Fix For: 6.1.1, 6.2, master (7.0)
>
> Attachments: SOLR-9237.patch
>
>
> With *6.1.0* the *protected* method 
> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter passes in a 
> *private* class called FvhContainer which makes it very difficult to extend.
> I have code that extends DefaultSolrHighlighter which I can't fix due to this 
> issue.
> Could you consider making FvhContainer  "protected" and use a constructor?



--
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-9237) DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be overidden

[Joel Bernstein (JIRA)]

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

Joel Bernstein commented on SOLR-9237:
--

Oops attached patch to the wrong ticket.

> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be 
> overidden
> ---
>
> Key: SOLR-9237
> URL: https://issues.apache.org/jira/browse/SOLR-9237
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 6.1
>Reporter: Gethin James
>Assignee: Jan Høydahl
> Fix For: 6.1.1, 6.2, master (7.0)
>
> Attachments: SOLR-9237.patch
>
>
> With *6.1.0* the *protected* method 
> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter passes in a 
> *private* class called FvhContainer which makes it very difficult to extend.
> I have code that extends DefaultSolrHighlighter which I can't fix due to this 
> issue.
> Could you consider making FvhContainer  "protected" and use a constructor?



--
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-9237) DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be overidden

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9237:
-
Attachment: SOLR-9243.patch

New patch fixes compilation error.

> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be 
> overidden
> ---
>
> Key: SOLR-9237
> URL: https://issues.apache.org/jira/browse/SOLR-9237
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 6.1
>Reporter: Gethin James
>Assignee: Jan Høydahl
> Fix For: 6.1.1, 6.2, master (7.0)
>
> Attachments: SOLR-9237.patch
>
>
> With *6.1.0* the *protected* method 
> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter passes in a 
> *private* class called FvhContainer which makes it very difficult to extend.
> I have code that extends DefaultSolrHighlighter which I can't fix due to this 
> issue.
> Could you consider making FvhContainer  "protected" and use a constructor?



--
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-9237) DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be overidden

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9237:
-
Attachment: (was: SOLR-9243.patch)

> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be 
> overidden
> ---
>
> Key: SOLR-9237
> URL: https://issues.apache.org/jira/browse/SOLR-9237
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 6.1
>Reporter: Gethin James
>Assignee: Jan Høydahl
> Fix For: 6.1.1, 6.2, master (7.0)
>
> Attachments: SOLR-9237.patch
>
>
> With *6.1.0* the *protected* method 
> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter passes in a 
> *private* class called FvhContainer which makes it very difficult to extend.
> I have code that extends DefaultSolrHighlighter which I can't fix due to this 
> issue.
> Could you consider making FvhContainer  "protected" and use a constructor?



--
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-9243) Add ability for the TermsComponent to fetch the docFreq for a list of terms

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9243:
-
Attachment: SOLR-9243.patch

New patch guarding against NULL TermContext

> Add ability for the TermsComponent to fetch the docFreq for a list of terms
> ---
>
> Key: SOLR-9243
> URL: https://issues.apache.org/jira/browse/SOLR-9243
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-9243.patch, SOLR-9243.patch
>
>
> Currently the TermsComponent is used to retrieve Terms given a set of 
> parameters.
> This ticket will add the ability to retrieve Terms and docFreq for a specific 
> list of Terms.
> This is needed to support SOLR-9193 which needs to fetch the docFreq for a 
> list of Terms.
> This should also be useful as a general tool for fetching docFreq given a 
> list of Terms.



--
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-9243) Add ability for the TermsComponent to fetch the docFreq for a list of terms

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9243:
-
Attachment: SOLR-9243.patch

Patch that shows proposed changes to the TermsComponent. Tests will follow.

> Add ability for the TermsComponent to fetch the docFreq for a list of terms
> ---
>
> Key: SOLR-9243
> URL: https://issues.apache.org/jira/browse/SOLR-9243
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
> Attachments: SOLR-9243.patch
>
>
> Currently the TermsComponent is used to retrieve Terms given a set of 
> parameters.
> This ticket will add the ability to retrieve Terms and docFreq for a specific 
> list of Terms.
> This is needed to support SOLR-9193 which needs to fetch the docFreq for a 
> list of Terms.
> This should also be useful as a general tool for fetching docFreq given a 
> list of Terms.



--
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-7287) New lemma-tizer plugin for ukrainian language.

[Cassandra Targett (JIRA)]

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

Cassandra Targett edited comment on LUCENE-7287 at 6/22/16 3:23 PM:


If you do that (make a comment on the page with some text), I'll make sure it 
gets into the Solr Ref Guide. Just so you know, since this is for 6.2, I won't 
be able to add the content until after the current Ref Guide for 6.1 is 
released (vote going on now).

_edit_: removed some of my earlier comment, I got this confused with 
LUCENE-7739.


was (Author: ctargett):
If you do that (make a comment on the page with some text or pointing to the 
wiki page someone said they wrote), I'll make sure it gets into the Solr Ref 
Guide. 

I'm not clear if this made it into 6.1, however? If not, I won't be able to add 
the content until after the current Ref Guide for 6.1 is released (vote going 
on now).

> New lemma-tizer plugin for ukrainian language.
> --
>
> Key: LUCENE-7287
> URL: https://issues.apache.org/jira/browse/LUCENE-7287
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Dmytro Hambal
>Priority: Minor
>  Labels: analysis, language, plugin
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7287.patch
>
>
> Hi all,
> I wonder whether you are interested in supporting a plugin which provides a 
> mapping between ukrainian word forms and their lemmas. Some tests and docs go 
> out-of-the-box =) .
> https://github.com/mrgambal/elasticsearch-ukrainian-lemmatizer
> It's really simple but still works and generates some value for its users.
> More: https://github.com/elastic/elasticsearch/issues/18303



--
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-7287) New lemma-tizer plugin for ukrainian language.

[Cassandra Targett (JIRA)]

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

Cassandra Targett commented on LUCENE-7287:
---

If you do that (make a comment on the page with some text or pointing to the 
wiki page someone said they wrote), I'll make sure it gets into the Solr Ref 
Guide. 

I'm not clear if this made it into 6.1, however? If not, I won't be able to add 
the content until after the current Ref Guide for 6.1 is released (vote going 
on now).

> New lemma-tizer plugin for ukrainian language.
> --
>
> Key: LUCENE-7287
> URL: https://issues.apache.org/jira/browse/LUCENE-7287
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Dmytro Hambal
>Priority: Minor
>  Labels: analysis, language, plugin
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7287.patch
>
>
> Hi all,
> I wonder whether you are interested in supporting a plugin which provides a 
> mapping between ukrainian word forms and their lemmas. Some tests and docs go 
> out-of-the-box =) .
> https://github.com/mrgambal/elasticsearch-ukrainian-lemmatizer
> It's really simple but still works and generates some value for its users.
> More: https://github.com/elastic/elasticsearch/issues/18303



--
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-7194) Ban Math.toRadians/toDegrees and remove all usages of it

[Michael McCandless (JIRA)]

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

Michael McCandless commented on LUCENE-7194:


Thank you [~daddywri]!

> Ban Math.toRadians/toDegrees and remove all usages of it
> 
>
> Key: LUCENE-7194
> URL: https://issues.apache.org/jira/browse/LUCENE-7194
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Karl Wright
> Fix For: 6.x, master (7.0)
>
> Attachments: LUCENE-7194.patch
>
>
> The result of these methods is unreliable and changes across jvm versions: we 
> cannot use these methods.
> The following program prints 0.7722082215479366 on previous versions of java 
> but 0.7722082215479367 on java 9 because Math.toRadians is no longer doing 
> the same thing:
> {code}
> public class test {
>   public static void main(String args[]) throws Exception {
> System.out.println(Math.toRadians(44.244272));
>   }
> }
> {code}
> This is because of https://bugs.openjdk.java.net/browse/JDK-4477961. 
> I am not really sure its a bug, because the method says that the conversion 
> is "generally inexact". 



--
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-9215) QT parameter doesn't appear to function anymore

[Erick Erickson (JIRA)]

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

Erick Erickson commented on SOLR-9215:
--

Can we either close this ticket or propose something specific to un-confuse 
this?

> QT parameter doesn't appear to function anymore
> ---
>
> Key: SOLR-9215
> URL: https://issues.apache.org/jira/browse/SOLR-9215
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0, master (7.0)
>Reporter: Markus Jelsma
> Fix For: 6.2, master (7.0)
>
>
> The qt parameter doesn't seem to work anymore. A call directly to the /terms 
> handler returns actual terms, as expected. Using the select handler but with 
> qt=terms returns noting.
> http://localhost:8983/solr/logs/select?qt=terms=true=compound_digest=100=index
> {code}
> 
> 
> 
>   0
>   0
>   
> terms
> true
> compound_digest
> 100
> index
>   
> 
> 
> 
> 
> {code}
> A peculiar detail, my unit tests that rely on the qt parameter are not 
> affected.



--
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-7287) New lemma-tizer plugin for ukrainian language.

[Ahmet Arslan (JIRA)]

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

Ahmet Arslan commented on LUCENE-7287:
--

only committers have rights to edit confluence wiki. Contributors include the 
proposed change/addition as a message at the end of the page.

> New lemma-tizer plugin for ukrainian language.
> --
>
> Key: LUCENE-7287
> URL: https://issues.apache.org/jira/browse/LUCENE-7287
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Dmytro Hambal
>Priority: Minor
>  Labels: analysis, language, plugin
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7287.patch
>
>
> Hi all,
> I wonder whether you are interested in supporting a plugin which provides a 
> mapping between ukrainian word forms and their lemmas. Some tests and docs go 
> out-of-the-box =) .
> https://github.com/mrgambal/elasticsearch-ukrainian-lemmatizer
> It's really simple but still works and generates some value for its users.
> More: https://github.com/elastic/elasticsearch/issues/18303



--
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-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+122) - Build # 17037 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17037/
Java: 32bit/jdk-9-ea+122 -server -XX:+UseSerialGC

2 tests failed.
FAILED:  org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs.testDMQ8

Error Message:
(+((field:yy (field:w5)^100.0) | (field:xx)^10.0)~0.5 -extra:extra) 
NEVER:MATCH: score(doc=713)=-1.9956312E-6 != explanationScore=-3.9912625E-6 
Explanation: -3.9912625E-6 = sum of:   -3.9912625E-6 = weight(field:w5 in 713) 
[RandomSimilarity], result of: -3.9912625E-6 = score(IBSimilarity, doc=713, 
freq=1.0), computed from:   100.0 = boost   0.0 = NormalizationH2, 
computed from:  1.0 = tf 5.502638 = avgFieldLength 
5.6493154E19 = len   0.2533109 = LambdaTTF, computed from:  2256.0 
= totalTermFreq 8909.0 = numberOfDocuments   -3.9912624E-8 = 
DistributionSPL  expected:<-1.9956312E-6> but was:<-3.9912625E-6>

Stack Trace:
junit.framework.AssertionFailedError: (+((field:yy (field:w5)^100.0) | 
(field:xx)^10.0)~0.5 -extra:extra) NEVER:MATCH: 
score(doc=713)=-1.9956312E-6 != explanationScore=-3.9912625E-6 Explanation: 
-3.9912625E-6 = sum of:
  -3.9912625E-6 = weight(field:w5 in 713) [RandomSimilarity], result of:
-3.9912625E-6 = score(IBSimilarity, doc=713, freq=1.0), computed from:
  100.0 = boost
  0.0 = NormalizationH2, computed from: 
1.0 = tf
5.502638 = avgFieldLength
5.6493154E19 = len
  0.2533109 = LambdaTTF, computed from: 
2256.0 = totalTermFreq
8909.0 = numberOfDocuments
  -3.9912624E-8 = DistributionSPL
 expected:<-1.9956312E-6> but was:<-3.9912625E-6>
at 
__randomizedtesting.SeedInfo.seed([882B619046E7216B:D4118BC551735775]:0)
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.failNotEquals(Assert.java:287)
at junit.framework.Assert.assertEquals(Assert.java:120)
at 
org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:338)
at 
org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:358)
at 
org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:358)
at 
org.apache.lucene.search.CheckHits.verifyExplanation(CheckHits.java:358)
at 
org.apache.lucene.search.CheckHits$ExplanationAsserter.collect(CheckHits.java:501)
at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
at 
org.apache.lucene.search.AssertingCollector$1.collect(AssertingCollector.java:56)
at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
at 
org.apache.lucene.search.AssertingLeafCollector.collect(AssertingLeafCollector.java:52)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.scoreRange(Weight.java:196)
at 
org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:183)
at 
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:79)
at 
org.apache.lucene.search.ReqExclBulkScorer.score(ReqExclBulkScorer.java:48)
at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
at 
org.apache.lucene.search.AssertingBulkScorer.score(AssertingBulkScorer.java:69)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
at 
org.apache.lucene.search.AssertingIndexSearcher.search(AssertingIndexSearcher.java:91)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
at 
org.apache.lucene.search.CheckHits.checkExplanations(CheckHits.java:310)
at 
org.apache.lucene.search.QueryUtils.checkExplanations(QueryUtils.java:104)
at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:132)
at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:128)
at org.apache.lucene.search.QueryUtils.check(QueryUtils.java:118)
at 
org.apache.lucene.search.CheckHits.checkHitCollector(CheckHits.java:98)
at 
org.apache.lucene.search.BaseExplanationTestCase.qtest(BaseExplanationTestCase.java:114)
at 
org.apache.lucene.search.TestSimpleExplanationsWithFillerDocs.qtest(TestSimpleExplanationsWithFillerDocs.java:113)
at 
org.apache.lucene.search.TestSimpleExplanations.testDMQ8(TestSimpleExplanations.java:182)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@9-ea/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@9-ea/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@9-ea/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@9-ea/Method.java:531)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 

[jira] [Commented] (LUCENE-7287) New lemma-tizer plugin for ukrainian language.

[Andriy Rysin (JIRA)]

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

Andriy Rysin commented on LUCENE-7287:
--

I've logged in into cwiki but I don't seem to have rights to edit the page.

> New lemma-tizer plugin for ukrainian language.
> --
>
> Key: LUCENE-7287
> URL: https://issues.apache.org/jira/browse/LUCENE-7287
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Dmytro Hambal
>Priority: Minor
>  Labels: analysis, language, plugin
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7287.patch
>
>
> Hi all,
> I wonder whether you are interested in supporting a plugin which provides a 
> mapping between ukrainian word forms and their lemmas. Some tests and docs go 
> out-of-the-box =) .
> https://github.com/mrgambal/elasticsearch-ukrainian-lemmatizer
> It's really simple but still works and generates some value for its users.
> More: https://github.com/elastic/elasticsearch/issues/18303



--
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-7194) Ban Math.toRadians/toDegrees and remove all usages of it

[Karl Wright (JIRA)]

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

Karl Wright resolved LUCENE-7194.
-
   Resolution: Fixed
Fix Version/s: master (7.0)
   6.x

> Ban Math.toRadians/toDegrees and remove all usages of it
> 
>
> Key: LUCENE-7194
> URL: https://issues.apache.org/jira/browse/LUCENE-7194
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Karl Wright
> Fix For: 6.x, master (7.0)
>
> Attachments: LUCENE-7194.patch
>
>
> The result of these methods is unreliable and changes across jvm versions: we 
> cannot use these methods.
> The following program prints 0.7722082215479366 on previous versions of java 
> but 0.7722082215479367 on java 9 because Math.toRadians is no longer doing 
> the same thing:
> {code}
> public class test {
>   public static void main(String args[]) throws Exception {
> System.out.println(Math.toRadians(44.244272));
>   }
> }
> {code}
> This is because of https://bugs.openjdk.java.net/browse/JDK-4477961. 
> I am not really sure its a bug, because the method says that the conversion 
> is "generally inexact". 



--
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-7194) Ban Math.toRadians/toDegrees and remove all usages of it

[ASF subversion and git services (JIRA)]

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

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

Commit 388d388c990c8d9e05ec9ba9bc881fdc921e734b in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=388d388 ]

LUCENE-7194: Ban Math.toRadians, Math.toDegrees


> Ban Math.toRadians/toDegrees and remove all usages of it
> 
>
> Key: LUCENE-7194
> URL: https://issues.apache.org/jira/browse/LUCENE-7194
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Karl Wright
> Attachments: LUCENE-7194.patch
>
>
> The result of these methods is unreliable and changes across jvm versions: we 
> cannot use these methods.
> The following program prints 0.7722082215479366 on previous versions of java 
> but 0.7722082215479367 on java 9 because Math.toRadians is no longer doing 
> the same thing:
> {code}
> public class test {
>   public static void main(String args[]) throws Exception {
> System.out.println(Math.toRadians(44.244272));
>   }
> }
> {code}
> This is because of https://bugs.openjdk.java.net/browse/JDK-4477961. 
> I am not really sure its a bug, because the method says that the conversion 
> is "generally inexact". 



--
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-7194) Ban Math.toRadians/toDegrees and remove all usages of it

[ASF subversion and git services (JIRA)]

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

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

Commit 40ca6f1d64ab8ec2e873c2a6c6815ca449b046a4 in lucene-solr's branch 
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=40ca6f1 ]

LUCENE-7194: Ban Math.toRadians and Math.toDegrees


> Ban Math.toRadians/toDegrees and remove all usages of it
> 
>
> Key: LUCENE-7194
> URL: https://issues.apache.org/jira/browse/LUCENE-7194
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Karl Wright
> Attachments: LUCENE-7194.patch
>
>
> The result of these methods is unreliable and changes across jvm versions: we 
> cannot use these methods.
> The following program prints 0.7722082215479366 on previous versions of java 
> but 0.7722082215479367 on java 9 because Math.toRadians is no longer doing 
> the same thing:
> {code}
> public class test {
>   public static void main(String args[]) throws Exception {
> System.out.println(Math.toRadians(44.244272));
>   }
> }
> {code}
> This is because of https://bugs.openjdk.java.net/browse/JDK-4477961. 
> I am not really sure its a bug, because the method says that the conversion 
> is "generally inexact". 



--
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-7276) Add an optional reason to the MatchNoDocsQuery

[Michael McCandless (JIRA)]

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

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

Another iteration ... the patch was much simpler now that LUCENE-7337 is done.

> Add an optional reason to the MatchNoDocsQuery
> --
>
> Key: LUCENE-7276
> URL: https://issues.apache.org/jira/browse/LUCENE-7276
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Ferenczi Jim
>Priority: Minor
>  Labels: patch
> Attachments: LUCENE-7276.patch, LUCENE-7276.patch, LUCENE-7276.patch, 
> LUCENE-7276.patch, LUCENE-7276.patch, LUCENE-7276.patch
>
>
> It's sometimes difficult to debug a query that results in a MatchNoDocsQuery. 
> The MatchNoDocsQuery is always rewritten in an empty boolean query.
> This patch adds an optional reason and implements a weight in order to keep 
> track of the reason why the query did not match any document. The reason is 
> printed on toString and when an explanation for noMatch is asked.  
> For instance the query:
> new MatchNoDocsQuery("Field not found").toString()
> => 'MatchNoDocsQuery["field 'title' not found"]'



--
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-9243) Add ability for the TermsComponent to fetch the docFreq for a list of terms

[Joel Bernstein (JIRA)]

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

Joel Bernstein updated SOLR-9243:
-
Description: 
Currently the TermsComponent is used to retrieve Terms given a set of 
parameters.

This ticket will add the ability to retrieve Terms and docFreq for a specific 
list of Terms.

This is needed to support SOLR-9193 which needs to fetch the docFreq for a list 
of Terms.

This should also be useful as a general tool for fetching docFreq given a list 
of Terms.

  was:
Currently the TermsComponent is used to retrieve Terms given a set of 
parameters.

This ticket will add the ability to retrieve Terms and docFreq for a specific 
list of Terms.

This is needed to support the SOLR-9193 which needs to fetch the docFreq for a 
list of Terms.

This should also be useful as a general tool for fetching docFreq given a list 
of Terms.


> Add ability for the TermsComponent to fetch the docFreq for a list of terms
> ---
>
> Key: SOLR-9243
> URL: https://issues.apache.org/jira/browse/SOLR-9243
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> Currently the TermsComponent is used to retrieve Terms given a set of 
> parameters.
> This ticket will add the ability to retrieve Terms and docFreq for a specific 
> list of Terms.
> This is needed to support SOLR-9193 which needs to fetch the docFreq for a 
> list of Terms.
> This should also be useful as a general tool for fetching docFreq given a 
> list of Terms.



--
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-9243) Add ability for the TermsComponent to fetch the docFreq for a list of terms

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-9243:


Assignee: Joel Bernstein

> Add ability for the TermsComponent to fetch the docFreq for a list of terms
> ---
>
> Key: SOLR-9243
> URL: https://issues.apache.org/jira/browse/SOLR-9243
> Project: Solr
>  Issue Type: Improvement
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> Currently the TermsComponent is used to retrieve Terms given a set of 
> parameters.
> This ticket will add the ability to retrieve Terms and docFreq for a specific 
> list of Terms.
> This is needed to support the SOLR-9193 which needs to fetch the docFreq for 
> a list of Terms.
> This should also be useful as a general tool for fetching docFreq given a 
> list of Terms.



--
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-9193) Add the nodeRank Streaming Expression

[Joel Bernstein (JIRA)]

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

Joel Bernstein reassigned SOLR-9193:


Assignee: Joel Bernstein

> Add the nodeRank Streaming Expression
> -
>
> Key: SOLR-9193
> URL: https://issues.apache.org/jira/browse/SOLR-9193
> Project: Solr
>  Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>
> The nodeRank Streaming Expression is another GraphExpression. It will 
> decorate a gatherNodes expression and us a tf-idf ranking algorithm to rank 
> the nodes to support recommendations.
> The gatherNodes expression only gathers nodes and aggregations. This is 
> similar in nature to tf in search ranking, where the number of times a node 
> appears in the traversal represents the tf. But this skews recommendations 
> towards nodes that appear frequently in the index.
> Using the idf for each node we can score each node as a function of tf and 
> idf. This will provide a boost to nodes that appear less frequently in the 
> index. 
> The nodeRank expression will gather the idf's from the shards for each node 
> emitted by the underlying gatherNodes expression. It will then perform the 
> ranking. The underlying gatherNodes expression will perform the aggregation 
> providing the tf.



--
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-9215) QT parameter doesn't appear to function anymore

[Markus Jelsma (JIRA)]

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

Markus Jelsma commented on SOLR-9215:
-

Yeah thanka, that's the problem indeed and i should have known it. But it is 
confusing indeed.

> QT parameter doesn't appear to function anymore
> ---
>
> Key: SOLR-9215
> URL: https://issues.apache.org/jira/browse/SOLR-9215
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0, master (7.0)
>Reporter: Markus Jelsma
> Fix For: 6.2, master (7.0)
>
>
> The qt parameter doesn't seem to work anymore. A call directly to the /terms 
> handler returns actual terms, as expected. Using the select handler but with 
> qt=terms returns noting.
> http://localhost:8983/solr/logs/select?qt=terms=true=compound_digest=100=index
> {code}
> 
> 
> 
>   0
>   0
>   
> terms
> true
> compound_digest
> 100
> index
>   
> 
> 
> 
> 
> {code}
> A peculiar detail, my unit tests that rely on the qt parameter are not 
> affected.



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

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

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

[Apache Jenkins Server]

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

No tests ran.

Build Log:
[...truncated 39773 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
   [smoker] Java 1.8 
JAVA_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (22.3 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.5.2-src.tgz...
   [smoker] 28.7 MB in 0.03 sec (1098.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.2.tgz...
   [smoker] 63.5 MB in 0.06 sec (1080.8 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.2.zip...
   [smoker] 73.9 MB in 0.06 sec (1146.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.5.2.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.2.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.2-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 220 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 220 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker]   Backcompat testing not required for release 6.0.1 because 
it's not less than 5.5.2
   [smoker]   Backcompat testing not required for release 6.0.0 because 
it's not less than 5.5.2
   [smoker]   Backcompat testing not required for release 6.1.0 because 
it's not less than 5.5.2
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (161.7 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-5.5.2-src.tgz...
   [smoker] 37.6 MB in 0.04 sec (997.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.2.tgz...
   [smoker] 130.5 MB in 0.13 sec (1027.9 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.2.zip...
   [smoker] 138.4 MB in 0.14 sec (1021.5 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-5.5.2.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-5.5.2.tgz...
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.2/contrib/dataimporthandler-extras/lib/javax.mail-1.5.1.jar:
 it has javax.* classes
   [smoker]   **WARNING**: skipping check of 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/tmp/unpack/solr-5.5.2/contrib/dataimporthandler-extras/lib/activation-1.1.1.jar:
 it has javax.* classes
   [smoker] copying unpacked distribution for Java 7 ...
   [smoker] test solr example w/ Java 7...
   

[jira] [Commented] (SOLR-9235) Indexing stuck after delete by range query

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev commented on SOLR-9235:


my gut feeling, you can only use ranges in delete query with 5.5.x and earlier. 

> Indexing stuck after delete by range query
> --
>
> Key: SOLR-9235
> URL: https://issues.apache.org/jira/browse/SOLR-9235
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 6.0.1, 6.1
>Reporter: Anders Melchiorsen
>
> Upgrading from Solr 4.0.0 to 6.0.1/6.1.0, this old query suddenly got our 
> indexing stuck:
> {noformat}
> lastdate_a:{* TO 20160620} AND lastdate_p:{* TO 20160620} AND 
> country:9
> {noformat}
> with this error logged:
> {noformat}
> 2016-06-20 02:20:36.429 ERROR (commitScheduler-15-thread-1) [   x:mycore] 
> o.a.s.u.CommitTracker auto commit error...:java.lang.NullPointerException
> at 
> org.apache.solr.query.SolrRangeQuery.createDocSet(SolrRangeQuery.java:156)
> at 
> org.apache.solr.query.SolrRangeQuery.access$200(SolrRangeQuery.java:57)
> at 
> org.apache.solr.query.SolrRangeQuery$ConstWeight.getSegState(SolrRangeQuery.java:412)
> at 
> org.apache.solr.query.SolrRangeQuery$ConstWeight.scorer(SolrRangeQuery.java:484)
> at 
> org.apache.lucene.search.LRUQueryCache$CachingWrapperWeight.scorer(LRUQueryCache.java:617)
> at 
> org.apache.lucene.search.BooleanWeight.scorer(BooleanWeight.java:389)
> at 
> org.apache.solr.update.DeleteByQueryWrapper$1.scorer(DeleteByQueryWrapper.java:89)
> at 
> org.apache.lucene.index.BufferedUpdatesStream.applyQueryDeletes(BufferedUpdatesStream.java:694)
> at 
> org.apache.lucene.index.BufferedUpdatesStream.applyDeletesAndUpdates(BufferedUpdatesStream.java:262)
> at 
> org.apache.lucene.index.IndexWriter.applyAllDeletesAndUpdates(IndexWriter.java:3187)
> at 
> org.apache.lucene.index.IndexWriter.maybeApplyDeletes(IndexWriter.java:3173)
> at 
> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2825)
> at 
> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2989)
> at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2956)
> at 
> org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:619)
> at org.apache.solr.update.CommitTracker.run(CommitTracker.java:217)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The types were:
> {noformat}
>omitNorms="true"/>
>   
>   
>multiValued="true" />
> {noformat}
> but changing the date fields into "integer" seems to avoid the problem:
> {noformat}
>   
> {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-9243) Add ability for the TermsComponent to fetch the docFreq for a list of terms

[Joel Bernstein (JIRA)]

Joel Bernstein created SOLR-9243:


 Summary: Add ability for the TermsComponent to fetch the docFreq 
for a list of terms
 Key: SOLR-9243
 URL: https://issues.apache.org/jira/browse/SOLR-9243
 Project: Solr
  Issue Type: Improvement
Reporter: Joel Bernstein


Currently the TermsComponent is used to retrieve Terms given a set of 
parameters.

This ticket will add the ability to retrieve Terms and docFreq for a specific 
list of Terms.

This is needed to support the SOLR-9193 which needs to fetch the docFreq for a 
list of Terms.

This should also be useful as a general tool for fetching docFreq given a list 
of Terms.



--
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-7287) New lemma-tizer plugin for ukrainian language.

[Ahmet Arslan (JIRA)]

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

Ahmet Arslan commented on LUCENE-7287:
--

I think you, as the author of Ukrainian. Thanks!

> New lemma-tizer plugin for ukrainian language.
> --
>
> Key: LUCENE-7287
> URL: https://issues.apache.org/jira/browse/LUCENE-7287
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Dmytro Hambal
>Priority: Minor
>  Labels: analysis, language, plugin
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7287.patch
>
>
> Hi all,
> I wonder whether you are interested in supporting a plugin which provides a 
> mapping between ukrainian word forms and their lemmas. Some tests and docs go 
> out-of-the-box =) .
> https://github.com/mrgambal/elasticsearch-ukrainian-lemmatizer
> It's really simple but still works and generates some value for its users.
> More: https://github.com/elastic/elasticsearch/issues/18303



--
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-7374) Backup/Restore should provide a param for specifying the directory implementation it should use

[Varun Thacker (JIRA)]

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

Varun Thacker updated SOLR-7374:

Attachment: SOLR-7374.patch

Hi Hrishikesh ,

I took your latest patch and made a few minor changes. I'll list them out as 
accurately as I can ( I closed the window where I was noted down the changes 
while making them )

1. In {{BackupRepository}} removed some modifiers that were not needed.
2. Created {{BackupRestoreUtils}} for some of the tests to reuse the classes. 
Methods like {{indexDocs}} and {{verifyDocs]} were moved there and made to 
reuse in our all backup/restore tests
3. Made some modifications to the CHANGES entry
4. Merged the replication handler and core admin handler test in 
{{TestHdfsBackupRestoreCore}} to one. We test it randomly 

I've run the test suite once and it passes along with precommit. Let me know if 
this looks good . I plan to go over it one more time tomorrow morning and 
commit it otherwise

> Backup/Restore should provide a param for specifying the directory 
> implementation it should use
> ---
>
> Key: SOLR-7374
> URL: https://issues.apache.org/jira/browse/SOLR-7374
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
>Assignee: Mark Miller
> Fix For: 6.2
>
> Attachments: SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch, 
> SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch, SOLR-7374.patch, 
> SOLR-7374.patch, SOLR-7374.patch
>
>
> Currently when we create a backup we use SimpleFSDirectory to write the 
> backup indexes. Similarly during a restore we open the index using 
> FSDirectory.open . 
> We should provide a param called {{directoryImpl}} or {{type}} which will be 
> used to specify the Directory implementation to backup the index. 
> Likewise during a restore you would need to specify the directory impl which 
> was used during backup so that the index can be opened correctly.
> This param will address the problem that currently if a user is running Solr 
> on HDFS there is no way to use the backup/restore functionality as the 
> directory is hardcoded.
> With this one could be running Solr on a local FS but backup the index on 
> HDFS etc.



--
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: [VOTE] Release Lucene/Solr 5.5.2 RC2

[Noble Paul]

+1

SUCCESS! [1:48:50.241582]

On Wed, Jun 22, 2016 at 4:28 PM, Sanne Grinovero
 wrote:
> +1
>
> [from the Hibernate Search integration testsuite]
>
> On 22 June 2016 at 06:35, Shalin Shekhar Mangar  
> wrote:
>> +1
>>
>> SUCCESS! [2:19:37.075305]
>>
>> On Tue, Jun 21, 2016 at 10:18 PM, Steve Rowe  wrote:
>>>
>>> Please vote for release candidate 2 for Lucene/Solr 5.5.2
>>>
>>> The artifacts can be downloaded from:
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.2-RC2-rev8e5d40b22a3968df065dfc078ef81cbb031f0e4a/
>>>
>>> You can run the smoke tester directly with this command:
>>>
>>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.2-RC2-rev8e5d40b22a3968df065dfc078ef81cbb031f0e4a/
>>>
>>> +1 from me - Docs, changes and javadocs look good, and smoke tester says:
>>> SUCCESS! [0:32:02.113685]
>>>
>>> --
>>> Steve
>>> www.lucidworks.com
>>>
>>>
>>> -
>>> 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
>



-- 
-
Noble Paul

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

[jira] [Commented] (LUCENE-7287) New lemma-tizer plugin for ukrainian language.

[Andriy Rysin (JIRA)]

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

Andriy Rysin commented on LUCENE-7287:
--

Thanks Ahmet, that looks good! Would you add/push those changes or shall I work 
on this?

> New lemma-tizer plugin for ukrainian language.
> --
>
> Key: LUCENE-7287
> URL: https://issues.apache.org/jira/browse/LUCENE-7287
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Dmytro Hambal
>Priority: Minor
>  Labels: analysis, language, plugin
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7287.patch
>
>
> Hi all,
> I wonder whether you are interested in supporting a plugin which provides a 
> mapping between ukrainian word forms and their lemmas. Some tests and docs go 
> out-of-the-box =) .
> https://github.com/mrgambal/elasticsearch-ukrainian-lemmatizer
> It's really simple but still works and generates some value for its users.
> More: https://github.com/elastic/elasticsearch/issues/18303



--
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-7282) Cache config or index schema objects by configset and share them across cores

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-7282 at 6/22/16 12:24 PM:


Looked at the patch. It's broken. 

The way you cache things assume that schema is immutable. it is not. 
{{IndexSchema}} can change all the time. So, the cache must be aware of the 
znode version from where the schema is loaded. 

There are two ways we can cache.
# Cache the schema file content and avoid reloading from ZK. This is low impact 
and cheaper to implement but less beneficial. The cost of parsing the XML is 
high. If we can pre-parse the XML and store them as Java objects and share this 
java object it is faster.
# Cache the {{IndexSchema}} object. This would mean, we need to carefully look  
at the lifecycle of components in {{IndexSchema}}. We will also have to keep in 
mind that eventually we will have to support dynamic loading of components in 
schema. I would say this is a risky path to take

 


was (Author: noble.paul):
Looked at the patch. It's broken. 

The way you cache things assume that schema is immutable. it is not. 
{{IndexSchema}} can change all the time. So, the cache must be aware of the 
znode version from where the schema is loaded. 

There are two ways we can cache.
# Cache the schema file content and avoid reloading from ZK. This is low impact 
and cheaper to implement but less beneficial. The cost of parsing the XML is 
high. If we can pre-parse the XML and store them as Java objects and share this 
java object it is faster.
# Cache the {{IndexSchema}} object. This would mean, we need to carefully look  
at the lifecycle of components in {{IndexSchema}}

 

> Cache config or index schema objects by configset and share them across cores
> -
>
> Key: SOLR-7282
> URL: https://issues.apache.org/jira/browse/SOLR-7282
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7282.patch
>
>
> Sharing schema and config objects has been known to improve startup 
> performance when a large number of cores are on the same box (See 
> http://wiki.apache.org/solr/LotsOfCores).Damien also saw improvements to 
> cluster startup speed upon caching the index schema in SOLR-7191.
> Now that SolrCloud configuration is based on config sets in ZK, we should 
> explore how we can minimize config/schema parsing for each core in a way that 
> is compatible with the recent/planned changes in the config and schema APIs.



--
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-7282) Cache config or index schema objects by configset and share them across cores

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-7282:
--

Looked at the patch. It's broken. 

The way you cache things assume that schema is immutable. it is not. 
{{IndexSchema}} can change all the time. So, the cache must be aware of the 
znode version from where the schema is loaded. 

There are two ways we can cache.
# Cache the schema file content and avoid reloading from ZK. This is low impact 
and cheaper to implement but less beneficial. The cost of parsing the XML is 
high. If we can pre-parse the XML and store them as Java objects and share this 
java object it is faster.
# Cache the {{IndexSchema}} object. This would mean, we need to carefully look  
at the lifecycle of components in {{IndexSchema}}

 

> Cache config or index schema objects by configset and share them across cores
> -
>
> Key: SOLR-7282
> URL: https://issues.apache.org/jira/browse/SOLR-7282
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7282.patch
>
>
> Sharing schema and config objects has been known to improve startup 
> performance when a large number of cores are on the same box (See 
> http://wiki.apache.org/solr/LotsOfCores).Damien also saw improvements to 
> cluster startup speed upon caching the index schema in SOLR-7191.
> Now that SolrCloud configuration is based on config sets in ZK, we should 
> explore how we can minimize config/schema parsing for each core in a way that 
> is compatible with the recent/planned changes in the config and schema APIs.



--
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-7191) Improve stability and startup performance of SolrCloud with thousands of collections

[Noble Paul (JIRA)]

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

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

patch updated to trunk

> Improve stability and startup performance of SolrCloud with thousands of 
> collections
> 
>
> Key: SOLR-7191
> URL: https://issues.apache.org/jira/browse/SOLR-7191
> Project: Solr
>  Issue Type: Bug
>  Components: SolrCloud
>Affects Versions: 5.0
>Reporter: Shawn Heisey
>Assignee: Shalin Shekhar Mangar
>  Labels: performance, scalability
> Attachments: SOLR-7191.patch, SOLR-7191.patch, SOLR-7191.patch, 
> SOLR-7191.patch, SOLR-7191.patch, lots-of-zkstatereader-updates-branch_5x.log
>
>
> A user on the mailing list with thousands of collections (5000 on 4.10.3, 
> 4000 on 5.0) is having severe problems with getting Solr to restart.
> I tried as hard as I could to duplicate the user setup, but I ran into many 
> problems myself even before I was able to get 4000 collections created on a 
> 5.0 example cloud setup.  Restarting Solr takes a very long time, and it is 
> not very stable once it's up and running.
> This kind of setup is very much pushing the envelope on SolrCloud performance 
> and scalability.  It doesn't help that I'm running both Solr nodes on one 
> machine (I started with 'bin/solr -e cloud') and that ZK is embedded.



--
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-7194) Ban Math.toRadians/toDegrees and remove all usages of it

[ASF subversion and git services (JIRA)]

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

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

Commit b11e48c7553daed127b1b231641d7367a09aed1b in lucene-solr's branch 
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b11e48c ]

LUCENE-7194: Ban Math.toRadians and Math.toDegrees


> Ban Math.toRadians/toDegrees and remove all usages of it
> 
>
> Key: LUCENE-7194
> URL: https://issues.apache.org/jira/browse/LUCENE-7194
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Karl Wright
> Attachments: LUCENE-7194.patch
>
>
> The result of these methods is unreliable and changes across jvm versions: we 
> cannot use these methods.
> The following program prints 0.7722082215479366 on previous versions of java 
> but 0.7722082215479367 on java 9 because Math.toRadians is no longer doing 
> the same thing:
> {code}
> public class test {
>   public static void main(String args[]) throws Exception {
> System.out.println(Math.toRadians(44.244272));
>   }
> }
> {code}
> This is because of https://bugs.openjdk.java.net/browse/JDK-4477961. 
> I am not really sure its a bug, because the method says that the conversion 
> is "generally inexact". 



--
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-7739) Lucene Classification Integration - UpdateRequestProcessor

[Tomas Ramanauskas (JIRA)]

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

Tomas Ramanauskas commented on SOLR-7739:
-

Thanks, Alessandro. I fixed the config and I think the code for this feature is 
now being executed, however it's still not working. So I'll send an e-mail to 
Solr-user mailing list.

> Lucene Classification Integration - UpdateRequestProcessor
> --
>
> Key: SOLR-7739
> URL: https://issues.apache.org/jira/browse/SOLR-7739
> Project: Solr
>  Issue Type: New Feature
>  Components: update
>Reporter: Alessandro Benedetti
>Assignee: Tommaso Teofili
>Priority: Minor
>  Labels: classification, index-time, update.chain, 
> updateProperties
> Fix For: 6.1, master (7.0)
>
> Attachments: SOLR-7739.1.patch, SOLR-7739.patch, SOLR-7739.patch, 
> SOLR-7739.patch
>
>
> It would be nice to have an UpdateRequestProcessor to interact with the 
> Lucene Classification Module and provide an easy way of auto classifying Solr 
> Documents on indexing.
> Documentation will be provided with the patch
> A first design will be provided soon.



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

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

[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_92) - Build # 265 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/265/
Java: 32bit/jdk1.8.0_92 -server -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.handler.TestReqParamsAPI.test

Error Message:
Could not get expected value  'CY val' for path 'response/params/y/c' full 
output: {   "responseHeader":{ "status":0, "QTime":0},   "response":{   
  "znodeVersion":0, "params":{"x":{ "a":"A val", "b":"B 
val", "":{"v":0},  from server:  
http://127.0.0.1:57018/pt_/w/collection1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'CY val' for path 
'response/params/y/c' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "response":{
"znodeVersion":0,
"params":{"x":{
"a":"A val",
"b":"B val",
"":{"v":0},  from server:  http://127.0.0.1:57018/pt_/w/collection1
at 
__randomizedtesting.SeedInfo.seed([FB5FA7FCCDB174EB:730B9826634D1913]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:481)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:159)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 

Re: [VOTE] Release Lucene/Solr 5.5.2 RC2

[Sanne Grinovero]

+1

[from the Hibernate Search integration testsuite]

On 22 June 2016 at 06:35, Shalin Shekhar Mangar  wrote:
> +1
>
> SUCCESS! [2:19:37.075305]
>
> On Tue, Jun 21, 2016 at 10:18 PM, Steve Rowe  wrote:
>>
>> Please vote for release candidate 2 for Lucene/Solr 5.5.2
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.2-RC2-rev8e5d40b22a3968df065dfc078ef81cbb031f0e4a/
>>
>> You can run the smoke tester directly with this command:
>>
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.2-RC2-rev8e5d40b22a3968df065dfc078ef81cbb031f0e4a/
>>
>> +1 from me - Docs, changes and javadocs look good, and smoke tester says:
>> SUCCESS! [0:32:02.113685]
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>>
>> -
>> 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

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

[Apache Jenkins Server]

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

2 tests failed.
FAILED:  
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithTimeDelay

Error Message:
Could not find collection : c1

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : c1
at 
__randomizedtesting.SeedInfo.seed([D6E90D24F425D34E:A977BAA19D47FEC4]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:170)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdate(ZkStateReaderTest.java:129)
at 
org.apache.solr.cloud.overseer.ZkStateReaderTest.testStateFormatUpdateWithTimeDelay(ZkStateReaderTest.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeMixedAdds

Error Message:
soft529 wasn't fast enough

Stack Trace:
java.lang.AssertionError: soft529 wasn't fast enough
  

[JENKINS] Lucene-Solr-5.5-Linux (64bit/jdk1.7.0_80) - Build # 330 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/330/
Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  org.apache.solr.schema.TestManagedSchemaAPI.test

Error Message:
Error from server at http://127.0.0.1:46535/solr/testschemaapi_shard1_replica1: 
ERROR: [doc=2] unknown field 'myNewField1'

Stack Trace:
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error from 
server at http://127.0.0.1:46535/solr/testschemaapi_shard1_replica1: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([6BDC47E46808537A:E388783EC6F43E82]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:632)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:981)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:870)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:806)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:101)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:69)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 

[jira] [Commented] (SOLR-9235) Indexing stuck after delete by range query

[Anders Melchiorsen (JIRA)]

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

Anders Melchiorsen commented on SOLR-9235:
--

I forgot to mention that the exception is from version 6.0.1. I did test with 
6.1.0 and saw the same issue.

> Indexing stuck after delete by range query
> --
>
> Key: SOLR-9235
> URL: https://issues.apache.org/jira/browse/SOLR-9235
> Project: Solr
>  Issue Type: Bug
>  Components: query parsers
>Affects Versions: 6.0.1, 6.1
>Reporter: Anders Melchiorsen
>
> Upgrading from Solr 4.0.0 to 6.0.1/6.1.0, this old query suddenly got our 
> indexing stuck:
> {noformat}
> lastdate_a:{* TO 20160620} AND lastdate_p:{* TO 20160620} AND 
> country:9
> {noformat}
> with this error logged:
> {noformat}
> 2016-06-20 02:20:36.429 ERROR (commitScheduler-15-thread-1) [   x:mycore] 
> o.a.s.u.CommitTracker auto commit error...:java.lang.NullPointerException
> at 
> org.apache.solr.query.SolrRangeQuery.createDocSet(SolrRangeQuery.java:156)
> at 
> org.apache.solr.query.SolrRangeQuery.access$200(SolrRangeQuery.java:57)
> at 
> org.apache.solr.query.SolrRangeQuery$ConstWeight.getSegState(SolrRangeQuery.java:412)
> at 
> org.apache.solr.query.SolrRangeQuery$ConstWeight.scorer(SolrRangeQuery.java:484)
> at 
> org.apache.lucene.search.LRUQueryCache$CachingWrapperWeight.scorer(LRUQueryCache.java:617)
> at 
> org.apache.lucene.search.BooleanWeight.scorer(BooleanWeight.java:389)
> at 
> org.apache.solr.update.DeleteByQueryWrapper$1.scorer(DeleteByQueryWrapper.java:89)
> at 
> org.apache.lucene.index.BufferedUpdatesStream.applyQueryDeletes(BufferedUpdatesStream.java:694)
> at 
> org.apache.lucene.index.BufferedUpdatesStream.applyDeletesAndUpdates(BufferedUpdatesStream.java:262)
> at 
> org.apache.lucene.index.IndexWriter.applyAllDeletesAndUpdates(IndexWriter.java:3187)
> at 
> org.apache.lucene.index.IndexWriter.maybeApplyDeletes(IndexWriter.java:3173)
> at 
> org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2825)
> at 
> org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2989)
> at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2956)
> at 
> org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:619)
> at org.apache.solr.update.CommitTracker.run(CommitTracker.java:217)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The types were:
> {noformat}
>omitNorms="true"/>
>   
>   
>multiValued="true" />
> {noformat}
> but changing the date fields into "integer" seems to avoid the problem:
> {noformat}
>   
> {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] (LUCENE-7194) Ban Math.toRadians/toDegrees and remove all usages of it

[Karl Wright (JIRA)]

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

Karl Wright updated LUCENE-7194:

Attachment: LUCENE-7194.patch

Here's the patch

> Ban Math.toRadians/toDegrees and remove all usages of it
> 
>
> Key: LUCENE-7194
> URL: https://issues.apache.org/jira/browse/LUCENE-7194
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Robert Muir
>Assignee: Karl Wright
> Attachments: LUCENE-7194.patch
>
>
> The result of these methods is unreliable and changes across jvm versions: we 
> cannot use these methods.
> The following program prints 0.7722082215479366 on previous versions of java 
> but 0.7722082215479367 on java 9 because Math.toRadians is no longer doing 
> the same thing:
> {code}
> public class test {
>   public static void main(String args[]) throws Exception {
> System.out.println(Math.toRadians(44.244272));
>   }
> }
> {code}
> This is because of https://bugs.openjdk.java.net/browse/JDK-4477961. 
> I am not really sure its a bug, because the method says that the conversion 
> is "generally inexact". 



--
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-7287) New lemma-tizer plugin for ukrainian language.

[Ahmet Arslan (JIRA)]

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

Ahmet Arslan commented on LUCENE-7287:
--

So, Solr field type counterpart of this analyzer would be something like:

{code:xml}


   





  

{code}

It would be nice to add an entry for Ukranian to 
https://cwiki.apache.org/confluence/display/solr/Language+Analysis

> New lemma-tizer plugin for ukrainian language.
> --
>
> Key: LUCENE-7287
> URL: https://issues.apache.org/jira/browse/LUCENE-7287
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Reporter: Dmytro Hambal
>Priority: Minor
>  Labels: analysis, language, plugin
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7287.patch
>
>
> Hi all,
> I wonder whether you are interested in supporting a plugin which provides a 
> mapping between ukrainian word forms and their lemmas. Some tests and docs go 
> out-of-the-box =) .
> https://github.com/mrgambal/elasticsearch-ukrainian-lemmatizer
> It's really simple but still works and generates some value for its users.
> More: https://github.com/elastic/elasticsearch/issues/18303



--
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.5 - Build # 17 - Still Failing

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-5.5/17/

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

Error Message:
Timeout occured while waiting response from server at: 
https://127.0.0.1:58598/_/fk

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting 
response from server at: https://127.0.0.1:58598/_/fk
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:586)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:241)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:230)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.makeRequest(CollectionsAPIDistributedZkTest.java:400)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:516)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.test(CollectionsAPIDistributedZkTest.java:179)
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:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:996)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:971)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 

[jira] [Commented] (LUCENE-7339) Bring back RandomAccessFilterStrategy

[Uwe Schindler (JIRA)]

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

Uwe Schindler commented on LUCENE-7339:
---

All fine :-) Thanks for committing!

> Bring back RandomAccessFilterStrategy
> -
>
> Key: LUCENE-7339
> URL: https://issues.apache.org/jira/browse/LUCENE-7339
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7339.patch
>
>
> FiteredQuery had 3 ways of running conjunctions: leap-frog, query first and 
> random-access filter. We still use leap-frog for conjunctions and we now have 
> a better "query-first" strategy through two-phase iteration. However, we 
> don't have any equivalent for the random-access filter strategy.



--
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-7351) BKDWriter should compress doc ids when all values in a block are the same

[Adrien Grand (JIRA)]

Adrien Grand created LUCENE-7351:


 Summary: BKDWriter should compress doc ids when all values in a 
block are the same
 Key: LUCENE-7351
 URL: https://issues.apache.org/jira/browse/LUCENE-7351
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor


BKDWriter writes doc ids using 4 bytes per document. I think it should compress 
similarly to postings when all docs in a block have the same packed value. This 
can happen either when a field has a default value which is common across 
documents or when quantization makes the number of unique values so small that 
a large index will necessarily have blocks that all contain the same value (eg. 
there are only 63490 unique half-float values).



--
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-7339) Bring back RandomAccessFilterStrategy

[Adrien Grand (JIRA)]

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

Adrien Grand updated LUCENE-7339:
-
Fix Version/s: 6.2
   master (7.0)

> Bring back RandomAccessFilterStrategy
> -
>
> Key: LUCENE-7339
> URL: https://issues.apache.org/jira/browse/LUCENE-7339
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Fix For: master (7.0), 6.2
>
> Attachments: LUCENE-7339.patch
>
>
> FiteredQuery had 3 ways of running conjunctions: leap-frog, query first and 
> random-access filter. We still use leap-frog for conjunctions and we now have 
> a better "query-first" strategy through two-phase iteration. However, we 
> don't have any equivalent for the random-access filter strategy.



--
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-7339) Bring back RandomAccessFilterStrategy

[Adrien Grand (JIRA)]

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

Adrien Grand resolved LUCENE-7339.
--
Resolution: Fixed

Thanks Uwe, I applied the simplification you suggested.

> Bring back RandomAccessFilterStrategy
> -
>
> Key: LUCENE-7339
> URL: https://issues.apache.org/jira/browse/LUCENE-7339
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7339.patch
>
>
> FiteredQuery had 3 ways of running conjunctions: leap-frog, query first and 
> random-access filter. We still use leap-frog for conjunctions and we now have 
> a better "query-first" strategy through two-phase iteration. However, we 
> don't have any equivalent for the random-access filter strategy.



--
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-7339) Bring back RandomAccessFilterStrategy

[ASF subversion and git services (JIRA)]

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

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

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

LUCENE-7339: Specialize conjunction with bit sets.


> Bring back RandomAccessFilterStrategy
> -
>
> Key: LUCENE-7339
> URL: https://issues.apache.org/jira/browse/LUCENE-7339
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7339.patch
>
>
> FiteredQuery had 3 ways of running conjunctions: leap-frog, query first and 
> random-access filter. We still use leap-frog for conjunctions and we now have 
> a better "query-first" strategy through two-phase iteration. However, we 
> don't have any equivalent for the random-access filter strategy.



--
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-7339) Bring back RandomAccessFilterStrategy

[ASF subversion and git services (JIRA)]

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

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

Commit 60dcef6c61b0a72f4a7bb6e9b27a0073464f53c5 in lucene-solr's branch 
refs/heads/branch_6x from [~jpountz]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=60dcef6 ]

LUCENE-7339: Specialize conjunction with bit sets.


> Bring back RandomAccessFilterStrategy
> -
>
> Key: LUCENE-7339
> URL: https://issues.apache.org/jira/browse/LUCENE-7339
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7339.patch
>
>
> FiteredQuery had 3 ways of running conjunctions: leap-frog, query first and 
> random-access filter. We still use leap-frog for conjunctions and we now have 
> a better "query-first" strategy through two-phase iteration. However, we 
> don't have any equivalent for the random-access filter strategy.



--
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-9237) DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be overidden

[JIRA]

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

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

Sure, however it makes the initialization a bit more explicit and enables 
inline construction with {{new}} - sounds like [~covolution]'s custom code 
would benefit, so I'm OK with that..

> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter can't be 
> overidden
> ---
>
> Key: SOLR-9237
> URL: https://issues.apache.org/jira/browse/SOLR-9237
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 6.1
>Reporter: Gethin James
>Assignee: Jan Høydahl
> Fix For: 6.1.1, 6.2, master (7.0)
>
> Attachments: SOLR-9237.patch
>
>
> With *6.1.0* the *protected* method 
> DefaultSolrHighlighter.doHighlightingByFastVectorHighlighter passes in a 
> *private* class called FvhContainer which makes it very difficult to extend.
> I have code that extends DefaultSolrHighlighter which I can't fix due to this 
> issue.
> Could you consider making FvhContainer  "protected" and use a constructor?



--
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: VOTE: Apache Solr Ref Guide for 6.1

[Shalin Shekhar Mangar]

+1

On Tue, Jun 21, 2016 at 11:49 PM, Cassandra Targett 
wrote:

> Please VOTE to release the Apache Solr Ref Guide for 6.1.
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.1-RC0/
>
> $ more /apache-solr-ref-guide-6.1.pdf.sha1
> 5929b03039e99644bc4ef23b37088b343e2ff0c8  apache-solr-ref-guide-6.1.pdf
>
> Here's my +1.
>
> Thanks,
> Cassandra
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
Regards,
Shalin Shekhar Mangar.

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+122) - Build # 940 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/940/
Java: 32bit/jdk-9-ea+122 -client -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 12551 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/solr/build/solr-core/test/temp/junit4-J1-20160622_054002_543.sysout
   [junit4] >>> JVM J1 emitted unexpected output (verbatim) 
   [junit4] java.lang.OutOfMemoryError: Java heap space
   [junit4] Dumping heap to 
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/heapdumps/java_pid10921.hprof ...
   [junit4] Heap dump file created [297225565 bytes in 0.473 secs]
   [junit4] <<< JVM J1: EOF 

[...truncated 10295 lines...]
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:740: The following 
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-6.x-Linux/build.xml:692: Some of the tests 
produced a heap dump, but did not fail. Maybe a suppressed OutOfMemoryError? 
Dumps created:
* java_pid10921.hprof

Total time: 83 minutes 34 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
[WARNINGS] Skipping publisher since build result is FAILURE
Recording test results
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



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

[JENKINS] Lucene-Solr-master-Solaris (64bit/jdk1.8.0) - Build # 664 - Failure!

[Policeman Jenkins Server]

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

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

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([7DB1B3A288D2B5B0:C763DCDA0BFC5BA5]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:780)
at 
org.apache.solr.update.AutoCommitTest.testCommitWithin(AutoCommitTest.java:325)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: REQUEST FAILED: 
xpath=//result[@numFound=1]
xml response was: 

00


request was:q=id:529=standard=0=20=2.2
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:773)
... 40 more




Build Log:
[...truncated 11543 lines...]
   [junit4] Suite: