date:20170207

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/440/
Java: 32bit/jdk1.7.0_80 -client -XX:+UseG1GC

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

Error Message:
Error from server at http://127.0.0.1:41008/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:41008/solr/testschemaapi_shard1_replica1: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([733B9A777AC1A766:FB6FA5ADD43DCA9E]:0)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.directUpdate(CloudSolrClient.java:653)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1002)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:891)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:827)
at 
org.apache.solr.schema.TestManagedSchemaAPI.testAddFieldAndDocument(TestManagedSchemaAPI.java:101)
at 
org.apache.solr.schema.TestManagedSchemaAPI.test(TestManagedSchemaAPI.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1764)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:871)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:921)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:367)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:809)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:460)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:880)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:781)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:816)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:827)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at

[JENKINS] Lucene-Solr-NightlyTests-6.x - Build # 276 - Failure

2017-02-07 Thread Apache Jenkins Server

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

7 tests failed.
FAILED:  org.apache.lucene.index.TestIndexSorting.testRandom3

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([B92E69CC2FAD4D04:1BF627164B5F6402]:0)
at 
org.apache.lucene.util.packed.Packed8ThreeBlocks.(Packed8ThreeBlocks.java:41)
at 
org.apache.lucene.util.packed.PackedInts.getMutable(PackedInts.java:963)
at 
org.apache.lucene.util.packed.PackedInts.getMutable(PackedInts.java:939)
at 
org.apache.lucene.util.packed.GrowableWriter.ensureCapacity(GrowableWriter.java:80)
at 
org.apache.lucene.util.packed.GrowableWriter.set(GrowableWriter.java:88)
at 
org.apache.lucene.util.packed.AbstractPagedMutable.set(AbstractPagedMutable.java:98)
at org.apache.lucene.util.fst.NodeHash.addNew(NodeHash.java:152)
at org.apache.lucene.util.fst.NodeHash.rehash(NodeHash.java:169)
at org.apache.lucene.util.fst.NodeHash.add(NodeHash.java:133)
at org.apache.lucene.util.fst.Builder.compileNode(Builder.java:214)
at org.apache.lucene.util.fst.Builder.freezeTail(Builder.java:310)
at org.apache.lucene.util.fst.Builder.add(Builder.java:414)
at 
org.apache.lucene.codecs.memory.MemoryDocValuesConsumer.writeFST(MemoryDocValuesConsumer.java:367)
at 
org.apache.lucene.codecs.memory.MemoryDocValuesConsumer.addSortedField(MemoryDocValuesConsumer.java:404)
at 
org.apache.lucene.codecs.DocValuesConsumer.mergeSortedField(DocValuesConsumer.java:653)
at 
org.apache.lucene.codecs.DocValuesConsumer.merge(DocValuesConsumer.java:204)
at 
org.apache.lucene.codecs.perfield.PerFieldDocValuesFormat$FieldsWriter.merge(PerFieldDocValuesFormat.java:153)
at 
org.apache.lucene.index.SegmentMerger.mergeDocValues(SegmentMerger.java:167)
at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:111)
at 
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:4363)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3940)
at 
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:40)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:2091)
at 
org.apache.lucene.index.IndexWriter.doAfterSegmentFlushed(IndexWriter.java:5004)
at 
org.apache.lucene.index.DocumentsWriter$MergePendingEvent.process(DocumentsWriter.java:731)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5042)
at 
org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5033)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1582)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1324)
at 
org.apache.lucene.index.TestIndexSorting.testRandom3(TestIndexSorting.java:2229)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)


FAILED:  org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testOps

Error Message:
Timeout waiting for CDCR replication to complete @source_collection:shard1

Stack Trace:
java.lang.RuntimeException: Timeout waiting for CDCR replication to complete 
@source_collection:shard1
at 
__randomizedtesting.SeedInfo.seed([C7ADB5AA436D7EF4:DBD529490C5E7529]:0)
at 
org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForReplicationToComplete(BaseCdcrDistributedZkTest.java:795)
at 
org.apache.solr.cloud.CdcrReplicationDistributedZkTest.testOps(CdcrReplicationDistributedZkTest.java:463)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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)

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

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/715/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseSerialGC

1 tests failed.
FAILED:  org.apache.solr.handler.admin.MBeansHandlerTest.testDiff

Error Message:
expected: but was:

Stack Trace:
org.junit.ComparisonFailure: expected: but 
was:
at 
__randomizedtesting.SeedInfo.seed([54C2D8E813518DCD:91D41C7303E7B5AD]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:63)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 11233 lines...]
   [junit4] Suite: org.apache.solr.handler.admin.MBeansHandlerTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.admin.MBeansHandlerTest_54C2D8E813518DCD-001\init-core-data-001
   [junit4]   2>

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

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2815/
Java: 32bit/jdk1.8.0_121 -server -XX:+UseG1GC

2 tests failed.
FAILED:  org.apache.solr.cloud.TestRandomRequestDistribution.test

Error Message:
Shard a1x2_shard1_replica1 received all 10 requests

Stack Trace:
java.lang.AssertionError: Shard a1x2_shard1_replica1 received all 10 requests
at 
__randomizedtesting.SeedInfo.seed([8F83FB2B644529B1:7D7C4F1CAB94449]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.TestRandomRequestDistribution.testRequestTracking(TestRandomRequestDistribution.java:121)
at 
org.apache.solr.cloud.TestRandomRequestDistribution.test(TestRandomRequestDistribution.java:65)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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

[jira] [Updated] (SOLR-10029) Fix search link on http://lucene.apache.org/

2017-02-07 Thread Otis Gospodnetic (JIRA)


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

Otis Gospodnetic updated SOLR-10029:

Summary: Fix search link on http://lucene.apache.org/  (was: Fix Search 
link in http://lucene.apache.org/ & http://lucene.apache.org/)

> Fix search link on http://lucene.apache.org/
> 
>
> Key: SOLR-10029
> URL: https://issues.apache.org/jira/browse/SOLR-10029
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: website
>Reporter: Tien Nguyen Manh
> Attachments: SOLR-10029.patch
>
>
> The current link to http://search-lucene.com is
> http://search-lucene.com/lucene?q=apache=sl
> http://search-lucene.com/solr?q=apache
> The project names  should be upcase
> http://search-lucene.com/Lucene?q=apache=sl
> http://search-lucene.com/Solr?q=apache



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18922/
Java: 64bit/jdk1.8.0_121 -XX:+UseCompressedOops -XX:+UseParallelGC

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

Error Message:
timeout waiting to see all nodes active

Stack Trace:
java.lang.AssertionError: timeout waiting to see all nodes active
at 
__randomizedtesting.SeedInfo.seed([BACAEA2536D8E523:329ED5FF982488DB]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.waitTillNodesActive(PeerSyncReplicationTest.java:326)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:277)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at

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

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

1 tests failed.
FAILED:  org.apache.solr.handler.admin.MBeansHandlerTest.testDiff

Error Message:
expected: but was:

Stack Trace:
org.junit.ComparisonFailure: expected: but 
was:
at 
__randomizedtesting.SeedInfo.seed([2DC91D0BFBC406C:C7CA554BAF0A780C]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:63)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12116 lines...]
   [junit4] Suite: org.apache.solr.handler.admin.MBeansHandlerTest
   [junit4]   2> Creating dataDir: 
/export/home/jenkins/workspace/Lucene-Solr-6.x-Solaris/solr/build/solr-core/test/J1/temp/solr.handler.admin.MBeansHandlerTest_2DC91D0BFBC406C-001/init-core-data-001

[jira] [Commented] (SOLR-10103) Admin UI -- display thread statistics in the dashboard

2017-02-07 Thread Alexandre Rafalovitch (JIRA)


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

Alexandre Rafalovitch commented on SOLR-10103:
--

What's the use case? What does knowing it is 20 vs 40 threads give you?

> Admin UI -- display thread statistics in the dashboard
> --
>
> Key: SOLR-10103
> URL: https://issues.apache.org/jira/browse/SOLR-10103
> Project: Solr
>  Issue Type: Wish
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UI
>Reporter: Shawn Heisey
>Priority: Minor
>
> The admin UI should display any available thread statistics in the dashboard. 
>  The most important number is probably active threads, but if other stats 
> like total threads are available, they could be displayed too.
> Alternatively, the numbers could be shown on the thread dump tab.  I'm 
> surprised they aren't there now.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10102) SynonymFilterFactory in example file is on query not index

2017-02-07 Thread Shawn Heisey (JIRA)


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

Shawn Heisey commented on SOLR-10102:
-

Docs on the default operator probably need to basically say that changing the 
operator to "AND" can have far-reaching effects on Solr's operation, often much 
greater than might be immediately apparent.  The effect on query-time synonyms 
could be one example.

> SynonymFilterFactory in example file is on query not index
> --
>
> Key: SOLR-10102
> URL: https://issues.apache.org/jira/browse/SOLR-10102
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: examples
>Affects Versions: 4.10.2, 6.4.1
>Reporter: Mike Lissner
>
> The example files for both 4.10.2 and 6.4.1 have entries like these:
> {code:xml}
>positionIncrementGap="100" multiValued="true">
> 
>   
>ignoreCase="true"/>
>   
> 
> 
>   
>ignoreCase="true"/>
>   
>ignoreCase="true" synonyms="synonyms.txt"/>
>   
> 
>   
> {code}
> You'll note that the synonym filter is applied at query time, which will 
> totally fail. Even [the 
> docs|https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory]
>  say:
> bq. The recommended approach for dealing with synonyms like this, is to 
> expand the synonym when indexing.
> Can we fix this? Or is there a reason why this is like this? As I understand 
> it, having synonyms on the query means that things just won't be returned 
> that should be. 
> For example, we have the token "5" set up with a synonym to the word "five". 
> So, if somebody searches for 5, the query filter will expand it to "5 AND 
> five", which, sure enough, the index doesn't matchno results. 
> So...instead of expanding the result set, like synonyms are supposed to do, 
> this actively contracts it.
> I hope my frustration in this is misplaced, but if I'm right about this bug, 
> can I say that this is the kind of thing that makes Solr super frustrating to 
> use? 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
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+155) - Build # 2814 - Unstable!

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

3 tests failed.
FAILED:  org.apache.solr.handler.admin.MBeansHandlerTest.testDiff

Error Message:
expected: but was:

Stack Trace:
org.junit.ComparisonFailure: expected: but 
was:
at 
__randomizedtesting.SeedInfo.seed([B1419F6B3DF6ACCD:74575BF02D4094AD]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:63)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:543)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 
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:368)
at java.base/java.lang.Thread.run(Thread.java:844)


FAILED:  org.apache.solr.handler.admin.TestApiFramework.testFramework

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([B1419F6B3DF6ACCD:A637554C3B2240F0]:0)
at 
net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:166)
at

[jira] [Created] (SOLR-10103) Admin UI -- display thread statistics in the dashboard

2017-02-07 Thread Shawn Heisey (JIRA)

Shawn Heisey created SOLR-10103:
---

 Summary: Admin UI -- display thread statistics in the dashboard
 Key: SOLR-10103
 URL: https://issues.apache.org/jira/browse/SOLR-10103
 Project: Solr
  Issue Type: Wish
  Security Level: Public (Default Security Level. Issues are Public)
  Components: UI
Reporter: Shawn Heisey
Priority: Minor


The admin UI should display any available thread statistics in the dashboard.  
The most important number is probably active threads, but if other stats like 
total threads are available, they could be displayed too.

Alternatively, the numbers could be shown on the thread dump tab.  I'm 
surprised they aren't there now.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10102) SynonymFilterFactory in example file is on query not index

2017-02-07 Thread Cassandra Targett (JIRA)


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

Cassandra Targett commented on SOLR-10102:
--

I read the sentence somewhat differently, as applying to the concept of 
multi-word synonyms, and not synonyms in general. Here is the full context:

bq. Keep in mind that while the SynonymFilter will happily work with synonyms 
containing multiple words (ie: "sea biscuit, sea biscit, seabiscuit") The 
recommended approach for dealing with synonyms like this, is to expand the 
synonym when indexing.

While "The" is capitalized there, the first sentence is incomplete unless you 
assume the section after the parentheses is the remainder of the sentence. In 
that context, I think the sentence does not in general recommend using 
index-time synonyms, but only when trying to work with multi-word synonyms. 

The section begins with a link to the documentation for general use 
(https://cwiki.apache.org/confluence/display/solr/Filter+Descriptions#FilterDescriptions-SynonymFilter),
 but whoever added that did not make it clear that the REAL documentation for 
Synonym Filters is in the Ref Guide and no longer in the wiki.

> SynonymFilterFactory in example file is on query not index
> --
>
> Key: SOLR-10102
> URL: https://issues.apache.org/jira/browse/SOLR-10102
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: examples
>Affects Versions: 4.10.2, 6.4.1
>Reporter: Mike Lissner
>
> The example files for both 4.10.2 and 6.4.1 have entries like these:
> {code:xml}
>positionIncrementGap="100" multiValued="true">
> 
>   
>ignoreCase="true"/>
>   
> 
> 
>   
>ignoreCase="true"/>
>   
>ignoreCase="true" synonyms="synonyms.txt"/>
>   
> 
>   
> {code}
> You'll note that the synonym filter is applied at query time, which will 
> totally fail. Even [the 
> docs|https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory]
>  say:
> bq. The recommended approach for dealing with synonyms like this, is to 
> expand the synonym when indexing.
> Can we fix this? Or is there a reason why this is like this? As I understand 
> it, having synonyms on the query means that things just won't be returned 
> that should be. 
> For example, we have the token "5" set up with a synonym to the word "five". 
> So, if somebody searches for 5, the query filter will expand it to "5 AND 
> five", which, sure enough, the index doesn't matchno results. 
> So...instead of expanding the result set, like synonyms are supposed to do, 
> this actively contracts it.
> I hope my frustration in this is misplaced, but if I'm right about this bug, 
> can I say that this is the kind of thing that makes Solr super frustrating to 
> use? 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10102) SynonymFilterFactory in example file is on query not index

2017-02-07 Thread Mike Lissner (JIRA)


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

Mike Lissner commented on SOLR-10102:
-

That makes sense. Does it make sense to update the example file where we set 
the default operator so that it has a note saying something like:

bq. If you change the default operator to AND, be sure to update the synonym 
filters. See: http://some-url-with-docs.com

Or maybe we update the default operator docs to say this? I don't know. I only 
know that as a user this is a pretty easy way to get bitten and you'd never 
expect to have to change synonyms when you change the default operator. 

> SynonymFilterFactory in example file is on query not index
> --
>
> Key: SOLR-10102
> URL: https://issues.apache.org/jira/browse/SOLR-10102
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: examples
>Affects Versions: 4.10.2, 6.4.1
>Reporter: Mike Lissner
>
> The example files for both 4.10.2 and 6.4.1 have entries like these:
> {code:xml}
>positionIncrementGap="100" multiValued="true">
> 
>   
>ignoreCase="true"/>
>   
> 
> 
>   
>ignoreCase="true"/>
>   
>ignoreCase="true" synonyms="synonyms.txt"/>
>   
> 
>   
> {code}
> You'll note that the synonym filter is applied at query time, which will 
> totally fail. Even [the 
> docs|https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory]
>  say:
> bq. The recommended approach for dealing with synonyms like this, is to 
> expand the synonym when indexing.
> Can we fix this? Or is there a reason why this is like this? As I understand 
> it, having synonyms on the query means that things just won't be returned 
> that should be. 
> For example, we have the token "5" set up with a synonym to the word "five". 
> So, if somebody searches for 5, the query filter will expand it to "5 AND 
> five", which, sure enough, the index doesn't matchno results. 
> So...instead of expanding the result set, like synonyms are supposed to do, 
> this actively contracts it.
> I hope my frustration in this is misplaced, but if I'm right about this bug, 
> can I say that this is the kind of thing that makes Solr super frustrating to 
> use? 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

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

