[jira] [Commented] (SOLR-9490) BoolField always returning false for non-DV fields?

[Pavan Shetty (JIRA)]

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

Pavan Shetty commented on SOLR-9490:


[~hossman], for me it seems to be the problem with solr's response writer. if i 
use xml or json response writer to get the information it returns proper value, 
true or false for boolean field, of course through solr admin console.

But if we have  binary response writer then it always returns false(or null) 
for boolean field, this one i tested through solr j client which uses this as 
response writer.

I changed lucene version 6.1 and 6.2 in solrconfig (or solr j version 6.1 / 
6.2) and it is working fine if solr version is below 6.2. if i change solr 
version to 6.2 then whatever lucene version (or solr j) it returns false for 
boolean field. Did reindexing each time i changed version of solr and lucene 
and issue is reproduce able for me.

> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {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-master-Solaris (64bit/jdk1.8.0) - Build # 836 - Unstable!

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 5 object(s) that were not 
released!!! [MockDirectoryWrapper, SolrCore, MDCAwareThreadPoolExecutor, 
MockDirectoryWrapper, MockDirectoryWrapper]
at __randomizedtesting.SeedInfo.seed([1F4A980471D0D0E3]: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.GeneratedMethodAccessor22.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:834)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at java.lang.Thread.run(Thread.java:745)


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

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

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1112 - Still Failing

[Apache Jenkins Server]

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

12 tests failed.
FAILED:  org.apache.solr.cloud.hdfs.HdfsUnloadDistributedZkTest.test

Error Message:
Error from server at http://127.0.0.1:46438: Error CREATEing SolrCore 
'test_unload_shard_and_collection_1': Unable to create core 
[test_unload_shard_and_collection_1] Caused by: Direct buffer memory

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at http://127.0.0.1:46438: Error CREATEing SolrCore 
'test_unload_shard_and_collection_1': Unable to create core 
[test_unload_shard_and_collection_1] Caused by: Direct buffer memory
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:608)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.cloud.UnloadDistributedZkTest.testUnloadShardAndCollection(UnloadDistributedZkTest.java:129)
at 
org.apache.solr.cloud.UnloadDistributedZkTest.test(UnloadDistributedZkTest.java:70)
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] [Assigned] (SOLR-9477) UpdateRequestProcessors ignore child documents

[Alexandre Rafalovitch (JIRA)]

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

Alexandre Rafalovitch reassigned SOLR-9477:
---

Assignee: Alexandre Rafalovitch

