[jira] [Commented] (SOLR-9490) BoolField always returning false for non-DV fields?
[ https://issues.apache.org/jira/browse/SOLR-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15476042#comment-15476042 ] Pavan Shetty commented on SOLR-9490: Also this issue is not dependent on docValues. DocValues true or false for boolean field , this issue is reproduce able. > 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&version=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
[jira] [Commented] (SOLR-9490) BoolField always returning false for non-DV fields?
[ https://issues.apache.org/jira/browse/SOLR-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&version=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!
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
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 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(Tes
[jira] [Assigned] (SOLR-9477) UpdateRequestProcessors ignore child documents
[ 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
[ 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
[ 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 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!
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 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(T
[JENKINS] Lucene-Solr-5.5-Linux (32bit/jdk1.8.0_102) - Build # 407 - Unstable!
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: org.apache.solr.handler.TestReplicationHandler
[JENKINS] Lucene-Solr-6.x-Windows (32bit/jdk1.8.0_102) - Build # 443 - Still Unstable!
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 con
[jira] [Assigned] (SOLR-9481) BasicAuthPlugin should support standalone mode
[ 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
[ 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
[ 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
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!
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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.ja
[jira] [Commented] (LUCENE-7438) UnifiedHighlighter
[ https://issues.apache.org/jira/browse/LUCENE-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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 com
[JENKINS] Lucene-Solr-6.x-Solaris (64bit/jdk1.8.0) - Build # 381 - Unstable!
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 com.carrotsearch.randomizedtesting.ThreadLeakControl$Sta
Re: VOTE: Solr Ref Guide for 6.2, RC1
+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!
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: https://127.0.0.1:36
[jira] [Commented] (SOLR-8742) HdfsDirectoryTest fails reliably after changes in LUCENE-6932
[ https://issues.apache.org/jira/browse/SOLR-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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?
[ https://issues.apache.org/jira/browse/SOLR-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&fl=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&fl=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&version=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-mai
Re: [VOTE] Release Lucene/Solr 5.5.3 RC1
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?
[ https://issues.apache.org/jira/browse/SOLR-9490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&fl=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&version=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
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
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&version=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
[ https://issues.apache.org/jira/browse/SOLR-9187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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 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&version=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
+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
[ https://issues.apache.org/jira/browse/LUCENE-7432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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]>
VOTE: Solr Ref Guide for 6.2, RC1
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
[ https://issues.apache.org/jira/browse/LUCENE-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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?
[ https://issues.apache.org/jira/browse/LUCENE-7439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Commented] (LUCENE-7438) UnifiedHighlighter
[ https://issues.apache.org/jira/browse/LUCENE-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-ma
[jira] [Created] (LUCENE-7439) Should FuzzyQuery match short terms too?
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
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
[jira] [Commented] (LUCENE-7438) UnifiedHighlighter
[ https://issues.apache.org/jira/browse/LUCENE-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SOLR-9187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&version=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
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&version=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
[ https://issues.apache.org/jira/browse/LUCENE-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
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 java.lang.Thread.run(T
[JENKINS] Lucene-Solr-5.5-Windows (64bit/jdk1.7.0_80) - Build # 120 - Unstable!
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 org.apache.lucene.util.TestRule
[JENKINS] Lucene-Solr-master-Linux (32bit/jdk1.8.0_102) - Build # 17782 - Failure!
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: {solr.data.dir=/home/jenkins/workspace/Lucene-Solr-master-Linux/solr/build/solr-solrj/test/J1/temp/solr.client.solrj.TestLBHttpSolrClient_621FE902F9132BD7-001/instance-0-001/collection
Re: Binary Response Writer Issue in solr version 6.2.0
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&version=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!
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 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowin
[JENKINS-EA] Lucene-Solr-6.x-Linux (64bit/jdk-9-ea+134) - Build # 1684 - Still Unstable!
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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Statement
Re: VOTE: Solr Reference Guide for Solr 6.2
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!
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 t