5 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI

Error Message:
Could not find collection : implicitcoll

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : implicitcoll
at 
__randomizedtesting.SeedInfo.seed([FA4E80167DED19F3:90AF0E7D4077AF8B]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:194)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:245)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:68)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:368)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection

Error Message:
Failed to list contents of

[JENKINS-EA] Lucene-Solr-master-Linux (32bit/jdk-9-ea+155) - Build # 18921 - Still Unstable!

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18921/
Java: 32bit/jdk-9-ea+155 -server -XX:+UseConcMarkSweepGC

2 tests failed.
FAILED:  org.apache.solr.handler.admin.TestApiFramework.testFramework

Error Message:


Stack Trace:
java.lang.ExceptionInInitializerError
at 
__randomizedtesting.SeedInfo.seed([66770BA64AFA1916:7101C1814C2EF52B]:0)
at 
net.sf.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:166)
at 
net.sf.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrategy.java:25)
at 
net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:216)
at net.sf.cglib.core.KeyFactory$Generator.create(KeyFactory.java:144)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:116)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:108)
at net.sf.cglib.core.KeyFactory.create(KeyFactory.java:104)
at net.sf.cglib.proxy.Enhancer.(Enhancer.java:69)
at 
org.easymock.internal.ClassProxyFactory.createEnhancer(ClassProxyFactory.java:259)
at 
org.easymock.internal.ClassProxyFactory.createProxy(ClassProxyFactory.java:174)
at org.easymock.internal.MocksControl.createMock(MocksControl.java:60)
at org.easymock.EasyMock.createMock(EasyMock.java:104)
at 
org.apache.solr.handler.admin.TestCoreAdminApis.getCoreContainerMock(TestCoreAdminApis.java:76)
at 
org.apache.solr.handler.admin.TestApiFramework.testFramework(TestApiFramework.java:59)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:543)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at

[jira] [Commented] (SOLR-10020) CoreAdminHandler silently swallows some errors

2017-02-07 Thread Erick Erickson (JIRA)


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

Erick Erickson commented on SOLR-10020:
---

Sorry, this week is crazy, so I probably can't until at least the weekend.

> CoreAdminHandler silently swallows some errors
> --
>
> Key: SOLR-10020
> URL: https://issues.apache.org/jira/browse/SOLR-10020
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
> Attachments: SOLR-10020.patch
>
>
> With the setup on SOLR-10006, after removing some index files and starting 
> that Solr instance I tried issuing a REQUESTRECOVERY command and it came back 
> as a success even though nothing actually happened. When the core is 
> accessed, a core init exception is returned by subsequent calls to getCore(). 
> There is no catch block after the try so no error is returned.
> Looking through the code I see several other commands that have a similar 
> pattern:
>  FORCEPREPAREFORLEADERSHIP_OP
> LISTSNAPSHOTS_OP
> getCoreStatus
> and perhaps others. getCore() can throw an exception, about the only explicit 
> one it does throw is if the core has an initialization error.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7662) Index with missing files should throw CorruptIndexException

2017-02-07 Thread Mike Drob (JIRA)


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

Mike Drob updated LUCENE-7662:
--
Attachment: LUCENE-7662.patch

[~mikemccand] - what do you think of this patch?

> Index with missing files should throw CorruptIndexException
> ---
>
> Key: LUCENE-7662
> URL: https://issues.apache.org/jira/browse/LUCENE-7662
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: core/index
>Affects Versions: 6.4
>Reporter: Mike Drob
> Attachments: LUCENE-7662.patch
>
>
> Similar to what we did in LUCENE-7592 for EOF, we should catch missing files 
> and rethrow those as CorruptIndexException.
> If a particular codec can handle missing files, it should be proactive check 
> for those optional files and not throw anything, so I think we can safely do 
> this at SegmentReader or SegmentCoreReaders level.
> Stack trace copied from SOLR-10006:
> {noformat}
> Caused by: java.nio.file.NoSuchFileException: 
> /Users/Erick/apache/solrVersions/trunk/solr/example/cloud/node3/solr/eoe_shard1_replica1/data/index/_1_Lucene50_0.doc
>   at 
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
>   at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
>   at 
> sun.nio.fs.UnixFileSystemProvider.newFileChannel(UnixFileSystemProvider.java:177)
>   at java.nio.channels.FileChannel.open(FileChannel.java:287)
>   at java.nio.channels.FileChannel.open(FileChannel.java:335)
>   at 
> org.apache.lucene.store.MMapDirectory.openInput(MMapDirectory.java:238)
>   at 
> org.apache.lucene.store.NRTCachingDirectory.openInput(NRTCachingDirectory.java:192)
>   at 
> org.apache.solr.core.MetricsDirectoryFactory$MetricsDirectory.openInput(MetricsDirectoryFactory.java:334)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsReader.(Lucene50PostingsReader.java:81)
>   at 
> org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat.fieldsProducer(Lucene50PostingsFormat.java:442)
>   at 
> org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.(PerFieldPostingsFormat.java:292)
>   at 
> org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:372)
>   at 
> org.apache.lucene.index.SegmentCoreReaders.(SegmentCoreReaders.java:109)
>   at org.apache.lucene.index.SegmentReader.(SegmentReader.java:74)
>   at 
> org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:143)
>   at 
> org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:195)
>   at 
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:103)
>   at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:473)
>   at 
> org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:103)
>   at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:79)
>   at 
> org.apache.solr.core.StandardIndexReaderFactory.newReader(StandardIndexReaderFactory.java:39)
>   at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1958)
>   ... 12 more
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10102) SynonymFilterFactory in example file is on query not index

2017-02-07 Thread Shawn Heisey (JIRA)


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

Shawn Heisey commented on SOLR-10102:
-

If the synonyms are expanded at index time, then you must completely reindex if 
you change your list of synonyms.  Also, your index might get significantly 
larger.

Applying them at query time results in a smaller index, and the ability to 
change the list without reindexing.

Assuming the standard lucne query parser, the default operator defaults to "OR" 
... which means that the query you're talking about would be "5 OR five" unless 
the defaults in Solr are changed.  Changing the default operator to "AND" tends 
to have effects that people don't think about.

If you've changed the default operator, it sounds like you should indeed want 
to do synonyms at index time, but for somebody who is going with defaults, 
query time can make things better.

Sounds like the docs need a little bit of a tweak.

> SynonymFilterFactory in example file is on query not index
> --
>
> Key: SOLR-10102
> URL: https://issues.apache.org/jira/browse/SOLR-10102
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: examples
>Affects Versions: 4.10.2, 6.4.1
>Reporter: Mike Lissner
>
> The example files for both 4.10.2 and 6.4.1 have entries like these:
> {code:xml}
>positionIncrementGap="100" multiValued="true">
> 
>   
>ignoreCase="true"/>
>   
> 
> 
>   
>ignoreCase="true"/>
>   
>ignoreCase="true" synonyms="synonyms.txt"/>
>   
> 
>   
> {code}
> You'll note that the synonym filter is applied at query time, which will 
> totally fail. Even [the 
> docs|https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory]
>  say:
> bq. The recommended approach for dealing with synonyms like this, is to 
> expand the synonym when indexing.
> Can we fix this? Or is there a reason why this is like this? As I understand 
> it, having synonyms on the query means that things just won't be returned 
> that should be. 
> For example, we have the token "5" set up with a synonym to the word "five". 
> So, if somebody searches for 5, the query filter will expand it to "5 AND 
> five", which, sure enough, the index doesn't matchno results. 
> So...instead of expanding the result set, like synonyms are supposed to do, 
> this actively contracts it.
> I hope my frustration in this is misplaced, but if I'm right about this bug, 
> can I say that this is the kind of thing that makes Solr super frustrating to 
> use? 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (SOLR-10102) SynonymFilterFactory in example file is on query not index

2017-02-07 Thread Mike Lissner (JIRA)

Mike Lissner created SOLR-10102:
---

Summary: SynonymFilterFactory in example file is on query not index
Key: SOLR-10102
URL: https://issues.apache.org/jira/browse/SOLR-10102
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: examples
Affects Versions: 6.4.1, 4.10.2
Reporter: Mike Lissner

The example files for both 4.10.2 and 6.4.1 have entries like these:

{code:xml}

{code}

You'll note that the synonym filter is applied at query time, which will
totally fail. Even [the
docs|https://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory]
say:

bq. The recommended approach for dealing with synonyms like this, is to expand
the synonym when indexing.

Can we fix this? Or is there a reason why this is like this? As I understand
it, having synonyms on the query means that things just won't be returned that
should be.

For example, we have the token "5" set up with a synonym to the word "five".
So, if somebody searches for 5, the query filter will expand it to "5 AND
five", which, sure enough, the index doesn't matchno results. So...instead
of expanding the result set, like synonyms are supposed to do, this actively
contracts it.

I hope my frustration in this is misplaced, but if I'm right about this bug,
can I say that this is the kind of thing that makes Solr super frustrating to
use?

--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Flume SolrSink No Error but not Indexing

2017-02-07 Thread Anatharaman, Srinatha (Contractor)

Hi,


I am indexing text document using Flume,
I do not see any error or warning message but data is not getting ingested to 
Solr
Log level for both Solr and Flume is set to TRACE, ALL

Flume version : 1.5.2.2.3
Solr Version : 5.5
Config files are as below
Flume Config :
agent.sources = SpoolDirSrc
agent.channels = FileChannel
agent.sinks = SolrSink

# Configure Source
agent.sources.SpoolDirSrc.channels = fileChannel
agent.sources.SpoolDirSrc.type = spooldir
agent.sources.SpoolDirSrc.spoolDir = /home/flume/source_emails
agent.sources.SpoolDirSrc.basenameHeader = true
agent.sources.SpoolDirSrc.fileHeader = true
#agent.sources.src1.fileSuffix = .COMPLETED
agent.sources.SpoolDirSrc.deserializer = 
org.apache.flume.sink.solr.morphline.BlobDeserializer$Builder
# Use a channel that buffers events in memory
agent.channels.FileChannel.type = file
agent.channels.FileChannel.capacity = 1
#agent.channels.FileChannel.transactionCapacity = 1
# Configure Solr Sink
agent.sinks.SolrSink.type = 
org.apache.flume.sink.solr.morphline.MorphlineSolrSink
agent.sinks.SolrSink.morphlineFile = /etc/flume/conf/morphline.conf
agent.sinks.SolrSink.batchsize = 1000
agent.sinks.SolrSink.batchDurationMillis = 2500
agent.sinks.SolrSink.channel = fileChannel
agent.sinks.SolrSink.morphlineId = morphline1
agent.sources.SpoolDirSrc.channels = FileChannel
agent.sinks.SolrSink.channel = FileChannel

Morphline Config
solrLocator: {
collection : gsearch
#zkHost : "127.0.0.1:9983"
zkHost : "codesolr-as-r3p:21810,codesolr-as-r3p:21811,codesolr-as-r3p:21812"
}
morphlines :
[
  {
id : morphline1
importCommands : ["org.kitesdk.**", "org.apache.solr.**"]
commands :
[
  { detectMimeType { includeDefaultMimeTypes : true } }
  {
solrCell {
  solrLocator : ${solrLocator}
  captureAttr : true
  lowernames : true
  capture : [_attachment_body, _attachment_mimetype, basename, content, 
content_encoding, content_type, file, meta]
  parsers : [ { parser : org.apache.tika.parser.txt.TXTParser } ]
 }
  }
  { generateUUID { field : id } }
  { sanitizeUnknownSolrFields { solrLocator : ${solrLocator} } }
  { logDebug { format : "output record: {}", args : ["@{}"] } }
  { loadSolr: { solrLocator : ${solrLocator} } }
]
  }
]

Please help me what could be the issue
Regards,
~Sri

[jira] [Commented] (LUCENE-7410) Make cache keys and closed listeners less trappy

2017-02-07 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-7410:


+1, this is a great infrastructure API improvement, thanks [~jpountz].  I only 
saw some minor issues:

Can/should we {{ensureOpen}} in the {{getReaderCacheHelper}} and
{{addClosedListener}} impls?  Just seems like it'd be some good extra
safety to catch accidental mis-use?

There is a typo (like -> live) here:

{noformat}
+// TODO: this is trappy as the expectation is that core keys like for a 
long
{noformat}

And a missing d in StandarDirectoryReader in the exception message here:

{noformat}
+if (cacheHelper == null) {
+  throw new IllegalStateException("StandarDirectoryReader must support 
caching");
+}
{noformat}

And extra s here:
{noformat}
+   * valuess updates may be considered equal. Consider using
{noformat}


> Make cache keys and closed listeners less trappy
> 
>
> Key: LUCENE-7410
> URL: https://issues.apache.org/jira/browse/LUCENE-7410
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Adrien Grand
> Attachments: LUCENE-7410.patch, LUCENE-7410.patch, LUCENE-7410.patch
>
>
> IndexReader currently exposes getCoreCacheKey(), 
> getCombinedCoreAndDeletesKey(), addCoreClosedListener() and 
> addReaderClosedListener(). They are typically used to manage resources whose 
> lifetime needs to mimic the lifetime of segments/indexes, typically caches.
> I think this is trappy for various reasons:
> h3. Memory leaks
> When maintaining a cache, entries are added to the cache based on the cache 
> key and then evicted using the cache key that is given back by the close 
> listener, so it is very important that both keys are the same.
> But if a filter reader happens to delegate get*Key() and not 
> add*ClosedListener() or vice-versa then there is potential for a memory leak 
> since the closed listener will be called on a different key and entries will 
> never be evicted from the cache.
> h3. Lifetime expectations
> The expectation of using the core cache key is that it will not change in 
> case of deletions, but this is only true on SegmentReader and LeafReader 
> impls that delegate to it. Other implementations such as composite readers or 
> parallel leaf readers use the same key for "core" and "combined core and 
> deletes".
> h3. Throw-away wrappers cause cache trashing
> An application might want to either expose more (with a ParrallelReader or 
> MultiReader) or less information (by filtering fields/docs that can be seen) 
> depending on the user who is logged in. In that case the application would 
> typically maintain a DirectoryReader and then wrap it per request depending 
> on the logged user and throw away the wrapper once the request is completed.
> The problem is that these wrappers have their own cache keys and the 
> application may build something costly and put it in a cache to throw it away 
> a couple milliseconds later. I would rather like for such readers to have a 
> way to opt out from caching on order to avoid this performance trap.
> h3. Type safety
> The keys that are exposed are plain java.lang.Object instances, which 
> requires caches to look like a {{Map}} which makes it very easy to 
> either try to get, put or remove on the wrong object since any object would 
> be accepted.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

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

9 tests failed.
FAILED:  org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI

Error Message:
Could not find collection : implicitcoll

Stack Trace:
org.apache.solr.common.SolrException: Could not find collection : implicitcoll
at 
__randomizedtesting.SeedInfo.seed([601FA41D176630EA:AFE2A762AFC8692]:0)
at 
org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:194)
at 
org.apache.solr.cloud.SolrCloudTestCase.getCollectionState(SolrCloudTestCase.java:245)
at 
org.apache.solr.cloud.CustomCollectionTest.testCustomCollectionsAPI(CustomCollectionTest.java:68)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:368)
at java.lang.Thread.run(Thread.java:745)


FAILED:  org.apache.solr.cloud.CustomCollectionTest.testRouteFieldForHashRouter

Error Message:
Collection not found: routeFieldColl

Stack Trace:

[jira] [Commented] (SOLR-10020) CoreAdminHandler silently swallows some errors

2017-02-07 Thread Mike Drob (JIRA)


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

Mike Drob commented on SOLR-10020:
--

[~erickerickson] - Do you have time to look at this patch?

> CoreAdminHandler silently swallows some errors
> --
>
> Key: SOLR-10020
> URL: https://issues.apache.org/jira/browse/SOLR-10020
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Erick Erickson
> Attachments: SOLR-10020.patch
>
>
> With the setup on SOLR-10006, after removing some index files and starting 
> that Solr instance I tried issuing a REQUESTRECOVERY command and it came back 
> as a success even though nothing actually happened. When the core is 
> accessed, a core init exception is returned by subsequent calls to getCore(). 
> There is no catch block after the try so no error is returned.
> Looking through the code I see several other commands that have a similar 
> pattern:
>  FORCEPREPAREFORLEADERSHIP_OP
> LISTSNAPSHOTS_OP
> getCoreStatus
> and perhaps others. getCore() can throw an exception, about the only explicit 
> one it does throw is if the core has an initialization error.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester


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

Steve Rowe edited comment on SOLR-6246 at 2/7/17 7:09 PM:
--

bq. I was confused too! I recommend marking this as fixed for 6.4.1 and 6.5.0 
[...]  I think adjusting the fix version is more true to the title of this 
issue being addressed at the 6.4.1 version.

I think you're right - I added 6.4.1 as fix version.  I'm leery of introducing 
an intentional difference between JIRA and CHANGES, but really the issue is 
that there should have been a *Solr* CHANGES note for the Lucene changes, but I 
didn't do that. 


was (Author: steve_rowe):
bq. I was confused too! I recommend marking this as fixed for 6.4.1 and 6.5.0 
[...]  I think adjusting the fix version is more true to the title of this 
issue being addressed at the 6.4.1 version.

I think you're right - I added 6.4.1 as fix version.  I'm leery of introducing 
an intentional difference in CHANGES, but really the issue is that there should 
have been a *Solr* CHANGES note for the Lucene changes, but I didn't do that. 

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
>Assignee: Steve Rowe
> Fix For: 6.4.1, 6.5, master (7.0)
>
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester


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

Steve Rowe edited comment on SOLR-6246 at 2/7/17 7:09 PM:
--

bq. I was confused too! I recommend marking this as fixed for 6.4.1 and 6.5.0 
[...]  I think adjusting the fix version is more true to the title of this 
issue being addressed at the 6.4.1 version.

I think you're right - I added 6.4.1 as fix version.  I'm leery of introducing 
an intentional difference in CHANGES, but really the issue is that there should 
have been a *Solr* CHANGES note for the Lucene changes, but I didn't do that. 


was (Author: steve_rowe):
bq. I was confused too! I recommend marking this as fixed for 6.4.1 and 6.5.0 
[...]  I think adjusting the fix version is more true to the title of this 
issue being addressed at the 6.4.1 version.

I think you're right - I added 6.4.1 as fix issue.  I'm leery of introducing an 
intentional difference in CHANGES, but really the issue is that there should 
have been a *Solr* CHANGES note for the Lucene changes, but I didn't do that. 

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
>Assignee: Steve Rowe
> Fix For: 6.4.1, 6.5, master (7.0)
>
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester


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

Steve Rowe commented on SOLR-6246:
--

bq. I was confused too! I recommend marking this as fixed for 6.4.1 and 6.5.0 
[...]  I think adjusting the fix version is more true to the title of this 
issue being addressed at the 6.4.1 version.

I think you're right - I added 6.4.1 as fix issue.  I'm leery of introducing an 
intentional difference in CHANGES, but really the issue is that there should 
have been a *Solr* CHANGES note for the Lucene changes, but I didn't do that. 

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
>Assignee: Steve Rowe
> Fix For: 6.4.1, 6.5, master (7.0)
>
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester


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

Steve Rowe updated SOLR-6246:
-
Fix Version/s: 6.4.1

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
>Assignee: Steve Rowe
> Fix For: 6.4.1, 6.5, master (7.0)
>
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

2017-02-07 Thread ASF subversion and git services (JIRA)

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

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

Error Message:
Error from server at http://127.0.0.1:33414/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:33414/solr/testschemaapi_shard1_replica1: ERROR: 
[doc=2] unknown field 'myNewField1'
at 
__randomizedtesting.SeedInfo.seed([8424E53103BB3F9C:C70DAEBAD475264]: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

[jira] [Created] (LUCENE-7682) UnifiedHighlighter not highlighting all terms relevant in SpanNearQuery

2017-02-07 Thread Michael Braun (JIRA)

Michael Braun created LUCENE-7682:
-

 Summary: UnifiedHighlighter not highlighting all terms relevant in 
SpanNearQuery
 Key: LUCENE-7682
 URL: https://issues.apache.org/jira/browse/LUCENE-7682
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/highlighter
Reporter: Michael Braun


Original text: "Something for protecting wildlife feed in a feed thing."
Query is:
   SpanNearQuery with Slop 9 - in order - 
  1. SpanTermQuery(wildlife)
  2. SpanTermQuery(feed)

This should highlight both instances of "feed" since they are both within slop 
of 9 of "wildlife". However, only the first instance is highlighted. This 
occurs with unordered SpanNearQuery as well.  Test below replicates. Affects 
both the current 6.x line and master.

Test that fits within TestUnifiedHighlighterMTQ:

{code}
  public void testOrderedSpanNearQueryWithDupeTerms() throws Exception {
RandomIndexWriter iw = new RandomIndexWriter(random(), dir, indexAnalyzer);
Document doc = new Document();
doc.add(new Field("body", "Something for protecting wildlife feed in a feed 
thing.", fieldType));
doc.add(newTextField("id", "id", Field.Store.YES));

iw.addDocument(doc);
IndexReader ir = iw.getReader();
iw.close();


IndexSearcher searcher = newSearcher(ir);
UnifiedHighlighter highlighter = new UnifiedHighlighter(searcher, 
indexAnalyzer);
int docID = searcher.search(new TermQuery(new Term("id", "id")), 
1).scoreDocs[0].doc;

SpanTermQuery termOne = new SpanTermQuery(new Term("body", "wildlife"));
SpanTermQuery termTwo = new SpanTermQuery(new Term("body", "feed"));
SpanNearQuery topQuery = new SpanNearQuery.Builder("body", true)
.setSlop(9)
.addClause(termOne)
.addClause(termTwo)
.build();

int[] docIds = new int[] {docID};

String snippets[] = highlighter.highlightFields(new String[] {"body"}, 
topQuery, docIds, new int[] {2}).get("body");
assertEquals(1, snippets.length);
assertEquals("Something for protecting wildlife feed in a 
feed thing.", snippets[0]);
ir.close();
  }
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-8396) Add support for PointFields in Solr


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

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

Commit 59c41e2a6c685dd9ac943c69d12e9bfe2a7d380e in lucene-solr's branch 
refs/heads/master from Tomas Fernandez Lobbe
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=59c41e2 ]

SOLR-10011: Add NumberType getNumberType() to FieldType and deprecate 
LegacyNumericType getNumericType()

Modify references to getNumericType() to use the new getNumberType(). 
NumberType is shared for the different numeric implementations supported in 
Solr (TrieFields and PointFields).
CC SOLR-8396


> Add support for PointFields in Solr
> ---
>
> Key: SOLR-8396
> URL: https://issues.apache.org/jira/browse/SOLR-8396
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Assignee: Tomás Fernández Löbbe
> Attachments: SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch, 
> SOLR-8396.patch, SOLR-8396.patch, SOLR-8396.patch
>
>
> In LUCENE-6917, [~mikemccand] mentioned that DimensionalValues are better 
> than NumericFields in most respects. We should explore the benefits of using 
> it in Solr and hence, if appropriate, switch over to using them.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10011) Refactor PointField & TrieField to share common code

2017-02-07 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-10011:


Commit 59c41e2a6c685dd9ac943c69d12e9bfe2a7d380e in lucene-solr's branch 
refs/heads/master from Tomas Fernandez Lobbe
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=59c41e2 ]

SOLR-10011: Add NumberType getNumberType() to FieldType and deprecate 
LegacyNumericType getNumericType()

Modify references to getNumericType() to use the new getNumberType(). 
NumberType is shared for the different numeric implementations supported in 
Solr (TrieFields and PointFields).
CC SOLR-8396


> Refactor PointField & TrieField to share common code
> 
>
> Key: SOLR-10011
> URL: https://issues.apache.org/jira/browse/SOLR-10011
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10011.patch, SOLR-10011.patch, SOLR-10011.patch, 
> SOLR-10011.patch, SOLR-10011.patch
>
>
> We should eliminate PointTypes and TrieTypes enum to have a common enum for 
> both. That would enable us to share a lot of code between the two field types.
> In the process, fix the bug:
> PointFields with indexed=false, docValues=true seem to be using 
> (Int|Double|Float|Long)Point.newRangeQuery() for performing exact matches and 
> range queries. However, they should instead be using DocValues based range 
> query.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7680) Never cache term filters

2017-02-07 Thread ASF subversion and git services (JIRA)


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

David Smiley commented on LUCENE-7680:
--

Thanks; for a moment there I confused this with the _old_ TermsFilter now 
called {{TermInSetQuery}}.  And I am aware of that using a high integer 
frequency to avoid caching will nonetheless pollute the cache, which is bad.  I 
guess it'd be easy to write an implementation that delegates to a 
{{UsageTrackingQueryCachingPolicy}}.  What do you think about making 
{{UsageTrackingQueryCachingPolicy}} non-final so that it could be easily 
overridden and minFrequencyToCache might be customized by users?

> Never cache term filters
> 
>
> Key: LUCENE-7680
> URL: https://issues.apache.org/jira/browse/LUCENE-7680
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7680.patch
>
>
> Currently we just require term filters to be used a lot in order to cache 
> them. Maybe instead we should look into never caching them. This should not 
> hurt performance since term filters are plenty fast, and would make other 
> filters more likely to be cached since we would not "pollute" the history 
> with filters that are not worth caching.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9997) Enable configuring SolrHttpClientBuilder via java system property


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

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

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

SOLR-9997: Enable configuring SolrHttpClientBuilder via java system property.


> Enable configuring SolrHttpClientBuilder via java system property
> -
>
> Key: SOLR-9997
> URL: https://issues.apache.org/jira/browse/SOLR-9997
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Hrishikesh Gadre
>Assignee: Mark Miller
>
> Currently SolrHttpClientBuilder needs to be configured via invoking 
> HttpClientUtil#setHttpClientBuilder(...) API. On the other hand SolrCLI 
> attempts to support configuring SolrHttpClientBuilder via Java system 
> property.  
> https://github.com/apache/lucene-solr/blob/9f58b6cd177f72b226c83adbb965cfe08d61d2fb/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L265
> But after changes for SOLR-4509, this is no longer working. This is because 
> we need to configure HttpClientBuilderFactory which can provide appropriate 
> SolrHttpClientBuilder instance (e.g. Krb5HttpClientBuilder). I verified that 
> SolrCLI does not work in a kerberos enabled cluster. During the testing I 
> also found that SolrCLI is hardcoded to use basic authentication,
> https://github.com/apache/lucene-solr/blob/9f58b6cd177f72b226c83adbb965cfe08d61d2fb/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L156
> This jira is to add support for configuring HttpClientBuilderFactory as a 
> java system property so that SolrCLI as well as other Solr clients can also 
> benefit this. Also we should provide a HttpClientBuilderFactory which support 
> configuring preemptive basic authentication so that we can remove the 
> hardcoded basic auth usage in SolrCLI (and enable it work with kerberos). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7680) Never cache term filters


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

Adrien Grand commented on LUCENE-7680:
--

I see this class as a default set of heuristics that should work well for most 
use-cases. If someone wants something more specific, I think the way to go 
should be to write a new impl, the API should be pretty simple to implement? As 
it stands, the class is indeed not designed for inheritance: in addition to 
those pkg-private methods, it is final.

bq. Granted I could implement minFrequencyToCache and return Integer.MAX_VALUE.

Requiring that a filter has been seen Integer.MAX_VALUE times would indeed make 
it never cached. However this change goes a bit further in the case of term 
filters: it also does not add them to the history, which makes other filters 
more likely of being cached than they are today. To take an extreme example, 
say you have a query with 100 term filters and 1 other filter (which is not a 
term). Even if that other filter was the same in every query, it would never 
get cached because term queries "pollute" the history (we only keep track of 
the last 256 used filters) and that other filter would only occur at most twice 
in the history. By not putting term filters in the history of recently used 
filters, then Lucene would be more likely to notice that that other filter gets 
reused all the time.

bq. Curious; did you consider marking TermFilter as "cheap"?

What do you mean? Maybe it is the cause of the confusion, but when I say term 
filter, I mean a TermQuery that is consumed with needsScores=false.

> Never cache term filters
> 
>
> Key: LUCENE-7680
> URL: https://issues.apache.org/jira/browse/LUCENE-7680
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7680.patch
>
>
> Currently we just require term filters to be used a lot in order to cache 
> them. Maybe instead we should look into never caching them. This should not 
> hurt performance since term filters are plenty fast, and would make other 
> filters more likely to be cached since we would not "pollute" the history 
> with filters that are not worth caching.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647, cla


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

David Smiley commented on LUCENE-7674:
--

+1 to Adrien Uwe's remarks.  It was released too early.

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
> Attachments: LUCENE-7674.patch
>
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
> at 
>

[jira] [Commented] (LUCENE-7680) Never cache term filters


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

David Smiley commented on LUCENE-7680:
--

The hard coded rules here (and others) concern me.  If I override 
{{shouldCache}} I should hopefully be able to have my own different rules.  I 
see that this method invokes a {{frequency(...)}} method and 
{{minFrequencyToCache(...)}} pair of methods; the former is package level.  It 
should be protected?   Granted I could implement minFrequencyToCache and return 
{{Integer.MAX_VALUE}}.

Curious; did you consider marking TermFilter as "cheap"?

> Never cache term filters
> 
>
> Key: LUCENE-7680
> URL: https://issues.apache.org/jira/browse/LUCENE-7680
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7680.patch
>
>
> Currently we just require term filters to be used a lot in order to cache 
> them. Maybe instead we should look into never caching them. This should not 
> hurt performance since term filters are plenty fast, and would make other 
> filters more likely to be cached since we would not "pollute" the history 
> with filters that are not worth caching.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7681) Remove LegacyDocValues implementations from MemoryIndex


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

Adrien Grand commented on LUCENE-7681:
--

+1 for using the new iterator API!

Is the norm really computed lazily? I see a call to {{getNormDocValues}} in 
{{freeze()}} which makes me think it is computed up-front.
Also I think the {{advanceExact}} impls do not honor the contract that docId() 
returns {{target}} after {{advanceExact(target)}} has been called, regardless 
of whether the document had a value for that doc (however, since target needs 
to be a valid docID, it may only be 0 in the case of MemoryIndex).

> Remove LegacyDocValues implementations from MemoryIndex
> ---
>
> Key: LUCENE-7681
> URL: https://issues.apache.org/jira/browse/LUCENE-7681
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: master (7.0)
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-7681.patch
>
>
> MemoryIndex in master is using the LegacyDocValue wrappers.  We should 
> replace these with plain 7.0-style iterators instead.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9997) Enable configuring SolrHttpClientBuilder via java system property

2017-02-07 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-9997:
---

Yeah, I know it's quite different on 6x vs 7x, I was just asking intention so I 
can place it correctly in CHANGES.