> UpdateRequestProcessors ignore child documents
> --
>
> Key: SOLR-9477
> URL: https://issues.apache.org/jira/browse/SOLR-9477
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2, master (7.0)
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
>  Labels: UpdateProcessor
>
> UpdateRequestProcessors completely ignore child documents. The only exception 
> is AddSchemaFieldsUpdateProcessorFactory. The rest seem to be completely 
> unaware that SolrInputDocument has getChildDocuments() or related methods.
> Easy test (on Solr 6.2):
> This works (with IDs auto-assigned and field names generated):
> {code}
> bin/solr create -c childtest
> bin/post -c childtest -type application/json -format solr -d '[{"a":1,"b":2}]'
> {code}
> This fails as the second/third command, with "missing ID field":
> {code}
> bin/post -c childtest -type application/json -format solr -d 
> '[{"a":1,"b":2,"_childDocuments_":[{"c":3,"d":4}]}]'
> {code}
> The message:
> {noformat}
> SimplePostTool version 5.0.0
> POSTing args to http://localhost:8983/solr/childtest/update...
> SimplePostTool: WARNING: Solr returned an error #400 (Bad Request) for url: 
> http://localhost:8983/solr/childtest/update
> SimplePostTool: WARNING: Response: 
> {"responseHeader":{"status":400,"QTime":4},"error":{"metadata":["error-class","org.apache.solr.common.SolrException","root-error-class","org.apache.solr.common.SolrException"],"msg":"[doc=null]
>  missing required field: id","code":400}}
> SimplePostTool: WARNING: IOException while reading response: 
> java.io.IOException: Server returned HTTP response code: 400 for URL: 
> http://localhost:8983/solr/childtest/update
> COMMITting Solr index changes to 
> http://localhost:8983/solr/childtest/update...
> Time spent: 0:00:00.042
> {noformat}
> I also verified it with BlankRemoving URP. I think this is a global problem.



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

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

[jira] [Assigned] (LUCENE-7417) Highlighting fails for MultiPhraseQuery's with one clause

[David Smiley (JIRA)]

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

David Smiley reassigned LUCENE-7417:


Assignee: David Smiley

> Highlighting fails for MultiPhraseQuery's with one clause
> -
>
> Key: LUCENE-7417
> URL: https://issues.apache.org/jira/browse/LUCENE-7417
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: 5.2.1, 5.x, 5.5.2
>Reporter: Thomas Kappler
>Assignee: David Smiley
> Attachments: multiphrasequery_singleclause_highlighting.patch
>
>
> This bug is the same issue as LUCENE-7231, just for MultiPhraseQuery instead 
> of PhraseQuery. The fix is the same as well. To reproduce, change the test 
> that was committed for LUCENE-7231 to use a MultiPhraseQuery. It results in 
> the same error
> {{java.lang.IllegalArgumentException: Less than 2 subSpans.size():1}}
> I have a patch including a test against branch_5.x, it just needs to go 
> through legal before I can post it.



--
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-7440) Document skipping on large indexes is broken

[Yonik Seeley (JIRA)]

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

Yonik Seeley updated LUCENE-7440:
-
Affects Version/s: master (7.0)

> Document skipping on large indexes is broken
> 
>
> Key: LUCENE-7440
> URL: https://issues.apache.org/jira/browse/LUCENE-7440
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/search
>Affects Versions: master (7.0)
>Reporter: Yonik Seeley
>Priority: Critical
>
> Large skips on large indexes fail.
> Anything that uses skips (such as a boolean query, filtered queries, faceted 
> queries, join queries, etc) can trigger this bug on a sufficiently large 
> index.



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

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

[jira] [Created] (LUCENE-7440) Document skipping on large indexes is broken

[Yonik Seeley (JIRA)]

Yonik Seeley created LUCENE-7440:


 Summary: Document skipping on large indexes is broken
 Key: LUCENE-7440
 URL: https://issues.apache.org/jira/browse/LUCENE-7440
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/search
Reporter: Yonik Seeley
Priority: Critical


Large skips on large indexes fail.
Anything that uses skips (such as a boolean query, filtered queries, faceted 
queries, join queries, etc) can trigger this bug on a sufficiently large index.




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

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

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

[Policeman Jenkins Server]

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

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

Error Message:
IOException occured when talking to server at: https://127.0.0.1:39846/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:39846/solr
at 
__randomizedtesting.SeedInfo.seed([AE293A8BA186279C:12474C9905D5A4E6]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:157)
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 

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

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: expected:<1> but was:<2>
at 
__randomizedtesting.SeedInfo.seed([554BB05F37C41891:8DBC74BB9C1FDACD]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexFetchOnMasterRestart(TestReplicationHandler.java:624)
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)




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

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

[Policeman Jenkins Server]

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

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

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 5 object(s) that were not 
released!!! [MockDirectoryWrapper, MockDirectoryWrapper, 
MDCAwareThreadPoolExecutor, MockDirectoryWrapper, TransactionLog]
at __randomizedtesting.SeedInfo.seed([BDF5F66642B9D578]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at 
org.apache.solr.SolrTestCaseJ4.teardownTestCases(SolrTestCaseJ4.java:258)
at sun.reflect.GeneratedMethodAccessor35.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 11268 lines...]
   [junit4] Suite: org.apache.solr.schema.TestManagedSchemaAPI
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.schema.TestManagedSchemaAPI_BDF5F66642B9D578-001\init-core-data-001
   [junit4]   2> 1002429 INFO  
(SUITE-TestManagedSchemaAPI-seed#[BDF5F66642B9D578]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (false) via: 
@org.apache.solr.util.RandomizeSSL(reason=, value=NaN, ssl=NaN, clientAuth=NaN)
   [junit4]   2> 1002432 INFO  
(SUITE-TestManagedSchemaAPI-seed#[BDF5F66642B9D578]-worker) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1002432 INFO  (Thread-1322) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1002432 INFO  (Thread-1322) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1002532 INFO  
(SUITE-TestManagedSchemaAPI-seed#[BDF5F66642B9D578]-worker) [] 
o.a.s.c.ZkTestServer start zk server on port:65298
   [junit4]   2> 1002532 INFO  
(SUITE-TestManagedSchemaAPI-seed#[BDF5F66642B9D578]-worker) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1002533 INFO  
(SUITE-TestManagedSchemaAPI-seed#[BDF5F66642B9D578]-worker) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1002538 INFO  (zkCallback-1257-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@1eebf2f name:ZooKeeperConnection 
Watcher:127.0.0.1:65298 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 1002538 INFO  
(SUITE-TestManagedSchemaAPI-seed#[BDF5F66642B9D578]-worker) [] 
o.a.s.c.c.ConnectionManager Client is 

[jira] [Assigned] (SOLR-9481) BasicAuthPlugin should support standalone mode

[JIRA]

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

Jan Høydahl reassigned SOLR-9481:
-

Assignee: Jan Høydahl

> BasicAuthPlugin should support standalone mode
> --
>
> Key: SOLR-9481
> URL: https://issues.apache.org/jira/browse/SOLR-9481
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: authentication
> Attachments: SOLR-9481.patch
>
>
> The BasicAuthPlugin currently only supports SolrCloud, and reads users and 
> credentials from ZK /security.json
> Add support for standalone mode operation



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

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

[jira] [Updated] (SOLR-9481) BasicAuthPlugin should support standalone mode

[JIRA]

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

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

First patch. Only changed CoreContainer to support loading security.json from 
SOLR_HOME. This was all it takes to fix all Auth/Autz plugins to work in 
standalone mode. Tested manually for {{BasicAuthPlugin}} and also 
{{RuleBasedAuthorizationPlugin}}, they both work without any modifications. The 
edit API does not work, will probably throw some exception that ZK is not 
available...

No automated tests yet.

> BasicAuthPlugin should support standalone mode
> --
>
> Key: SOLR-9481
> URL: https://issues.apache.org/jira/browse/SOLR-9481
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Jan Høydahl
>  Labels: authentication
> Attachments: SOLR-9481.patch
>
>
> The BasicAuthPlugin currently only supports SolrCloud, and reads users and 
> credentials from ZK /security.json
> Add support for standalone mode operation



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

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

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

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-9438:

Attachment: SOLR-9438.patch

Changes:
# We record the parent leader node name and the ephemeral owner of its live 
node (zk session id which created the live node) at the start of the split 
process.
# These two pieces of information called "shard_parent_node" and 
"shard_parent_zk_session" respectively, are stored in the cluster state along 
with the slice information.
# When all replicas of all sub-shards are live, the overseer checks if the 
parent leader node is still live and if its ephemeral owner is still the same. 
If yes, it switches the sub-shard states to active and parent to inactive. If 
not, it  changes the sub-shard state to a newly introduced "recovery_failed" 
state.
# Any shard in "recovery_failed" state does not receive any indexing or 
querying traffic.
# I beefed up the test to check for both outcomes and to assert that all 
documents that were successfully indexed are visible on a distributed search. 
Additionally, if the split succeeds, we also assert that all replicas of the 
sub-shards are consistent i.e. have the same number of docs.
# Fixed a test bug where concurrent watcher invocations on collection state 
would shutdown the leader node again even after the test had restarted it 
already to assert document counts.

Results of beasting are looking good as far as this particular bug is 
concerned, but there is a curious failure where one and only core stays down 
and times out the waiting for recovery check. I'm still digging.

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



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

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

RE: Java function throws exception on JSP web application

[Martin Gainty]

NoMethodFoundError is wrong servlet jar you cannot mix servlet-api.jar that 
does not meet the current Java Servlet Spec supported for your webapp
https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api
cannot override final class means exactly that ..any class that attempts to 
override a final class will throw that exception
select another class with commensurate functionality that isnt final to 
override or just use concrete implementation of final class itself
https://coderanch.com/t/410683/java/java/final-class
Martin-
> Date: Mon, 5 Sep 2016 00:41:54 -0700
> From: reg9sz...@freemail.hu
> To: dev@lucene.apache.org
> Subject: Re: Java function throws exception on JSP web application
> 
> Now, I became angry with silly errors. I created a new web application,
> copied the jars ini it, and now it works fine. 
> 
> But I have no idea, wat is the difference between the two applications.
> 
> 
> 
> --
> View this message in context: 
> http://lucene.472066.n3.nabble.com/Java-function-throws-exception-on-JSP-web-application-tp4294431p4294632.html
> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
  

[JENKINS-EA] Lucene-Solr-6.x-Linux (32bit/jdk-9-ea+134) - Build # 1687 - Unstable!

[Policeman Jenkins Server]

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

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

Error Message:
IOException occured when talking to server at: https://127.0.0.1:45062/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:45062/solr
at 
__randomizedtesting.SeedInfo.seed([DE61965EA597D88B:620FE04C01C45BF1]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:157)
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:535)
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 

[jira] [Commented] (LUCENE-7438) UnifiedHighlighter

[Timothy M. Rodriguez (JIRA)]

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

Timothy M. Rodriguez commented on LUCENE-7438:
--

Actually, I think passage relevancy might be something we'd look into in more 
details down the line.  Definitely, some of the things in LUCENE-4909 could be 
useful. :)  I see merit in keeping things separate to allow for flexibility.

> UnifiedHighlighter
> --
>
> Key: LUCENE-7438
> URL: https://issues.apache.org/jira/browse/LUCENE-7438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 6.2
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
>
> The UnifiedHighlighter is an evolution of the PostingsHighlighter that is 
> able to highlight using offsets in either postings, term vectors, or from 
> analysis (a TokenStream). Lucene’s existing highlighters are mostly 
> demarcated along offset source lines, whereas here it is unified -- hence 
> this proposed name. In this highlighter, the offset source strategy is 
> separated from the core highlighting functionalty. The UnifiedHighlighter 
> further improves on the PostingsHighlighter’s design by supporting accurate 
> phrase highlighting using an approach similar to the standard highlighter’s 
> WeightedSpanTermExtractor. The next major improvement is a hybrid offset 
> source strategythat utilizes postings and “light” term vectors (i.e. just the 
> terms) for highlighting multi-term queries (wildcards) without resorting to 
> analysis. Phrase highlighting and wildcard highlighting can both be disabled 
> if you’d rather highlight a little faster albeit not as accurately reflecting 
> the query.
> We’ve benchmarked an earlier version of this highlighter comparing it to the 
> other highlighters and the results were exciting! It’s tempting to share 
> those results but it’s definitely due for another benchmark, so we’ll work on 
> that. Performance was the main motivator for creating the UnifiedHighlighter, 
> as the standard Highlighter (the only one meeting Bloomberg Law’s accuracy 
> requirements) wasn’t fast enough, even with term vectors along with several 
> improvements we contributed back, and even after we forked it to highlight in 
> multiple threads.



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

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

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

[Apache Jenkins Server]

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

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

Error Message:
[/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_8618A0AD70CFB586-001/solr-instance-032/./collection1/data,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_8618A0AD70CFB586-001/solr-instance-032/./collection1/data/index.20160908212734713,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_8618A0AD70CFB586-001/solr-instance-032/./collection1/data/index.20160908212735331]
 expected:<2> but was:<3>

Stack Trace:
java.lang.AssertionError: 
[/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_8618A0AD70CFB586-001/solr-instance-032/./collection1/data,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_8618A0AD70CFB586-001/solr-instance-032/./collection1/data/index.20160908212734713,
 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Tests-5.5/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_8618A0AD70CFB586-001/solr-instance-032/./collection1/data/index.20160908212735331]
 expected:<2> but was:<3>
at 
__randomizedtesting.SeedInfo.seed([8618A0AD70CFB586:716B4EF5B6271A60]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at 
org.apache.solr.handler.TestReplicationHandler.checkForSingleIndex(TestReplicationHandler.java:897)
at 
org.apache.solr.handler.TestReplicationHandler.doTestIndexAndConfigAliasReplication(TestReplicationHandler.java:1327)
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 

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

[Policeman Jenkins Server]

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

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

Error Message:
IOException occured when talking to server at: https://127.0.0.1:44380/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:44380/solr
at 
__randomizedtesting.SeedInfo.seed([FBA885795CD87371:47C6F36BF88BF00B]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:157)
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 

Re: VOTE: Solr Ref Guide for 6.2, RC1

[David Smiley]

+1

On Thu, Sep 8, 2016 at 12:14 PM Steve Rowe  wrote:

> +1
>
> --
> Steve
> www.lucidworks.com
>
> > On Sep 8, 2016, at 11:34 AM, Cassandra Targett 
> wrote:
> >
> > After a respin, please VOTE to release the Apache Solr Reference Guide
> for 6.2.
> >
> > The artifacts are available at:
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.2-RC1/
> .
> >
> > $ more apache-solr-ref-guide-6.2.pdf.sha1
> > b070de9fb7806795cd1d55f1dd15d0a5a374d0b2  apache-solr-ref-guide-6.2.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
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-9-ea+134) - Build # 17784 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/17784/
Java: 64bit/jdk-9-ea+134 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
Unexpected exception type, expected RemoteSolrException

Stack Trace:
junit.framework.AssertionFailedError: Unexpected exception type, expected 
RemoteSolrException
at 
__randomizedtesting.SeedInfo.seed([157CDB7FB3088C12:A912AD6D175B0F68]:0)
at 
org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2682)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:111)
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:535)
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(java.base@9-ea/Thread.java:843)
Caused by: org.apache.solr.client.solrj.SolrServerException: IOException 
occured when talking to server at: 

[jira] [Commented] (SOLR-8742) HdfsDirectoryTest fails reliably after changes in LUCENE-6932

[Steve Rowe (JIRA)]

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

Steve Rowe commented on SOLR-8742:
--

Another reproducing seed on master from my Jenkins - though it only reproduces 
if I leave off the {{-Dtests.method=testEOF}}:

{noformat}
   [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=HdfsDirectoryTest 
-Dtests.method=testEOF -Dtests.seed=CEBB0B6DA161A793 -Dtests.slow=true 
-Dtests.locale=de-AT -Dtests.timezone=Europe/Minsk -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.36s J1  | HdfsDirectoryTest.testEOF <<<
   [junit4]> Throwable #1: java.lang.NullPointerException
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([CEBB0B6DA161A793:5FD04965E34501EF]:0)
   [junit4]>at 
org.apache.lucene.store.RAMInputStream.readByte(RAMInputStream.java:69)
   [junit4]>at 
org.apache.solr.store.hdfs.HdfsDirectoryTest.testEof(HdfsDirectoryTest.java:158)
   [junit4]>at 
org.apache.solr.store.hdfs.HdfsDirectoryTest.testEOF(HdfsDirectoryTest.java:150)
   [junit4]>at java.lang.Thread.run(Thread.java:745)
{noformat}

> HdfsDirectoryTest fails reliably after changes in LUCENE-6932
> -
>
> Key: SOLR-8742
> URL: https://issues.apache.org/jira/browse/SOLR-8742
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> the following seed fails reliably for me on master...
> {noformat}
>[junit4]   2> 1370568 INFO  
> (TEST-HdfsDirectoryTest.testEOF-seed#[A0D22782D87E1CE2]) [] 
> o.a.s.SolrTestCaseJ4 ###Ending testEOF
>[junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=HdfsDirectoryTest 
> -Dtests.method=testEOF -Dtests.seed=A0D22782D87E1CE2 -Dtests.slow=true 
> -Dtests.locale=es-PR -Dtests.timezone=Indian/Mauritius -Dtests.asserts=true 
> -Dtests.file.encoding=ISO-8859-1
>[junit4] ERROR   0.13s J0 | HdfsDirectoryTest.testEOF <<<
>[junit4]> Throwable #1: java.lang.NullPointerException
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([A0D22782D87E1CE2:31B9658A9A5ABA9E]:0)
>[junit4]>  at 
> org.apache.lucene.store.RAMInputStream.readByte(RAMInputStream.java:69)
>[junit4]>  at 
> org.apache.solr.store.hdfs.HdfsDirectoryTest.testEof(HdfsDirectoryTest.java:159)
>[junit4]>  at 
> org.apache.solr.store.hdfs.HdfsDirectoryTest.testEOF(HdfsDirectoryTest.java:151)
>[junit4]>  at java.lang.Thread.run(Thread.java:745)
> {noformat}
> git bisect says this is the first commit where it started failing..
> {noformat}
> ddc65d977f920013c5fca16c8ac75ae2c6895f9d is the first bad commit
> commit ddc65d977f920013c5fca16c8ac75ae2c6895f9d
> Author: Michael McCandless 
> Date:   Thu Jan 21 17:50:28 2016 +
> LUCENE-6932: RAMInputStream now throws EOFException if you seek beyond 
> the end of the file
> 
> git-svn-id: https://svn.apache.org/repos/asf/lucene/dev/trunk@1726039 
> 13f79535-47bb-0310-9956-ffa450edef68
> {noformat}
> ...which seems remarkable relevant and likely to indicate a problem that 
> needs fixed in the HdfsDirectory code (or perhaps just the test)



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

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

[jira] [Comment Edited] (SOLR-9490) BoolField always returning false for non-DV fields?

[Hoss Man (JIRA)]

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

Hoss Man edited comment on SOLR-9490 at 9/8/16 5:40 PM:


I'm having trouble trying to (trivially) reproduce this ... [~cjcowie]'s 
comments suggest this has nothing to do with the response writer used, and that 
the JSON output would demonstrate the same problem, but when i try the simplest 
possible steps to demonstrate it seems to be working fine...

{noformat}
$ git co releases/lucene-solr/6.2.0
...
$ ant clean && cd solr && ant server && bin/solr -e techproducts
...
POSTing file solr.xml to [base]
...
$ grep inStock example/exampledocs/solr.xml 
  true
$ curl 'http://localhost:8983/solr/techproducts/query?q=id:SOLR1000=inStock'
{
  "responseHeader":{
"status":0,
"QTime":0,
"params":{
  "q":"id:SOLR1000",
  "fl":"inStock"}},
  "response":{"numFound":1,"start":0,"docs":[
  {
"inStock":true}]
  }}
{noformat}

what am i missing?

Colvin: what is the {{version}} attribute on your schema?  does this problem 
exist only when you use "old" (pre-6.2) indexes after upgrading, or can folks 
reproduce this problem even with completely new indexes (build with 6.2) ?

*EDIT:* Note this is the definition of inStock in the 6.2 techproducts schema...

{code}

...
   
...

{code}



was (Author: hossman):
I'm having trouble trying to (trivially) reproduce this ... [~cjcowie]'s 
comments suggest this has nothing to do with the response writer used, and that 
the JSON output would demonstrate the same problem, but when i try the simplest 
possible steps to demonstrate it seems to be working fine...

{noformat}
$ git co releases/lucene-solr/6.2.0
...
$ ant clean && cd solr && ant server && bin/solr -e techproducts
...
POSTing file solr.xml to [base]
...
$ grep inStock example/exampledocs/solr.xml 
  true
$ curl 'http://localhost:8983/solr/techproducts/query?q=id:SOLR1000=inStock'
{
  "responseHeader":{
"status":0,
"QTime":0,
"params":{
  "q":"id:SOLR1000",
  "fl":"inStock"}},
  "response":{"numFound":1,"start":0,"docs":[
  {
"inStock":true}]
  }}
{noformat}

what am i missing?

Colvin: what is the {{version}} attribute on your schema?  does this problem 
exist only when you use "old" (pre-6.2) indexes after upgrading, or can folks 
reproduce this problem even with completely new indexes (build with 6.2) ?


> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {quote}



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

-
To unsubscribe, e-mail: 

Re: [VOTE] Release Lucene/Solr 5.5.3 RC1

[Anshum Gupta]

Hi Pushkar,

Let's not discuss another release in this vote thread.

On Thu, Sep 8, 2016 at 10:27 AM Pushkar Raste 
wrote:

> Do we also need a 6.3 release, since solr-9310 is a major issue
>
> On Sep 7, 2016 3:27 PM, "Anshum Gupta"  wrote:
>
>> This vote has passed. I'll resume working on the release.
>>
>> Thank you everyone.
>>
>> On Wed, Sep 7, 2016 at 9:03 AM Steve Rowe  wrote:
>>
>>> +1
>>>
>>> I ran the smoke tester with Java7 and Java8: SUCCESS! [1:00:05.335775]
>>>
>>> Docs, changes and javadocs look good.
>>>
>>> --
>>> Steve
>>> www.lucidworks.com
>>>
>>> > On Sep 6, 2016, at 1:59 AM, Shalin Shekhar Mangar <
>>> shalinman...@gmail.com> wrote:
>>> >
>>> > +1
>>> >
>>> > SUCCESS! [1:07:01.319712]
>>> >
>>> >
>>> > On Fri, Sep 2, 2016 at 7:59 PM, Anshum Gupta 
>>> wrote:
>>> > Please vote for release candidate 1 for Lucene/Solr 5.5.3
>>> >
>>> > The artifacts can be downloaded from:
>>> >
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.3-RC1-rev8655b97b27d8da470c8235683af11a8b85a2b10f
>>> >
>>> > You can run the smoke tester directly with this command (on the
>>> release branch):
>>> >
>>> > python3 -u dev-tools/scripts/smokeTestRelease.py \
>>> >
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.3-RC1-rev8655b97b27d8da470c8235683af11a8b85a2b10f
>>> >
>>> > Here's my +1
>>> > SUCCESS! [0:36:59.036831]
>>> >
>>> >
>>> >
>>> > --
>>> > Regards,
>>> > Shalin Shekhar Mangar.
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>

[jira] [Commented] (SOLR-9490) BoolField always returning false for non-DV fields?

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9490:


I'm having trouble trying to (trivially) reproduce this ... [~cjcowie]'s 
comments suggest this has nothing to do with the response writer used, and that 
the JSON output would demonstrate the same problem, but when i try the simplest 
possible steps to demonstrate it seems to be working fine...

{noformat}
$ git co releases/lucene-solr/6.2.0
...
$ ant clean && cd solr && ant server && bin/solr -e techproducts
...
POSTing file solr.xml to [base]
...
$ grep inStock example/exampledocs/solr.xml 
  true
$ curl 'http://localhost:8983/solr/techproducts/query?q=id:SOLR1000=inStock'
{
  "responseHeader":{
"status":0,
"QTime":0,
"params":{
  "q":"id:SOLR1000",
  "fl":"inStock"}},
  "response":{"numFound":1,"start":0,"docs":[
  {
"inStock":true}]
  }}
{noformat}

what am i missing?

Colvin: what is the {{version}} attribute on your schema?  does this problem 
exist only when you use "old" (pre-6.2) indexes after upgrading, or can folks 
reproduce this problem even with completely new indexes (build with 6.2) ?


> BoolField always returning false for non-DV fields?
> ---
>
> Key: SOLR-9490
> URL: https://issues.apache.org/jira/browse/SOLR-9490
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.2
>Reporter: Hoss Man
>Priority: Critical
>
> 2 diff users posted comments in SOLR-9187 indicating that changes introduced 
> in that issue have broken BoolFields that do *not* use DocValues...
> [~cjcowie]...
> {quote}
> Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
> BoolField now means that booleans without DocValues return null, which then 
> turns into Boolean.FALSE in toObject() regardless of whether the value is 
> true or false.
> e.g. with this schema, facet counts are correct, the returned values are 
> wrong.
> {code}
>  required="false" multiValued="false"/>
> 
> {code}
> {code}
> "response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
>   {
> "id":"124",
> "f_EVE64":false,
> "_version_":1544828487600177152},
>   {
> "id":"123",
> "f_EVE64":false,
> "_version_":1544828492458229760}]
>   },
>   "facet_counts":{
> "facet_queries":{},
> "facet_fields":{
>   "f_EVE64":[
> "false",1,
> "true",1]},
> {code}
> Could toExternal() perhaps fallback to how it originally behaved? e.g.
> {code}
> if (f.binaryValue() == null) {
>   return indexedToReadable(f.stringValue());
> }
> {code}
> {quote}
> [~pavan_shetty]...
> {quote}
> I downloaded solr version 6.2.0 (6.2.0 
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and 
> installed my core.
> In my schema.xml i have an field like following :
>  multiValued="false"/>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
> false value for above field even though it contains true boolean value. This 
> is happening for all boolean fields.
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> It is working fine in other response writer.
> If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
> clearly this is a bug in version 6.2.0.
> {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

Re: Release Solr 5.5.3

[Anshum Gupta]

The release notes (draft) can be found here:

Lucene: https://wiki.apache.org/lucene-java/ReleaseNote553
Solr: https://wiki.apache.org/solr/ReleaseNote553

Please feel free to edit/fix it.

-Anshum

On Wed, Jul 20, 2016 at 1:35 PM David Smiley 
wrote:

> Okay.  BTW SOLR-9290 isn't "Just" high indexing rates, but it's for those
> using SSL too -- correct me if I'm wrong.  We don't want to raise alarm
> bells too loudly :-)
>
> On Wed, Jul 20, 2016 at 4:18 PM Anshum Gupta 
> wrote:
>
>> Hi,
>>
>> With SOLR-9290 fixed, I think it calls for a bug fix release as it
>> impacts all users with high indexing rates.
>>
>> If someone else wants to work on the release, I am fine with it else,
>> I'll be happy to be the RM and cut an RC a week from now.
>>
>> --
>> Anshum Gupta
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

Re: Binary Response Writer Issue in solr version 6.2.0

[Chris Hostetter]

New jira to track this: https://issues.apache.org/jira/browse/SOLR-9490

: Date: Thu, 8 Sep 2016 18:41:31 +0530
: From: Pavan S Shetty 
: Reply-To: dev@lucene.apache.org
: To: dev@lucene.apache.org
: Subject: Re: Binary Response Writer Issue in solr version 6.2.0
: 
: Thanks Alexandre...
: 
: Yes, it is same issue. I updated this in that ticket also, so that it can
: be useful.
: 
: Thanks,
: 
: Pavan
: 
: On Thu, Sep 8, 2016 at 3:43 PM, Alexandre Rafalovitch 
: wrote:
: 
: > Looks like the same issue Colvin Cowie reported in
: > https://issues.apache.org/jira/browse/SOLR-9187 ?
: >
: > Regards,
: >Alex.
: > 
: > Newsletter and resources for Solr beginners and intermediates:
: > http://www.solr-start.com/
: >
: >
: > On 8 September 2016 at 13:21, Pavan S Shetty 
: > wrote:
: > > I downloaded solr version 6.2.0 (6.2.0
: > > 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37)
: > and
: > > installed my core.
: > >
: > > In my schema.xml i have an field like following :
: > >
: > >  > multiValued="false"/>
: > >
: > > Now i am accessing this field using SolrJ (6.1.0). But i am always
: > getting
: > > false value for above field even though it contains true boolean value.
: > This
: > > is happening for all boolean fields.
: > >
: > > http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
: > >
: > > If i change the solr version to 6.1.0, with same SolrJ, it starts
: > working.
: > > So clearly this is a bug in version 6.2.0.
: > >
: > > This is my first mail and issue report, so please correct me or need to
: > send
: > > this to some other group or mail let me know.
: > >
: > > Thanks,
: > >
: > > Pavan
: >
: > -
: > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
: > For additional commands, e-mail: dev-h...@lucene.apache.org
: >
: >
: 

-Hoss
http://www.lucidworks.com/

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

[jira] [Commented] (SOLR-9187) Support dates and booleans in /export handler, support boolean DocValues fields

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-9187:


Since this change has already been released, commenting here on bugs it may 
have introduced isn't the best idea -- too easy to get lost, and any fix has to 
be tracked in a new issue anyway.

I've created SOLR-9490 to track these new reports from [~cjcowie] and 
[~pavan_shetty]

> Support dates and booleans in /export handler, support boolean DocValues 
> fields
> ---
>
> Key: SOLR-9187
> URL: https://issues.apache.org/jira/browse/SOLR-9187
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9187.patch, SOLR-9187.patch, SOLR-9187.patch
>
>
> Since these can be DV fields it seems like it should. The first-level problem 
> is that SortingResponseWriter doesn't check for date types as a legal export 
> value. Whether there are repercussions elsewhere I don't know yet.



--
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.3 RC1

[Pushkar Raste]

Do we also need a 6.3 release, since solr-9310 is a major issue

On Sep 7, 2016 3:27 PM, "Anshum Gupta"  wrote:

> This vote has passed. I'll resume working on the release.
>
> Thank you everyone.
>
> On Wed, Sep 7, 2016 at 9:03 AM Steve Rowe  wrote:
>
>> +1
>>
>> I ran the smoke tester with Java7 and Java8: SUCCESS! [1:00:05.335775]
>>
>> Docs, changes and javadocs look good.
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>> > On Sep 6, 2016, at 1:59 AM, Shalin Shekhar Mangar <
>> shalinman...@gmail.com> wrote:
>> >
>> > +1
>> >
>> > SUCCESS! [1:07:01.319712]
>> >
>> >
>> > On Fri, Sep 2, 2016 at 7:59 PM, Anshum Gupta 
>> wrote:
>> > Please vote for release candidate 1 for Lucene/Solr 5.5.3
>> >
>> > The artifacts can be downloaded from:
>> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.3-RC1-
>> rev8655b97b27d8da470c8235683af11a8b85a2b10f
>> >
>> > You can run the smoke tester directly with this command (on the release
>> branch):
>> >
>> > python3 -u dev-tools/scripts/smokeTestRelease.py \
>> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-5.5.3-RC1-
>> rev8655b97b27d8da470c8235683af11a8b85a2b10f
>> >
>> > Here's my +1
>> > SUCCESS! [0:36:59.036831]
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Shalin Shekhar Mangar.
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

[jira] [Created] (SOLR-9490) BoolField always returning false for non-DV fields?

[Hoss Man (JIRA)]

Hoss Man created SOLR-9490:
--

 Summary: BoolField always returning false for non-DV fields?
 Key: SOLR-9490
 URL: https://issues.apache.org/jira/browse/SOLR-9490
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: 6.2
Reporter: Hoss Man
Priority: Critical


2 diff users posted comments in SOLR-9187 indicating that changes introduced in 
that issue have broken BoolFields that do *not* use DocValues...

[~cjcowie]...
{quote}
Hi, I've just picked up 6.2.0. It seems that the change to toExternal() in 
BoolField now means that booleans without DocValues return null, which then 
turns into Boolean.FALSE in toObject() regardless of whether the value is true 
or false.

e.g. with this schema, facet counts are correct, the returned values are wrong.
{code}


{code}
{code}
"response":{"numFound":2,"start":0,"maxScore":1.0,"docs":[
  {
"id":"124",
"f_EVE64":false,
"_version_":1544828487600177152},
  {
"id":"123",
"f_EVE64":false,
"_version_":1544828492458229760}]
  },
  "facet_counts":{
"facet_queries":{},
"facet_fields":{
  "f_EVE64":[
"false",1,
"true",1]},
{code}
Could toExternal() perhaps fallback to how it originally behaved? e.g.
{code}
if (f.binaryValue() == null) {
  return indexedToReadable(f.stringValue());
}
{code}
{quote}

[~pavan_shetty]...
{quote}
I downloaded solr version 6.2.0 (6.2.0 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 
- mike - 2016-08-20 05:41:37) and installed my core.

In my schema.xml i have an field like following :



Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
false value for above field even though it contains true boolean value. This is 
happening for all boolean fields.

http://localhost:8983/solr...wt=javabin=2 HTTP/1.1

It is working fine in other response writer.

If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
clearly this is a bug in version 6.2.0.
{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

Re: VOTE: Solr Ref Guide for 6.2, RC1

[Steve Rowe]

+1

--
Steve
www.lucidworks.com

> On Sep 8, 2016, at 11:34 AM, Cassandra Targett  wrote:
> 
> After a respin, please VOTE to release the Apache Solr Reference Guide for 
> 6.2.
> 
> The artifacts are available at: 
> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.2-RC1/.
> 
> $ more apache-solr-ref-guide-6.2.pdf.sha1
> b070de9fb7806795cd1d55f1dd15d0a5a374d0b2  apache-solr-ref-guide-6.2.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

[jira] [Commented] (LUCENE-7432) TestIndexWriterOnError.testCheckpoint fails on IBM J9

[Kevin Langman (JIRA)]

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

Kevin Langman commented on LUCENE-7432:
---

   [junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestThreadedForceMerge -Dtests.seed=F594DD5B58B22D4D 
-Dtests.nightly=true -Dtests.slow=true -Dtests.locale=nl-BE 
-Dtests.timezone=Africa/Malabo -Dtests.asserts=true 
-Dtests.file.encoding=ISO-8859-1
   [junit4] ERROR   0.00s J0 | TestThreadedForceMerge (suite) <<<
   [junit4]> Throwable #1: java.lang.RuntimeException: Could not access 
field 'ANALYZER'.
   [junit4]>at 
__randomizedtesting.SeedInfo.seed([F594DD5B58B22D4D]:0)
   [junit4]>at java.lang.Thread.run(Thread.java:785)
   [junit4]> Caused by: java.security.AccessControlException: Access denied 
("java.lang.reflect.ReflectPermission" "suppressAccessChecks")
   [junit4]>at 
java.security.AccessController.throwACE(AccessController.java:157)
   [junit4]>at 
java.security.AccessController.checkPermissionHelper(AccessController.java:217)
   [junit4]>at 
java.security.AccessController.checkPermission(AccessController.java:349)
   [junit4]>at 
java.lang.SecurityManager.checkPermission(SecurityManager.java:562)
   [junit4]>at 
java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:143)
   [junit4]>at 
java.security.AccessController.doPrivileged(AccessController.java:594)
   [junit4]>... 10 more
   [junit4] Completed [44/432 (6!)] on J0 in 1.18s, 1 test, 1 error <<< 
FAILURES!


> TestIndexWriterOnError.testCheckpoint fails on IBM J9
> -
>
> Key: LUCENE-7432
> URL: https://issues.apache.org/jira/browse/LUCENE-7432
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Michael McCandless
>  Labels: IBM-J9
>
> Not sure if this is a J9 issue or a Lucene issue, but using this version of 
> J9:
> {noformat}
> 09:26 $ java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp10-20160720_02(SR3fp10))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 
> 20160719_312156 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160719_1144_B312156
> JIT  - tr.r14.java_20160629_120284.01
> GC   - R28_Java8_SR3_20160719_1144_B312156_CMPRSS
> J9CL - 20160719_312156)
> JCL - 20160719_01 based on Oracle jdk8u101-b13
> {noformat}
> This test failure seems to reproduce:
> {noformat}
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestIndexWriterOnVMError -Dtests.method=testCheckpoint 
> -Dtests.seed=FAB0DC147AFDBF4E -Dtests.nightly=true -Dtests.slow=true 
> -Dtests.locale=kn -Dtests.timezone=Australia/South -Dtests.asserts=true 
> -Dtests.file.encoding=UTF-8
>[junit4] ERROR196s | TestIndexWriterOnVMError.testCheckpoint <<<
>[junit4]> Throwable #1: java.lang.RuntimeException: 
> MockDirectoryWrapper: cannot close: there are still 9 open files: 
> {_2_Asserting_0.pos=1, _2_Asserting_0.dvd=1, _2.fdt=1, _2_Asserting_0.doc=1, 
> _2_Asserting_0.tim=1, _2.nvd=1, _2.tvd=1, _3.cfs=1, _2.dim=1}
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([FAB0DC147AFDBF4E:FBA18A7C5B16548D]:0)
>[junit4]>  at 
> org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:841)
>[junit4]>  at 
> org.apache.lucene.index.TestIndexWriterOnVMError.doTest(TestIndexWriterOnVMError.java:89)
>[junit4]>  at 
> org.apache.lucene.index.TestIndexWriterOnVMError.testCheckpoint(TestIndexWriterOnVMError.java:280)
>[junit4]>  at java.lang.Thread.run(Thread.java:785)
>[junit4]> Caused by: java.lang.RuntimeException: unclosed IndexInput: 
> _2.dim
>[junit4]>  at 
> org.apache.lucene.store.MockDirectoryWrapper.addFileHandle(MockDirectoryWrapper.java:732)
>[junit4]>  at 
> org.apache.lucene.store.MockDirectoryWrapper.openInput(MockDirectoryWrapper.java:776)
>[junit4]>  at 
> org.apache.lucene.codecs.lucene60.Lucene60PointsReader.(Lucene60PointsReader.java:85)
>[junit4]>  at 
> org.apache.lucene.codecs.lucene60.Lucene60PointsFormat.fieldsReader(Lucene60PointsFormat.java:104)
>[junit4]>  at 
> org.apache.lucene.codecs.asserting.AssertingPointsFormat.fieldsReader(AssertingPointsFormat.java:66)
>[junit4]>  at 
> org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:128)
>[junit4]>  at 
> org.apache.lucene.index.SegmentReader.(SegmentReader.java:74)
>[junit4]>  at 
> org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:145)
>[junit4]>  at 
> org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:197)
>[junit4]>  at 
> 

VOTE: Solr Ref Guide for 6.2, RC1

[Cassandra Targett]

After a respin, please VOTE to release the Apache Solr Reference Guide for
6.2.

The artifacts are available at:
https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.2-RC1/
.

$ more apache-solr-ref-guide-6.2.pdf.sha1
b070de9fb7806795cd1d55f1dd15d0a5a374d0b2  apache-solr-ref-guide-6.2.pdf

Here's my +1.

Thanks,
Cassandra

[jira] [Commented] (LUCENE-7438) UnifiedHighlighter

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7438:
--

Thanks for chiming in Rob.

For the present while there are feature gaps (see "Missing features" above), I 
don't think we can suggest that there be only one highlighter.  I admit I see 
that as potential eventuality that I think is desirable, but it's a moot 
discussion right now.  That being said, the UH, being based on the PH, does 
everything it does and more.  It scores/ranks and formats using the same code.  
The very kernel of the highlighter that produces the Passages[] (now in 
FieldHighlighter.highlightOffsetsEnums) is essentially the same.  Still, I 
don't think we should do any removing of highlighters at this time.  
Eventually, we can ask ourselves, what is highlighter XYZ giving us over the 
UnifiedHighlighter?  And then we can see if we (and other users) think it's 
worth keeping it.

RE PostingsHighlighter perf trade-offs:

Yeah I know it's possible to craft an extreme case that would exercise the 
PostingsEnum reuse --  loads of terms in the query and an optimized index.  
Once we have some benchmarking, we can see how much of a hit was lost by not 
re-using.  That feature was retained in the UH for many months until just 
recently when it underwent a large refactor to simplify things.  Other than 
this, I don't believe there are any tricks in the PH that we removed in the UH.

RE ranking/scoring "needs":

I'm not aware that the UH might have different passing scoring "needs" than the 
PH.  The PH's algorithm seems really nice to me; I didn't put any thought into 
this aspect.  But yeah maybe there might be improvements for phrase/span 
queries in particular.  By the way, PhraseHelper, simply filters out certain 
occurrences of certain terms.  Perhaps the frequency of the span might be used 
in scoring?  But to know that, you must iterate them, and then you lose lazy 
iteration.  Perhaps someone wanting to trade-off performance for possibly 
better passage relevance would make this trade-off?  We/BLAW have no plans to 
do that.  If someone comes along with such a requirement, I hope we can 
accommodate that interesting direction.

RE moving / renaming / visibility

If you have specific suggestions (e.g. w.r.t. MultiTermHighlighting) on how 
they might be renamed and re-shuffled to different packages than I'd love to 
hear your thoughts on that.  Some things of the UH are expressly public because 
we/BLAW are using those endpoints but we/BLAW don't use MultiTermHighlighting 
at this time.  But I could imagine some custom wildcard query coming into 
existence and it would be a PITA if we couldn't help MTH understand some new 
query.  Similar for WSTE.

BTW there is a visibility test expressly for ensuring certain things are public.

> UnifiedHighlighter
> --
>
> Key: LUCENE-7438
> URL: https://issues.apache.org/jira/browse/LUCENE-7438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 6.2
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
>
> The UnifiedHighlighter is an evolution of the PostingsHighlighter that is 
> able to highlight using offsets in either postings, term vectors, or from 
> analysis (a TokenStream). Lucene’s existing highlighters are mostly 
> demarcated along offset source lines, whereas here it is unified -- hence 
> this proposed name. In this highlighter, the offset source strategy is 
> separated from the core highlighting functionalty. The UnifiedHighlighter 
> further improves on the PostingsHighlighter’s design by supporting accurate 
> phrase highlighting using an approach similar to the standard highlighter’s 
> WeightedSpanTermExtractor. The next major improvement is a hybrid offset 
> source strategythat utilizes postings and “light” term vectors (i.e. just the 
> terms) for highlighting multi-term queries (wildcards) without resorting to 
> analysis. Phrase highlighting and wildcard highlighting can both be disabled 
> if you’d rather highlight a little faster albeit not as accurately reflecting 
> the query.
> We’ve benchmarked an earlier version of this highlighter comparing it to the 
> other highlighters and the results were exciting! It’s tempting to share 
> those results but it’s definitely due for another benchmark, so we’ll work on 
> that. Performance was the main motivator for creating the UnifiedHighlighter, 
> as the standard Highlighter (the only one meeting Bloomberg Law’s accuracy 
> requirements) wasn’t fast enough, even with term vectors along with several 
> improvements we contributed back, and even after we forked it to highlight in 
> multiple threads.



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

[jira] [Updated] (LUCENE-7434) Add minNumberShouldMatch parameter to SpanNearQuery

[Mikhail Khludnev (JIRA)]

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

Mikhail Khludnev updated LUCENE-7434:
-
Attachment: TestMinShouldMatchSpan.java
FSA for repeating words.PNG
a b c d e f mm=3.PNG

attaching a proof for {{x a a a}} and a terrific pic for it

> Add minNumberShouldMatch parameter to SpanNearQuery
> ---
>
> Key: LUCENE-7434
> URL: https://issues.apache.org/jira/browse/LUCENE-7434
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/search
>Reporter: Tim Allison
>Priority: Minor
> Attachments: AllPairsNearSpans20160902.patch, FSA for repeating 
> words.PNG, TestMinShouldMatchSpan.java, TestMinShouldMatchSpan.java, a b c d 
> e f mm=3.PNG, a b c d e f mm=3.PNG
>
>
> On the user list, [~saar32] asked about a new type of SpanQuery that would 
> allow for something like BooleanQuery's minimumNumberShouldMatch
> bq. Given a set of search terms (t1, t2, t3, ti), return all documents where 
> in a sequence of x=10 tokens at least c=3 of the search terms appear within 
> the sequence.
> I _think_ we can modify SpanNearQuery fairly easily to accommodate this.  
> I'll submit a PR in the next few days.



--
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-7439) Should FuzzyQuery match short terms too?