> Enable configuring SolrHttpClientBuilder via java system property
> -
>
> Key: SOLR-9997
> URL: https://issues.apache.org/jira/browse/SOLR-9997
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Hrishikesh Gadre
>Assignee: Mark Miller
>
> Currently SolrHttpClientBuilder needs to be configured via invoking 
> HttpClientUtil#setHttpClientBuilder(...) API. On the other hand SolrCLI 
> attempts to support configuring SolrHttpClientBuilder via Java system 
> property.  
> https://github.com/apache/lucene-solr/blob/9f58b6cd177f72b226c83adbb965cfe08d61d2fb/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L265
> But after changes for SOLR-4509, this is no longer working. This is because 
> we need to configure HttpClientBuilderFactory which can provide appropriate 
> SolrHttpClientBuilder instance (e.g. Krb5HttpClientBuilder). I verified that 
> SolrCLI does not work in a kerberos enabled cluster. During the testing I 
> also found that SolrCLI is hardcoded to use basic authentication,
> https://github.com/apache/lucene-solr/blob/9f58b6cd177f72b226c83adbb965cfe08d61d2fb/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L156
> This jira is to add support for configuring HttpClientBuilderFactory as a 
> java system property so that SolrCLI as well as other Solr clients can also 
> benefit this. Also we should provide a HttpClientBuilderFactory which support 
> configuring preemptive basic authentication so that we can remove the 
> hardcoded basic auth usage in SolrCLI (and enable it work with kerberos). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9997) Enable configuring SolrHttpClientBuilder via java system property

2017-02-07 Thread Hrishikesh Gadre (JIRA)


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

Hrishikesh Gadre commented on SOLR-9997:


[~markrmil...@gmail.com] This patch will work only for 7x. Let me upload a 
patch for 6x.

> Enable configuring SolrHttpClientBuilder via java system property
> -
>
> Key: SOLR-9997
> URL: https://issues.apache.org/jira/browse/SOLR-9997
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Hrishikesh Gadre
>Assignee: Mark Miller
>
> Currently SolrHttpClientBuilder needs to be configured via invoking 
> HttpClientUtil#setHttpClientBuilder(...) API. On the other hand SolrCLI 
> attempts to support configuring SolrHttpClientBuilder via Java system 
> property.  
> https://github.com/apache/lucene-solr/blob/9f58b6cd177f72b226c83adbb965cfe08d61d2fb/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L265
> But after changes for SOLR-4509, this is no longer working. This is because 
> we need to configure HttpClientBuilderFactory which can provide appropriate 
> SolrHttpClientBuilder instance (e.g. Krb5HttpClientBuilder). I verified that 
> SolrCLI does not work in a kerberos enabled cluster. During the testing I 
> also found that SolrCLI is hardcoded to use basic authentication,
> https://github.com/apache/lucene-solr/blob/9f58b6cd177f72b226c83adbb965cfe08d61d2fb/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L156
> This jira is to add support for configuring HttpClientBuilderFactory as a 
> java system property so that SolrCLI as well as other Solr clients can also 
> benefit this. Also we should provide a HttpClientBuilderFactory which support 
> configuring preemptive basic authentication so that we can remove the 
> hardcoded basic auth usage in SolrCLI (and enable it work with kerberos). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9997) Enable configuring SolrHttpClientBuilder via java system property

2017-02-07 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-9997:
---

Is this just for 7x or 6x too?

> Enable configuring SolrHttpClientBuilder via java system property
> -
>
> Key: SOLR-9997
> URL: https://issues.apache.org/jira/browse/SOLR-9997
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 6.3
>Reporter: Hrishikesh Gadre
>Assignee: Mark Miller
>
> Currently SolrHttpClientBuilder needs to be configured via invoking 
> HttpClientUtil#setHttpClientBuilder(...) API. On the other hand SolrCLI 
> attempts to support configuring SolrHttpClientBuilder via Java system 
> property.  
> https://github.com/apache/lucene-solr/blob/9f58b6cd177f72b226c83adbb965cfe08d61d2fb/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L265
> But after changes for SOLR-4509, this is no longer working. This is because 
> we need to configure HttpClientBuilderFactory which can provide appropriate 
> SolrHttpClientBuilder instance (e.g. Krb5HttpClientBuilder). I verified that 
> SolrCLI does not work in a kerberos enabled cluster. During the testing I 
> also found that SolrCLI is hardcoded to use basic authentication,
> https://github.com/apache/lucene-solr/blob/9f58b6cd177f72b226c83adbb965cfe08d61d2fb/solr/core/src/java/org/apache/solr/util/SolrCLI.java#L156
> This jira is to add support for configuring HttpClientBuilderFactory as a 
> java system property so that SolrCLI as well as other Solr clients can also 
> benefit this. Also we should provide a HttpClientBuilderFactory which support 
> configuring preemptive basic authentication so that we can remove the 
> hardcoded basic auth usage in SolrCLI (and enable it work with kerberos). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1231 - Still Unstable

2017-02-07 Thread Apache Jenkins Server

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

4 tests failed.
FAILED:  org.apache.lucene.search.TestFuzzyQuery.testRandom

Error Message:
Test abandoned because suite timeout was reached.

Stack Trace:
java.lang.Exception: Test abandoned because suite timeout was reached.
at __randomizedtesting.SeedInfo.seed([772F33043763FD1D]:0)


FAILED:  junit.framework.TestSuite.org.apache.lucene.search.TestFuzzyQuery

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([772F33043763FD1D]:0)


FAILED:  org.apache.solr.cloud.RollingRestartTest.test

Error Message:
Unable to restart (#8): CloudJettyRunner 
[url=http://127.0.0.1:40537/tz/collection1]

Stack Trace:
java.lang.AssertionError: Unable to restart (#8): CloudJettyRunner 
[url=http://127.0.0.1:40537/tz/collection1]
at 
__randomizedtesting.SeedInfo.seed([41393A96F5B11305:C96D054C5B4D7EFD]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:103)
at 
org.apache.solr.cloud.RollingRestartTest.test(RollingRestartTest.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester


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

David Smiley commented on SOLR-6246:


I was confused too!  I recommend marking this as fixed for 6.4.1 _and_ 6.5.0.  
If not both, then just 6.4.1.  Of course this isn't a substitute for reading 
release notes but nonetheless I think adjusting the fix version is more true to 
the title of this issue being addressed at the 6.4.1 version.

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
>Assignee: Steve Rowe
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18920/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseParallelGC

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

Error Message:
timeout waiting to see all nodes active

Stack Trace:
java.lang.AssertionError: timeout waiting to see all nodes active
at 
__randomizedtesting.SeedInfo.seed([8C195BFE53CE2548:44D6424FD3248B0]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.waitTillNodesActive(PeerSyncReplicationTest.java:326)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:277)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at

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

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Windows/714/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseG1GC

1 tests failed.
FAILED:  org.apache.solr.handler.admin.MBeansHandlerTest.testDiff

Error Message:
expected: but was:

Stack Trace:
org.junit.ComparisonFailure: expected: but 
was:
at 
__randomizedtesting.SeedInfo.seed([F8B49D764FB5EC9:CA9D8D4C744D66A9]:0)
at org.junit.Assert.assertEquals(Assert.java:125)
at org.junit.Assert.assertEquals(Assert.java:147)
at 
org.apache.solr.handler.admin.MBeansHandlerTest.testDiff(MBeansHandlerTest.java:63)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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:368)
at java.lang.Thread.run(Thread.java:745)




Build Log:
[...truncated 12171 lines...]
   [junit4] Suite: org.apache.solr.handler.admin.MBeansHandlerTest
   [junit4]   2> Creating dataDir: 
C:\Users\jenkins\workspace\Lucene-Solr-6.x-Windows\solr\build\solr-core\test\J1\temp\solr.handler.admin.MBeansHandlerTest_F8B49D764FB5EC9-001\init-core-data-001
   [junit4]   2>

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

2017-02-07 Thread jefferyyuan (JIRA)


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

jefferyyuan commented on SOLR-6246:
---

This is great news. Thanks so much [~steve_rowe] for clarifying my questions.
- I should do more search before asking here. My fault. 
I do read release notes for Solr 6.4.1 but not lucene 6.4.1 - which I should.
Also I should have read the issue links this Jira depends on.

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
>Assignee: Steve Rowe
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9912) SimpleFacets - support facet.excludeTerms parameter


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

David Smiley commented on SOLR-9912:


Nicely concise :-)  +1 to commit [~cpoerschke]

> SimpleFacets - support facet.excludeTerms parameter
> ---
>
> Key: SOLR-9912
> URL: https://issues.apache.org/jira/browse/SOLR-9912
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jonny Marks
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9912.patch, SOLR-9912.patch, SOLR-9912.patch, 
> SOLR-9912.patch
>
>
> This ticket is for supporting a new facet.excludeTerms parameter for removing 
> specific terms from the facet counts, without having to exclude the terms 
> from the index itself.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7638) Optimize graph query produced by QueryBuilder

2017-02-07 Thread Matt Weber (JIRA)


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

Matt Weber commented on LUCENE-7638:


[~jim.ferenczi] Sorry so late been swamped.  Anyways, this is great!  I really 
like this approach, awesome job man!

> Optimize graph query produced by QueryBuilder
> -
>
> Key: LUCENE-7638
> URL: https://issues.apache.org/jira/browse/LUCENE-7638
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
> Attachments: LUCENE-7638.patch, LUCENE-7638.patch
>
>
> The QueryBuilder creates a graph query when the underlying TokenStream 
> contains token with PositionLengthAttribute greater than 1.
> These TokenStreams are in fact graphs (lattice to be more precise) where 
> synonyms can span on multiple terms. 
> Currently the graph query is built by visiting all the path of the graph 
> TokenStream. For instance if you have a synonym like "ny, new york" and you 
> search for "new york city", the query builder would produce two pathes:
> "new york city", "ny city"
> This can quickly explode when the number of multi terms synonyms increase. 
> The query "ny ny" for instance would produce 4 pathes and so on.
> For boolean queries with should or must clauses it should be more efficient 
> to build a boolean query that merges all the intersections in the graph. So 
> instead of "new york city", "ny city" we could produce:
> "+((+new +york) ny) +city"
> The attached patch is a proposal to do that instead of the all path solution.
> The patch transforms multi terms synonyms in graph query for each 
> intersection in the graph. This is not done in this patch but we could also 
> create a specialized query that gives equivalent scores to multi terms 
> synonyms like the SynonymQuery does for single term synonyms.
> For phrase query this patch does not change the current behavior but we could 
> also use the new method to create optimized graph SpanQuery.
> [~mattweber] I think this patch could optimize a lot of cases where multiple 
> muli-terms synonyms are present in a single request. Could you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[JENKINS] Lucene-Solr-master-Windows (32bit/jdk1.8.0_121) - Build # 6380 - Still Unstable!

2017-02-07 Thread ASF subversion and git services (JIRA)

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6380/
Java: 32bit/jdk1.8.0_121 -client -XX:+UseSerialGC

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

Error Message:
expected:<152> but was:<145>

Stack Trace:
java.lang.AssertionError: expected:<152> but was:<145>
at 
__randomizedtesting.SeedInfo.seed([A18C3EAA701B53F3:29D80170DEE73E0B]: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.cloud.PeerSyncReplicationTest.bringUpDeadNodeAndEnsureNoReplication(PeerSyncReplicationTest.java:286)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.forceNodeFailureAndDoPeerSync(PeerSyncReplicationTest.java:259)
at 
org.apache.solr.cloud.PeerSyncReplicationTest.test(PeerSyncReplicationTest.java:138)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at

[jira] [Commented] (LUCENE-6989) Implement MMapDirectory unmapping for coming Java 9 changes


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

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

Commit 0f4ff1227ac96511e48f5b528349b0512c1e5fc1 in lucene-solr's branch 
refs/heads/branch_5_5 from [~thetaphi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0f4ff12 ]

LUCENE-6989: Fix javadocs


> Implement MMapDirectory unmapping for coming Java 9 changes
> ---
>
> Key: LUCENE-6989
> URL: https://issues.apache.org/jira/browse/LUCENE-6989
> Project: Lucene - Core
>  Issue Type: Task
>  Components: core/store
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: 6.0, 5.5.4, 6.4
>
> Attachments: LUCENE-6989-disable5x.patch, 
> LUCENE-6989-disable5x.patch, LUCENE-6989-fixbuild148.patch, 
> LUCENE-6989.patch, LUCENE-6989.patch, LUCENE-6989.patch, LUCENE-6989.patch, 
> LUCENE-6989-v2.patch, LUCENE-6989-v3-post-b148.patch, 
> LUCENE-6989-v3-post-b148.patch, LUCENE-6989-v3-testFixes.patch
>
>
> Originally, the sun.misc.Cleaner interface was declared as "critical API" in 
> [JEP 260|http://openjdk.java.net/jeps/260 ]
> Unfortunately the decission was changed in favor of a oficially supported 
> {{java.lang.ref.Cleaner}} API. A side effect of this change is to move all 
> existing {{sun.misc.Cleaner}} APIs into a non-exported package. This causes 
> our forceful unmapping to no longer work, because we can get the cleaner 
> instance via reflection, but trying to invoke it will throw one of the new 
> Jigsaw RuntimeException because it is completely inaccessible. This will make 
> our forceful unmapping fail. There are also no changes in Garbage collector, 
> the problem still exists.
> For more information see this [mailing list 
> thread|http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/thread.html#38243].
> This commit will likely be done, making our unmapping efforts no longer 
> working. Alan Bateman is aware of this issue and will open a new issue at 
> OpenJDK to allow forceful unmapping without using the now private 
> sun.misc.Cleaner. The idea is to let the internal class sun.misc.Cleaner 
> implement the Runable interface, so we can simply cast to runable and call 
> the run() method to unmap. The code would then work. This will lead to minor 
> changes in our unmapper in MMapDirectory: An instanceof check and casting if 
> possible.
> I opened this issue to keep track and implement the changes as soon as 
> possible, so people will have working unmapping when java 9 comes out. 
> Current Lucene versions will no longer work with Java 9.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7681) Remove LegacyDocValues implementations from MemoryIndex


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

Alan Woodward updated LUCENE-7681:
--
Attachment: LUCENE-7681.patch

Patch.  This also re-instates the caching of norm values that was removed when 
we cut over to the iterator API (we cache the value itself rather than a 
NumericDocValues instance).  I'm open to stripping this out again though, or 
just computing it up-front rather than lazily as is done now.

> Remove LegacyDocValues implementations from MemoryIndex
> ---
>
> Key: LUCENE-7681
> URL: https://issues.apache.org/jira/browse/LUCENE-7681
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: master (7.0)
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Attachments: LUCENE-7681.patch
>
>
> MemoryIndex in master is using the LegacyDocValue wrappers.  We should 
> replace these with plain 7.0-style iterators instead.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7679) MemoryIndex.addField() ignores some FieldType settings

2017-02-07 Thread Martijn van Groningen (JIRA)


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

Martijn van Groningen commented on LUCENE-7679:
---

+1

> MemoryIndex.addField() ignores some FieldType settings
> --
>
> Key: LUCENE-7679
> URL: https://issues.apache.org/jira/browse/LUCENE-7679
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Alan Woodward
> Attachments: LUCENE-7679.patch
>
>
> Spotted by a luwak user: https://github.com/flaxsearch/luwak/issues/135.  
> MemoryIndex never omits norms, which means that it can produce incorrect 
> scores.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester


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

Steve Rowe commented on SOLR-6246:
--

[~jefferyyuan], you yourself tested 6.4.1 and found that the fixes included in 
that release fixed your problem.  Quoting the CHANGES.txt entry for this issue:

bq. Added tests to check that the changes in LUCENE-7564 and LUCENE-7670 enable 
AnalyzingInfixSuggester and BlendedInfixSuggester to play nicely with core 
reload.

LUCENE-7564 and LUCENE-7670 contain the fixes for the problem identified in 
this issue, and they were included in Lucene/Solr 6.4.1.

This issue contains tests that confirm the fix in the Solr context, and it 
wasn't ready until after the 6.4.1 release candidate voting was already 
underway, so couldn't be included.  

Here's what I included in the Solr 6.4.1 release announcement:

bq. AnalyzingInfixSuggester/BlendedInfixSuggester now work with core reload

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
>Assignee: Steve Rowe
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (LUCENE-7681) Remove LegacyDocValues implementations from MemoryIndex

Alan Woodward created LUCENE-7681:
-

 Summary: Remove LegacyDocValues implementations from MemoryIndex
 Key: LUCENE-7681
 URL: https://issues.apache.org/jira/browse/LUCENE-7681
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: master (7.0)
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor


MemoryIndex in master is using the LegacyDocValue wrappers.  We should replace 
these with plain 7.0-style iterators instead.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Lucene/Solr 5.5.4

2017-02-07 Thread Adrien Grand

Are we good with the backports? I will do a second pass over the Lucene
changes to check whether there are important fixes we missed. If someone
could check the Solr side as well that would be great.

Le lun. 6 févr. 2017 à 21:01, Jan Høydahl  a écrit :

> Hmm, need to backport the test fix for SOLR-10031 on Windows for 5_5
> branch. Master commit aa5e048cbf7c6fa9e8331c51b5f3331636dd7951
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 6. feb. 2017 kl. 14.42 skrev Adrien Grand :
>
> Thanks Uwe and Steve!
>
> Le lun. 6 févr. 2017 à 14:12, Steve Rowe  a écrit :
>
> I enabled the already existing 5.5 branch jobs on ASF Jenkins.
>
> --
> Steve
> www.lucidworks.com
>
> > On Feb 6, 2017, at 8:09 AM, Uwe Schindler  wrote:
> >
> > Hi.
> >
> > No problem, I'll help! Will do it when back home from Brussels. It is
> more complicated, because it needs Java 7 and smoker should run on both. So
> we should reuse disabled old jobs.
> >
> > Uwe
> >
> > Am 6. Februar 2017 12:06:41 MEZ schrieb Adrien Grand  >:
> > Could someone help me enable Jenkins builds on branch_5_5?
> >
> > Le lun. 6 févr. 2017 à 12:02, Adrien Grand  a écrit :
> > I started backporting some changes. Please find below the list of
> changes we have in 5.5.4 for now. Uwe, do you think we should try to
> backport LUCENE-7651 too?
> >
> > * LUCENE-7417: The standard Highlighter could throw an
> IllegalArgumentException when
> >   trying to highlight a query containing a degenerate case of a
> MultiPhraseQuery with one
> >   term.  (Thomas Kappler via David Smiley)
> >
> > * LUCENE-7657: Fixed potential memory leak in the case that a
> (Span)TermQuery
> >   with a TermContext is cached. (Adrien Grand)
> >
> > * LUCENE-7647: Made stored fields reclaim native memory more
> aggressively when
> >   configured with BEST_COMPRESSION. This could otherwise result in
> out-of-memory
> >   issues. (Adrien Grand)
> >
> > * LUCENE-7562: CompletionFieldsConsumer sometimes throws
> >   NullPointerException on ghost fields (Oliver Eilhard via Mike
> McCandless)
> >
> > * LUCENE-7543: Make changes-to-html target an offline operation, by
> moving the
> >   Lucene and Solr DOAP RDF files into the Git source repository under
> >   dev-tools/doap/ and then pulling release dates from those files,
> rather than
> >   from JIRA. (Mano Kovacs, hossman, Steve Rowe)
> >
> > * SOLR-9819: Upgrade commons-fileupload to 1.3.2, fixing a potential
> vulnerability CVE-2016-3092 (Anshum Gupta)
> >
> > * SOLR-10031: Validation of filename params in ReplicationHandler
> (Hrishikesh Gadre, janhoy)
> >
> >
> > Le ven. 3 févr. 2017 à 12:17, Adrien Grand  a écrit :
> > Sure, the list of bugs I gave is not exhaustive. :)
> >
> > By the way I did not say it explicitly but I don't mind being the
> release manager for this release.
> >
> > Le ven. 3 févr. 2017 à 12:16, Michael McCandless <
> luc...@mikemccandless.com> a écrit :
> > +1
> >
> > I would also like to backport
> > https://issues.apache.org/jira/browse/LUCENE-7562 for 5.5.4 (and
> > probably there are other bug fixes).
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> >
> > On Fri, Feb 3, 2017 at 6:02 AM, Adrien Grand  wrote:
> > > Hello,
> > >
> > > I would like to propose releasing Lucene/Solr 5.5.4 in order to
> address both
> > > https://issues.apache.org/jira/browse/LUCENE-7647 and
> > > https://issues.apache.org/jira/browse/LUCENE-7657 like for the 6.4.1
> > > release.
> > >
> > > I propose to start building a RC after 6.4.1 is out in order to not
> have to
> > > RCs running at the same time, which means we could hopefully build the
> first
> > > RC early next week.
> > >
> > > Opinions?
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> >
> > --
> > Uwe Schindler
> > Achterdiek 19, 28357 Bremen
> > https://www.thetaphi.de
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>