[Tim Allison (JIRA)]

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

Tim Allison commented on LUCENE-7439:
-

Added link to LUCENE-5206.  +1 on fixing this.  Thank you!

> Should FuzzyQuery match short terms too?
> 
>
> Key: LUCENE-7439
> URL: https://issues.apache.org/jira/browse/LUCENE-7439
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: master (7.0), 6.3
>
>
> Today, if you ask {{FuzzyQuery}} to match {{abcd}} with edit distance 2, it 
> will fail to match the term {{ab}} even though it's 2 edits away.
> Its javadocs explain this:
> {noformat}
>  * NOTE: terms of length 1 or 2 will sometimes not match because of how 
> the scaled
>  * distance between two terms is computed.  For a term to match, the edit 
> distance between
>  * the terms must be less than the minimum length term (either the input 
> term, or
>  * the candidate term).  For example, FuzzyQuery on term "abcd" with 
> maxEdits=2 will
>  * not match an indexed term "ab", and FuzzyQuery on term "a" with maxEdits=2 
> will not
>  * match an indexed term "abc".
> {noformat}
> On the one hand, I can see that this behavior is sort of justified in that 
> 50% of the characters are different and so this is a very "weak" match, but 
> on the other hand, it's quite unexpected since edit distance is such an exact 
> measure so the terms should have matched.
> It seems like the behavior is caused by internal implementation details about 
> how the relative (floating point) score is computed.  I think we should fix 
> it, so that edit distance 2 does in fact match all terms with edit distance 
> <= 2.



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

[VOTE] Release PyLucene 6.2.0 (rc1)

[Andi Vajda]

After an almost two year hiatus, a new PyLucene version is ready for 
release. The PyLucene 6.2.0 (rc1) release tracking the recent release of 
Apache Lucene 6.2.0 is ready.


A release candidate is available from:
  https://dist.apache.org/repos/dist/dev/lucene/pylucene/6.2.0-rc1/

PyLucene 6.2.0 is built with JCC 2.22 included in these release artifacts.

Please vote to release these artifacts as PyLucene 6.2.0.
Anyone interested in this release can and should vote !

Thanks !

Andi..

ps: the KEYS file for PyLucene release signing is at:
https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS

pps: here is my +1

[jira] [Commented] (LUCENE-7438) UnifiedHighlighter

[Robert Muir (JIRA)]

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

Robert Muir commented on LUCENE-7438:
-

I think there are room for plenty of new highlighters in lucene, so its great 
to have another one. I do get the feeling from some issues etc, that some feel 
there "can be only one", but I don't see any good reasons for that. On the 
other hand, like codecs and other things in lucene, we should explore different 
approaches that give the user more choices (like this new highlighter here). 

I think this is especially important because of how "personal" highlighting is 
to the app, and the fact that performance/relevance is tricky stuff here 
depending on how the app works! For example about the reuse note: this 
highlighter discards reuse of some internal lucene structures, but under some 
circumstances (e.g. certain query structures/Directory impl/doc sizes/top-N 
sizes/stopwords or lack thereof) this could indeed matter a lot. For PH it does 
this simply because it tries to maximize perf everywhere (possibly to the 
extreme: perhaps it really is the wrong tradeoff, but that was a "different" 
direction to explore). There are lots of ways these things can perform or be 
very slow, and a lot of it is hard to generalize across all use-cases!