[jira] [Commented] (SOLR-7759) DebugComponent's explain should be implemented as a distributed query

2017-02-07 Thread Alessandro Benedetti (JIRA)


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

Alessandro Benedetti commented on SOLR-7759:


[~markus17] any feedback on this ?
[~anshumg] ?
Anyone interested ?

> DebugComponent's explain should be implemented as a distributed query
> -
>
> Key: SOLR-7759
> URL: https://issues.apache.org/jira/browse/SOLR-7759
> Project: Solr
>  Issue Type: Bug
>Reporter: Varun Thacker
> Attachments: SOLR_7759.patch
>
>
> Currently when we use debugQuery to see the explanation of the matched 
> documents, the query fired to get the statistics for the matched documents is 
> not a distributed query.
> This is a problem when using distributed idf. The actual documents are being 
> scored using the global stats and not per shard stats , but the explain will 
> show us the score by taking into account the stats from the shard where the 
> document belongs to.
> We should try to implement the explain query as a distributed request so that 
> the scores match the actual document scores.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Backport mmap to 5.5

2017-02-07 Thread Adrien Grand

This sounds like the right trade-off to me, thanks Uwe!

Le mar. 7 févr. 2017 à 11:53, Uwe Schindler  a écrit :

> Hi Adrien,
>
>
>
> I backported the MMAP stuff. Unfortunately we cannot run the tests with
> Java 9 on Lucene 5, because we have many failing tests for other reasons
> (like RAMUsageTester). So this only fixes Java 9 unmapping. I tested it
> successfully, so all looks good. Most stuff was to add a missing method and
> convert lambdas to Java 7.
>
>
>
> I also backported some other issues:
>
>- Update Groovy
>- Javadocs fixes for Java 8u121
>
>
>
> The recent one is a bit tricky and still broken, but it no longer fails
> the build on recent Java 8 and possibly on paid (!!) Java 7 updates we have
> no access to! I sent a separate e-mail for discussion.
>
>
>
> I may do some documentation/changes fixes, but otherwise I am fine to go.
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Adrien Grand [mailto:jpou...@gmail.com]
> *Sent:* Monday, February 6, 2017 2:44 PM
> *To:* dev@lucene.apache.org
> *Subject:* Re: Backport mmap to 5.5
>
>
>
> Hi Uwe,
>
> It works for me. Thanks for doing it.
>
>
>
> Le lun. 6 févr. 2017 à 14:23, Uwe Schindler  a écrit :
>
> Hi,
>
> I was talking on Saturday with Sanne Grinovero this weekend on FOSDEM.
> Because they have to support the current version of Hibernate Search for
> longer time including Java 9 support, they would like to have current Java
> 9 support backported to 5.5 and 5.3. I told him 5.3 is unlikely to get ever
> released, but he may apply the 5.5 patch to 5.3, too.
>
> As the backport requires some Java 7 changes, I'd like to do this now. So
> give me one or 2 days!
>
> OK?
>
> Uwe
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>
>

[jira] [Updated] (SOLR-9912) SimpleFacets - support facet.excludeTerms parameter

2017-02-07 Thread Jonny Marks (JIRA)


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

Jonny Marks updated SOLR-9912:
--
Attachment: SOLR-9912.patch

Moved ExcludeBytesRefFilter to anonymous inner class

> SimpleFacets - support facet.excludeTerms parameter
> ---
>
> Key: SOLR-9912
> URL: https://issues.apache.org/jira/browse/SOLR-9912
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Jonny Marks
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-9912.patch, SOLR-9912.patch, SOLR-9912.patch, 
> SOLR-9912.patch
>
>
> This ticket is for supporting a new facet.excludeTerms parameter for removing 
> specific terms from the facet counts, without having to exclude the terms 
> from the index itself.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

2017-02-07 Thread ASF subversion and git services (JIRA)

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18919/
Java: 64bit/jdk1.8.0_121 -XX:-UseCompressedOops -XX:+UseParallelGC

2 tests failed.
FAILED:  
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI

Error Message:
Error from server at https://127.0.0.1:38556/solr/awhollynewcollection_0: 
Expected mime type application/octet-stream but got text/html.   
 
Error 510HTTP ERROR: 510 Problem 
accessing /solr/awhollynewcollection_0/select. Reason: 
{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg={awhollynewcollection_0:5},code=510}
 http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028   

Stack Trace:
org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error 
from server at https://127.0.0.1:38556/solr/awhollynewcollection_0: Expected 
mime type application/octet-stream but got text/html. 


Error 510 


HTTP ERROR: 510
Problem accessing /solr/awhollynewcollection_0/select. Reason:

{metadata={error-class=org.apache.solr.common.SolrException,root-error-class=org.apache.solr.common.SolrException},msg={awhollynewcollection_0:5},code=510}
http://eclipse.org/jetty;>Powered by Jetty:// 
9.3.14.v20161028



at 
__randomizedtesting.SeedInfo.seed([7CC0394495B80543:34B54DF0938B2AD6]:0)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:595)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:279)
at 
org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:268)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.doRequest(LBHttpSolrClient.java:439)
at 
org.apache.solr.client.solrj.impl.LBHttpSolrClient.request(LBHttpSolrClient.java:391)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1358)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1109)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1212)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1212)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1212)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1212)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:1212)
at 
org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:1042)
at 
org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:160)
at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:942)
at 
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCollectionsAPI(CollectionsAPIDistributedZkTest.java:517)
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:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at

[jira] [Commented] (LUCENE-7568) Optimize merge when index sorting is used but the index is already sorted


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

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

Commit 568f130c501c9c04a40a27e7952699490f155759 in lucene-solr's branch 
refs/heads/branch_6x from [~jim.ferenczi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=568f130 ]

LUCENE-7568: Fix test that should never create segments with a single document.


> Optimize merge when index sorting is used but the index is already sorted
> -
>
> Key: LUCENE-7568
> URL: https://issues.apache.org/jira/browse/LUCENE-7568
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Jim Ferenczi
> Fix For: master (7.0), 6.4
>
> Attachments: LUCENE-7568.patch, LUCENE-7568.patch
>
>
> When the index sorting is defined a lot of optimizations are disabled during 
> the merge. For instance the bulk merge of the compressing stored fields is 
> disabled since documents are not merged sequentially. Though it can happen 
> that index sorting is enabled but the index is already in sorted order (the 
> sort field is not filled or filled with the same value for all documents). In 
> such case we can detect that the sort is not needed and activate the merge 
> optimization.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7568) Optimize merge when index sorting is used but the index is already sorted

2017-02-07 Thread ASF subversion and git services (JIRA)


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

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

Commit 37b75bef3f39840227f85aa5c330337fd101b003 in lucene-solr's branch 
refs/heads/master from [~jim.ferenczi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=37b75be ]

LUCENE-7568: Fix test that should never create segments with a single document.


> Optimize merge when index sorting is used but the index is already sorted
> -
>
> Key: LUCENE-7568
> URL: https://issues.apache.org/jira/browse/LUCENE-7568
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: core/index
>Reporter: Jim Ferenczi
> Fix For: master (7.0), 6.4
>
> Attachments: LUCENE-7568.patch, LUCENE-7568.patch
>
>
> When the index sorting is defined a lot of optimizations are disabled during 
> the merge. For instance the bulk merge of the compressing stored fields is 
> disabled since documents are not merged sequentially. Though it can happen 
> that index sorting is enabled but the index is already in sorted order (the 
> sort field is not filled or filled with the same value for all documents). In 
> such case we can detect that the sort is not needed and activate the merge 
> optimization.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9916) Add arithmetic operations to the SelectStream

2017-02-07 Thread Dennis Gove (JIRA)


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

Dennis Gove commented on SOLR-9916:
---

Future work for another ticket will be to remove the use of BooleanOperation 
over to use evaluators.

> Add arithmetic operations to the SelectStream
> -
>
> Key: SOLR-9916
> URL: https://issues.apache.org/jira/browse/SOLR-9916
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-9916.patch
>
>
> One of the things that will be needed as the SQL implementation matures is 
> the ability to do arithmetic operations. For example:
> select (a+b) from x;
> select sum(a)+sum(b) from x;
> We will need to support arithmetic operations within the Streaming API to 
> support these types of operations.
> It looks like adding arithmetic operations to the SelectStream is the best 
> place to add this functionality.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (SOLR-9916) Add arithmetic operations to the SelectStream

2017-02-07 Thread Dennis Gove (JIRA)


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

Dennis Gove updated SOLR-9916:
--
Attachment: SOLR-9916.patch

Includes the following evaluators

{code}
StreamEvaluator
  ComplexEvaluator // evaluators allowing other StreamEvaluators as parameters 
(looking for better class name)
NumberEvaluator // evaluators resulting in a Number return value
  AbsoluteValueEvaluator // abs(a)
  AddEvaluator // add(a,b,...,z)
  DivideEvaluator // div(a,b)
  MultiplyEvaluator // mult(a,b,...,z)
  SubtractEvaluator // sub(a,b)
BooleanEvaluator // evaluators resulting in a Boolean return value
  AndEvaluator // and(a,b,...,z) == true iff all all true
  EqualsEvaluator // eq(a,b,...,z) == true iff all are equal
  GreaterThanEqualToEvaluator
  GreaterThanEvaluator
  LessThanEqualToEvaluator
  LessThanEvaluator
  OrEvaluator
ConditionalEvaluator // evaluators performing a conditional and returning 
an Object based on the result
  IfThenElseEvaluator
  SimpleEvaluator // evaluators not allowing other StreamEvaluators as 
parameters (looking for a better class name)
FieldEvaluator // return the value of the field - not something that needs 
to be expressed in the expression
{code}

Still needed:
* ValueEvaluator
* Addition Testing
* Handling of null raw value
* Additional evaluators

> Add arithmetic operations to the SelectStream
> -
>
> Key: SOLR-9916
> URL: https://issues.apache.org/jira/browse/SOLR-9916
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
> Attachments: SOLR-9916.patch
>
>
> One of the things that will be needed as the SQL implementation matures is 
> the ability to do arithmetic operations. For example:
> select (a+b) from x;
> select sum(a)+sum(b) from x;
> We will need to support arithmetic operations within the Streaming API to 
> support these types of operations.
> It looks like adding arithmetic operations to the SelectStream is the best 
> place to add this functionality.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

2017-02-07 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-5944: Reverting the previous fix for SolrCmdDistributor


> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Attachments: defensive-checks.log.gz, 
> demo-why-dynamic-fields-cannot-be-inplace-updated-first-time.patch, 
> DUP.patch, hoss.62D328FA1DEA57FD.fail2.txt, hoss.62D328FA1DEA57FD.fail3.txt, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt, master-vs-5944-regular-updates.png, 
> regular-vs-dv-updates.png, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9916) Add arithmetic operations to the SelectStream

2017-02-07 Thread Dennis Gove (JIRA)


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

Dennis Gove commented on SOLR-9916:
---

I've decided to go in a slightly different direction with this. After 
refamilarizing myself with StreamOperations, it became clear that operations 
are meant to modify tuples. For example, the ReplaceOperation replaces some 
field value with some other value via the {code} void operate(Tuple){code} 
function. Newer operations like the BooleanOperation extends that with an 
evaluate() function, but I find it's not quite as clear as it could be. 

Bringing this back to the problem we want to solve: we want to evaluate some 
value based on a tuple. This isn't meant to modify a tuple but instead to 
calculate new values from other values that exist within tuple. This is true 
whether we are adding, multiplying, determining equality, greater than, or 
choosing with an if/else. We are evaluating, but not modifying, the tuple.

To solve this problem, I'm introducing a new set of classes called 
StreamEvaluators. StreamEvaluators follow the same functional expression 
structure as everything else within the streaming sphere and define the 
function {code}public Object evaluate(Tuple){code}. The object returned from 
this function is the result of the evaluation against the tuple. For example, 
the result returned for the expresssion {code}add(a,b){code} is the result of 
field a added to field b. The datatype of the returned result is determined by 
the evaluator and the source field types. For example, {code}add(a,b){code} 
could reasonably return a Number, either Long or Double, while 
{code}eq(a,b){code} could reasonably return a Boolean, while 
{code}if(eq(a,b),c,d){code} could reasonably return any type.

StreamEvaluators come in two basic flavors - those that can contain other 
evaluators and those that can't.
{code}
add(a,b) // field a + field b
sub(add(a,b),c) // (a + b) - c
mult(if(gt("a",b),a,b),c) // if field a > field b then a * c else b * c
if(eq(a,b),val(34),c) // if a == b then value 34 else c
if(eq(a,b),val(foo),c) // if a == b then value "foo" else c
if(eq(a,null),b,c) // if a is null then b else c
{code}

There are a couple pieces of note in here.

* null is a special case and will be treated as a standard null value
* A ValueEvaluator {code}val(), val(), val(){code} 
will evaluate to the raw value contained within
** This allows us to easily distinguish between field names and raw string 
values.
* Within any other evaluator, a string, quoted or not, will be considered a 
field name

As a result of this, the class structure is turning into this.

{code}
StreamEvaluator
  ComplexEvaluator // evaluators allowing other StreamEvaluators as parameters 
(looking for better class name)
NumberEvaluator // evaluators resulting in a Number return value
  AbsoluteValueEvaluator // abs(a)
  AddEvaluator // add(a,b,...,z)
  DivideEvaluator // div(a,b)
  MultiplyEvaluator // mult(a,b,...,z)
  SubtractEvaluator // sub(a,b)
BooleanEvaluator // evaluators resulting in a Boolean return value
  AndEvaluator // and(a,b,...,z) == true iff all all true
  EqualsEvaluator // eq(a,b,...,z) == true iff all are equal
  GreaterThanEqualToEvaluator
  GreaterThanEvaluator
  LessThanEqualToEvaluator
  LessThanEvaluator
  OrEvaluator
ConditionalEvaluator // evaluators performing a conditional and returning 
an Object based on the result
  IfThenElseEvaluator
  SimpleEvaluator // evaluators not allowing other StreamEvaluators as 
parameters (looking for a better class name)
ValueEvaluator // return the raw value as-is
FieldEvaluator // return the value of the field - not something that needs 
to be expressed in the expression
{code}

StreamEvaluators will become a type of parameter supported by the SelectStream 
and executed *after* the execution of operations in that select clause. The 
result of the evaluation will be put into the tuple under the 'as' field name.

{code}select(...,add(a,b) as aPlusb){code}

> Add arithmetic operations to the SelectStream
> -
>
> Key: SOLR-9916
> URL: https://issues.apache.org/jira/browse/SOLR-9916
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Joel Bernstein
>
> One of the things that will be needed as the SQL implementation matures is 
> the ability to do arithmetic operations. For example:
> select (a+b) from x;
> select sum(a)+sum(b) from x;
> We will need to support arithmetic operations within the Streaming API to 
> support these types of operations.
> It looks like adding arithmetic operations to the SelectStream is the best 
> place to add this functionality.



--
This message was sent by Atlassian

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

2017-02-07 Thread ASF subversion and git services (JIRA)

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-6.x-Linux/2811/
Java: 32bit/jdk-9-ea+153 -client -XX:+UseParallelGC

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

Error Message:
Could not get expected value  'A val' for path 'params/a' full output: {   
"responseHeader":{ "status":0, "QTime":0},   "params":{"wt":"json"},   
"context":{ "webapp":"/solr", "path":"/dump1", 
"httpMethod":"GET"}},  from server:  
https://127.0.0.1:37764/solr/collection1_shard1_replica1

Stack Trace:
java.lang.AssertionError: Could not get expected value  'A val' for path 
'params/a' full output: {
  "responseHeader":{
"status":0,
"QTime":0},
  "params":{"wt":"json"},
  "context":{
"webapp":"/solr",
"path":"/dump1",
"httpMethod":"GET"}},  from server:  
https://127.0.0.1:37764/solr/collection1_shard1_replica1
at 
__randomizedtesting.SeedInfo.seed([4603498CA559E3E5:CE5776560BA58E1D]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.core.TestSolrConfigHandler.testForResponseElement(TestSolrConfigHandler.java:556)
at 
org.apache.solr.handler.TestReqParamsAPI.testReqParams(TestReqParamsAPI.java:152)
at 
org.apache.solr.handler.TestReqParamsAPI.test(TestReqParamsAPI.java:69)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:543)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1713)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:907)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:943)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:957)
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:368)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:916)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:802)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:852)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
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 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at

[jira] [Commented] (LUCENE-7638) Optimize graph query produced by QueryBuilder


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

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

Commit 5386116e9a3b54db4674b21e39a41cc4d43553f8 in lucene-solr's branch 
refs/heads/branch_6x from [~jim.ferenczi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5386116 ]

LUCENE-7638: Query parsers now analyze the token graph for articulation points 
(or cut vertices) in order to create more efficient queries for multi-token 
synonyms.


> Optimize graph query produced by QueryBuilder
> -
>
> Key: LUCENE-7638
> URL: https://issues.apache.org/jira/browse/LUCENE-7638
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
> Attachments: LUCENE-7638.patch, LUCENE-7638.patch
>
>
> The QueryBuilder creates a graph query when the underlying TokenStream 
> contains token with PositionLengthAttribute greater than 1.
> These TokenStreams are in fact graphs (lattice to be more precise) where 
> synonyms can span on multiple terms. 
> Currently the graph query is built by visiting all the path of the graph 
> TokenStream. For instance if you have a synonym like "ny, new york" and you 
> search for "new york city", the query builder would produce two pathes:
> "new york city", "ny city"
> This can quickly explode when the number of multi terms synonyms increase. 
> The query "ny ny" for instance would produce 4 pathes and so on.
> For boolean queries with should or must clauses it should be more efficient 
> to build a boolean query that merges all the intersections in the graph. So 
> instead of "new york city", "ny city" we could produce:
> "+((+new +york) ny) +city"
> The attached patch is a proposal to do that instead of the all path solution.
> The patch transforms multi terms synonyms in graph query for each 
> intersection in the graph. This is not done in this patch but we could also 
> create a specialized query that gives equivalent scores to multi terms 
> synonyms like the SynonymQuery does for single term synonyms.
> For phrase query this patch does not change the current behavior but we could 
> also use the new method to create optimized graph SpanQuery.
> [~mattweber] I think this patch could optimize a lot of cases where multiple 
> muli-terms synonyms are present in a single request. Could you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7680) Never cache term filters

2017-02-07 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-7680:


+1

> Never cache term filters
> 
>
> Key: LUCENE-7680
> URL: https://issues.apache.org/jira/browse/LUCENE-7680
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7680.patch
>
>
> Currently we just require term filters to be used a lot in order to cache 
> them. Maybe instead we should look into never caching them. This should not 
> hurt performance since term filters are plenty fast, and would make other 
> filters more likely to be cached since we would not "pollute" the history 
> with filters that are not worth caching.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

2017-02-07 Thread ASF subversion and git services (JIRA)


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

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

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

SOLR-5944: Use SolrCmdDistributor's synchronous mode for in-place updates


> Support updates of numeric DocValues
> 
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
>Assignee: Ishan Chattopadhyaya
> Attachments: defensive-checks.log.gz, 
> demo-why-dynamic-fields-cannot-be-inplace-updated-first-time.patch, 
> DUP.patch, hoss.62D328FA1DEA57FD.fail2.txt, hoss.62D328FA1DEA57FD.fail3.txt, 
> hoss.62D328FA1DEA57FD.fail.txt, hoss.D768DD9443A98DC.fail.txt, 
> hoss.D768DD9443A98DC.pass.txt, master-vs-5944-regular-updates.png, 
> regular-vs-dv-updates.png, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, 
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt, 
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be 
> really nice to have Solr support this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10079) TestInPlaceUpdatesDistrib failure

2017-02-07 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-10079:


Commit 6520d06ce763c885dc9479370a0cc26612229e46 in lucene-solr's branch 
refs/heads/master from [~ichattopadhyaya]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6520d06 ]

SOLR-10079: Test fix for TestInPlaceUpdatesDistrib, using clearIndex()


> TestInPlaceUpdatesDistrib failure
> -
>
> Key: SOLR-10079
> URL: https://issues.apache.org/jira/browse/SOLR-10079
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Steve Rowe
>Assignee: Ishan Chattopadhyaya
> Attachments: SOLR-10079.patch
>
>
> From [https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/18881/], 
> reproduces for me:
> {noformat}
> Checking out Revision d8d61ff61d1d798f5e3853ef66bc485d0d403f18 
> (refs/remotes/origin/master)
> [...]
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=TestInPlaceUpdatesDistrib -Dtests.method=test 
> -Dtests.seed=E1BB56269B8215B0 -Dtests.multiplier=3 -Dtests.slow=true 
> -Dtests.locale=sr-Latn-RS -Dtests.timezone=America/Grand_Turk 
> -Dtests.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 77.7s J2 | TestInPlaceUpdatesDistrib.test <<<
>[junit4]> Throwable #1: java.lang.AssertionError: Earlier: [79, 79, 
> 79], now: [78, 78, 78]
>[junit4]>  at 
> __randomizedtesting.SeedInfo.seed([E1BB56269B8215B0:69EF69FC357E7848]:0)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.ensureRtgWorksWithPartialUpdatesTest(TestInPlaceUpdatesDistrib.java:425)
>[junit4]>  at 
> org.apache.solr.update.TestInPlaceUpdatesDistrib.test(TestInPlaceUpdatesDistrib.java:142)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>[junit4]>  at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>[junit4]>  at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>[junit4]>  at 
> java.base/java.lang.reflect.Method.invoke(Method.java:543)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:985)
>[junit4]>  at 
> org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:960)
>[junit4]>  at java.base/java.lang.Thread.run(Thread.java:844)
> [...]
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): 
> {id_i=PostingsFormat(name=LuceneFixedGap), title_s=FSTOrd50, 
> id=PostingsFormat(name=Asserting), 
> id_field_copy_that_does_not_support_in_place_update_s=FSTOrd50}, 
> docValues:{inplace_updatable_float=DocValuesFormat(name=Asserting), 
> id_i=DocValuesFormat(name=Direct), _version_=DocValuesFormat(name=Asserting), 
> title_s=DocValuesFormat(name=Lucene70), id=DocValuesFormat(name=Lucene70), 
> id_field_copy_that_does_not_support_in_place_update_s=DocValuesFormat(name=Lucene70),
>  inplace_updatable_int_with_default=DocValuesFormat(name=Asserting), 
> inplace_updatable_int=DocValuesFormat(name=Direct), 
> inplace_updatable_float_with_default=DocValuesFormat(name=Direct)}, 
> maxPointsInLeafNode=1342, maxMBSortInHeap=6.368734895089348, 
> sim=RandomSimilarity(queryNorm=true): {}, locale=sr-Latn-RS, 
> timezone=America/Grand_Turk
>[junit4]   2> NOTE: Linux 4.4.0-53-generic i386/Oracle Corporation 9-ea 
> (32-bit)/cpus=12,threads=1,free=107734480,total=518979584
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647, cla

2017-02-07 Thread Mikhail Khludnev (JIRA)


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

Mikhail Khludnev commented on LUCENE-7674:
--

Oh.. I've got your point, guys. Thanks. I'd probably raise gsoc ticket and try 
to scratch backlog. 

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
> Attachments: LUCENE-7674.patch
>
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at 
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
> at 
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:119)
> at 
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:518)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:308)
>

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121


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

Uwe Schindler commented on LUCENE-7651:
---

We don't have access to recent paid only Java 7 JDKs, but as the Javadocs fix 
was declared a security issue, I assume that it is also applied to Java 7, so 
without this fix Java 7 paid updates will fail the build, too.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Fix For: 6.x, master (7.0), 6.5, 6.4.1
>
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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

Build: https://jenkins.thetaphi.de/job/Lucene-Solr-5.5-Linux/435/
Java: 32bit/jdk1.7.0_80 -client -XX:+UseG1GC

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

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

Stack Trace:
java.lang.AssertionError: ObjectTracker found 1 object(s) that were not 
released!!! [NRTCachingDirectory]
at __randomizedtesting.SeedInfo.seed([F4FA94D9435419C9]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:238)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java: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 11248 lines...]
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4]   2> Creating dataDir: 
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_F4FA94D9435419C9-001/init-core-data-001
   [junit4]   2> 746399 INFO  