As far as the duplication of classes, I'd be a little careful before 
refactoring too much of it, because of that very reason. Maybe UH needs to 
ultimately go in different directions than PH and we should just let it do that.

For example ranking: PH disregards query structure and tries to use a 
bag-of-words approach with something similar to traditional ranking for that, 
the idea is that hopefully that stuff works well on a small scale too.

But UH might need something else: if it attempts to use more query structure 
than bag-of-words, then UH might need to do something else. I haven't looked to 
see how things like IDF are computed there, that's just an example.

And maybe the right direction for PH, given what it tries to do, is to do 
something like LUCENE-4909... that sorta sits out there because we don't have a 
good way of measuring quality? 

I also do worry a bit about making internal-only classes like 
MultitermHighlighting public to the user, I think this has a real heavy API 
cost. Maybe for that one in particular its the right way to go, given how 
hacky/hairy it is especially. Maybe it can be renamed to something better to 
limit the confusion :) This problem isn't really unique to highlighters though, 
its something that should be addressed better in general, e.g. with 
internal-only packages that are hidden or something like that.

Anyway, these are just some general thoughts. Glad to see we will have more 
choices.

> UnifiedHighlighter
> --
>
> Key: LUCENE-7438
> URL: https://issues.apache.org/jira/browse/LUCENE-7438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 6.2
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
>
> The UnifiedHighlighter is an evolution of the PostingsHighlighter that is 
> able to highlight using offsets in either postings, term vectors, or from 
> analysis (a TokenStream). Lucene’s existing highlighters are mostly 
> demarcated along offset source lines, whereas here it is unified -- hence 
> this proposed name. In this highlighter, the offset source strategy is 
> separated from the core highlighting functionalty. The UnifiedHighlighter 
> further improves on the PostingsHighlighter’s design by supporting accurate 
> phrase highlighting using an approach similar to the standard highlighter’s 
> WeightedSpanTermExtractor. The next major improvement is a hybrid offset 
> source strategythat utilizes postings and “light” term vectors (i.e. just the 
> terms) for highlighting multi-term queries (wildcards) without resorting to 
> analysis. Phrase highlighting and wildcard highlighting can both be disabled 
> if you’d rather highlight a little faster albeit not as accurately reflecting 
> the query.
> We’ve benchmarked an earlier version of this highlighter comparing it to the 
> other highlighters and the results were exciting! It’s tempting to share 
> those results but it’s definitely due for another benchmark, so we’ll work on 
> that. Performance was the main motivator for creating the UnifiedHighlighter, 
> as the standard Highlighter (the only one meeting Bloomberg Law’s accuracy 
> requirements) wasn’t fast enough, even with term vectors along with several 
> improvements we contributed back, and even after we forked it to highlight in 
> multiple threads.



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

-
To unsubscribe, e-mail: 

Re: testing PyLucene 6.2

[Andi Vajda]

On Thu, 8 Sep 2016, Dirk Rothe wrote:


Am 08.09.2016, 11:10 Uhr, schrieb Andi Vajda :



On Thu, 8 Sep 2016, Dirk Rothe wrote:


Am 05.09.2016, 21:27 Uhr, schrieb Andi Vajda :



class _Tokenizer(PythonTokenizer):
 def __init__(self, INPUT):
super(_Tokenizer, self).__init__(INPUT)
 # prepare INPUT
 def incrementToken(self):
 # stuff into termAtt/offsetAtt/posIncrAtt

class Analyzer6(PythonAnalyzer):
 def createComponents(self, fieldName):
 return Analyzer.TokenStreamComponents(_Tokenizer())

The PositionIncrementTestCase is pretty similar but initialized with 
static input. Would be a nice place for an example with dynamic input, I 
think.


This was our 3.6 approach:
class Analyzer3(PythonAnalyzer):
 def tokenStream(self, fieldName, reader):
data = data_from_reader(reader)
class _tokenStream(PythonTokenStream):
def __init__(self):
 super(_tokenStream, self).__init__()
 # prepare termAtt/offsetAtt/posIncrAtt
def incrementToken(self):
 # stuff from data into termAtt/offsetAtt/posIncrAtt
   return _tokenStream()

Any hints how to get Analyzer6 working?


I've lost track of the countless API changes since 3.x.

The Lucene project does a good job at tracking them in the CHANGES.txt 
file, usually pointing at the issue that tracked it, often with examples 
about how to accomplish the same in the new way and the rationale behind 
the change.


I guess we are here:
https://issues.apache.org/jira/browse/LUCENE-5388
https://svn.apache.org/viewvc?view=revision=1556801

You can also look at the PyLucene tests I just ported to 6.x. For example, 
in test_Analyzers.py, you can see that Tokenizer no longer takes a reader 
but can be set one with setReader() after construction.


Yes, I've done that pretty carefully. I think, this quote points in the right 
direction: "The tokenStream method takes a String or Reader and will pass 
this to Tokenizer#setReader()."
from: 
http://mail-archives.apache.org/mod_mbox/lucene-java-user/201502.mbox/%3C021701d04f86$55331f10$ff995d30$@thetaphi.de%3E


I've checked the lucene source and this happens automatically an cannot be 
overwritten.


So I've hacked something ugly together which seems to work.

class _Tokenizer(PythonTokenizer):
  def __init__(self, getReader):
  super(_Tokenizer, self).__init__()
  self.getReader = getReader
  self.i = 0
  self.data = []

  def incrementToken(self):
  if self.i == 0:
  self.data = data_from_reader(self.getReader())
  if self.i == len(self.data):
  # we are reused - reset
  self.i = 0
  return False
  # stuff from self.data into termAtt/offsetAtt/posIncrAtt
  self.i += 1
  return True

class Analyzer6(PythonAnalyzer):
  def createComponents(self, fieldName):
   return Analyzer.TokenStreamComponents(_Tokenizer(lambda: 
self._reader))

  def initReader(self, fieldName, reader):
  # capture reader
  self._reader = reader
  return reader

I've made initReader() python-overridable (see patch). What do you think?


Not sure what to think. While your change looks fine, if Lucene decided to 
make this 'hard', it may be a sign that you're doing something wrong or 
going the wrong way about it.


I suggest you ask on the java-u...@lucene.apache.org list as you're probably 
not the first one to transition from 3.x to something more recent.


Please let pylucene-dev@ know what you find out...

Andi..



--dirk

[jira] [Created] (LUCENE-7439) Should FuzzyQuery match short terms too?

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-7439:
--

 Summary: Should FuzzyQuery match short terms too?
 Key: LUCENE-7439
 URL: https://issues.apache.org/jira/browse/LUCENE-7439
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: master (7.0), 6.3


Today, if you ask {{FuzzyQuery}} to match {{abcd}} with edit distance 2, it 
will fail to match the term {{ab}} even though it's 2 edits away.

Its javadocs explain this:

{noformat}
 * NOTE: terms of length 1 or 2 will sometimes not match because of how the 
scaled
 * distance between two terms is computed.  For a term to match, the edit 
distance between
 * the terms must be less than the minimum length term (either the input term, 
or
 * the candidate term).  For example, FuzzyQuery on term "abcd" with maxEdits=2 
will
 * not match an indexed term "ab", and FuzzyQuery on term "a" with maxEdits=2 
will not
 * match an indexed term "abc".
{noformat}

On the one hand, I can see that this behavior is sort of justified in that 50% 
of the characters are different and so this is a very "weak" match, but on the 
other hand, it's quite unexpected since edit distance is such an exact measure 
so the terms should have matched.

It seems like the behavior is caused by internal implementation details about 
how the relative (floating point) score is computed.  I think we should fix it, 
so that edit distance 2 does in fact match all terms with edit distance <= 2.



--
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: Solr Reference Guide for Solr 6.2

[Cassandra Targett]

Thanks Steve for finding that and Mikhail for removing it. I'll check
it again and respin.

Cassandra

On Thu, Sep 8, 2016 at 3:34 AM, Mikhail Khludnev  wrote:
> I just removed this macro. I'm sorry for violating that taboo.
>
> On Thu, Sep 8, 2016 at 4:23 AM, Steve Rowe  wrote:
>>
>> I scanned the whole PDF and found a problem that I think warrants respin -
>> otherwise it looks good to me:
>>
>> In the Transforming Result Documents section, under Available Transformers
>> / [subquery], under the Note on page 346, it says:
>>
>>   JIRA Issues Macro: The JIRA server returned a trusted apps error:
>> USER_UNKNOWN; Unknown User: {0}; ["cassandra.targett”]
>>
>> I searched and didn’t find the above problem anywhere else in the PDF.
>>
>> --
>> Steve
>> www.lucidworks.com
>>
>> > On Sep 7, 2016, at 3:16 PM, Cassandra Targett 
>> > wrote:
>> >
>> > At long last, please VOTE to release the Apache Solr Ref Guide for 6.2.
>> >
>> > The artifacts can be downloaded from:
>> > https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.2-RC0/
>> >
>> > $ more apache-solr-ref-guide-6.2-RC0/apache-solr-ref-guide-6.2.pdf.sha1
>> > 22f2dcdceb9ec69bb4de6dfb20e0c008850200dd  apache-solr-ref-guide-6.2.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
>>
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev

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

Re: testing PyLucene 6.2

[Dirk Rothe]

Am 08.09.2016, 11:10 Uhr, schrieb Andi Vajda :



On Thu, 8 Sep 2016, Dirk Rothe wrote:


Am 05.09.2016, 21:27 Uhr, schrieb Andi Vajda :



class _Tokenizer(PythonTokenizer):
  def __init__(self, INPUT):
super(_Tokenizer, self).__init__(INPUT)
  # prepare INPUT
  def incrementToken(self):
  # stuff into termAtt/offsetAtt/posIncrAtt

class Analyzer6(PythonAnalyzer):
  def createComponents(self, fieldName):
  return Analyzer.TokenStreamComponents(_Tokenizer())

The PositionIncrementTestCase is pretty similar but initialized with  
static input. Would be a nice place for an example with dynamic input,  
I think.


This was our 3.6 approach:
class Analyzer3(PythonAnalyzer):
  def tokenStream(self, fieldName, reader):
 data = data_from_reader(reader)
 class _tokenStream(PythonTokenStream):
 def __init__(self):
  super(_tokenStream, self).__init__()
  # prepare termAtt/offsetAtt/posIncrAtt
 def incrementToken(self):
  # stuff from data into termAtt/offsetAtt/posIncrAtt
return _tokenStream()

Any hints how to get Analyzer6 working?


I've lost track of the countless API changes since 3.x.

The Lucene project does a good job at tracking them in the CHANGES.txt  
file, usually pointing at the issue that tracked it, often with examples  
about how to accomplish the same in the new way and the rationale behind  
the change.


I guess we are here:
https://issues.apache.org/jira/browse/LUCENE-5388
https://svn.apache.org/viewvc?view=revision=1556801

You can also look at the PyLucene tests I just ported to 6.x. For  
example, in test_Analyzers.py, you can see that Tokenizer no longer  
takes a reader but can be set one with setReader() after construction.


Yes, I've done that pretty carefully. I think, this quote points in the  
right direction: "The tokenStream method takes a String or Reader and will  
pass this to Tokenizer#setReader()."
from:  
http://mail-archives.apache.org/mod_mbox/lucene-java-user/201502.mbox/%3C021701d04f86$55331f10$ff995d30$@thetaphi.de%3E


I've checked the lucene source and this happens automatically an cannot be  
overwritten.


So I've hacked something ugly together which seems to work.

class _Tokenizer(PythonTokenizer):
def __init__(self, getReader):
super(_Tokenizer, self).__init__()
self.getReader = getReader
self.i = 0
self.data = []

def incrementToken(self):
if self.i == 0:
self.data = data_from_reader(self.getReader())
if self.i == len(self.data):
# we are reused - reset
self.i = 0
return False
# stuff from self.data into termAtt/offsetAtt/posIncrAtt
self.i += 1
return True

class Analyzer6(PythonAnalyzer):
def createComponents(self, fieldName):
 return Analyzer.TokenStreamComponents(_Tokenizer(lambda:  
self._reader))

def initReader(self, fieldName, reader):
# capture reader
self._reader = reader
return reader

I've made initReader() python-overridable (see patch). What do you think?

--dirk

[jira] [Commented] (LUCENE-7438) UnifiedHighlighter

[Timothy M. Rodriguez (JIRA)]

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

Timothy M. Rodriguez commented on LUCENE-7438:
--

I'm not a fan of forking classes with Uxyz naming scheme.  I think it'd be 
better to make the existing classes re-usable or keep the current naming 
scheme.  That being said, if we make the existing classes re-usable, it might 
be better to plan on moving them into some common package later on so it's 
clearer that they are re-used.

> UnifiedHighlighter
> --
>
> Key: LUCENE-7438
> URL: https://issues.apache.org/jira/browse/LUCENE-7438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 6.2
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
>
> The UnifiedHighlighter is an evolution of the PostingsHighlighter that is 
> able to highlight using offsets in either postings, term vectors, or from 
> analysis (a TokenStream). Lucene’s existing highlighters are mostly 
> demarcated along offset source lines, whereas here it is unified -- hence 
> this proposed name. In this highlighter, the offset source strategy is 
> separated from the core highlighting functionalty. The UnifiedHighlighter 
> further improves on the PostingsHighlighter’s design by supporting accurate 
> phrase highlighting using an approach similar to the standard highlighter’s 
> WeightedSpanTermExtractor. The next major improvement is a hybrid offset 
> source strategythat utilizes postings and “light” term vectors (i.e. just the 
> terms) for highlighting multi-term queries (wildcards) without resorting to 
> analysis. Phrase highlighting and wildcard highlighting can both be disabled 
> if you’d rather highlight a little faster albeit not as accurately reflecting 
> the query.
> We’ve benchmarked an earlier version of this highlighter comparing it to the 
> other highlighters and the results were exciting! It’s tempting to share 
> those results but it’s definitely due for another benchmark, so we’ll work on 
> that. Performance was the main motivator for creating the UnifiedHighlighter, 
> as the standard Highlighter (the only one meeting Bloomberg Law’s accuracy 
> requirements) wasn’t fast enough, even with term vectors along with several 
> improvements we contributed back, and even after we forked it to highlight in 
> multiple threads.



--
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-9187) Support dates and booleans in /export handler, support boolean DocValues fields

[Pavan Shetty (JIRA)]

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

Pavan Shetty commented on SOLR-9187:


As suggested in devel mailing list i am updating this here...

Binary Response Writer Issue in solr version 6.2.0 :

I downloaded solr version 6.2.0 (6.2.0 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 
- mike - 2016-08-20 05:41:37) and installed my core.

In my schema.xml i have an field like following :



Now i am accessing this field using SolrJ (6.1.0). But i am always getting 
false value for above field even though it contains true boolean value. This is 
happening for all boolean fields.

http://localhost:8983/solr...wt=javabin=2 HTTP/1.1

It is working fine in other response writer.

If i change the solr version to 6.1.0, with same SolrJ, it starts working. So 
clearly this is a bug in version 6.2.0.

This is my first mail and issue report, so please correct me.

Thanks,

Pavan

> Support dates and booleans in /export handler, support boolean DocValues 
> fields
> ---
>
> Key: SOLR-9187
> URL: https://issues.apache.org/jira/browse/SOLR-9187
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9187.patch, SOLR-9187.patch, SOLR-9187.patch
>
>
> Since these can be DV fields it seems like it should. The first-level problem 
> is that SortingResponseWriter doesn't check for date types as a legal export 
> value. Whether there are repercussions elsewhere I don't know yet.



--
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: Binary Response Writer Issue in solr version 6.2.0

[Pavan S Shetty]

Thanks Alexandre...

Yes, it is same issue. I updated this in that ticket also, so that it can
be useful.

Thanks,

Pavan

On Thu, Sep 8, 2016 at 3:43 PM, Alexandre Rafalovitch 
wrote:

> Looks like the same issue Colvin Cowie reported in
> https://issues.apache.org/jira/browse/SOLR-9187 ?
>
> Regards,
>Alex.
> 
> Newsletter and resources for Solr beginners and intermediates:
> http://www.solr-start.com/
>
>
> On 8 September 2016 at 13:21, Pavan S Shetty 
> wrote:
> > I downloaded solr version 6.2.0 (6.2.0
> > 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37)
> and
> > installed my core.
> >
> > In my schema.xml i have an field like following :
> >
> >  > multiValued="false"/>
> >
> > Now i am accessing this field using SolrJ (6.1.0). But i am always
> getting
> > false value for above field even though it contains true boolean value.
> This
> > is happening for all boolean fields.
> >
> > http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
> >
> > If i change the solr version to 6.1.0, with same SolrJ, it starts
> working.
> > So clearly this is a bug in version 6.2.0.
> >
> > This is my first mail and issue report, so please correct me or need to
> send
> > this to some other group or mail let me know.
> >
> > Thanks,
> >
> > Pavan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[jira] [Commented] (LUCENE-7438) UnifiedHighlighter

[David Smiley (JIRA)]

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

David Smiley commented on LUCENE-7438:
--

I think we can avoid some duplication confusion as follows:

For the internal classes that user's don't normally use:

* *MultiTermHighlighting*: transfer most of the changes I did in 
MultiTermHighlighting to the copy in the {{postingshighlight}} package -- 
particularly to anything that already existed there. Then make that public and 
lucene.internal so it can be accessed.  That is very low-impact on the PH. For 
the couple methods added -- {{uninvertAndFilterTerms}} and 
{{makeStringMatchAutomata}} I think we can add these to FieldOffsetStrategy and 
AnalysisOffsetStrategy respectively.  And add comments mentioning it would 
logically go in MTH but since that's in a different highlighter, we don't.
* *TokenStreamFromTermVector*: I think we can replace the one in the 
{{highlighter}} with this one, as the sparseness ratio is configurable in the 
constructor.

For the surface classes users use: Passage, PassageScorer, PassageFormatter, 
DefaultPassageFormatter.  -- I don't think it good to have users use parts of 
another highlighter ({{postingshighlight}}), which is weird for users.  I 
propose copying these with a leading 'U', i.e. {{UPassage}} etc.  That said if 
others think that's a worse trade-off, it's no big deal to me.  Once 
{{o.a.l.s.ph.Passage}}'s constructor is public, it's possible to do that.

RE benchmarks... not sure when we'll have those ready but I would hope by the 
end of this month.  I figure using our benchmark module on wikipedia is a fine 
way to go.  I've used that to benchmark enhancements to the standard 
highlighter before.

Thoughts (esp. from other committers)?  [~rcmuir], I figure you'll have some 
valuable feedback as you did most (all?) of the herculean work on the 
PostingsHighlighter which was an ideal starting point for this UH.   I know 
some folks are on vacation or at another conference right now who I know want 
to provide feedback so I'm in no hurry to commit anything.

> UnifiedHighlighter
> --
>
> Key: LUCENE-7438
> URL: https://issues.apache.org/jira/browse/LUCENE-7438
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/highlighter
>Affects Versions: 6.2
>Reporter: Timothy M. Rodriguez
>Assignee: David Smiley
>
> The UnifiedHighlighter is an evolution of the PostingsHighlighter that is 
> able to highlight using offsets in either postings, term vectors, or from 
> analysis (a TokenStream). Lucene’s existing highlighters are mostly 
> demarcated along offset source lines, whereas here it is unified -- hence 
> this proposed name. In this highlighter, the offset source strategy is 
> separated from the core highlighting functionalty. The UnifiedHighlighter 
> further improves on the PostingsHighlighter’s design by supporting accurate 
> phrase highlighting using an approach similar to the standard highlighter’s 
> WeightedSpanTermExtractor. The next major improvement is a hybrid offset 
> source strategythat utilizes postings and “light” term vectors (i.e. just the 
> terms) for highlighting multi-term queries (wildcards) without resorting to 
> analysis. Phrase highlighting and wildcard highlighting can both be disabled 
> if you’d rather highlight a little faster albeit not as accurately reflecting 
> the query.
> We’ve benchmarked an earlier version of this highlighter comparing it to the 
> other highlighters and the results were exciting! It’s tempting to share 
> those results but it’s definitely due for another benchmark, so we’ll work on 
> that. Performance was the main motivator for creating the UnifiedHighlighter, 
> as the standard Highlighter (the only one meeting Bloomberg Law’s accuracy 
> requirements) wasn’t fast enough, even with term vectors along with several 
> improvements we contributed back, and even after we forked it to highlight in 
> multiple threads.



--
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 # 4 - Still Failing

[Apache Jenkins Server]

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

4 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.cloud.CollectionsAPIDistributedZkTest

Error Message:
27 threads leaked from SUITE scope at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest: 1) Thread[id=7564, 
name=searcherExecutor-3891-thread-1, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)2) Thread[id=7710, 
name=searcherExecutor-4076-thread-1, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)3) Thread[id=7654, 
name=searcherExecutor-4023-thread-1, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)4) Thread[id=7698, 
name=searcherExecutor-4067-thread-1, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)5) Thread[id=7714, 
name=searcherExecutor-4070-thread-1, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at java.lang.Thread.run(Thread.java:745)6) Thread[id=7683, 
name=searcherExecutor-4053-thread-1, state=WAITING, 
group=TGRP-CollectionsAPIDistributedZkTest] at 
sun.misc.Unsafe.park(Native Method) at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) 
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)   
  at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
at 

[JENKINS] Lucene-Solr-5.5-Windows (64bit/jdk1.7.0_80) - Build # 120 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Windows/120/
Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseSerialGC

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

Error Message:
Error from server at http://127.0.0.1:54079/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:54079/solr/testschemaapi_shard1_replica1: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([1DA3DCBD0B585EF9:95F7E367A5A43301]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:653)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1002)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:891)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:827)
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 

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

[Policeman Jenkins Server]

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

1 tests failed.
FAILED:  org.apache.solr.client.solrj.TestLBHttpSolrClient.testReliability

Error Message:
GC overhead limit exceeded

Stack Trace:
java.lang.OutOfMemoryError: GC overhead limit exceeded
at 
__randomizedtesting.SeedInfo.seed([621FE902F9132BD7:A3D734445875FA7E]:0)
at java.io.ByteArrayOutputStream.(ByteArrayOutputStream.java:77)
at sun.security.ssl.OutputRecord.(OutputRecord.java:94)
at sun.security.ssl.OutputRecord.(OutputRecord.java:105)
at sun.security.ssl.AppOutputStream.(AppOutputStream.java:52)
at sun.security.ssl.SSLSocketImpl.init(SSLSocketImpl.java:636)
at sun.security.ssl.SSLSocketImpl.(SSLSocketImpl.java:567)
at 
sun.security.ssl.SSLSocketFactoryImpl.createSocket(SSLSocketFactoryImpl.java:110)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:363)
at 
org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
at 
org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
at 
org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
at 
org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
at 
org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at 
org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:513)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:578)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:149)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:957)
at 
org.apache.solr.client.solrj.TestLBHttpSolrClient.waitForServer(TestLBHttpSolrClient.java:237)
at 
org.apache.solr.client.solrj.TestLBHttpSolrClient.testReliability(TestLBHttpSolrClient.java:225)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)




Build Log:
[...truncated 13192 lines...]
   [junit4] Suite: org.apache.solr.client.solrj.TestLBHttpSolrClient
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-solrj/test/J1/temp/solr.client.solrj.TestLBHttpSolrClient_621FE902F9132BD7-001/init-core-data-001
   [junit4]   2> 71688 INFO  
(SUITE-TestLBHttpSolrClient-seed#[621FE902F9132BD7]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (true) and clientAuth (true) via: 
@org.apache.solr.util.RandomizeSSL(reason=, ssl=NaN, value=NaN, clientAuth=NaN)
   [junit4]   2> 71700 INFO  
(TEST-TestLBHttpSolrClient.testSimple-seed#[621FE902F9132BD7]) [] 
o.a.s.SolrTestCaseJ4 ###Starting testSimple
   [junit4]   2> 71708 INFO  
(TEST-TestLBHttpSolrClient.testSimple-seed#[621FE902F9132BD7]) [] 
o.e.j.s.Server jetty-9.3.8.v20160314
   [junit4]   2> 71710 INFO  
(TEST-TestLBHttpSolrClient.testSimple-seed#[621FE902F9132BD7]) [] 
o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@1d1d11{/solr,null,AVAILABLE}
   [junit4]   2> 71712 INFO  
(TEST-TestLBHttpSolrClient.testSimple-seed#[621FE902F9132BD7]) [] 
o.e.j.s.ServerConnector Started ServerConnector@11a60a5{SSL,[ssl, 
http/1.1]}{127.0.0.1:37294}
   [junit4]   2> 71712 INFO  
(TEST-TestLBHttpSolrClient.testSimple-seed#[621FE902F9132BD7]) [] 
o.e.j.s.Server Started @73461ms
   [junit4]   2> 71713 INFO  
(TEST-TestLBHttpSolrClient.testSimple-seed#[621FE902F9132BD7]) [] 
o.a.s.c.s.e.JettySolrRunner Jetty properties: 

Re: Binary Response Writer Issue in solr version 6.2.0

[Alexandre Rafalovitch]

Looks like the same issue Colvin Cowie reported in
https://issues.apache.org/jira/browse/SOLR-9187 ?

Regards,
   Alex.

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


On 8 September 2016 at 13:21, Pavan S Shetty  wrote:
> I downloaded solr version 6.2.0 (6.2.0
> 764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and
> installed my core.
>
> In my schema.xml i have an field like following :
>
>  multiValued="false"/>
>
> Now i am accessing this field using SolrJ (6.1.0). But i am always getting
> false value for above field even though it contains true boolean value. This
> is happening for all boolean fields.
>
> http://localhost:8983/solr...wt=javabin=2 HTTP/1.1
>
> If i change the solr version to 6.1.0, with same SolrJ, it starts working.
> So clearly this is a bug in version 6.2.0.
>
> This is my first mail and issue report, so please correct me or need to send
> this to some other group or mail let me know.
>
> Thanks,
>
> Pavan

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

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

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/442/
Java: 32bit/jdk1.8.0_102 -server -XX:+UseConcMarkSweepGC

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

Error Message:
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:59364/z/b/forceleader_test_collection_shard1_replica2]

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: 
org.apache.solr.client.solrj.SolrServerException: No live SolrServers available 
to handle this 
request:[http://127.0.0.1:59364/z/b/forceleader_test_collection_shard1_replica2]
at 
__randomizedtesting.SeedInfo.seed([2E27EFE7FBC1E2E5:C8B0DB27C2431B84]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:769)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1161)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1050)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:992)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:753)
at 
org.apache.solr.cloud.AbstractFullDistribZkTestBase.sendDocsWithRetry(AbstractFullDistribZkTestBase.java:741)
at 
org.apache.solr.cloud.ForceLeaderTest.sendDoc(ForceLeaderTest.java:424)
at 
org.apache.solr.cloud.ForceLeaderTest.assertSendDocFails(ForceLeaderTest.java:315)
at 
org.apache.solr.cloud.ForceLeaderTest.testReplicasInLIRNoLeader(ForceLeaderTest.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:992)
at 
org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:967)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 

[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+134) - Build # 1684 - Still Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/1684/
Java: 64bit/jdk-9-ea+134 -XX:+UseCompressedOops -XX:+UseG1GC

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

Error Message:
IOException occured when talking to server at: https://127.0.0.1:34588/solr

Stack Trace:
org.apache.solr.client.solrj.SolrServerException: IOException occured when 
talking to server at: https://127.0.0.1:34588/solr
at 
__randomizedtesting.SeedInfo.seed([3DF163E137381C2:BFB1602CB72002B8]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:606)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:261)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:250)
at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1219)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:157)
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:535)
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 

testing PyLucene 6.2

[Dirk Rothe]

Am 05.09.2016, 21:27 Uhr, schrieb Andi Vajda :



On Mon, 5 Sep 2016, Dirk Rothe wrote:
 A volunteer is requested to build and test PyLucene's trunk on  
Windows. If noone comes forward, I intend to try to release PyLucene  
6.2 in a few weeks, still.


Nice Job!

I've successfully build PyLucene 6.2 on windows. Most tests pass:
* skipped the three test_ICU* due to missing "import icu"


Yes, for this you need to install PyICU: https://github.com/ovalhub/pyicu