(TEST-TestReplicationHandler.doTestIndexFetchOnMasterRestart-seed#[F4FA94D9435419C9])
 [] o.a.s.SolrTestCaseJ4 ###Starting doTestIndexFetchOnMasterRestart
   [junit4]   2> 746399 INFO  
(TEST-TestReplicationHandler.doTestIndexFetchOnMasterRestart-seed#[F4FA94D9435419C9])
 [] o.a.s.SolrTestCaseJ4 Writing core.properties file to 
/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_F4FA94D9435419C9-001/solr-instance-001/collection1
   [junit4]   2> 746402 INFO  
(TEST-TestReplicationHandler.doTestIndexFetchOnMasterRestart-seed#[F4FA94D9435419C9])
 [] o.e.j.s.Server jetty-9.2.13.v20150730
   [junit4]   2> 746403 INFO  
(TEST-TestReplicationHandler.doTestIndexFetchOnMasterRestart-seed#[F4FA94D9435419C9])
 [] o.e.j.s.h.ContextHandler Started 
o.e.j.s.ServletContextHandler@1a6fad7{/solr,null,AVAILABLE}
   [junit4]   2> 746403 INFO  
(TEST-TestReplicationHandler.doTestIndexFetchOnMasterRestart-seed#[F4FA94D9435419C9])
 [] o.e.j.s.ServerConnector Started 
ServerConnector@486d4a{HTTP/1.1}{127.0.0.1:35702}
   [junit4]   2> 746403 INFO  
(TEST-TestReplicationHandler.doTestIndexFetchOnMasterRestart-seed#[F4FA94D9435419C9])
 [] o.e.j.s.Server Started @747601ms
   [junit4]   2> 746403 INFO  
(TEST-TestReplicationHandler.doTestIndexFetchOnMasterRestart-seed#[F4FA94D9435419C9])
 [] o.a.s.c.s.e.JettySolrRunner Jetty properties: {hostContext=/solr, 
hostPort=35702, 
solr.data.dir=/home/jenkins/workspace/Lucene-Solr-5.5-Linux/solr/build/solr-core/test/J0/temp/solr.handler.TestReplicationHandler_F4FA94D9435419C9-001/solr-instance-001/collection1/data}

RE: Backport mmap to 5.5

2017-02-07 Thread Uwe Schindler

Hi Adrien,

 

I backported the MMAP stuff. Unfortunately we cannot run the tests with Java 9 
on Lucene 5, because we have many failing tests for other reasons (like 
RAMUsageTester). So this only fixes Java 9 unmapping. I tested it successfully, 
so all looks good. Most stuff was to add a missing method and convert lambdas 
to Java 7.

 

I also backported some other issues:

*   Update Groovy
*   Javadocs fixes for Java 8u121

 

The recent one is a bit tricky and still broken, but it no longer fails the 
build on recent Java 8 and possibly on paid (!!) Java 7 updates we have no 
access to! I sent a separate e-mail for discussion.

 

I may do some documentation/changes fixes, but otherwise I am fine to go.

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de  

eMail: u...@thetaphi.de

 

From: Adrien Grand [mailto:jpou...@gmail.com] 
Sent: Monday, February 6, 2017 2:44 PM
To: dev@lucene.apache.org
Subject: Re: Backport mmap to 5.5

 

Hi Uwe,

It works for me. Thanks for doing it.

 

Le lun. 6 févr. 2017 à 14:23, Uwe Schindler  > a écrit :

Hi,

I was talking on Saturday with Sanne Grinovero this weekend on FOSDEM. Because 
they have to support the current version of Hibernate Search for longer time 
including Java 9 support, they would like to have current Java 9 support 
backported to 5.5 and 5.3. I told him 5.3 is unlikely to get ever released, but 
he may apply the 5.5 patch to 5.3, too.

As the backport requires some Java 7 changes, I'd like to do this now. So give 
me one or 2 days!

OK?

Uwe
--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de

Fwd: MODERATE for dev@lucene.apache.org

2017-02-07 Thread aurelian rosca

I find this file that might help you:
http://mirrors.m247.ro/apache/lucene/solr/ref-guide/apache-solr-ref-guide-6.3.pdf
Take a look at the example from the 305 page from the above document
regarding the XML Query Parser.

-- Forwarded message --
From: 
Date: Tue, Feb 7, 2017 at 9:14 AM
Subject: MODERATE for dev@lucene.apache.org
To:
Cc: dev-allow-tc.1486451671.bcboogoaonllcdhocbdk-neeraj.kumar.ext=
bayer@lucene.apache.org



To approve:
   dev-accept-1486451671.89455.pghcjomnfnconlela...@lucene.apache.org
To reject:
   dev-reject-1486451671.89455.pghcjomnfnconlela...@lucene.apache.org
To give a reason to reject:
%%% Start comment
%%% End comment



-- Forwarded message --
From: Neeraj Kumar 
To: "'dev@lucene.apache.org'" 
Cc:
Date: Tue, 7 Feb 2017 07:13:57 +
Subject: Solr -Issue

Could you please tell me how to use spanNot query in solr.

exmaple: spanNot(spanNear((b,c),30,false),spanNear(a,d))





Mit freundlichen Grüßen / Best Regards

TCS Deutschland GmbH

i.V. Neeraj Kumar



TCS Deutschland GmbH

Contractpartner of Bayer Business Services GmbH

BBS-ITS-R/BCS



On behalf of

Bayer Business Services GmbH

51368 Leverkusen, Deutschland



Tel: +91-120-6163122 <+91%20120%20616%203122>

E-Mail: neeraj.kumar@bayer.com

Web: http://www.business-services.bayer.com



Geschäftsführung: Daniel Hartert, Vorsitzender   |   Wilhelm Oehlschläger,
Arbeitsdirektor

Vorsitzender des Aufsichtsrats: Johannes Dietsch

Sitz der Gesellschaft: Leverkusen   |   Amtsgericht Köln, HRB 49895

RE: [jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121

2017-02-07 Thread Uwe Schindler

Hi Adrien,

what do you think about this issue?
https://issues.apache.org/jira/browse/LUCENE-7651

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Uwe Schindler (JIRA) [mailto:j...@apache.org]
> Sent: Tuesday, February 7, 2017 11:44 AM
> To: dev@lucene.apache.org
> Subject: [jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8
> update 121
> 
> 
> [ https://issues.apache.org/jira/browse/LUCENE-
> 7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15855724#comment-15855724 ]
> 
> Uwe Schindler commented on LUCENE-7651:
> ---
> 
> I backported this change to Lucene 5.5.4, because otherwise we cannot run
> the build with Java 8 anymore. The problem is the following: Java 7's
> Javadocs do not add a "script.js" file to the Javadocs output, so this fix 
> injects
> the javadocs, but because a "script.js" is nowhere referenced in the HTML
> files, prettyprint is not loaded.
> 
> We have the following possibilities:
> - revert this backport commit, but it prevents smoketester from suceeding (as
> it checks also Java 8). It also makes it impossible to build the 5.5.4 release
> with Java 8
> - add more hacks to inject a script tag into the head element, but that's 
> really
> complicated as you have to do it in every HTML file!
> - ignore the fact that Javadocs do not code-prettyprint correctly anymore in
> Java 7. The Javadocs are fine, just the code exaples are no longer syntax
> highlighted.
> 
> I'd go for the third item. Any comments? If we go this route, I will add a
> comment to the Changelog that prettyprinting Javadocs is no longer working,
> if docs are build with Java 7.
> 
> > Javadocs build fails with Java 8 update 121
> > ---
> >
> > Key: LUCENE-7651
> > URL: https://issues.apache.org/jira/browse/LUCENE-7651
> > Project: Lucene - Core
> >  Issue Type: Bug
> >  Components: general/javadocs
> >Affects Versions: 6.4
> > Environment: Java 8 update 121
> >Reporter: Uwe Schindler
> >Assignee: Uwe Schindler
> >Priority: Critical
> >  Labels: Java8
> > Fix For: 6.x, master (7.0), 6.5, 6.4.1
> >
> > Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-
> 7651.patch, LUCENE-7651.patch
> >
> >
> > Oracle released the recent Java 8 security update (u121). The Jenkins builds
> fail with the following error while building the Javadocs:
> > {noformat}
> >   [javadoc] Constructing Javadoc information...
> >   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
> >   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
> >   [javadoc] 1 error
> > {noformat}
> > This is caused by the Javascript added to pretty-print code examples. We
> load this in the page footer "{{}}" parameter.
> > Surely, it will be posisble to simply add the mentioned argument, but this
> will break builds with earlier Java 8 versions.
> > This is nowhere documented, I haven't seen any documentation about this
> flag nowhere, so I assume this is a bug in Java. They can't change or add
> command line parameters in minor updates of Java 8. I will ask on the
> OpenJDK mailing lists if this is a bug (maybe accidentally backported from
> Java 9).
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org


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

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

2017-02-07 Thread Andreas Ravn (JIRA)


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

Andreas Ravn commented on SOLR-6246:


I'd also appreciate if this fix could be provided in 6.4.x. This bug is our 
critical impediment for a two-major-versions update.

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
>Assignee: Steve Rowe
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7651) Javadocs build fails with Java 8 update 121


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

Uwe Schindler commented on LUCENE-7651:
---

I backported this change to Lucene 5.5.4, because otherwise we cannot run the 
build with Java 8 anymore. The problem is the following: Java 7's Javadocs do 
not add a "script.js" file to the Javadocs output, so this fix injects the 
javadocs, but because a "script.js" is nowhere referenced in the HTML files, 
prettyprint is not loaded.

We have the following possibilities:
- revert this backport commit, but it prevents smoketester from suceeding (as 
it checks also Java 8). It also makes it impossible to build the 5.5.4 release 
with Java 8
- add more hacks to inject a script tag into the head element, but that's 
really complicated as you have to do it in every HTML file!
- ignore the fact that Javadocs do not code-prettyprint correctly anymore in 
Java 7. The Javadocs are fine, just the code exaples are no longer syntax 
highlighted.

I'd go for the third item. Any comments? If we go this route, I will add a 
comment to the Changelog that prettyprinting Javadocs is no longer working, if 
docs are build with Java 7.

> Javadocs build fails with Java 8 update 121
> ---
>
> Key: LUCENE-7651
> URL: https://issues.apache.org/jira/browse/LUCENE-7651
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/javadocs
>Affects Versions: 6.4
> Environment: Java 8 update 121
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>Priority: Critical
>  Labels: Java8
> Fix For: 6.x, master (7.0), 6.5, 6.4.1
>
> Attachments: LUCENE-7651.patch, LUCENE-7651.patch, LUCENE-7651.patch, 
> LUCENE-7651.patch
>
>
> Oracle released the recent Java 8 security update (u121). The Jenkins builds 
> fail with the following error while building the Javadocs:
> {noformat}
>   [javadoc] Constructing Javadoc information...
>   [javadoc] javadoc: error - Argument for -bottom contains JavaScript.
>   [javadoc] Use --allow-script-in-comments to allow use of JavaScript.
>   [javadoc] 1 error
> {noformat}
> This is caused by the Javascript added to pretty-print code examples. We load 
> this in the page footer "{{}}" parameter.
> Surely, it will be posisble to simply add the mentioned argument, but this 
> will break builds with earlier Java 8 versions.
> This is nowhere documented, I haven't seen any documentation about this flag 
> nowhere, so I assume this is a bug in Java. They can't change or add command 
> line parameters in minor updates of Java 8. I will ask on the OpenJDK mailing 
> lists if this is a bug (maybe accidentally backported from Java 9).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7680) Never cache term filters


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

Adrien Grand commented on LUCENE-7680:
--

For the record, this would still allow compound filters that wrap term filters 
to be cached (eg. a BooleanQuery or a ToParentBlockJoinQuery).

> Never cache term filters
> 
>
> Key: LUCENE-7680
> URL: https://issues.apache.org/jira/browse/LUCENE-7680
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7680.patch
>
>
> Currently we just require term filters to be used a lot in order to cache 
> them. Maybe instead we should look into never caching them. This should not 
> hurt performance since term filters are plenty fast, and would make other 
> filters more likely to be cached since we would not "pollute" the history 
> with filters that are not worth caching.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-10100) Hiding credentials from security.json when retrieving through /admin/zookeeper

2017-02-07 Thread Mano Kovacs (JIRA)


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

Mano Kovacs commented on SOLR-10100:


[~janhoy], thanks for point out the other jira. I am not completely sure the 
two jiras are the same. This jira is proposing to hide passwords in general, 
regardless of access level as general security hardening. I might not consider 
some use-cases when the administrator needs to access the password through the 
UI, so I looking forward for any suggestion.

> Hiding credentials from security.json when retrieving through /admin/zookeeper
> --
>
> Key: SOLR-10100
> URL: https://issues.apache.org/jira/browse/SOLR-10100
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: security
>Reporter: Mano Kovacs
>
> {{/admin/zookeeper}} API is currently exposing {{security.json}} as-is, which 
> can contain security credentials as well.
> Proposing a configurable list for hiding elements of {{security.json}} when 
> loaded through {{/admin/zookeeper}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7596) Update Groovy to 2.4.8 in build system


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

Uwe Schindler commented on LUCENE-7596:
---

I backported this to Lucene 5.5.4 to be able to run tests with Java 9.

> Update Groovy to 2.4.8 in build system
> --
>
> Key: LUCENE-7596
> URL: https://issues.apache.org/jira/browse/LUCENE-7596
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: 6.x, master (7.0), 5.5.4, 6.4
>
>
> The current version of Groovy used by several Ant components is incompatible 
> with Java 9 build 148+. We need to update to 2.4.8 once it is released: 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-December/010474.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7679) MemoryIndex.addField() ignores some FieldType settings


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

Alan Woodward updated LUCENE-7679:
--
Attachment: LUCENE-7679.patch

Here is a patch that re-organises how MemoryIndex builds its internal field 
Info structures.  If an IndexableField is passed to addField(), we re-use as 
many of its FieldType settings as possible.

I needed to make FieldInfo.setDocValuesType() public, but that brings it into 
line with .setPointDimensions() so I don't think it's too bad a change?

> MemoryIndex.addField() ignores some FieldType settings
> --
>
> Key: LUCENE-7679
> URL: https://issues.apache.org/jira/browse/LUCENE-7679
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Alan Woodward
> Attachments: LUCENE-7679.patch
>
>
> Spotted by a luwak user: https://github.com/flaxsearch/luwak/issues/135.  
> MemoryIndex never omits norms, which means that it can produce incorrect 
> scores.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7596) Update Groovy to 2.4.8 in build system


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

Uwe Schindler updated LUCENE-7596:
--
Fix Version/s: 5.5.4

> Update Groovy to 2.4.8 in build system
> --
>
> Key: LUCENE-7596
> URL: https://issues.apache.org/jira/browse/LUCENE-7596
> Project: Lucene - Core
>  Issue Type: Bug
>  Components: general/build
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: 6.x, master (7.0), 5.5.4, 6.4
>
>
> The current version of Groovy used by several Ant components is incompatible 
> with Java 9 build 148+. We need to update to 2.4.8 once it is released: 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-December/010474.html



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Updated] (LUCENE-7680) Never cache term filters


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

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

Here is a patch.

> Never cache term filters
> 
>
> Key: LUCENE-7680
> URL: https://issues.apache.org/jira/browse/LUCENE-7680
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-7680.patch
>
>
> Currently we just require term filters to be used a lot in order to cache 
> them. Maybe instead we should look into never caching them. This should not 
> hurt performance since term filters are plenty fast, and would make other 
> filters more likely to be cached since we would not "pollute" the history 
> with filters that are not worth caching.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-6989) Implement MMapDirectory unmapping for coming Java 9 changes


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

Uwe Schindler commented on LUCENE-6989:
---

I backported the MMap unmapper for Java 9 to the 5.5 branch. I had to do some 
changes:
- Add a pkgprivate static method for missing {{Objects.nonNull(...)}} to 
support Java 7
- Add workaround for a Java 7 bug (AssertionError inside JVM classes) regarding 
the {{noop()}} MH.
- Backport the test fixes
- Remove lambdas and method references

I also backported LUCENE-7596 (Groovy support so test infra works with Java 9).

> Implement MMapDirectory unmapping for coming Java 9 changes
> ---
>
> Key: LUCENE-6989
> URL: https://issues.apache.org/jira/browse/LUCENE-6989
> Project: Lucene - Core
>  Issue Type: Task
>  Components: core/store
>Reporter: Uwe Schindler
>Assignee: Uwe Schindler
>  Labels: Java9
> Fix For: 6.0, 5.5.4, 6.4
>
> Attachments: LUCENE-6989-disable5x.patch, 
> LUCENE-6989-disable5x.patch, LUCENE-6989-fixbuild148.patch, 
> LUCENE-6989.patch, LUCENE-6989.patch, LUCENE-6989.patch, LUCENE-6989.patch, 
> LUCENE-6989-v2.patch, LUCENE-6989-v3-post-b148.patch, 
> LUCENE-6989-v3-post-b148.patch, LUCENE-6989-v3-testFixes.patch
>
>
> Originally, the sun.misc.Cleaner interface was declared as "critical API" in 
> [JEP 260|http://openjdk.java.net/jeps/260 ]
> Unfortunately the decission was changed in favor of a oficially supported 
> {{java.lang.ref.Cleaner}} API. A side effect of this change is to move all 
> existing {{sun.misc.Cleaner}} APIs into a non-exported package. This causes 
> our forceful unmapping to no longer work, because we can get the cleaner 
> instance via reflection, but trying to invoke it will throw one of the new 
> Jigsaw RuntimeException because it is completely inaccessible. This will make 
> our forceful unmapping fail. There are also no changes in Garbage collector, 
> the problem still exists.
> For more information see this [mailing list 
> thread|http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/thread.html#38243].
> This commit will likely be done, making our unmapping efforts no longer 
> working. Alan Bateman is aware of this issue and will open a new issue at 
> OpenJDK to allow forceful unmapping without using the now private 
> sun.misc.Cleaner. The idea is to let the internal class sun.misc.Cleaner 
> implement the Runable interface, so we can simply cast to runable and call 
> the run() method to unmap. The code would then work. This will lead to minor 
> changes in our unmapper in MMapDirectory: An instanceof check and casting if 
> possible.
> I opened this issue to keep track and implement the changes as soon as 
> possible, so people will have working unmapping when java 9 comes out. 
> Current Lucene versions will no longer work with Java 9.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Created] (LUCENE-7680) Never cache term filters

Adrien Grand created LUCENE-7680:


 Summary: Never cache term filters
 Key: LUCENE-7680
 URL: https://issues.apache.org/jira/browse/LUCENE-7680
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Priority: Minor


Currently we just require term filters to be used a lot in order to cache them. 
Maybe instead we should look into never caching them. This should not hurt 
performance since term filters are plenty fast, and would make other filters 
more likely to be cached since we would not "pollute" the history with filters 
that are not worth caching.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Comment Edited] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647


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

Uwe Schindler edited comment on LUCENE-7674 at 2/7/17 10:30 AM:


I agree with Adrien. The current block join support in Solr is a desaster, 
because it was released to early. Just nuke the broken APIs and create a new 
one, so Solr internally knows from schema/mapping how to block join and also 
prevent misformed updates. This is also worth a backwards compatibility break! 
Doing expensive runtime checks on every query just to keep a broken 
API/implementation is not a good idea. Break hard and come with a better API, 
the users will still be more happy, trust me. I know so many users who f*ck up 
the block joins, as Solr does not enforce it correctly. Do the following:
- remove Solr ID fields from child documents (why do we have them? This also 
makes updates to child documents impossible)
- always hide child documents on "normal" queries and return them only with the 
parent document (like Elasticsearch does)
- automatically add block join queries if fields of the child documents are 
part of the query
- add some extra queries to specifically search on childs and return childs 
only (hiding parents, of course)
- if somebody updates a parent document, delete also all childs and create a 
new block
- hide the block join filter. Solr should have an internal marker field to 
support block join, which is never exposed


was (Author: thetaphi):
I agree with Adrien. The current block join support in Solr is a desaster, 
because it was released to early. Just nuke the broken APIs and create a new 
one, so Solr internally knows from schema/mapping how to block join and also 
prevent misformed updates. This is also worth a backwards compatibility break! 
Doing expensive runtime checks on every query just to keep a broken 
API/implementation is not a good idea. Break hard and come with a better API, 
the users will still be more happy, trust me. I know so many users who f*ck up 
the block joins, as Solr does not enforce it correctly. Do the following:
- remove Solr ID fields from child documents (why do we have them? This also 
makes updates to child documents impossible)
- always hide child documents on "normal" queries and return them only with the 
parent document (like Elasticsearch does)
- automatically add block join queries if fields of the child documents are 
part of the query
- add some extra queries to specifically search on childs and return childs 
only (hiding parents, of course)
- if somebody updates a parent document, delete also all childs and create a 
new block

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
> Attachments: LUCENE-7674.patch
>
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
>

[jira] [Created] (LUCENE-7679) MemoryIndex.addField() ignores some FieldType settings

Alan Woodward created LUCENE-7679:
-

 Summary: MemoryIndex.addField() ignores some FieldType settings
 Key: LUCENE-7679
 URL: https://issues.apache.org/jira/browse/LUCENE-7679
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Alan Woodward


Spotted by a luwak user: https://github.com/flaxsearch/luwak/issues/135.  
MemoryIndex never omits norms, which means that it can produce incorrect scores.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647, cla

2017-02-07 Thread ASF subversion and git services (JIRA)


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

Uwe Schindler commented on LUCENE-7674:
---

I agree with Adrien. The current block join support in Solr is a desaster, 
because it was released to early. Just nuke the broken APIs and create a new 
one, so Solr internally knows from schema/mapping how to block join and also 
prevent misformed updates. This is also worth a backwards compatibility break! 
Doing expensive runtime checks on every query just to keep a broken 
API/implementation is not a good idea. Break hard and come with a better API, 
the users will still be more happy, trust me. I know so many users who f*ck up 
the block joins, as Solr does not enforce it correctly. Do the following:
- remove Solr ID fields from child documents (why do we have them? This also 
makes updates to child documents impossible)
- always hide child documents on "normal" queries and return them only with the 
parent document (like Elasticsearch does)
- automatically add block join queries if fields of the child documents are 
part of the query
- add some extra queries to specifically search on childs and return childs 
only (hiding parents, of course)
- if somebody updates a parent document, delete also all childs and create a 
new block

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
> Attachments: LUCENE-7674.patch
>
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
>

[jira] [Commented] (LUCENE-7638) Optimize graph query produced by QueryBuilder


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

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

Commit e764d3e0590e998676a18f2b11364cecced4a8ad in lucene-solr's branch 
refs/heads/master from [~jim.ferenczi]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e764d3e ]

LUCENE-7638: Query parsers now analyze the token graph for articulation points 
(or cut vertices) in order to create more efficient queries for multi-token 
synonyms.


> Optimize graph query produced by QueryBuilder
> -
>
> Key: LUCENE-7638
> URL: https://issues.apache.org/jira/browse/LUCENE-7638
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Jim Ferenczi
> Attachments: LUCENE-7638.patch, LUCENE-7638.patch
>
>
> The QueryBuilder creates a graph query when the underlying TokenStream 
> contains token with PositionLengthAttribute greater than 1.
> These TokenStreams are in fact graphs (lattice to be more precise) where 
> synonyms can span on multiple terms. 
> Currently the graph query is built by visiting all the path of the graph 
> TokenStream. For instance if you have a synonym like "ny, new york" and you 
> search for "new york city", the query builder would produce two pathes:
> "new york city", "ny city"
> This can quickly explode when the number of multi terms synonyms increase. 
> The query "ny ny" for instance would produce 4 pathes and so on.
> For boolean queries with should or must clauses it should be more efficient 
> to build a boolean query that merges all the intersections in the graph. So 
> instead of "new york city", "ny city" we could produce:
> "+((+new +york) ny) +city"
> The attached patch is a proposal to do that instead of the all path solution.
> The patch transforms multi terms synonyms in graph query for each 
> intersection in the graph. This is not done in this patch but we could also 
> create a specialized query that gives equivalent scores to multi terms 
> synonyms like the SynonymQuery does for single term synonyms.
> For phrase query this patch does not change the current behavior but we could 
> also use the new method to create optimized graph SpanQuery.
> [~mattweber] I think this patch could optimize a lot of cases where multiple 
> muli-terms synonyms are present in a single request. Could you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (LUCENE-7674) java.lang.IllegalStateException: Child query must not match same docs with parent filter. Combine them as must clauses (+) to find a problem doc. docId=2147483647, cla


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

Adrien Grand commented on LUCENE-7674:
--

It feels wrong to me that we enforce these rules at search time, while they 
should be enforced at index time. I think the true fix to all these block join 
issues would be to make Solr know queries that describe the parent and child 
spaces rather than expect users to provide them at search time. Then once it 
knows that, it could reject update/delete operations that would break the block 
structure, fail queries that use a parent query that is not one of the expected 
ones, maybe add a FILTER clause to the child query to restrict it to the child 
space in case some fields are used at multiple levels, etc.

> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> 
>
> Key: LUCENE-7674
> URL: https://issues.apache.org/jira/browse/LUCENE-7674
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.3
>Reporter: Tim Underwood
> Attachments: LUCENE-7674.patch
>
>
> Started seeing this error message on a production Solr 6.3.0 system today 
> making use of parent/child documents:
> {code}
> java.lang.IllegalStateException: Child query must not match same docs with 
> parent filter. Combine them as must clauses (+) to find a problem doc. 
> docId=2147483647, class org.apache.lucene.search.ConjunctionScorer
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.checkOrthogonal(ToParentBlockJoinQuery.java:403)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.access$400(ToParentBlockJoinQuery.java:206)
> at 
> org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer$1.nextDoc(ToParentBlockJoinQuery.java:327)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:219)
> at 
> org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:172)
> at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:39)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:669)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:473)
> at 
> org.apache.solr.search.DocSetUtil.createDocSetGeneric(DocSetUtil.java:106)
> at org.apache.solr.search.DocSetUtil.createDocSet(DocSetUtil.java:95)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocSetNC(SolrIndexSearcher.java:1379)
> at 
> org.apache.solr.search.SolrIndexSearcher.getPositiveDocSet(SolrIndexSearcher.java:1057)
> at 
> org.apache.solr.search.SolrIndexSearcher.getProcessedFilter(SolrIndexSearcher.java:1227)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1842)
> at 
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1616)
> at 
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:617)
> at 
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:531)
> at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:295)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:153)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2213)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:303)
> at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:254)
> at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1668)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:581)
> at 
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at 
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1160)
> at 
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
> at 
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1092)
> at 
>

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

2017-02-07 Thread Apache Jenkins Server

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

No tests ran.

Build Log:
[...truncated 39769 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist
 [copy] Copying 461 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/lucene
 [copy] Copying 245 files to 
/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/solr
   [smoker] Java 1.7 JAVA_HOME=/home/jenkins/tools/java/latest1.7
   [smoker] Java 1.8 JAVA_HOME=/home/jenkins/tools/java/latest1.8
   [smoker] NOTE: output encoding is UTF-8
   [smoker] 
   [smoker] Load release URL 
"file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-5.5/lucene/build/smokeTestRelease/dist/"...
   [smoker] 
   [smoker] Test Lucene...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.01 sec (26.7 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download lucene-5.5.4-src.tgz...
   [smoker] 28.8 MB in 0.03 sec (863.2 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.4.tgz...
   [smoker] 63.5 MB in 0.07 sec (875.1 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download lucene-5.5.4.zip...
   [smoker] 73.9 MB in 0.09 sec (841.0 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack lucene-5.5.4.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.4.zip...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] test demo with 1.7...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] test demo with 1.8...
   [smoker]   got 6190 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] check Lucene's javadoc JAR
   [smoker]   unpack lucene-5.5.4-src.tgz...
   [smoker] make sure no JARs/WARs in src dist...
   [smoker] run "ant validate"
   [smoker] run tests w/ Java 7 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.7...
   [smoker]   got 220 hits for query "lucene"
   [smoker] checkindex with 1.7...
   [smoker] generate javadocs w/ Java 7...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker] run tests w/ Java 8 and testArgs='-Dtests.slow=false'...
   [smoker] test demo with 1.8...
   [smoker]   got 220 hits for query "lucene"
   [smoker] checkindex with 1.8...
   [smoker] generate javadocs w/ Java 8...
   [smoker] 
   [smoker] Crawl/parse...
   [smoker] 
   [smoker] Verify...
   [smoker]   confirm all releases have coverage in TestBackwardsCompatibility
   [smoker] find all past Lucene releases...
   [smoker] run TestBackwardsCompatibility..
   [smoker]   Backcompat testing not required for release 6.0.1 because 
it's not less than 5.5.4
   [smoker]   Backcompat testing not required for release 6.0.0 because 
it's not less than 5.5.4
   [smoker]   Backcompat testing not required for release 6.4.1 because 
it's not less than 5.5.4
   [smoker]   Backcompat testing not required for release 6.4.0 because 
it's not less than 5.5.4
   [smoker]   Backcompat testing not required for release 6.1.0 because 
it's not less than 5.5.4
   [smoker]   Backcompat testing not required for release 6.2.1 because 
it's not less than 5.5.4
   [smoker]   Backcompat testing not required for release 6.2.0 because 
it's not less than 5.5.4
   [smoker]   Backcompat testing not required for release 6.3.0 because 
it's not less than 5.5.4
   [smoker] success!
   [smoker] 
   [smoker] Test Solr...
   [smoker]   test basics...
   [smoker]   get KEYS
   [smoker] 0.2 MB in 0.00 sec (69.7 MB/sec)
   [smoker]   check changes HTML...
   [smoker]   download solr-5.5.4-src.tgz...
   [smoker] 37.7 MB in 0.05 sec (751.6 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.4.tgz...
   [smoker] 130.5 MB in 0.17 sec (767.7 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   download solr-5.5.4.zip...
   [smoker] 138.4 MB in 0.17 sec (814.4 MB/sec)
   [smoker] verify md5/sha1 digests
   [smoker]   unpack solr-5.5.4.tgz...
   [smoker] verify JAR metadata/identity/no javax.* or java.* classes...
   [smoker] unpack lucene-5.5.4.tgz...
   [smoker]   **WARNING**: skipping check of

[jira] [Comment Edited] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

2017-02-07 Thread jefferyyuan (JIRA)


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

jefferyyuan edited comment on SOLR-6246 at 2/7/17 9:34 AM:
---

Thanks [~steve_rowe]
I am wondering is there any plan to also fix this issue in 6.4.x version? 
This fix is so valuable, without this we can't really use 
AnalyzingInfixSuggester - as we always reload the collections to update schema 
or config etc.

And it takes time to release 6.5 - usually several(2 or 3) months.


was (Author: yuanyun.cn):
Thanks [~steve_rowe]
I am wondering is there any plan to also fix this issue in 6.4.x version? 
This fix is so valuable, without this we can't really use 
AnalyzingInfixSuggester - as we always reload the collections to update schema 
or config etc.

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
>Assignee: Steve Rowe
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-6246) Core fails to reload when AnalyzingInfixSuggester is used as a Suggester

2017-02-07 Thread jefferyyuan (JIRA)


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

jefferyyuan commented on SOLR-6246:
---

Thanks [~steve_rowe]
I am wondering is there any plan to also fix this issue in 6.4.x version? 
This fix is so valuable, without this we can't really use 
AnalyzingInfixSuggester - as we always reload the collections to update schema 
or config etc.

> Core fails to reload when AnalyzingInfixSuggester is used as a Suggester
> 
>
> Key: SOLR-6246
> URL: https://issues.apache.org/jira/browse/SOLR-6246
> Project: Solr
>  Issue Type: Sub-task
>  Components: SearchComponents - other
>Affects Versions: 4.8, 4.8.1, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4
>Reporter: Varun Thacker
>Assignee: Steve Rowe
> Fix For: 6.5, master (7.0)
>
> Attachments: SOLR-6246.patch, SOLR-6246.patch, SOLR-6246-test.patch, 
> SOLR-6246-test.patch, SOLR-6246-test.patch, SOLR-6246-test.patch
>
>
> LUCENE-5477 - added near-real-time suggest building to 
> AnalyzingInfixSuggester. One of the changes that went in was a writer is 
> persisted now to support real time updates via the add() and update() methods.
> When we call Solr's reload command, a new instance of AnalyzingInfixSuggester 
> is created. When trying to create a new writer on the same Directory a lock 
> cannot be obtained and Solr fails to reload the core.
> Also when AnalyzingInfixLookupFactory throws a RuntimeException we should 
> pass along the original message.
> I am not sure what should be the approach to fix it. Should we have a 
> reloadHook where we close the writer?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

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