I'm going to assume this would work for now.

* fixed test_PyLucene.py by ignoring open file handles (os.error) in  
shutil.rmtree() in Test_PyLuceneWithFSStore.tearDown()


Do you have a patch for me to apply ?


Yes, attached.


* then stuff like these in test_PythonDirectory.py

[..]

Can't make sense of this one, sorry.


* and this one in test_PythonException.py

[..]

This one could be because you may not have built JCC in shared mode ?
I vaguely remember there being a problem with proper cross-boundary  
exception propagation requiring JCC to be built in shared mode.


jcc.SHARED reports True, so seems OK.

I don't think these Windows glitches are really problematic, and our  
production code runs only in linux environments anyway.
And I'm more interested in whether porting around 3kloc lucene-interfaces  
from v3.6 goes smoothly.


I've hit the first problematic case with an custom  
PythonAnalyzer/PythonTokenizer where I don't see how to pass the input to  
the Tokenizer implementation.
I thought maybe like this, but PythonTokenizer does not accept an INPUT  
anymore (available in v4.10 and v3.6).


class _Tokenizer(PythonTokenizer):
def __init__(self, INPUT):
super(_Tokenizer, self).__init__(INPUT)
# prepare INPUT
def incrementToken(self):
# stuff into termAtt/offsetAtt/posIncrAtt

class Analyzer6(PythonAnalyzer):
def createComponents(self, fieldName):
return Analyzer.TokenStreamComponents(_Tokenizer())

The PositionIncrementTestCase is pretty similar but initialized with  
static input. Would be a nice place for an example with dynamic input, I  
think.


This was our 3.6 approach:
class Analyzer3(PythonAnalyzer):
def tokenStream(self, fieldName, reader):
   data = data_from_reader(reader)
   class _tokenStream(PythonTokenStream):
   def __init__(self):
super(_tokenStream, self).__init__()
# prepare termAtt/offsetAtt/posIncrAtt
   def incrementToken(self):
# stuff from data into termAtt/offsetAtt/posIncrAtt
  return _tokenStream()

Any hints how to get Analyzer6 working?

--dirk

Re: VOTE: Solr Reference Guide for Solr 6.2

[Mikhail Khludnev]

I just removed this macro. I'm sorry for violating that taboo.

On Thu, Sep 8, 2016 at 4:23 AM, Steve Rowe  wrote:

> I scanned the whole PDF and found a problem that I think warrants respin -
> otherwise it looks good to me:
>
> In the Transforming Result Documents section, under Available Transformers
> / [subquery], under the Note on page 346, it says:
>
>   JIRA Issues Macro: The JIRA server returned a trusted apps error:
> USER_UNKNOWN; Unknown User: {0}; ["cassandra.targett”]
>
> I searched and didn’t find the above problem anywhere else in the PDF.
>
> --
> Steve
> www.lucidworks.com
>
> > On Sep 7, 2016, at 3:16 PM, Cassandra Targett 
> wrote:
> >
> > At long last, please VOTE to release the Apache Solr Ref Guide for 6.2.
> >
> > The artifacts can be downloaded from: https://dist.apache.org/repos/
> dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-6.2-RC0/
> >
> > $ more apache-solr-ref-guide-6.2-RC0/apache-solr-ref-guide-6.2.pdf.sha1
> > 22f2dcdceb9ec69bb4de6dfb20e0c008850200dd  apache-solr-ref-guide-6.2.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
>
>


-- 
Sincerely yours
Mikhail Khludnev

[JENKINS] Lucene-Solr-5.5-Linux (32bit/jdk1.7.0_80) - Build # 403 - Unstable!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/403/
Java: 32bit/jdk1.7.0_80 -client -XX:+UseConcMarkSweepGC

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

Error Message:
1 thread leaked from SUITE scope at 
org.apache.solr.handler.TestSolrConfigHandlerCloud: 1) Thread[id=14244, 
name=Thread-4561, state=TIMED_WAITING, group=TGRP-TestSolrConfigHandlerCloud]   
  at java.lang.Thread.sleep(Native Method) at 
org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101)
 at 
org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:355) 
at 
org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48)
 at 
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:70)
 at 
org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:108)
 at 
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:79)   
  at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:920) 
at org.apache.solr.core.SolrCore$11.run(SolrCore.java:2623) at 
org.apache.solr.cloud.ZkController$5.run(ZkController.java:2480)

Stack Trace:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE 
scope at org.apache.solr.handler.TestSolrConfigHandlerCloud: 
   1) Thread[id=14244, name=Thread-4561, state=TIMED_WAITING, 
group=TGRP-TestSolrConfigHandlerCloud]
at java.lang.Thread.sleep(Native Method)
at 
org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:101)
at 
org.apache.solr.core.SolrResourceLoader.openSchema(SolrResourceLoader.java:355)
at 
org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:48)
at 
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:70)
at 
org.apache.solr.core.ConfigSetService.createIndexSchema(ConfigSetService.java:108)
at 
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:79)
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:920)
at org.apache.solr.core.SolrCore$11.run(SolrCore.java:2623)
at org.apache.solr.cloud.ZkController$5.run(ZkController.java:2480)
at __randomizedtesting.SeedInfo.seed([496B9CBCB5E36BC8]:0)




Build Log:
[...truncated 12251 lines...]
   [junit4] Suite: org.apache.solr.handler.TestSolrConfigHandlerCloud
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/solr-core/test/J2/temp/solr.handler.TestSolrConfigHandlerCloud_496B9CBCB5E36BC8-001/init-core-data-001
   [junit4]   2> 1969051 INFO  
(SUITE-TestSolrConfigHandlerCloud-seed#[496B9CBCB5E36BC8]-worker) [] 
o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false)
   [junit4]   2> 1969051 INFO  
(SUITE-TestSolrConfigHandlerCloud-seed#[496B9CBCB5E36BC8]-worker) [] 
o.a.s.BaseDistributedSearchTestCase Setting hostContext system property: /
   [junit4]   2> 1969053 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[496B9CBCB5E36BC8]) [] 
o.a.s.c.ZkTestServer STARTING ZK TEST SERVER
   [junit4]   2> 1969053 INFO  (Thread-4354) [] o.a.s.c.ZkTestServer client 
port:0.0.0.0/0.0.0.0:0
   [junit4]   2> 1969053 INFO  (Thread-4354) [] o.a.s.c.ZkTestServer 
Starting server
   [junit4]   2> 1969153 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[496B9CBCB5E36BC8]) [] 
o.a.s.c.ZkTestServer start zk server on port:35163
   [junit4]   2> 1969153 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[496B9CBCB5E36BC8]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1969154 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[496B9CBCB5E36BC8]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper
   [junit4]   2> 1969156 INFO  (zkCallback-1866-thread-1) [] 
o.a.s.c.c.ConnectionManager Watcher 
org.apache.solr.common.cloud.ConnectionManager@999865 name:ZooKeeperConnection 
Watcher:127.0.0.1:35163 got event WatchedEvent state:SyncConnected type:None 
path:null path:null type:None
   [junit4]   2> 1969157 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[496B9CBCB5E36BC8]) [] 
o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper
   [junit4]   2> 1969157 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[496B9CBCB5E36BC8]) [] 
o.a.s.c.c.SolrZkClient Using default ZkACLProvider
   [junit4]   2> 1969157 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[496B9CBCB5E36BC8]) [] 
o.a.s.c.c.SolrZkClient makePath: /solr
   [junit4]   2> 1969159 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[496B9CBCB5E36BC8]) [] 
o.a.s.c.c.SolrZkClient Using default ZkCredentialsProvider
   [junit4]   2> 1969159 INFO  
(TEST-TestSolrConfigHandlerCloud.test-seed#[496B9CBCB5E36BC8]) [] 
o.a.s.c.c.ConnectionManager Waiting for client to connect 

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

[Policeman Jenkins Server]

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

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

Error Message:
Unexpected exception type, expected RemoteSolrException

Stack Trace:
junit.framework.AssertionFailedError: Unexpected exception type, expected 
RemoteSolrException
at 
__randomizedtesting.SeedInfo.seed([8ECAC20A99BAD722:32A4B4183DE95458]:0)
at 
org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2682)
at 
org.apache.solr.security.BasicAuthIntegrationTest.testBasicAuth(BasicAuthIntegrationTest.java:111)
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: org.apache.solr.client.solrj.SolrServerException: IOException 
occured when talking to server at: https://127.0.0.1:45198/solr
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:622)
at 

Binary Response Writer Issue in solr version 6.2.0

[Pavan S Shetty]

I downloaded solr version 6.2.0 (6.2.0
764d0f19151dbff6f5fcd9fc4b2682cf934590c5 - mike - 2016-08-20 05:41:37) and
installed my core.

In my schema.xml i have an field like following :



Now i am accessing this field using SolrJ (6.1.0). But i am always getting
false value for above field even though it contains true boolean value.
This is happening for all boolean fields.

http://localhost:8983/solr...wt=javabin=2 HTTP/1.1

If i change the solr version to 6.1.0, with same SolrJ, it starts working.
So clearly this is a bug in version 6.2.0.

This is my first mail and issue report, so please correct me or need to
send this to some other group or mail let me know.

Thanks,

Pavan

[jira] [Commented] (SOLR-9269) Ability to create/delete/list snapshots for a solr core

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9269:
--

Github user hgadre commented on the issue:

https://github.com/apache/lucene-solr/pull/68
  
@dsmiley can you please take a look?


> Ability to create/delete/list snapshots for a solr core
> ---
>
> Key: SOLR-9269
> URL: https://issues.apache.org/jira/browse/SOLR-9269
> Project: Solr
>  Issue Type: Sub-task
>  Components: SolrCloud
>Reporter: Hrishikesh Gadre
>Assignee: David Smiley
> Fix For: 6.2
>
> Attachments: SOLR-9269.patch, SOLR-9269.patch
>
>
> Support snapshot create/delete/list functionality @ the Solr core level. 
> Please refer to parent JIRA for more details.



--
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-9441) Solr collection backup on HDFS can only be manipulated by the Solr process owner

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SOLR-9441:
--

Github user hgadre commented on the issue:

https://github.com/apache/lucene-solr/pull/71
  
@vthacker can you please take a look?


> Solr collection backup on HDFS can only be manipulated by the Solr process 
> owner
> 
>
> Key: SOLR-9441
> URL: https://issues.apache.org/jira/browse/SOLR-9441
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: trunk
>Reporter: Hrishikesh Gadre
>
> When we backup Solr collection using HDFS backup repository, the backup 
> folder (and the files) are created with permissions 755 (i.e. only solr 
> process owner can delete/move the backup folder). This is inconvenient from 
> user perspective since the backup is essentially a full-copy of the Solr 
> collection and hence manipulating it doesn't affect the Solr collection state 
> in any way.
> We should provide an option by which we can enable other users to manipulate 
> the backup folders. 



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

[GitHub] lucene-solr issue #68: [SOLR-9269] Refactor the snapshot cleanup mechanism t...

[hgadre]

Github user hgadre commented on the issue:

https://github.com/apache/lucene-solr/pull/68
  
@dsmiley can you please take a look?


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

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

[GitHub] lucene-solr issue #71: [SOLR-9441] Support configuring umask for HDFS backup...

[hgadre]

Github user hgadre commented on the issue:

https://github.com/apache/lucene-solr/pull/71
  
@vthacker can you please take a look?


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

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