[JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4897 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4897/ 1 tests failed. REGRESSION: org.apache.solr.SolrInfoMBeanTest.testCallMBeanInfo Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([1A0FF3F20E930EC1:E5697ECE65EB73DF]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.junit.Assert.assertNotNull(Assert.java:537) at org.apache.solr.SolrInfoMBeanTest.testCallMBeanInfo(SolrInfoMBeanTest.java:66) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 11295 lines...] [junit4] Suite: org.apache.solr.SolrInfoMBeanTest [junit4] 2> Creating dataDir: /usr/home/jenkins/jen
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.8.0_20) - Build # 11215 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11215/ Java: 64bit/jdk1.8.0_20 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.SolrInfoMBeanTest.testCallMBeanInfo Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([24540AD9C4EEAFD3:DB3287E5AF96D2CD]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.junit.Assert.assertNotNull(Assert.java:537) at org.apache.solr.SolrInfoMBeanTest.testCallMBeanInfo(SolrInfoMBeanTest.java:66) 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:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 11563 lines...] [junit4] Suite: org.apache.solr.SolrInfoMBeanT
[jira] [Commented] (LUCENE-5969) Add Lucene50Codec
[ https://issues.apache.org/jira/browse/LUCENE-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14156130#comment-14156130 ] ASF subversion and git services commented on LUCENE-5969: - Commit 1628889 from [~rcmuir] in branch 'dev/branches/lucene5969' [ https://svn.apache.org/r1628889 ] LUCENE-5969: start improving CFSDir > Add Lucene50Codec > - > > Key: LUCENE-5969 > URL: https://issues.apache.org/jira/browse/LUCENE-5969 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5969.patch, LUCENE-5969.patch > > > Spinoff from LUCENE-5952: > * Fix .si to write Version as 3 ints, not a String that requires parsing at > read time. > * Lucene42TermVectorsFormat should not use the same codecName as > Lucene41StoredFieldsFormat > It would also be nice if we had a "bumpCodecVersion" script so rolling a new > codec is not so daunting. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1225: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1225/ 2 tests failed. FAILED: org.apache.solr.cloud.HttpPartitionTest.org.apache.solr.cloud.HttpPartitionTest Error Message: 1 thread leaked from SUITE scope at org.apache.solr.cloud.HttpPartitionTest: 1) Thread[id=11871, name=Thread-3457, state=RUNNABLE, group=TGRP-HttpPartitionTest] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160) at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84) at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260) at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283) at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251) at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:271) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123) at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:682) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:486) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:466) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.cloud.ZkController.waitForLeaderToSeeDownState(ZkController.java:1607) at org.apache.solr.cloud.ZkController.registerAllCoresAsDown(ZkController.java:406) at org.apache.solr.cloud.ZkController.access$000(ZkController.java:93) at org.apache.solr.cloud.ZkController$1.command(ZkController.java:257) at org.apache.solr.common.cloud.ConnectionManager$1$1.run(ConnectionManager.java:166) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.cloud.HttpPartitionTest: 1) Thread[id=11871, name=Thread-3457, state=RUNNABLE, group=TGRP-HttpPartitionTest] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160) at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84) at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260) at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283) at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251) at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:271) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123) at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:682) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:486) at org.apache.http.impl.client.AbstractHttpClient.doEx
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_20) - Build # 11367 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11367/ Java: 32bit/jdk1.8.0_20 -client -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.solr.SolrInfoMBeanTest.testCallMBeanInfo Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([283937652F30A6B6:D75FBA594448DBA8]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.junit.Assert.assertNotNull(Assert.java:537) at org.apache.solr.SolrInfoMBeanTest.testCallMBeanInfo(SolrInfoMBeanTest.java:66) 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:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) Build Log: [...truncated 11439 lines...] [junit4] Suite: org.apache.solr.SolrInfoMBeanTest [junit4
[jira] [Assigned] (SOLR-6545) Query field list with wild card on dynamic field fails
[ https://issues.apache.org/jira/browse/SOLR-6545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-6545: --- Assignee: Shalin Shekhar Mangar > Query field list with wild card on dynamic field fails > -- > > Key: SOLR-6545 > URL: https://issues.apache.org/jira/browse/SOLR-6545 > Project: Solr > Issue Type: Bug >Affects Versions: 4.10 > Environment: Mac OS X 10.9.5, Ubuntu 14.04.1 LTS >Reporter: Burke Webster >Assignee: Shalin Shekhar Mangar >Priority: Critical > Attachments: SOLR-6545.patch > > > Downloaded 4.10.0, unpacked, and setup a solrcloud 2-node cluster by running: > bin/solr -e cloud > Accepting all the default options and you will have a 2 node cloud running > with replication factor of 2. > Now add 2 documents by going to example/exampledocs, creating the following > file named my_test.xml: > > > 1000 > test 1 > Text about test 1. > Category A > > > 1001 > test 2 > Stuff about test 2. > Category B > > > Then import these documents by running: > java -Durl=http://localhost:7574/solr/gettingstarted/update -jar post.jar > my_test.xml > Verify the docs are there by hitting: > http://localhost:8983/solr/gettingstarted/select?q=*:* > Now run a query and ask for only the id and cat_*_s fields: > http://localhost:8983/solr/gettingstarted/select?q=*:*&fl=id,cat_* > You will only get the id fields back. Change the query a little to include a > third field: > http://localhost:8983/solr/gettingstarted/select?q=*:*&fl=id,name,cat_* > You will now get the following exception: > java.lang.NullPointerException > at > org.apache.solr.handler.component.QueryComponent.returnFields(QueryComponent.java:1257) > at > org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:720) > at > org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:695) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:324) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1967) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) > at org.eclipse.jetty.server.Server.handle(Server.java:368) > at > org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) > at > org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) > at > org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942) > at > org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) > at > org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) > at > org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) > at > org.eclipse.jetty.util.thread.QueuedTh
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_20) - Build # 4246 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4246/ Java: 32bit/jdk1.8.0_20 -client -XX:+UseParallelGC 2 tests failed. REGRESSION: org.apache.solr.SolrInfoMBeanTest.testCallMBeanInfo Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([B1C053563717DE9:F47A8809080900F7]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.junit.Assert.assertNotNull(Assert.java:537) at org.apache.solr.SolrInfoMBeanTest.testCallMBeanInfo(SolrInfoMBeanTest.java:66) 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:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) REGRESSION: org.apache.solr.cloud.DeleteReplicaTest.testDistribSearch Error Message: No live SolrServers a
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.9.0-ea-b28) - Build # 11214 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11214/ Java: 32bit/jdk1.9.0-ea-b28 -server -XX:+UseG1GC 3 tests failed. REGRESSION: org.apache.solr.SolrInfoMBeanTest.testCallMBeanInfo Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([FAEFB82808F91341:589351463816E5F]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.junit.Assert.assertNotNull(Assert.java:537) at org.apache.solr.SolrInfoMBeanTest.testCallMBeanInfo(SolrInfoMBeanTest.java:66) 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:484) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) REGRESSION: org.apache.solr.cloud.CloudExitableDirectoryReaderTest.testDistribSearch Error Message: no excep
[jira] [Commented] (SOLR-6564) Fix failing ExitableDirectoryReader tests for Solr
[ https://issues.apache.org/jira/browse/SOLR-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155937#comment-14155937 ] Anshum Gupta commented on SOLR-6564: Still need to fix the Cloud version. The non-cloud version didn't fail for me over 50 runs after this fix (and with reduced doc count). > Fix failing ExitableDirectoryReader tests for Solr > -- > > Key: SOLR-6564 > URL: https://issues.apache.org/jira/browse/SOLR-6564 > Project: Solr > Issue Type: Test > Components: Tests >Reporter: Anshum Gupta >Assignee: Anshum Gupta > > ExitableDirectoryReader tests are failing as they enumerate over the terms in > less than 1ms (min timeAllowed value that case be set). Need to fix this. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6564) Fix failing ExitableDirectoryReader tests for Solr
[ https://issues.apache.org/jira/browse/SOLR-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155936#comment-14155936 ] ASF subversion and git services commented on SOLR-6564: --- Commit 1628873 from [~anshumg] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1628873 ] SOLR-6564: Fix failing ExitableDirectoryReader tests for Solr (Merge from trunk, r1628872) > Fix failing ExitableDirectoryReader tests for Solr > -- > > Key: SOLR-6564 > URL: https://issues.apache.org/jira/browse/SOLR-6564 > Project: Solr > Issue Type: Test > Components: Tests >Reporter: Anshum Gupta >Assignee: Anshum Gupta > > ExitableDirectoryReader tests are failing as they enumerate over the terms in > less than 1ms (min timeAllowed value that case be set). Need to fix this. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6564) Fix failing ExitableDirectoryReader tests for Solr
[ https://issues.apache.org/jira/browse/SOLR-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155921#comment-14155921 ] ASF subversion and git services commented on SOLR-6564: --- Commit 1628872 from [~anshumg] in branch 'dev/trunk' [ https://svn.apache.org/r1628872 ] SOLR-6564: Fix failing ExitableDirectoryReader tests for Solr > Fix failing ExitableDirectoryReader tests for Solr > -- > > Key: SOLR-6564 > URL: https://issues.apache.org/jira/browse/SOLR-6564 > Project: Solr > Issue Type: Test > Components: Tests >Reporter: Anshum Gupta >Assignee: Anshum Gupta > > ExitableDirectoryReader tests are failing as they enumerate over the terms in > less than 1ms (min timeAllowed value that case be set). Need to fix this. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Getting non-default tests to pass
On 9/30/2014 2:54 PM, Shawn Heisey wrote: > I'm running tests on branch_5x to see how things look for release, and > turning on additional tests (nightly, weekly, monster) ... a bunch of > Test2B tests are failing, apparently because the heap is too small. > I've been trying to figure out how to make it larger, haven't found it yet. > > What options are required to make sure that the test JVMs have the > resources required for these tests to complete properly? I got some help on the IRC dev channel on increasing the heap size. I'm trying now with -Dtests.heapsize=2g because 1g wasn't enough for them to pass. It's taking a really long time, I'm hoping that's because it's working, not because it's still too small. The machine where I'm running them also runs a number of actively updated Solr indexes that are far too large for the available OS disk cache (which has now been decreased by about 6GB -- three test JVMs at 2GB each), so that is probably contributing to performance issues. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr atomic updates: default values
: atomic updates. Here is the use-case I am looking at... I want to keep : track of the indexed-on date which is a snapshot in time of when that : particular document was indexed for the first time. Currently I have that : value stored and the value is set to "NOW" as the default value in the : schema. Now, I want to actually set this value in the update chain prior to : the distributed index request so all replicas obtain the exact same value. : Unfortunately there isn't a way to specify use this new "NOW" date *only* : if the value hasn't been indexed prior, so I was thinking that this can be There is actually, but it takes a little creative thinking... Assume you want this field to be named 'timestamp', then you want an update chain that looks something like this... timestamp_tmp timestamp_tmp timestamp timestamp timestamp_tmp ...so on every doc update, a "timestamp_tmp" field will be computed on the initial node, then during the DistributedUpdateProcessor, when the leader deals with merging in existing values if the doc update is an atomic update, you may get an existing (older) value in the "timestamp" field. then (on each replica) timestamp_tmp will be cloned into timestamp, and the minimum (ie: oldest) value will be used. at which point you can now ignore/remove timestamp_tmp from the documents. (disclaimer: doing this all from memory, haven't verified it works as is ... may be typos or logic ordering mistakes, but the basic gist should be sound) -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6249) Schema API changes return success before all cores are updated
[ https://issues.apache.org/jira/browse/SOLR-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter updated SOLR-6249: - Attachment: SOLR-6249_reconnect.patch Here's an additional patch that addresses the ZkIndexSchemaReader watcher reconnect issue discussed in the comments. [~noble.paul] please take a quick look. I know you recommended integrating this into ZkStateReader, but I did it in ZkController instead because on the server-side, ZkStateReader actually uses the OnReconnect implementation in ZkController. The basic idea here is that any component that sets up a watcher can register an OnReconnect listener with ZkController to be called after a reconnected Zk session; see the command method in ZkIndexSchemaReader for an example. If this looks acceptable to everyone watching, I'll commit and then backport to branch_5x > Schema API changes return success before all cores are updated > -- > > Key: SOLR-6249 > URL: https://issues.apache.org/jira/browse/SOLR-6249 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis, SolrCloud >Reporter: Gregory Chanan >Assignee: Timothy Potter > Attachments: SOLR-6249.patch, SOLR-6249.patch, SOLR-6249.patch, > SOLR-6249_reconnect.patch > > > See SOLR-6137 for more details. > The basic issue is that Schema API changes return success when the first core > is updated, but other cores asynchronously read the updated schema from > ZooKeeper. > So a client application could make a Schema API change and then index some > documents based on the new schema that may fail on other nodes. > Possible fixes: > 1) Make the Schema API calls synchronous > 2) Give the client some ability to track the state of the schema. They can > already do this to a certain extent by checking the Schema API on all the > replicas and verifying that the field has been added, though this is pretty > cumbersome. Maybe it makes more sense to do this sort of thing on the > collection level, i.e. Schema API changes return the zk version to the > client. We add an API to return the current zk version. On a replica, if > the zk version is >= the version the client has, the client knows that > replica has at least seen the schema change. We could also provide an API to > do the distribution and checking across the different replicas of the > collection so that clients don't need ot do that themselves. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5879) Add auto-prefix terms to block tree terms dict
[ https://issues.apache.org/jira/browse/LUCENE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155732#comment-14155732 ] Robert Muir commented on LUCENE-5879: - Patch looks good except for FixedBitSetTermsEnum. What is this doing? Can we remove it? I think its bogus how it does 'super(null)', its superclass should not even allow such a thing. > Add auto-prefix terms to block tree terms dict > -- > > Key: LUCENE-5879 > URL: https://issues.apache.org/jira/browse/LUCENE-5879 > Project: Lucene - Core > Issue Type: New Feature > Components: core/codecs >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch, > LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch, > LUCENE-5879.patch, LUCENE-5879.patch > > > This cool idea to generalize numeric/trie fields came from Adrien: > Today, when we index a numeric field (LongField, etc.) we pre-compute > (via NumericTokenStream) outside of indexer/codec which prefix terms > should be indexed. > But this can be inefficient: you set a static precisionStep, and > always add those prefix terms regardless of how the terms in the field > are actually distributed. Yet typically in real world applications > the terms have a non-random distribution. > So, it should be better if instead the terms dict decides where it > makes sense to insert prefix terms, based on how dense the terms are > in each region of term space. > This way we can speed up query time for both term (e.g. infix > suggester) and numeric ranges, and it should let us use less index > space and get faster range queries. > > This would also mean that min/maxTerm for a numeric field would now be > correct, vs today where the externally computed prefix terms are > placed after the full precision terms, causing hairy code like > NumericUtils.getMaxInt/Long. So optos like LUCENE-5860 become > feasible. > The terms dict can also do tricks not possible if you must live on top > of its APIs, e.g. to handle the adversary/over-constrained case when a > given prefix has too many terms following it but finer prefixes > have too few (what block tree calls "floor term blocks"). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5879) Add auto-prefix terms to block tree terms dict
[
https://issues.apache.org/jira/browse/LUCENE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155699#comment-14155699
]
Robert Muir commented on LUCENE-5879:
-
{quote}
One approach we might be able to take here is to more strongly
separate out the auto-prefix terms from the ordinary terms (e.g., so
they feel like two different fields, in the impl), such that intersect
becomes something like a merge between the postings format's "normal"
intersect, with these auto-prefix terms pulling from a shadow field.
If we did this then other postings formats could also more easily add
auto-prefix handling, and maybe even the default impl for
Terms.intersect could use auto-prefix terms ...
But we can try this later; this is a big enough change already.
{quote}
I agree it can be deferred, but I am worried if it gets dropped completely.
Here, in order to make this easy to use, the feature is "temporarily" placed in
fieldinfos with a warning.
However, this is kind of screwed up when its currently a blocktree impl detail,
and, well,
its kinda complicated stuff to implement (no offense!). Realistically, if in 3
months, blocktree is still
the only impl, how will people feel if I want to nuke this fieldinfo and
fieldtype?
Will they be -1 that i break spatial/solr/whatever starts using it (possibly
even their source code compile)?
Because I think the following situations are ok:
Result #1
* fieldinfo option (so its a "lucene feature" not a codec-specific feature)
* "generic" impl so that all codecs actually support said feature, like
everything else in fieldinfo
Result #2
* codec-specific option (so its just a blocktree option)
But the following is not an ok "permanent situation":
Result #3
* fieldinfo option (so it advertises as a "lucene feature", not a
codec-specific feature)
* however, only blocktree actually supports the option
* impossible to move on to next-gen termsdict because it doesnt support it
* impossible to remove from fieldinfo because e.g. .document
api/spatial/solr/old indexes/whatever rely upon it
How can we prevent this from happening?
> Add auto-prefix terms to block tree terms dict
> --
>
> Key: LUCENE-5879
> URL: https://issues.apache.org/jira/browse/LUCENE-5879
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/codecs
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, Trunk
>
> Attachments: LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch,
> LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch,
> LUCENE-5879.patch, LUCENE-5879.patch
>
>
> This cool idea to generalize numeric/trie fields came from Adrien:
> Today, when we index a numeric field (LongField, etc.) we pre-compute
> (via NumericTokenStream) outside of indexer/codec which prefix terms
> should be indexed.
> But this can be inefficient: you set a static precisionStep, and
> always add those prefix terms regardless of how the terms in the field
> are actually distributed. Yet typically in real world applications
> the terms have a non-random distribution.
> So, it should be better if instead the terms dict decides where it
> makes sense to insert prefix terms, based on how dense the terms are
> in each region of term space.
> This way we can speed up query time for both term (e.g. infix
> suggester) and numeric ranges, and it should let us use less index
> space and get faster range queries.
>
> This would also mean that min/maxTerm for a numeric field would now be
> correct, vs today where the externally computed prefix terms are
> placed after the full precision terms, causing hairy code like
> NumericUtils.getMaxInt/Long. So optos like LUCENE-5860 become
> feasible.
> The terms dict can also do tricks not possible if you must live on top
> of its APIs, e.g. to handle the adversary/over-constrained case when a
> given prefix has too many terms following it but finer prefixes
> have too few (what block tree calls "floor term blocks").
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5979) Use the cost API instead of a heuristic on the first document in FilteredQuery to decide on whether to use random access
[ https://issues.apache.org/jira/browse/LUCENE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155677#comment-14155677 ] Robert Muir commented on LUCENE-5979: - ok. > Use the cost API instead of a heuristic on the first document in > FilteredQuery to decide on whether to use random access > > > Key: LUCENE-5979 > URL: https://issues.apache.org/jira/browse/LUCENE-5979 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 5.0 > > Attachments: LUCENE-5979.patch > > > Now that some major filters such as TermsFilter and > MultiTermQueryWrapperFilter return DocIdSets that have a better cost, we > should switch to the cost API. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 1822 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1822/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. REGRESSION: org.apache.solr.TestDistributedSearch.testDistribSearch Error Message: Request took too long during query expansion. Terminating request. Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Request took too long during query expansion. Terminating request. at __randomizedtesting.SeedInfo.seed([2E3B19871D967C87:AFDD979F6AC91CBB]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:568) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.TestDistributedSearch.queryPartialResults(TestDistributedSearch.java:596) at org.apache.solr.TestDistributedSearch.doTest(TestDistributedSearch.java:499) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:875) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRul
Re: Solr atomic updates: default values
Quick clarification, when I say you can't sub-class the DistributedUpdateProcessor that is in the context of attempting to override the default merging functionality in the getUpdatedDocument method (which is package-private and not overridable from a solr-plugins classpath loader) but also code along the way uses the private constructor of the inner RequestReplicationTracker class which is required by a call to the SolrCmdDistributor. -Steve On Wed, Oct 1, 2014 at 5:51 PM, Steve Davids wrote: > I was curious if it would make sense to provide a "default" command for > atomic updates. Here is the use-case I am looking at... I want to keep > track of the indexed-on date which is a snapshot in time of when that > particular document was indexed for the first time. Currently I have that > value stored and the value is set to "NOW" as the default value in the > schema. Now, I want to actually set this value in the update chain prior to > the distributed index request so all replicas obtain the exact same value. > Unfortunately there isn't a way to specify use this new "NOW" date *only* > if the value hasn't been indexed prior, so I was thinking that this can be > simply handled by a "default" atomic update key that would only apply the > value if the document that is to being merged doesn't already have a value > specified. In addition to the validity of that thought, I was wondering if > people would find it beneficial to allow sub-classing of the > DistributedUpdateProcessorFactory (currently unable to due to inner > classes) or at a minimum allow clients to specify their own merge logic > implementation if they see fit. > > I would be happy to provide some patches if people think these are > reasonable use-cases. > > Thanks, > > -Steve >
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2146 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2146/ 1 tests failed. FAILED: org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.testDistribSearch Error Message: No live SolrServers available to handle this request:[https://127.0.0.1:21713/kpo/v, https://127.0.0.1:59147/kpo/v, https://127.0.0.1:33500/kpo/v] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[https://127.0.0.1:21713/kpo/v, https://127.0.0.1:59147/kpo/v, https://127.0.0.1:33500/kpo/v] at __randomizedtesting.SeedInfo.seed([ED47B979B672F53D:6CA13761C12D9501]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:322) at org.apache.solr.client.solrj.impl.CloudSolrServer.sendRequest(CloudSolrServer.java:880) at org.apache.solr.client.solrj.impl.CloudSolrServer.requestWithRetryOnStaleState(CloudSolrServer.java:658) at org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:601) at org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.removeAndWaitForLastReplicaGone(DeleteLastCustomShardedReplicaTest.java:117) at org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.doTest(DeleteLastCustomShardedReplicaTest.java:107) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.luce
[jira] [Created] (SOLR-6577) The ability to add or change arbitrary replica properties must not allow the system properties to be changed
Erick Erickson created SOLR-6577: Summary: The ability to add or change arbitrary replica properties must not allow the system properties to be changed Key: SOLR-6577 URL: https://issues.apache.org/jira/browse/SOLR-6577 Project: Solr Issue Type: Bug Reporter: Erick Erickson Assignee: Erick Erickson Just realized a...significant problem with the "arbitrary property" bit (SOLR-6512). The way I wrote it I can delete _any_ property at all, things like core node_name etc. And when you _do_ delete some of these, interesting things happen, like the cluster becomes unusable. Oops. I think the right thing to do here is to automatically add a "property" prefix to all of the arbitrary properties that a user tries to add or delete. I'll have a patch up tomorrow for this I hope. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Solr atomic updates: default values
I was curious if it would make sense to provide a "default" command for atomic updates. Here is the use-case I am looking at... I want to keep track of the indexed-on date which is a snapshot in time of when that particular document was indexed for the first time. Currently I have that value stored and the value is set to "NOW" as the default value in the schema. Now, I want to actually set this value in the update chain prior to the distributed index request so all replicas obtain the exact same value. Unfortunately there isn't a way to specify use this new "NOW" date *only* if the value hasn't been indexed prior, so I was thinking that this can be simply handled by a "default" atomic update key that would only apply the value if the document that is to being merged doesn't already have a value specified. In addition to the validity of that thought, I was wondering if people would find it beneficial to allow sub-classing of the DistributedUpdateProcessorFactory (currently unable to due to inner classes) or at a minimum allow clients to specify their own merge logic implementation if they see fit. I would be happy to provide some patches if people think these are reasonable use-cases. Thanks, -Steve
[jira] [Updated] (LUCENE-5984) Remove ChainedFilter
[ https://issues.apache.org/jira/browse/LUCENE-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-5984: - Attachment: LUCENE-5984.patch Here is the patch. > Remove ChainedFilter > > > Key: LUCENE-5984 > URL: https://issues.apache.org/jira/browse/LUCENE-5984 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > Attachments: LUCENE-5984.patch > > > I would like to suggest removing ChainedFilter. It is currently only used in > Solr's CurrencyField but could easily be replaced with a BooleanFilter and my > understanding of this filter is that it can generally be replaced with a > BooleanFilter. So let's drop it and suggest using BooleanFilter instead? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-5.x #720: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-5.x/720/ 1 tests failed. FAILED: org.apache.solr.cloud.DeleteReplicaTest.testDistribSearch Error Message: No live SolrServers available to handle this request:[http://127.0.0.1:10963/xpe/nf, http://127.0.0.1:45783/xpe/nf, http://127.0.0.1:51988/xpe/nf, http://127.0.0.1:42734/xpe/nf, http://127.0.0.1:39958/xpe/nf] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:10963/xpe/nf, http://127.0.0.1:45783/xpe/nf, http://127.0.0.1:51988/xpe/nf, http://127.0.0.1:42734/xpe/nf, http://127.0.0.1:39958/xpe/nf] at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:568) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.doRequest(LBHttpSolrServer.java:343) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:304) at org.apache.solr.client.solrj.impl.CloudSolrServer.sendRequest(CloudSolrServer.java:880) at org.apache.solr.client.solrj.impl.CloudSolrServer.requestWithRetryOnStaleState(CloudSolrServer.java:658) at org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:601) at org.apache.solr.cloud.DeleteReplicaTest.removeAndWaitForReplicaGone(DeleteReplicaTest.java:171) at org.apache.solr.cloud.DeleteReplicaTest.deleteLiveReplicaTest(DeleteReplicaTest.java:144) at org.apache.solr.cloud.DeleteReplicaTest.doTest(DeleteReplicaTest.java:88) Build Log: [...truncated 52993 lines...] BUILD FAILED /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:547: The following error occurred while executing this line: /usr/home/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-5.x/build.xml:199: The following error occurred while executing this line: : Java returned: 1 Total time: 217 minutes 26 seconds Build step 'Invoke Ant' marked build as failure Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5979) Use the cost API instead of a heuristic on the first document in FilteredQuery to decide on whether to use random access
[ https://issues.apache.org/jira/browse/LUCENE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155466#comment-14155466 ] Adrien Grand commented on LUCENE-5979: -- bq. I just am worried about 'crappy' implementations though, like FixedBitSet. Must that one really implement DocIDSet? LUCENE-5938 makes sure to not use FixedBitSet when the doc ids to store are sparse. I think the only last bad guys are ChainedFilter (which I proposed to remove) and BooleanFilter (that could be fixed). So I don't think this should be a blocker for this issue? > Use the cost API instead of a heuristic on the first document in > FilteredQuery to decide on whether to use random access > > > Key: LUCENE-5979 > URL: https://issues.apache.org/jira/browse/LUCENE-5979 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 5.0 > > Attachments: LUCENE-5979.patch > > > Now that some major filters such as TermsFilter and > MultiTermQueryWrapperFilter return DocIdSets that have a better cost, we > should switch to the cost API. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6476) Create a bulk mode for schema API
[
https://issues.apache.org/jira/browse/SOLR-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155458#comment-14155458
]
Mark Miller commented on SOLR-6476:
---
+1. If measuring elapsed time, please use nanoTime and not currentTimeMillis.
> Create a bulk mode for schema API
> -
>
> Key: SOLR-6476
> URL: https://issues.apache.org/jira/browse/SOLR-6476
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: managedResource
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch
>
>
> The current schema API does one operation at a time and the normal usecase is
> that users add multiple fields/fieldtypes/copyFields etc in one shot.
> example
> {code:javascript}
> curl http://localhost:8983/solr/collection1/schema -H
> 'Content-type:application/json' -d '{
> "add-field": {
> "name":"sell-by",
> "type":"tdate",
> "stored":true
> },
> "add-field":{
> "name":"catchall",
> "type":"text_general",
> "stored":false
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6476) Create a bulk mode for schema API
[
https://issues.apache.org/jira/browse/SOLR-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155455#comment-14155455
]
Ramkumar Aiyengar commented on SOLR-6476:
-
bq. actually System.currentTimeMillis() is fine if used in the same thread .
And if it is used in different threads it can give wrong values.
It's nothing to do with the number of threads. currentTimeMillis uses the wall
time and is not guaranteed to be monotonic. So if the sysadmin or ntp for
example changes time (or horror, if your system time uses local time and you
cross a DST transition), the difference in value between two measurements is
not guaranteed to reflect the actual duration of time. So in this case for
example you might end up violating the timeout altogether. nanoTime essentially
exposes a counter which keeps increasing, so while it has no bearing on the
system time (so a value by itself is meaningless), differences are guaranteed
to be accurate. (Well, as long as the platform supports it, which is almost
everywhere except for some random old versions of Windows).
> Create a bulk mode for schema API
> -
>
> Key: SOLR-6476
> URL: https://issues.apache.org/jira/browse/SOLR-6476
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: managedResource
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch
>
>
> The current schema API does one operation at a time and the normal usecase is
> that users add multiple fields/fieldtypes/copyFields etc in one shot.
> example
> {code:javascript}
> curl http://localhost:8983/solr/collection1/schema -H
> 'Content-type:application/json' -d '{
> "add-field": {
> "name":"sell-by",
> "type":"tdate",
> "stored":true
> },
> "add-field":{
> "name":"catchall",
> "type":"text_general",
> "stored":false
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6576) ModifiableSolrParams#add(SolrParams) is performing a set operation instead of an add
[
https://issues.apache.org/jira/browse/SOLR-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155314#comment-14155314
]
Steve Davids commented on SOLR-6576:
Oops, I glanced at the code too fast last night and saw the suppress deprecated
warning:
{code}
@SuppressWarnings({"deprecation"})
public static SolrParams wrapAppended(SolrParams params, SolrParams defaults) {
{code}
which I mistook as @deprecated for some reason, my bad.
> ModifiableSolrParams#add(SolrParams) is performing a set operation instead of
> an add
>
>
> Key: SOLR-6576
> URL: https://issues.apache.org/jira/browse/SOLR-6576
> Project: Solr
> Issue Type: Bug
>Reporter: Steve Davids
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6576.patch
>
>
> Came across this bug by attempting to append multiple ModifiableSolrParam
> objects together but found the last one was clobbering the previously set
> values. The add operation should append the values to the previously defined
> values, not perform a set operation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: how to do auto suggestion using apache lucene?
Thanks, It is a part of the whole series of the overlapping projects to make Solr documentation easier to navigate and search at solr-start.com. Regards, Alex,. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 On 1 October 2014 12:18, david.w.smi...@gmail.com wrote: > > On Wed, Oct 1, 2014 at 9:19 AM, Alexandre Rafalovitch > wrote: >> >> https://github.com/arafalov/Solr-Javadoc/tree/master/SearchServer > > > Pretty cool, Alex! > > ~ David Smiley > Freelance Apache Lucene/Solr Search Consultant/Developer > http://www.linkedin.com/in/davidwsmiley - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6517) CollectionsAPI call ELECTPREFERREDLEADERS
[ https://issues.apache.org/jira/browse/SOLR-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155277#comment-14155277 ] Noble Paul commented on SOLR-6517: -- bq.ecause I feel it's an unnecessary complexity that doesn't add enough value to justify doing it now Actually it is much simpler. If you look at the overseer roles implementation , you can figure it has not added any complexity > CollectionsAPI call ELECTPREFERREDLEADERS > - > > Key: SOLR-6517 > URL: https://issues.apache.org/jira/browse/SOLR-6517 > Project: Solr > Issue Type: New Feature >Affects Versions: 5.0, Trunk >Reporter: Erick Erickson >Assignee: Erick Erickson > > Perhaps the final piece of SOLR-6491. Once the preferred leadership roles are > assigned, there has to be a command "make it so Mr. Solr". This is something > of a placeholder to collect ideas. One wouldn't want to flood the system with > hundreds of re-assignments at once. Should this be synchronous or asnych? > Should it make the best attempt but not worry about perfection? Should it??? > a collection=name parameter would be required and it would re-elect all the > leaders that were on the 'wrong' node > I'm thinking an optionally allowing one to specify a shard in the case where > you wanted to make a very specific change. Note that there's no need to > specify a particular replica, since there should be only a single > preferredLeader per slice. > This command would do nothing to any slice that did not have a replica with a > preferredLeader role. Likewise it would do nothing if the slice in question > already had the leader role assigned to the node with the preferredLeader > role. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6513) Add a collectionsAPI call BALANCESLICEUNIQUE
[ https://issues.apache.org/jira/browse/SOLR-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155271#comment-14155271 ] Erick Erickson commented on SOLR-6513: -- By assigning the property, the cluster will tend toward the desired configuration without _any_ "reassign leader now" command simply because each node with the property will put itself at the head of the list for leader election. So having an auto-assignment that does this is an easy way to set up a cluster that stays balanced "well enough most of the time". Then the "reassign leaders now" command can be used when the system gets out of whack. It's _really_ tedious to assign, say, 100+ shards manually ;). Additionally, (see the discussion at SOLR-6491) consider a heterogeneous network of machines of varying capacities hosting many collections. Building a tool to auto-rebalance them all is a R&D project ;). Absent that, having a preferred leader property that can be assigned allows the operators to incorporate their knowledge of the hardware, loads (i.e. one collection may be much hotter than others) etc. Given the need for manual assignment, using the same mechanism for optionally assigning the property automatically is actually somewhat simpler overall, at least to me. > Add a collectionsAPI call BALANCESLICEUNIQUE > > > Key: SOLR-6513 > URL: https://issues.apache.org/jira/browse/SOLR-6513 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-6513.patch > > > Another sub-task for SOLR-6491. The ability to assign a property on a > node-by-node basis is nice, but tedious to get right for a sysadmin, > especially if there are, say, 100s of nodes hosting a system. This JIRA would > essentially provide an automatic mechanism for assigning a property. This > particular command simply changes the cluster state, it doesn't do anything > like re-assign functions. > My idea for this version is fairly limited. You'd have to specify a > collection and there would be no attempt to, say, evenly distribute the > preferred leader role/property for this collection by looking at _other_ > collections. Or by looking at underlying hardware capabilities. Or > It would be a pretty simple round-robin assignment. About the only > intelligence built in would be to change as few roles/properties as possible. > Let's say that the correct number of nodes for this role turned out to be 3. > Any node currently having 3 properties for this collection would NOT be > changed. Any node having 2 properties would have one added that would be > taken from some node with > 3 properties like this. > This probably needs an optional parameter, something like > "includeInactiveNodes=true|false" > Since this is an arbitrary property, one must specify sliceUnique=true. So > for the "preferredLeader" functionality, one would specify something like: > action=BALANCESLICEUNIQUE&property=preferredLeader&proprety.value=true. > There are checks in this code that require the preferredLeader to have a t/f > value and require that sliceUnique bet true. That said, this can be called on > an arbitrary property that has only one such property per slice. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6517) CollectionsAPI call ELECTPREFERREDLEADERS
[ https://issues.apache.org/jira/browse/SOLR-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155266#comment-14155266 ] Erick Erickson commented on SOLR-6517: -- bq: I am asking why don't we push the option to a request param and the users get the power of choosing multilple preferred leaders and if one shard goes down the other can clearly take up the that role Because I feel it's an unnecessary complexity that doesn't add enough value to justify doing it now. Leadership election will still occur if the preferred leader is down, just as it does not. Additionally auto-assigning the property becomes harder if multiples are allowed. > CollectionsAPI call ELECTPREFERREDLEADERS > - > > Key: SOLR-6517 > URL: https://issues.apache.org/jira/browse/SOLR-6517 > Project: Solr > Issue Type: New Feature >Affects Versions: 5.0, Trunk >Reporter: Erick Erickson >Assignee: Erick Erickson > > Perhaps the final piece of SOLR-6491. Once the preferred leadership roles are > assigned, there has to be a command "make it so Mr. Solr". This is something > of a placeholder to collect ideas. One wouldn't want to flood the system with > hundreds of re-assignments at once. Should this be synchronous or asnych? > Should it make the best attempt but not worry about perfection? Should it??? > a collection=name parameter would be required and it would re-elect all the > leaders that were on the 'wrong' node > I'm thinking an optionally allowing one to specify a shard in the case where > you wanted to make a very specific change. Note that there's no need to > specify a particular replica, since there should be only a single > preferredLeader per slice. > This command would do nothing to any slice that did not have a replica with a > preferredLeader role. Likewise it would do nothing if the slice in question > already had the leader role assigned to the node with the preferredLeader > role. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6512) Add a collections API call to add/delete arbitrary properties to a specific replica
[ https://issues.apache.org/jira/browse/SOLR-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-6512. -- Resolution: Fixed Fix Version/s: Trunk 5.0 I'll be adding to the ref guide momentarily. > Add a collections API call to add/delete arbitrary properties to a specific > replica > --- > > Key: SOLR-6512 > URL: https://issues.apache.org/jira/browse/SOLR-6512 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson > Fix For: 5.0, Trunk > > Attachments: SOLR-6512.patch, SOLR-6512.patch, SOLR-6512.patch, > SOLR-6512.patch > > > This is a sub-task for SOLR-6491, but seems generally useful. > Since this is in support of the "preferredLeader" functionality, I've run > into some considerations that I wanted some feedback on how to handle. > "preferredLeader" has the restriction that there should only be one per > slice, so setting this for a particular node means removing the property for > all the other replicas on the slice. Not a problem to do, my question is more > whether this is something reasonable to enforce on an arbitrary property > based on what that property is? Perfectly do-able, but "semantically > challenged". Currently, this is never a node with "preferedLeader" set to > "false", it is forcibly removed from other nodes in the slice when this > property is assigned. > The problem here is that there's nothing about assigning an arbitrary > property to a node that would reasonably imply this kind of behavior. One > could always control this with secondary flags on the command, e.g. > "shardExclusive=true|false" for instance, perhaps with safety checks in for > known one-per-shard properties like "preferredLeader". > "preferredLeader" seems to fit more naturally into a "role", but currently > ADDROLE and DELTEROLE have nothing to do with the notion of setting a role > for a particular node relative to a collection/shard. Easy enough to add, but > enforcing the "only one node per slice may have this role" rule there is > similarly arbitrary and overloads the ADDROLE/DELETEROLE in a way that seems > equally confusing. Plus, checking whether the required collection/shard/node > params are present becomes based on the value of the property being set, > which is all equally arbitrary. > The other interesting thing is that setting an arbitrary property on a node > would allow one to mess things up royally by, say, changing properties like > "core", or "base_url" or node_name at will. Actually this is potentially > useful, but very, very dangerous and I'm not particularly interested in > supporting it ;). I suppose we could require a prefix, say the only settable > properties are "property.whatever". > We could also add something specific to nodes, something like > ADDREPLICAROLE/DELETEREPLICAROLE, perhaps with sub-params like > "onlyOneAllowedPerShard", but this gets messy and relies on the users "doing > the right thing". I prefer enforcing rules like this based on the role I > think. Or at least enforcing these kinds of requirements on the > "preferredLeader" role if we go that way. > What are people's thoughts here? I think I'm tending towards the > ADDREPLICAROLE/DELETEREPLICAROLE way of doing this, but it's not set in > stone. I have code locally for arbitrary properties that I can modify for the > role bits. > So, if I'm going to summarize the points I'd like feedback on: > 1> Is setting arbitrary properties on a node desirable? If so, should we > require a prefix like "property" to prevent resetting values SolrCloud > depends on? > 2> Is it better to piggyback on ADDROLE/DELETEROLE? Personally I'm not in > favor of this one. Too messy with requiring additional parameters to work > right in this case > 3> Is the best option to create new collections API calls for > ADDREPLICAROLE/DELETEREPLICAROLE that > 3.1> require collection/slice/node parameters > 3.2> enforces the "onlyOnePerShard" rule for certain known roles > 3.3 v1> allows users to specify arbitrary roles something like > "onlyOnePerShard" as an optional T|F parameter, otherwise is totally open. > -or- > 3.3 v2> No support other than "preferredLeader", only roles that are > pre-defined are allowed, in which case the "onlyOnePerShard" is implicit in > the role. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6512) Add a collections API call to add/delete arbitrary properties to a specific replica
[ https://issues.apache.org/jira/browse/SOLR-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155247#comment-14155247 ] ASF subversion and git services commented on SOLR-6512: --- Commit 1628802 from [~erickoerickson] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1628802 ] SOLR-6512: Add a collections API call to add/delete arbitrary properties to a specific replica > Add a collections API call to add/delete arbitrary properties to a specific > replica > --- > > Key: SOLR-6512 > URL: https://issues.apache.org/jira/browse/SOLR-6512 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-6512.patch, SOLR-6512.patch, SOLR-6512.patch, > SOLR-6512.patch > > > This is a sub-task for SOLR-6491, but seems generally useful. > Since this is in support of the "preferredLeader" functionality, I've run > into some considerations that I wanted some feedback on how to handle. > "preferredLeader" has the restriction that there should only be one per > slice, so setting this for a particular node means removing the property for > all the other replicas on the slice. Not a problem to do, my question is more > whether this is something reasonable to enforce on an arbitrary property > based on what that property is? Perfectly do-able, but "semantically > challenged". Currently, this is never a node with "preferedLeader" set to > "false", it is forcibly removed from other nodes in the slice when this > property is assigned. > The problem here is that there's nothing about assigning an arbitrary > property to a node that would reasonably imply this kind of behavior. One > could always control this with secondary flags on the command, e.g. > "shardExclusive=true|false" for instance, perhaps with safety checks in for > known one-per-shard properties like "preferredLeader". > "preferredLeader" seems to fit more naturally into a "role", but currently > ADDROLE and DELTEROLE have nothing to do with the notion of setting a role > for a particular node relative to a collection/shard. Easy enough to add, but > enforcing the "only one node per slice may have this role" rule there is > similarly arbitrary and overloads the ADDROLE/DELETEROLE in a way that seems > equally confusing. Plus, checking whether the required collection/shard/node > params are present becomes based on the value of the property being set, > which is all equally arbitrary. > The other interesting thing is that setting an arbitrary property on a node > would allow one to mess things up royally by, say, changing properties like > "core", or "base_url" or node_name at will. Actually this is potentially > useful, but very, very dangerous and I'm not particularly interested in > supporting it ;). I suppose we could require a prefix, say the only settable > properties are "property.whatever". > We could also add something specific to nodes, something like > ADDREPLICAROLE/DELETEREPLICAROLE, perhaps with sub-params like > "onlyOneAllowedPerShard", but this gets messy and relies on the users "doing > the right thing". I prefer enforcing rules like this based on the role I > think. Or at least enforcing these kinds of requirements on the > "preferredLeader" role if we go that way. > What are people's thoughts here? I think I'm tending towards the > ADDREPLICAROLE/DELETEREPLICAROLE way of doing this, but it's not set in > stone. I have code locally for arbitrary properties that I can modify for the > role bits. > So, if I'm going to summarize the points I'd like feedback on: > 1> Is setting arbitrary properties on a node desirable? If so, should we > require a prefix like "property" to prevent resetting values SolrCloud > depends on? > 2> Is it better to piggyback on ADDROLE/DELETEROLE? Personally I'm not in > favor of this one. Too messy with requiring additional parameters to work > right in this case > 3> Is the best option to create new collections API calls for > ADDREPLICAROLE/DELETEREPLICAROLE that > 3.1> require collection/slice/node parameters > 3.2> enforces the "onlyOnePerShard" rule for certain known roles > 3.3 v1> allows users to specify arbitrary roles something like > "onlyOnePerShard" as an optional T|F parameter, otherwise is totally open. > -or- > 3.3 v2> No support other than "preferredLeader", only roles that are > pre-defined are allowed, in which case the "onlyOnePerShard" is implicit in > the role. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5879) Add auto-prefix terms to block tree terms dict
[ https://issues.apache.org/jira/browse/LUCENE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155245#comment-14155245 ] Michael McCandless commented on LUCENE-5879: bq. But the problem is, at search time, there's tricky logic in intersect() to use these prefix terms ... One approach we might be able to take here is to more strongly separate out the auto-prefix terms from the ordinary terms (e.g., so they feel like two different fields, in the impl), such that intersect becomes something like a merge between the postings format's "normal" intersect, with these auto-prefix terms pulling from a shadow field. If we did this then other postings formats could also more easily add auto-prefix handling, and maybe even the default impl for Terms.intersect could use auto-prefix terms ... But we can try this later; this is a big enough change already. > Add auto-prefix terms to block tree terms dict > -- > > Key: LUCENE-5879 > URL: https://issues.apache.org/jira/browse/LUCENE-5879 > Project: Lucene - Core > Issue Type: New Feature > Components: core/codecs >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch, > LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch, > LUCENE-5879.patch, LUCENE-5879.patch > > > This cool idea to generalize numeric/trie fields came from Adrien: > Today, when we index a numeric field (LongField, etc.) we pre-compute > (via NumericTokenStream) outside of indexer/codec which prefix terms > should be indexed. > But this can be inefficient: you set a static precisionStep, and > always add those prefix terms regardless of how the terms in the field > are actually distributed. Yet typically in real world applications > the terms have a non-random distribution. > So, it should be better if instead the terms dict decides where it > makes sense to insert prefix terms, based on how dense the terms are > in each region of term space. > This way we can speed up query time for both term (e.g. infix > suggester) and numeric ranges, and it should let us use less index > space and get faster range queries. > > This would also mean that min/maxTerm for a numeric field would now be > correct, vs today where the externally computed prefix terms are > placed after the full precision terms, causing hairy code like > NumericUtils.getMaxInt/Long. So optos like LUCENE-5860 become > feasible. > The terms dict can also do tricks not possible if you must live on top > of its APIs, e.g. to handle the adversary/over-constrained case when a > given prefix has too many terms following it but finer prefixes > have too few (what block tree calls "floor term blocks"). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5879) Add auto-prefix terms to block tree terms dict
[ https://issues.apache.org/jira/browse/LUCENE-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5879: --- Attachment: LUCENE-5879.patch New patch, enhancing CheckIndex to test term ranges of varying sizes (number of terms). This uncovered back compat bug in the patch, now fixed. This isn't guaranteed to touch all auto-prefix terms but it should touch most. Net/net I think we should commit what we have here now, and get jenkins testing it. The new FieldType option is marked experimental (and has warnings in the javadocs) ... there are many things still to explore, and we need to sort out the migration from NumericField, but I think it's important to get this starting point to where users can try it out and then we iterate from there. Tests pass, precommit passes. I plan to commit soon... > Add auto-prefix terms to block tree terms dict > -- > > Key: LUCENE-5879 > URL: https://issues.apache.org/jira/browse/LUCENE-5879 > Project: Lucene - Core > Issue Type: New Feature > Components: core/codecs >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch, > LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch, LUCENE-5879.patch, > LUCENE-5879.patch, LUCENE-5879.patch > > > This cool idea to generalize numeric/trie fields came from Adrien: > Today, when we index a numeric field (LongField, etc.) we pre-compute > (via NumericTokenStream) outside of indexer/codec which prefix terms > should be indexed. > But this can be inefficient: you set a static precisionStep, and > always add those prefix terms regardless of how the terms in the field > are actually distributed. Yet typically in real world applications > the terms have a non-random distribution. > So, it should be better if instead the terms dict decides where it > makes sense to insert prefix terms, based on how dense the terms are > in each region of term space. > This way we can speed up query time for both term (e.g. infix > suggester) and numeric ranges, and it should let us use less index > space and get faster range queries. > > This would also mean that min/maxTerm for a numeric field would now be > correct, vs today where the externally computed prefix terms are > placed after the full precision terms, causing hairy code like > NumericUtils.getMaxInt/Long. So optos like LUCENE-5860 become > feasible. > The terms dict can also do tricks not possible if you must live on top > of its APIs, e.g. to handle the adversary/over-constrained case when a > given prefix has too many terms following it but finer prefixes > have too few (what block tree calls "floor term blocks"). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_20) - Build # 11364 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/11364/ Java: 32bit/jdk1.8.0_20 -server -XX:+UseConcMarkSweepGC 1 tests failed. REGRESSION: org.apache.solr.cloud.DeleteReplicaTest.testDistribSearch Error Message: No live SolrServers available to handle this request:[https://127.0.0.1:43656/o/pp, https://127.0.0.1:53379/o/pp, https://127.0.0.1:45790/o/pp, https://127.0.0.1:58387/o/pp, https://127.0.0.1:47579/o/pp] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[https://127.0.0.1:43656/o/pp, https://127.0.0.1:53379/o/pp, https://127.0.0.1:45790/o/pp, https://127.0.0.1:58387/o/pp, https://127.0.0.1:47579/o/pp] at __randomizedtesting.SeedInfo.seed([74C11B046D6B815A:F527951C1A34E166]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:322) at org.apache.solr.client.solrj.impl.CloudSolrServer.sendRequest(CloudSolrServer.java:880) at org.apache.solr.client.solrj.impl.CloudSolrServer.requestWithRetryOnStaleState(CloudSolrServer.java:658) at org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:601) at org.apache.solr.cloud.DeleteReplicaTest.removeAndWaitForReplicaGone(DeleteReplicaTest.java:171) at org.apache.solr.cloud.DeleteReplicaTest.deleteLiveReplicaTest(DeleteReplicaTest.java:144) at org.apache.solr.cloud.DeleteReplicaTest.doTest(DeleteReplicaTest.java:88) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) at sun.reflect.GeneratedMethodAccessor40.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomi
[jira] [Updated] (LUCENE-5985) Populate MIGRATE.txt with useful information for upgrade to Lucene 5.0
[ https://issues.apache.org/jira/browse/LUCENE-5985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-5985: -- Description: We have the migration guide (formatted as markdown) in the Lucene root directory. Unfortunately, not all breaking changes are explained there (like NIO2 changes or removal of FieldCache). We should collect those breaking issues and give some instructions how to migrate your code to 5.0. was: We have the migration guide (formatted as markdown) in the Lucene root directory. Unfortunately, not all breaking changes are explained there (like NIO2 changes) or removal of FieldCache. We should collect those breaking issues and give some instructions how to migrate your code to 5.0. > Populate MIGRATE.txt with useful information for upgrade to Lucene 5.0 > -- > > Key: LUCENE-5985 > URL: https://issues.apache.org/jira/browse/LUCENE-5985 > Project: Lucene - Core > Issue Type: Task > Components: general/javadocs >Reporter: Uwe Schindler > Fix For: 5.0 > > > We have the migration guide (formatted as markdown) in the Lucene root > directory. > Unfortunately, not all breaking changes are explained there (like NIO2 > changes or removal of FieldCache). We should collect those breaking issues > and give some instructions how to migrate your code to 5.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5985) Populate MIGRATE.txt with useful information for upgrade to Lucene 5.0
Uwe Schindler created LUCENE-5985: - Summary: Populate MIGRATE.txt with useful information for upgrade to Lucene 5.0 Key: LUCENE-5985 URL: https://issues.apache.org/jira/browse/LUCENE-5985 Project: Lucene - Core Issue Type: Task Components: general/javadocs Reporter: Uwe Schindler Fix For: 5.0 We have the migration guide (formatted as markdown) in the Lucene root directory. Unfortunately, not all breaking changes are explained there (like NIO2 changes) or removal of FieldCache. We should collect those breaking issues and give some instructions how to migrate your code to 5.0. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5980) IW positions check not quite right
[ https://issues.apache.org/jira/browse/LUCENE-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155146#comment-14155146 ] Uwe Schindler commented on LUCENE-5980: --- +1 #stopindexcorrumption > IW positions check not quite right > -- > > Key: LUCENE-5980 > URL: https://issues.apache.org/jira/browse/LUCENE-5980 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-5980.patch > > > I noticed this when working on LUCENE-5977. > We only check that position doesn't overflow, not length. So a buggy analyzer > can happily write a corrupt index (negative freq) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5979) Use the cost API instead of a heuristic on the first document in FilteredQuery to decide on whether to use random access
[ https://issues.apache.org/jira/browse/LUCENE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155111#comment-14155111 ] Uwe Schindler commented on LUCENE-5979: --- bq. I just am worried about 'crappy' implementations though, like FixedBitSet. Must that one really implement DocIDSet? LUCENE-5441 was opened to solve this. I just did not finish it, but the patch should still work as base for extending. > Use the cost API instead of a heuristic on the first document in > FilteredQuery to decide on whether to use random access > > > Key: LUCENE-5979 > URL: https://issues.apache.org/jira/browse/LUCENE-5979 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 5.0 > > Attachments: LUCENE-5979.patch > > > Now that some major filters such as TermsFilter and > MultiTermQueryWrapperFilter return DocIdSets that have a better cost, we > should switch to the cost API. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6512) Add a collections API call to add/delete arbitrary properties to a specific replica
[ https://issues.apache.org/jira/browse/SOLR-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155106#comment-14155106 ] ASF subversion and git services commented on SOLR-6512: --- Commit 1628773 from [~erickoerickson] in branch 'dev/trunk' [ https://svn.apache.org/r1628773 ] SOLR-6512: Add a collections API call to add/delete arbitrary properties to a specific replica > Add a collections API call to add/delete arbitrary properties to a specific > replica > --- > > Key: SOLR-6512 > URL: https://issues.apache.org/jira/browse/SOLR-6512 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-6512.patch, SOLR-6512.patch, SOLR-6512.patch, > SOLR-6512.patch > > > This is a sub-task for SOLR-6491, but seems generally useful. > Since this is in support of the "preferredLeader" functionality, I've run > into some considerations that I wanted some feedback on how to handle. > "preferredLeader" has the restriction that there should only be one per > slice, so setting this for a particular node means removing the property for > all the other replicas on the slice. Not a problem to do, my question is more > whether this is something reasonable to enforce on an arbitrary property > based on what that property is? Perfectly do-able, but "semantically > challenged". Currently, this is never a node with "preferedLeader" set to > "false", it is forcibly removed from other nodes in the slice when this > property is assigned. > The problem here is that there's nothing about assigning an arbitrary > property to a node that would reasonably imply this kind of behavior. One > could always control this with secondary flags on the command, e.g. > "shardExclusive=true|false" for instance, perhaps with safety checks in for > known one-per-shard properties like "preferredLeader". > "preferredLeader" seems to fit more naturally into a "role", but currently > ADDROLE and DELTEROLE have nothing to do with the notion of setting a role > for a particular node relative to a collection/shard. Easy enough to add, but > enforcing the "only one node per slice may have this role" rule there is > similarly arbitrary and overloads the ADDROLE/DELETEROLE in a way that seems > equally confusing. Plus, checking whether the required collection/shard/node > params are present becomes based on the value of the property being set, > which is all equally arbitrary. > The other interesting thing is that setting an arbitrary property on a node > would allow one to mess things up royally by, say, changing properties like > "core", or "base_url" or node_name at will. Actually this is potentially > useful, but very, very dangerous and I'm not particularly interested in > supporting it ;). I suppose we could require a prefix, say the only settable > properties are "property.whatever". > We could also add something specific to nodes, something like > ADDREPLICAROLE/DELETEREPLICAROLE, perhaps with sub-params like > "onlyOneAllowedPerShard", but this gets messy and relies on the users "doing > the right thing". I prefer enforcing rules like this based on the role I > think. Or at least enforcing these kinds of requirements on the > "preferredLeader" role if we go that way. > What are people's thoughts here? I think I'm tending towards the > ADDREPLICAROLE/DELETEREPLICAROLE way of doing this, but it's not set in > stone. I have code locally for arbitrary properties that I can modify for the > role bits. > So, if I'm going to summarize the points I'd like feedback on: > 1> Is setting arbitrary properties on a node desirable? If so, should we > require a prefix like "property" to prevent resetting values SolrCloud > depends on? > 2> Is it better to piggyback on ADDROLE/DELETEROLE? Personally I'm not in > favor of this one. Too messy with requiring additional parameters to work > right in this case > 3> Is the best option to create new collections API calls for > ADDREPLICAROLE/DELETEREPLICAROLE that > 3.1> require collection/slice/node parameters > 3.2> enforces the "onlyOnePerShard" rule for certain known roles > 3.3 v1> allows users to specify arbitrary roles something like > "onlyOnePerShard" as an optional T|F parameter, otherwise is totally open. > -or- > 3.3 v2> No support other than "preferredLeader", only roles that are > pre-defined are allowed, in which case the "onlyOnePerShard" is implicit in > the role. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6512) Add a collections API call to add/delete arbitrary properties to a specific replica
[ https://issues.apache.org/jira/browse/SOLR-6512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-6512: - Attachment: SOLR-6512.patch Final patch with CHANGES.txt addition > Add a collections API call to add/delete arbitrary properties to a specific > replica > --- > > Key: SOLR-6512 > URL: https://issues.apache.org/jira/browse/SOLR-6512 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-6512.patch, SOLR-6512.patch, SOLR-6512.patch, > SOLR-6512.patch > > > This is a sub-task for SOLR-6491, but seems generally useful. > Since this is in support of the "preferredLeader" functionality, I've run > into some considerations that I wanted some feedback on how to handle. > "preferredLeader" has the restriction that there should only be one per > slice, so setting this for a particular node means removing the property for > all the other replicas on the slice. Not a problem to do, my question is more > whether this is something reasonable to enforce on an arbitrary property > based on what that property is? Perfectly do-able, but "semantically > challenged". Currently, this is never a node with "preferedLeader" set to > "false", it is forcibly removed from other nodes in the slice when this > property is assigned. > The problem here is that there's nothing about assigning an arbitrary > property to a node that would reasonably imply this kind of behavior. One > could always control this with secondary flags on the command, e.g. > "shardExclusive=true|false" for instance, perhaps with safety checks in for > known one-per-shard properties like "preferredLeader". > "preferredLeader" seems to fit more naturally into a "role", but currently > ADDROLE and DELTEROLE have nothing to do with the notion of setting a role > for a particular node relative to a collection/shard. Easy enough to add, but > enforcing the "only one node per slice may have this role" rule there is > similarly arbitrary and overloads the ADDROLE/DELETEROLE in a way that seems > equally confusing. Plus, checking whether the required collection/shard/node > params are present becomes based on the value of the property being set, > which is all equally arbitrary. > The other interesting thing is that setting an arbitrary property on a node > would allow one to mess things up royally by, say, changing properties like > "core", or "base_url" or node_name at will. Actually this is potentially > useful, but very, very dangerous and I'm not particularly interested in > supporting it ;). I suppose we could require a prefix, say the only settable > properties are "property.whatever". > We could also add something specific to nodes, something like > ADDREPLICAROLE/DELETEREPLICAROLE, perhaps with sub-params like > "onlyOneAllowedPerShard", but this gets messy and relies on the users "doing > the right thing". I prefer enforcing rules like this based on the role I > think. Or at least enforcing these kinds of requirements on the > "preferredLeader" role if we go that way. > What are people's thoughts here? I think I'm tending towards the > ADDREPLICAROLE/DELETEREPLICAROLE way of doing this, but it's not set in > stone. I have code locally for arbitrary properties that I can modify for the > role bits. > So, if I'm going to summarize the points I'd like feedback on: > 1> Is setting arbitrary properties on a node desirable? If so, should we > require a prefix like "property" to prevent resetting values SolrCloud > depends on? > 2> Is it better to piggyback on ADDROLE/DELETEROLE? Personally I'm not in > favor of this one. Too messy with requiring additional parameters to work > right in this case > 3> Is the best option to create new collections API calls for > ADDREPLICAROLE/DELETEREPLICAROLE that > 3.1> require collection/slice/node parameters > 3.2> enforces the "onlyOnePerShard" rule for certain known roles > 3.3 v1> allows users to specify arbitrary roles something like > "onlyOnePerShard" as an optional T|F parameter, otherwise is totally open. > -or- > 3.3 v2> No support other than "preferredLeader", only roles that are > pre-defined are allowed, in which case the "onlyOnePerShard" is implicit in > the role. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6576) ModifiableSolrParams#add(SolrParams) is performing a set operation instead of an add
[ https://issues.apache.org/jira/browse/SOLR-6576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155103#comment-14155103 ] Hoss Man commented on SOLR-6576: bq. So in my head I would think the method for the current functionality would mimic the "set" capability ... and should be named appropriately. I don't disagree with you, it's just the missfortune of how the API evolved w/o people giving a more critical eye to what those methods were named. bq. Also, SolrParams.wrapAppended(SolrParams) is deprecated so that isn't very re-assuring to use. Uh? ... no it's not what makes you say that? https://lucene.apache.org/solr/4_10_0/solr-solrj/org/apache/solr/common/params/SolrParams.html#wrapAppended%28org.apache.solr.common.params.SolrParams,%20org.apache.solr.common.params.SolrParams%29 > ModifiableSolrParams#add(SolrParams) is performing a set operation instead of > an add > > > Key: SOLR-6576 > URL: https://issues.apache.org/jira/browse/SOLR-6576 > Project: Solr > Issue Type: Bug >Reporter: Steve Davids > Fix For: 5.0, Trunk > > Attachments: SOLR-6576.patch > > > Came across this bug by attempting to append multiple ModifiableSolrParam > objects together but found the last one was clobbering the previously set > values. The add operation should append the values to the previously defined > values, not perform a set operation. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5979) Use the cost API instead of a heuristic on the first document in FilteredQuery to decide on whether to use random access
[ https://issues.apache.org/jira/browse/LUCENE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155089#comment-14155089 ] Uwe Schindler commented on LUCENE-5979: --- Thanks for removing the crappy extra leapfrog iterator that was just there to deliver the firstFilterDoc (because it was consumed before). I am unfortunately not completely familar with the absolute or non-absolute cost values to make a good guess if cost * 100 > maxDoc is fine... > Use the cost API instead of a heuristic on the first document in > FilteredQuery to decide on whether to use random access > > > Key: LUCENE-5979 > URL: https://issues.apache.org/jira/browse/LUCENE-5979 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 5.0 > > Attachments: LUCENE-5979.patch > > > Now that some major filters such as TermsFilter and > MultiTermQueryWrapperFilter return DocIdSets that have a better cost, we > should switch to the cost API. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6517) CollectionsAPI call ELECTPREFERREDLEADERS
[ https://issues.apache.org/jira/browse/SOLR-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155088#comment-14155088 ] Noble Paul commented on SOLR-6517: -- bq.This is exactly what happens with one twist. "preferredLeader" is a known property that automatically enforces the sliceUnique=true Yes, I saw it in the code and that is why I am asking why don't we push the option to a request param and the users get the power of choosing multilple preferred leaders and if one shard goes down the other can clearly take up the that role > CollectionsAPI call ELECTPREFERREDLEADERS > - > > Key: SOLR-6517 > URL: https://issues.apache.org/jira/browse/SOLR-6517 > Project: Solr > Issue Type: New Feature >Affects Versions: 5.0, Trunk >Reporter: Erick Erickson >Assignee: Erick Erickson > > Perhaps the final piece of SOLR-6491. Once the preferred leadership roles are > assigned, there has to be a command "make it so Mr. Solr". This is something > of a placeholder to collect ideas. One wouldn't want to flood the system with > hundreds of re-assignments at once. Should this be synchronous or asnych? > Should it make the best attempt but not worry about perfection? Should it??? > a collection=name parameter would be required and it would re-elect all the > leaders that were on the 'wrong' node > I'm thinking an optionally allowing one to specify a shard in the case where > you wanted to make a very specific change. Note that there's no need to > specify a particular replica, since there should be only a single > preferredLeader per slice. > This command would do nothing to any slice that did not have a replica with a > preferredLeader role. Likewise it would do nothing if the slice in question > already had the leader role assigned to the node with the preferredLeader > role. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5979) Use the cost API instead of a heuristic on the first document in FilteredQuery to decide on whether to use random access
[ https://issues.apache.org/jira/browse/LUCENE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155071#comment-14155071 ] Robert Muir commented on LUCENE-5979: - I don't think the documentation prevents it, its just this would be the first use of it. so I am +1, I just am worried about 'crappy' implementations though, like FixedBitSet. Must that one really implement DocIDSet? > Use the cost API instead of a heuristic on the first document in > FilteredQuery to decide on whether to use random access > > > Key: LUCENE-5979 > URL: https://issues.apache.org/jira/browse/LUCENE-5979 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 5.0 > > Attachments: LUCENE-5979.patch > > > Now that some major filters such as TermsFilter and > MultiTermQueryWrapperFilter return DocIdSets that have a better cost, we > should switch to the cost API. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5986) Don't allow runaway queries from harming Solr cluster health or search performance
[ https://issues.apache.org/jira/browse/SOLR-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14155068#comment-14155068 ] Anshum Gupta commented on SOLR-5986: [~shalinmangar], had planned to wrap this today. Just trying to minimize the variables involved in the test while I change it. > Don't allow runaway queries from harming Solr cluster health or search > performance > -- > > Key: SOLR-5986 > URL: https://issues.apache.org/jira/browse/SOLR-5986 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Steve Davids >Assignee: Anshum Gupta >Priority: Critical > Fix For: 5.0 > > Attachments: SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, > SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, > SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, > SOLR-5986.patch > > > The intent of this ticket is to have all distributed search requests stop > wasting CPU cycles on requests that have already timed out or are so > complicated that they won't be able to execute. We have come across a case > where a nasty wildcard query within a proximity clause was causing the > cluster to enumerate terms for hours even though the query timeout was set to > minutes. This caused a noticeable slowdown within the system which made us > restart the replicas that happened to service that one request, the worst > case scenario are users with a relatively low zk timeout value will have > nodes start dropping from the cluster due to long GC pauses. > [~amccurry] Built a mechanism into Apache Blur to help with the issue in > BLUR-142 (see commit comment for code, though look at the latest code on the > trunk for newer bug fixes). > Solr should be able to either prevent these problematic queries from running > by some heuristic (possibly estimated size of heap usage) or be able to > execute a thread interrupt on all query threads once the time threshold is > met. This issue mirrors what others have discussed on the mailing list: > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6476) Create a bulk mode for schema API
[
https://issues.apache.org/jira/browse/SOLR-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154985#comment-14154985
]
Noble Paul edited comment on SOLR-6476 at 10/1/14 4:28 PM:
---
bq.Aren't you going to backport this to branch_5x?
yes but I am waiting for [~thelabdude] to port the changes from SOLR-6249 tobe
ported first
was (Author: noble.paul):
bq.Aren't you going to backport this to branch_5x?
yes
> Create a bulk mode for schema API
> -
>
> Key: SOLR-6476
> URL: https://issues.apache.org/jira/browse/SOLR-6476
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: managedResource
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch
>
>
> The current schema API does one operation at a time and the normal usecase is
> that users add multiple fields/fieldtypes/copyFields etc in one shot.
> example
> {code:javascript}
> curl http://localhost:8983/solr/collection1/schema -H
> 'Content-type:application/json' -d '{
> "add-field": {
> "name":"sell-by",
> "type":"tdate",
> "stored":true
> },
> "add-field":{
> "name":"catchall",
> "type":"text_general",
> "stored":false
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6530) Commits under network partition can put any node in down state by any node
[ https://issues.apache.org/jira/browse/SOLR-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-6530: Attachment: SOLR-6530.patch Patch with the right test. I accidentally included an old version of the test with my last patch. > Commits under network partition can put any node in down state by any node > -- > > Key: SOLR-6530 > URL: https://issues.apache.org/jira/browse/SOLR-6530 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Priority: Critical > Fix For: 5.0, Trunk > > Attachments: SOLR-6530.patch, SOLR-6530.patch, SOLR-6530.patch, > SOLR-6530.patch, SOLR-6530.patch, SOLR-6530.patch > > > Commits are executed by any node in SolrCloud i.e. they're not routed via the > leader like other updates. > # Suppose there's 1 collection, 1 shard, 2 replicas (A and B) and A is the > leader > # Suppose a commit request is made to node B during a time where B cannot > talk to A due to a partition for any reason (failing switch, heavy GC, > whatever) > # B fails to distribute the commit to A (times out) and asks A to recover > # This was okay earlier because a leader just ignores recovery requests but > with leader initiated recovery code, B puts A in the "down" state and A can > never get out of that state. > tl;dr; During network partitions, if enough commit/optimize requests are sent > to the cluster, all the nodes in the cluster will eventually be marked as > "down". -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6530) Commits under network partition can put any node in down state by any node
[ https://issues.apache.org/jira/browse/SOLR-6530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-6530: Attachment: SOLR-6530.patch Folding in the change suggested by Ramkumar. > Commits under network partition can put any node in down state by any node > -- > > Key: SOLR-6530 > URL: https://issues.apache.org/jira/browse/SOLR-6530 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Priority: Critical > Fix For: 5.0, Trunk > > Attachments: SOLR-6530.patch, SOLR-6530.patch, SOLR-6530.patch, > SOLR-6530.patch, SOLR-6530.patch > > > Commits are executed by any node in SolrCloud i.e. they're not routed via the > leader like other updates. > # Suppose there's 1 collection, 1 shard, 2 replicas (A and B) and A is the > leader > # Suppose a commit request is made to node B during a time where B cannot > talk to A due to a partition for any reason (failing switch, heavy GC, > whatever) > # B fails to distribute the commit to A (times out) and asks A to recover > # This was okay earlier because a leader just ignores recovery requests but > with leader initiated recovery code, B puts A in the "down" state and A can > never get out of that state. > tl;dr; During network partitions, if enough commit/optimize requests are sent > to the cluster, all the nodes in the cluster will eventually be marked as > "down". -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: how to do auto suggestion using apache lucene?
On Wed, Oct 1, 2014 at 9:19 AM, Alexandre Rafalovitch wrote: > https://github.com/arafalov/Solr-Javadoc/tree/master/SearchServer Pretty cool, Alex! ~ David Smiley Freelance Apache Lucene/Solr Search Consultant/Developer http://www.linkedin.com/in/davidwsmiley
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b28) - Build # 11211 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11211/ Java: 64bit/jdk1.9.0-ea-b28 -XX:+UseCompressedOops -XX:+UseParallelGC 3 tests failed. REGRESSION: org.apache.solr.core.ExitableDirectoryReaderTest.testQueriesOnDocsWithMultipleTerms Error Message: Stack Trace: java.lang.AssertionError: at __randomizedtesting.SeedInfo.seed([25DED21A01C97284:4B1EE1CB2DBC09AB]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.assertQEx(SolrTestCaseJ4.java:850) at org.apache.solr.core.ExitableDirectoryReaderTest.testQueriesOnDocsWithMultipleTerms(ExitableDirectoryReaderTest.java:88) 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:484) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.solr.core.ExitableDirectoryReaderTest.testPrefixQuery Error Message: Stack Trace: jav
[jira] [Commented] (SOLR-6476) Create a bulk mode for schema API
[
https://issues.apache.org/jira/browse/SOLR-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154989#comment-14154989
]
Steve Rowe commented on SOLR-6476:
--
Thanks Noble, your last commit fixed the two issues I mentioned. +1 to resolve
once you've backported.
> Create a bulk mode for schema API
> -
>
> Key: SOLR-6476
> URL: https://issues.apache.org/jira/browse/SOLR-6476
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: managedResource
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch
>
>
> The current schema API does one operation at a time and the normal usecase is
> that users add multiple fields/fieldtypes/copyFields etc in one shot.
> example
> {code:javascript}
> curl http://localhost:8983/solr/collection1/schema -H
> 'Content-type:application/json' -d '{
> "add-field": {
> "name":"sell-by",
> "type":"tdate",
> "stored":true
> },
> "add-field":{
> "name":"catchall",
> "type":"text_general",
> "stored":false
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6476) Create a bulk mode for schema API
[
https://issues.apache.org/jira/browse/SOLR-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-6476:
-
Fix Version/s: 5.0
> Create a bulk mode for schema API
> -
>
> Key: SOLR-6476
> URL: https://issues.apache.org/jira/browse/SOLR-6476
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: managedResource
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch
>
>
> The current schema API does one operation at a time and the normal usecase is
> that users add multiple fields/fieldtypes/copyFields etc in one shot.
> example
> {code:javascript}
> curl http://localhost:8983/solr/collection1/schema -H
> 'Content-type:application/json' -d '{
> "add-field": {
> "name":"sell-by",
> "type":"tdate",
> "stored":true
> },
> "add-field":{
> "name":"catchall",
> "type":"text_general",
> "stored":false
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6476) Create a bulk mode for schema API
[
https://issues.apache.org/jira/browse/SOLR-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154985#comment-14154985
]
Noble Paul commented on SOLR-6476:
--
bq.Aren't you going to backport this to branch_5x?
yes
> Create a bulk mode for schema API
> -
>
> Key: SOLR-6476
> URL: https://issues.apache.org/jira/browse/SOLR-6476
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: managedResource
> Fix For: Trunk
>
> Attachments: SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch
>
>
> The current schema API does one operation at a time and the normal usecase is
> that users add multiple fields/fieldtypes/copyFields etc in one shot.
> example
> {code:javascript}
> curl http://localhost:8983/solr/collection1/schema -H
> 'Content-type:application/json' -d '{
> "add-field": {
> "name":"sell-by",
> "type":"tdate",
> "stored":true
> },
> "add-field":{
> "name":"catchall",
> "type":"text_general",
> "stored":false
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6476) Create a bulk mode for schema API
[
https://issues.apache.org/jira/browse/SOLR-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154984#comment-14154984
]
ASF subversion and git services commented on SOLR-6476:
---
Commit 1628747 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1628747 ]
SOLR-6476
> Create a bulk mode for schema API
> -
>
> Key: SOLR-6476
> URL: https://issues.apache.org/jira/browse/SOLR-6476
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: managedResource
> Fix For: Trunk
>
> Attachments: SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch
>
>
> The current schema API does one operation at a time and the normal usecase is
> that users add multiple fields/fieldtypes/copyFields etc in one shot.
> example
> {code:javascript}
> curl http://localhost:8983/solr/collection1/schema -H
> 'Content-type:application/json' -d '{
> "add-field": {
> "name":"sell-by",
> "type":"tdate",
> "stored":true
> },
> "add-field":{
> "name":"catchall",
> "type":"text_general",
> "stored":false
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-6517) CollectionsAPI call ELECTPREFERREDLEADERS
[ https://issues.apache.org/jira/browse/SOLR-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154963#comment-14154963 ] Erick Erickson edited comment on SOLR-6517 at 10/1/14 3:47 PM: --- bq: A user wants to move the shard leader to a particular replica and he invokes a action=SETREPLICAPROP&prop=prefrerredLeader&val=true . Here I should be able to pass a param "sliceUnique=true" which will remove the property from other replicas if the param is not passed two replicas will have the same value This is exactly what happens with one twist. "preferredLeader" is a known property that automatically enforces the sliceUnique=true parameter. All other properties' uniqueness are completely under the control of the user. sliceUnique defaults to 'false'. I don't see the practical use of having multiple preferred leaders per slice. I can imagine having a weight attached to the property governing where it inserted itself in the ephemeral node list, but that's a complexity I'll save for another JIRA I think ;). edit - Or perhaps we'll add the ability to define multiple preferred leader properties per slice at some point in the future. How that interacts with SOLR-6513 where the property is auto-balanced amongst all nodes is an open question that I don't want to address right now. "progress, not perfection" and all that. was (Author: erickerickson): bq: A user wants to move the shard leader to a particular replica and he invokes a action=SETREPLICAPROP&prop=prefrerredLeader&val=true . Here I should be able to pass a param "sliceUnique=true" which will remove the property from other replicas if the param is not passed two replicas will have the same value This is exactly what happens with one twist. "preferredLeader" is a known property that automatically enforces the sliceUnique=true parameter. All other properties' uniqueness are completely under the control of the user. sliceUnique defaults to 'false'. I don't see the practical use of having multiple preferred leaders per slice. I can imagine having a weight attached to the property governing where it inserted itself in the ephemeral node list, but that's a complexity I'll save for another JIRA I think ;). > CollectionsAPI call ELECTPREFERREDLEADERS > - > > Key: SOLR-6517 > URL: https://issues.apache.org/jira/browse/SOLR-6517 > Project: Solr > Issue Type: New Feature >Affects Versions: 5.0, Trunk >Reporter: Erick Erickson >Assignee: Erick Erickson > > Perhaps the final piece of SOLR-6491. Once the preferred leadership roles are > assigned, there has to be a command "make it so Mr. Solr". This is something > of a placeholder to collect ideas. One wouldn't want to flood the system with > hundreds of re-assignments at once. Should this be synchronous or asnych? > Should it make the best attempt but not worry about perfection? Should it??? > a collection=name parameter would be required and it would re-elect all the > leaders that were on the 'wrong' node > I'm thinking an optionally allowing one to specify a shard in the case where > you wanted to make a very specific change. Note that there's no need to > specify a particular replica, since there should be only a single > preferredLeader per slice. > This command would do nothing to any slice that did not have a replica with a > preferredLeader role. Likewise it would do nothing if the slice in question > already had the leader role assigned to the node with the preferredLeader > role. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-6476) Create a bulk mode for schema API
[
https://issues.apache.org/jira/browse/SOLR-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-6476:
-
Issue Type: New Feature (was: Bug)
> Create a bulk mode for schema API
> -
>
> Key: SOLR-6476
> URL: https://issues.apache.org/jira/browse/SOLR-6476
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: managedResource
> Fix For: Trunk
>
> Attachments: SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch
>
>
> The current schema API does one operation at a time and the normal usecase is
> that users add multiple fields/fieldtypes/copyFields etc in one shot.
> example
> {code:javascript}
> curl http://localhost:8983/solr/collection1/schema -H
> 'Content-type:application/json' -d '{
> "add-field": {
> "name":"sell-by",
> "type":"tdate",
> "stored":true
> },
> "add-field":{
> "name":"catchall",
> "type":"text_general",
> "stored":false
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-6476) Create a bulk mode for schema API
[
https://issues.apache.org/jira/browse/SOLR-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe reopened SOLR-6476:
--
Noble, you apparently ignored this comment I made earlier when you committed -
it's still a problem:
{quote}
In {{SchemaManager.waitForOtherReplicasToUpdate()}}, called from
{{doOperations()}}, you send -1 in as {{maxWaitSecs}} to
{{ManagedIndexSchema.waitForSchemaZkVersionAgreement()}} when the timeout has
been exceeded, but AFAICT negative values aren't handled appropriately there,
e.g. it gets sent in unexamined to {{ExecutorService.invokeAll()}}:
{quote}
Two more issues:
1. It's better form to use the conversion function for
nanoseconds->milliseconds rather than having constant conversion factors - you
have (starting at line #159 in {{SchemaManager}}):
{code:java}
long timeLeftSecs1 = timeout - ((System.nanoTime() - startTime) /100);
[...]
long timeLeftSecs = timeout - ((System.nanoTime() - startTime) /100);
{code}
But everywhere else in Solr, e.g. line #178 in {{HttpShardHandler}}:
{code:java}
ssr.elapsedTime = TimeUnit.MILLISECONDS.convert(System.nanoTime() - startTime,
TimeUnit.NANOSECONDS);
{code}
2. Aren't you going to backport this to branch_5x?
> Create a bulk mode for schema API
> -
>
> Key: SOLR-6476
> URL: https://issues.apache.org/jira/browse/SOLR-6476
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: managedResource
> Fix For: Trunk
>
> Attachments: SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch
>
>
> The current schema API does one operation at a time and the normal usecase is
> that users add multiple fields/fieldtypes/copyFields etc in one shot.
> example
> {code:javascript}
> curl http://localhost:8983/solr/collection1/schema -H
> 'Content-type:application/json' -d '{
> "add-field": {
> "name":"sell-by",
> "type":"tdate",
> "stored":true
> },
> "add-field":{
> "name":"catchall",
> "type":"text_general",
> "stored":false
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5984) Remove ChainedFilter
[ https://issues.apache.org/jira/browse/LUCENE-5984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154965#comment-14154965 ] Yonik Seeley commented on LUCENE-5984: -- +1 > Remove ChainedFilter > > > Key: LUCENE-5984 > URL: https://issues.apache.org/jira/browse/LUCENE-5984 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Priority: Minor > > I would like to suggest removing ChainedFilter. It is currently only used in > Solr's CurrencyField but could easily be replaced with a BooleanFilter and my > understanding of this filter is that it can generally be replaced with a > BooleanFilter. So let's drop it and suggest using BooleanFilter instead? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6517) CollectionsAPI call ELECTPREFERREDLEADERS
[ https://issues.apache.org/jira/browse/SOLR-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154963#comment-14154963 ] Erick Erickson commented on SOLR-6517: -- bq: A user wants to move the shard leader to a particular replica and he invokes a action=SETREPLICAPROP&prop=prefrerredLeader&val=true . Here I should be able to pass a param "sliceUnique=true" which will remove the property from other replicas if the param is not passed two replicas will have the same value This is exactly what happens with one twist. "preferredLeader" is a known property that automatically enforces the sliceUnique=true parameter. All other properties' uniqueness are completely under the control of the user. sliceUnique defaults to 'false'. I don't see the practical use of having multiple preferred leaders per slice. I can imagine having a weight attached to the property governing where it inserted itself in the ephemeral node list, but that's a complexity I'll save for another JIRA I think ;). > CollectionsAPI call ELECTPREFERREDLEADERS > - > > Key: SOLR-6517 > URL: https://issues.apache.org/jira/browse/SOLR-6517 > Project: Solr > Issue Type: New Feature >Affects Versions: 5.0, Trunk >Reporter: Erick Erickson >Assignee: Erick Erickson > > Perhaps the final piece of SOLR-6491. Once the preferred leadership roles are > assigned, there has to be a command "make it so Mr. Solr". This is something > of a placeholder to collect ideas. One wouldn't want to flood the system with > hundreds of re-assignments at once. Should this be synchronous or asnych? > Should it make the best attempt but not worry about perfection? Should it??? > a collection=name parameter would be required and it would re-elect all the > leaders that were on the 'wrong' node > I'm thinking an optionally allowing one to specify a shard in the case where > you wanted to make a very specific change. Note that there's no need to > specify a particular replica, since there should be only a single > preferredLeader per slice. > This command would do nothing to any slice that did not have a replica with a > preferredLeader role. Likewise it would do nothing if the slice in question > already had the leader role assigned to the node with the preferredLeader > role. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5984) Remove ChainedFilter
Adrien Grand created LUCENE-5984: Summary: Remove ChainedFilter Key: LUCENE-5984 URL: https://issues.apache.org/jira/browse/LUCENE-5984 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Priority: Minor I would like to suggest removing ChainedFilter. It is currently only used in Solr's CurrencyField but could easily be replaced with a BooleanFilter and my understanding of this filter is that it can generally be replaced with a BooleanFilter. So let's drop it and suggest using BooleanFilter instead? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6513) Add a collectionsAPI call BALANCESLICEUNIQUE
[ https://issues.apache.org/jira/browse/SOLR-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154947#comment-14154947 ] Erick Erickson commented on SOLR-6513: -- Shalin: The biggest bit here is that by having a property and inserting itself at the head of the list for leader election, the cluster will tend to self-correct. That is, every time a leader election occurs, the replica with the property should be at the head of the list (assuming it's active) and become the leader. Most of the time, this will probably be "good enough", but in the pathological case of things getting really out of whack, hitting the "relect leaders" API call (SOLR-6517) will re-distribute leadership. So one scenario is to set up a cluster, call this API and not have to redistribute the leaders periodically via SOLR-6517. Additionally, as discussed in SOLR-6491, there's no real substitute for an operations person's knowledge of the system. Consider a cluster of heterogeneous machines hosting multiple collections, some of which have heavy traffic and some of which do not. Even creating a way to characterize that kind of setup in a general way such that having only a "rebalance your leaders now" command would do the right thing hurts my head. > Add a collectionsAPI call BALANCESLICEUNIQUE > > > Key: SOLR-6513 > URL: https://issues.apache.org/jira/browse/SOLR-6513 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-6513.patch > > > Another sub-task for SOLR-6491. The ability to assign a property on a > node-by-node basis is nice, but tedious to get right for a sysadmin, > especially if there are, say, 100s of nodes hosting a system. This JIRA would > essentially provide an automatic mechanism for assigning a property. This > particular command simply changes the cluster state, it doesn't do anything > like re-assign functions. > My idea for this version is fairly limited. You'd have to specify a > collection and there would be no attempt to, say, evenly distribute the > preferred leader role/property for this collection by looking at _other_ > collections. Or by looking at underlying hardware capabilities. Or > It would be a pretty simple round-robin assignment. About the only > intelligence built in would be to change as few roles/properties as possible. > Let's say that the correct number of nodes for this role turned out to be 3. > Any node currently having 3 properties for this collection would NOT be > changed. Any node having 2 properties would have one added that would be > taken from some node with > 3 properties like this. > This probably needs an optional parameter, something like > "includeInactiveNodes=true|false" > Since this is an arbitrary property, one must specify sliceUnique=true. So > for the "preferredLeader" functionality, one would specify something like: > action=BALANCESLICEUNIQUE&property=preferredLeader&proprety.value=true. > There are checks in this code that require the preferredLeader to have a t/f > value and require that sliceUnique bet true. That said, this can be called on > an arbitrary property that has only one such property per slice. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_40-ea-b04) - Build # 4245 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4245/
Java: 32bit/jdk1.8.0_40-ea-b04 -client -XX:+UseG1GC
1 tests failed.
REGRESSION: org.apache.solr.core.TestNonNRTOpen.testReaderIsNotNRT
Error Message:
SOLR-5815? : wrong maxDoc: core=org.apache.solr.core.SolrCore@fe95e2
searcher=Searcher@1ce4ec2[collection1]
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_4(5.0.0):C1)
Uninverting(_5(5.0.0):C1)))} expected:<3> but was:<2>
Stack Trace:
java.lang.AssertionError: SOLR-5815? : wrong maxDoc:
core=org.apache.solr.core.SolrCore@fe95e2
searcher=Searcher@1ce4ec2[collection1]
main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_4(5.0.0):C1)
Uninverting(_5(5.0.0):C1)))} expected:<3> but was:<2>
at
__randomizedtesting.SeedInfo.seed([D837DBF28C36EE33:6DB1BA7533F75CC7]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at
org.apache.solr.core.TestNonNRTOpen.assertNotNRT(TestNonNRTOpen.java:142)
at
org.apache.solr.core.TestNonNRTOpen.testReaderIsNotNRT(TestNonNRTOpen.java:100)
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:483)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
[jira] [Commented] (SOLR-6476) Create a bulk mode for schema API
[
https://issues.apache.org/jira/browse/SOLR-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154925#comment-14154925
]
ASF subversion and git services commented on SOLR-6476:
---
Commit 1628734 from [~noble.paul] in branch 'dev/trunk'
[ https://svn.apache.org/r1628734 ]
SOLR-6476
> Create a bulk mode for schema API
> -
>
> Key: SOLR-6476
> URL: https://issues.apache.org/jira/browse/SOLR-6476
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: managedResource
> Fix For: Trunk
>
> Attachments: SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch
>
>
> The current schema API does one operation at a time and the normal usecase is
> that users add multiple fields/fieldtypes/copyFields etc in one shot.
> example
> {code:javascript}
> curl http://localhost:8983/solr/collection1/schema -H
> 'Content-type:application/json' -d '{
> "add-field": {
> "name":"sell-by",
> "type":"tdate",
> "stored":true
> },
> "add-field":{
> "name":"catchall",
> "type":"text_general",
> "stored":false
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6476) Create a bulk mode for schema API
[
https://issues.apache.org/jira/browse/SOLR-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-6476.
--
Resolution: Fixed
Fix Version/s: Trunk
> Create a bulk mode for schema API
> -
>
> Key: SOLR-6476
> URL: https://issues.apache.org/jira/browse/SOLR-6476
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: managedResource
> Fix For: Trunk
>
> Attachments: SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch
>
>
> The current schema API does one operation at a time and the normal usecase is
> that users add multiple fields/fieldtypes/copyFields etc in one shot.
> example
> {code:javascript}
> curl http://localhost:8983/solr/collection1/schema -H
> 'Content-type:application/json' -d '{
> "add-field": {
> "name":"sell-by",
> "type":"tdate",
> "stored":true
> },
> "add-field":{
> "name":"catchall",
> "type":"text_general",
> "stored":false
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 644 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/644/ 1 tests failed. REGRESSION: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch Error Message: Error CREATEing SolrCore 'halfcollection_shard1_replica1': Unable to create core [halfcollection_shard1_replica1] Caused by: Could not get shard id for core: halfcollection_shard1_replica1 Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Error CREATEing SolrCore 'halfcollection_shard1_replica1': Unable to create core [halfcollection_shard1_replica1] Caused by: Could not get shard id for core: halfcollection_shard1_replica1 at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:570) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testErrorHandling(CollectionsAPIDistributedZkTest.java:583) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:205) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleM
[jira] [Commented] (LUCENE-5969) Add Lucene50Codec
[ https://issues.apache.org/jira/browse/LUCENE-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154866#comment-14154866 ] ASF subversion and git services commented on LUCENE-5969: - Commit 1628714 from [~rcmuir] in branch 'dev/branches/lucene5969' [ https://svn.apache.org/r1628714 ] LUCENE-5969: fix formats > Add Lucene50Codec > - > > Key: LUCENE-5969 > URL: https://issues.apache.org/jira/browse/LUCENE-5969 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5969.patch, LUCENE-5969.patch > > > Spinoff from LUCENE-5952: > * Fix .si to write Version as 3 ints, not a String that requires parsing at > read time. > * Lucene42TermVectorsFormat should not use the same codecName as > Lucene41StoredFieldsFormat > It would also be nice if we had a "bumpCodecVersion" script so rolling a new > codec is not so daunting. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5983) RoaringDocIdSet
[
https://issues.apache.org/jira/browse/LUCENE-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-5983:
-
Attachment: LUCENE-5983.patch
Here are a patch and the results of the benchmark on this new DocIdSet:
http://people.apache.org/~jpountz/doc_id_sets4.html
Compared to the paper, I also optimized the super-dense case in order to encode
the negation of the set to save space (like WAH8DocIdSet does). I like the fact
that this set is overall very fast, especially to build, which is an
interesting characteristic for caching, so I replaced WAH8DocIdSet with this
new DocIdSet in CachingWrapperFilter. Another nice property is that it is
naturally indexed, it doesn't need a side-car data-structure like the WAH8 and
PFOR doc id sets: in the array case, you can just perform a binary search, and
in the FixedBitSet case you already have random-access.
In order to avoid the profusion of doc id sets, I'm thinking of removing the
WAH8 and PFOR doc id sets since this one looks better to me in most areas.
> RoaringDocIdSet
> ---
>
> Key: LUCENE-5983
> URL: https://issues.apache.org/jira/browse/LUCENE-5983
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-5983.patch
>
>
> Robert pointed me to this paper: http://arxiv.org/pdf/1402.6407v4 that
> describes an interesting way to build doc id sets: The bit space is divided
> into blocks of 2^16 bits so that you can store the bits which are set either
> in a short[] (2 bytes per doc ID) or in a FixedBitSet. The choice is easy, if
> less than 2^12 bits are set, then the short[] representation is more compact
> otherwise a FixedBitSet would be more compact. It's quite similar to the way
> that Solr builds DocSets in {{SolrIndexSearcher.getDocSet(DocsEnumState)}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5983) RoaringDocIdSet
Adrien Grand created LUCENE-5983:
Summary: RoaringDocIdSet
Key: LUCENE-5983
URL: https://issues.apache.org/jira/browse/LUCENE-5983
Project: Lucene - Core
Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
Robert pointed me to this paper: http://arxiv.org/pdf/1402.6407v4 that
describes an interesting way to build doc id sets: The bit space is divided
into blocks of 2^16 bits so that you can store the bits which are set either in
a short[] (2 bytes per doc ID) or in a FixedBitSet. The choice is easy, if less
than 2^12 bits are set, then the short[] representation is more compact
otherwise a FixedBitSet would be more compact. It's quite similar to the way
that Solr builds DocSets in {{SolrIndexSearcher.getDocSet(DocsEnumState)}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5979) Use the cost API instead of a heuristic on the first document in FilteredQuery to decide on whether to use random access
[ https://issues.apache.org/jira/browse/LUCENE-5979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154811#comment-14154811 ] Adrien Grand commented on LUCENE-5979: -- I don't think the documentation of the cost API prevents from interpreting the cost as an absolute value? Even if it is not something that we do today, I think all our current DocIdSetIterator (but FixedBitSet) return cost values that are ok to intepret as an absolute value? Even if this estimation is very vague it would be much better than what we have today to decide on the filter strategy to use. Moreover I think this could also prove valuable in CachingWrapperFilter to decide on the cacheable impl to use: some impls would likely better at high-cardinality and vice-versa? > Use the cost API instead of a heuristic on the first document in > FilteredQuery to decide on whether to use random access > > > Key: LUCENE-5979 > URL: https://issues.apache.org/jira/browse/LUCENE-5979 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Adrien Grand >Assignee: Adrien Grand >Priority: Minor > Fix For: 5.0 > > Attachments: LUCENE-5979.patch > > > Now that some major filters such as TermsFilter and > MultiTermQueryWrapperFilter return DocIdSets that have a better cost, we > should switch to the cost API. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: how to do auto suggestion using apache lucene?
Dear Alex, Thank you for your response. It's is Lucene directly and i am using servlet,jsp. -- View this message in context: http://lucene.472066.n3.nabble.com/how-to-do-auto-suggestion-using-apache-lucene-tp4162080p4162102.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: how to do auto suggestion using apache lucene?
Any reason it's Lucene directly and not Solr or ElasticSearch? Here is an example with Solr, Spring Data and Select2: https://github.com/arafalov/Solr-Javadoc/tree/master/SearchServer (the first version was built from scratch in 3 hours). Regards, Alex. Personal: http://www.outerthoughts.com/ and @arafalov Solr resources and newsletter: http://www.solr-start.com/ and @solrstart Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 On 1 October 2014 08:18, rashed wrote: > Hi, > > I developed a web application for search the term. Now , i want to develop > auto suggestion field in the search field where user put term for example > Test, then in the drop down user able to see list of files where test > belongs. > > Can anybody help me how can i do that using apache lucene? > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/how-to-do-auto-suggestion-using-apache-lucene-tp4162080.html > Sent from the Lucene - Java Developer mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5969) Add Lucene50Codec
[ https://issues.apache.org/jira/browse/LUCENE-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154771#comment-14154771 ] ASF subversion and git services commented on LUCENE-5969: - Commit 1628697 from [~rcmuir] in branch 'dev/branches/lucene5969' [ https://svn.apache.org/r1628697 ] LUCENE-5969: give remaining codecs segment headers and cleanups > Add Lucene50Codec > - > > Key: LUCENE-5969 > URL: https://issues.apache.org/jira/browse/LUCENE-5969 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5969.patch, LUCENE-5969.patch > > > Spinoff from LUCENE-5952: > * Fix .si to write Version as 3 ints, not a String that requires parsing at > read time. > * Lucene42TermVectorsFormat should not use the same codecName as > Lucene41StoredFieldsFormat > It would also be nice if we had a "bumpCodecVersion" script so rolling a new > codec is not so daunting. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
how to do auto suggestion using apache lucene?
Hi, I developed a web application for search the term. Now , i want to develop auto suggestion field in the search field where user put term for example Test, then in the drop down user able to see list of files where test belongs. Can anybody help me how can i do that using apache lucene? -- View this message in context: http://lucene.472066.n3.nabble.com/how-to-do-auto-suggestion-using-apache-lucene-tp4162080.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Arbitrary queries in facet pivots
I'd like to get feedback on the approach in SOLR-4212 allowing any query to be applied at any level in pivot facets. I know there's been a lot of work lately around both facet pivots and stats component (through SOLR-2894 finally making it in and SOLR-6348 starting to be tackled), and this seems related. I know the functionality is something we're looking for in our use cases, so I'd love to see the feature make it into a release and will help as much as I can to make it happen, including completely rewriting it if the approach is deemed completely wrong. :) Base idea is to have something like: facet.pivot=field1,field2,field3&f.field2.facet.pivot.q=somequery&f.field3.facet.pivot.q=somedate:[NOW-1YEAR TO NOW]&f.field3.facet.pivot.q=someotherquery... Which would add results similar to facet queries, at the appropriate level in the pivots. So, any feedback will be appreciated. Thanks, Steve - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b28) - Build # 11210 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11210/ Java: 64bit/jdk1.9.0-ea-b28 -XX:+UseCompressedOops -XX:+UseSerialGC 2 tests failed. REGRESSION: org.apache.solr.core.ExitableDirectoryReaderTest.testPrefixQuery Error Message: Stack Trace: java.lang.AssertionError: at __randomizedtesting.SeedInfo.seed([6E1E527AF3DDAA6D:DD49663897004EE8]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.SolrTestCaseJ4.assertQEx(SolrTestCaseJ4.java:850) at org.apache.solr.core.ExitableDirectoryReaderTest.testPrefixQuery(ExitableDirectoryReaderTest.java:67) 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:484) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at java.lang.Thread.run(Thread.java:745) FAILED: org.apache.solr.cloud.CloudExitableDirectoryReaderTest.testDistribSearch Error Message: no exception matching expected: 400: Request took
[jira] [Commented] (SOLR-6476) Create a bulk mode for schema API
[
https://issues.apache.org/jira/browse/SOLR-6476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154760#comment-14154760
]
Noble Paul commented on SOLR-6476:
--
actually System.currentTimeMillis() is fine if used in the same thread . And if
it is used in different threads it can give wrong values. However , for
uniformity I shall change it to System.nanoTime()
> Create a bulk mode for schema API
> -
>
> Key: SOLR-6476
> URL: https://issues.apache.org/jira/browse/SOLR-6476
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Reporter: Noble Paul
>Assignee: Noble Paul
> Labels: managedResource
> Attachments: SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch, SOLR-6476.patch,
> SOLR-6476.patch
>
>
> The current schema API does one operation at a time and the normal usecase is
> that users add multiple fields/fieldtypes/copyFields etc in one shot.
> example
> {code:javascript}
> curl http://localhost:8983/solr/collection1/schema -H
> 'Content-type:application/json' -d '{
> "add-field": {
> "name":"sell-by",
> "type":"tdate",
> "stored":true
> },
> "add-field":{
> "name":"catchall",
> "type":"text_general",
> "stored":false
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5969) Add Lucene50Codec
[ https://issues.apache.org/jira/browse/LUCENE-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154758#comment-14154758 ] ASF subversion and git services commented on LUCENE-5969: - Commit 1628692 from [~rcmuir] in branch 'dev/branches/lucene5969' [ https://svn.apache.org/r1628692 ] LUCENE-5969: more cleanups > Add Lucene50Codec > - > > Key: LUCENE-5969 > URL: https://issues.apache.org/jira/browse/LUCENE-5969 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5969.patch, LUCENE-5969.patch > > > Spinoff from LUCENE-5952: > * Fix .si to write Version as 3 ints, not a String that requires parsing at > read time. > * Lucene42TermVectorsFormat should not use the same codecName as > Lucene41StoredFieldsFormat > It would also be nice if we had a "bumpCodecVersion" script so rolling a new > codec is not so daunting. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_67) - Build # 4347 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/4347/ Java: 64bit/jdk1.7.0_67 -XX:+UseCompressedOops -XX:+UseSerialGC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandlerBackup Error Message: 1 thread leaked from SUITE scope at org.apache.solr.handler.TestReplicationHandlerBackup: 1) Thread[id=850, name=Thread-409, state=RUNNABLE, group=TGRP-TestReplicationHandlerBackup] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read1(BufferedInputStream.java:275) at java.io.BufferedInputStream.read(BufferedInputStream.java:334) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:633) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323) at java.net.URL.openStream(URL.java:1037) at org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:318) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from SUITE scope at org.apache.solr.handler.TestReplicationHandlerBackup: 1) Thread[id=850, name=Thread-409, state=RUNNABLE, group=TGRP-TestReplicationHandlerBackup] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read1(BufferedInputStream.java:275) at java.io.BufferedInputStream.read(BufferedInputStream.java:334) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:633) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323) at java.net.URL.openStream(URL.java:1037) at org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:318) at __randomizedtesting.SeedInfo.seed([B0FB0A2FF32F2A30]:0) FAILED: junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandlerBackup Error Message: There are still zombie threads that couldn't be terminated:1) Thread[id=850, name=Thread-409, state=RUNNABLE, group=TGRP-TestReplicationHandlerBackup] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read1(BufferedInputStream.java:275) at java.io.BufferedInputStream.read(BufferedInputStream.java:334) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:633) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323) at java.net.URL.openStream(URL.java:1037) at org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:318) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: There are still zombie threads that couldn't be terminated: 1) Thread[id=850, name=Thread-409, state=RUNNABLE, group=TGRP-TestReplicationHandlerBackup] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read1(BufferedInputStream.java:275) at java.io.BufferedInputStream.read(BufferedInputStream.java:334) at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:687) at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:633) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1323) at java.net.URL.openStream(URL.java:1037) at org.apache.solr.handler.TestReplicationHandlerBackup$BackupThread.run(TestReplicationHandlerBackup.java:318) at __randomizedtesting.SeedInfo.seed([B0FB0A2FF32F2A30]:0) Build Log: [...truncated 10666 lines...] [junit4] Suite: org.apache.solr.handler.TestReplicationHandlerBackup [junit4] 2> Creating dataDir: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\temp\solr.handler.TestReplicationH
[jira] [Commented] (LUCENE-5969) Add Lucene50Codec
[ https://issues.apache.org/jira/browse/LUCENE-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154740#comment-14154740 ] ASF subversion and git services commented on LUCENE-5969: - Commit 1628688 from [~rcmuir] in branch 'dev/branches/lucene5969' [ https://svn.apache.org/r1628688 ] LUCENE-5969: clean up unnecessary back compat and add segment header > Add Lucene50Codec > - > > Key: LUCENE-5969 > URL: https://issues.apache.org/jira/browse/LUCENE-5969 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5969.patch, LUCENE-5969.patch > > > Spinoff from LUCENE-5952: > * Fix .si to write Version as 3 ints, not a String that requires parsing at > read time. > * Lucene42TermVectorsFormat should not use the same codecName as > Lucene41StoredFieldsFormat > It would also be nice if we had a "bumpCodecVersion" script so rolling a new > codec is not so daunting. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6517) CollectionsAPI call ELECTPREFERREDLEADERS
[ https://issues.apache.org/jira/browse/SOLR-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154720#comment-14154720 ] Noble Paul commented on SOLR-6517: -- Let me try to explain how I think of the feature * A user wants to move the shard leader to a particular replica and he invokes a action=SETREPLICAPROP&prop=prefrerredLeader&val=true . Here I should be able to pass a param "sliceUnique=true" which will remove the property from other replicas if the param is not passed two replicas will have the same value * When this command is invoked it can act exactly like the [overseer role command | https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-api15AddRole] .If there are more than one preferred leaders choose whichever is available/first in the queue * This kicks in when a down replica comes back up also > CollectionsAPI call ELECTPREFERREDLEADERS > - > > Key: SOLR-6517 > URL: https://issues.apache.org/jira/browse/SOLR-6517 > Project: Solr > Issue Type: New Feature >Affects Versions: 5.0, Trunk >Reporter: Erick Erickson >Assignee: Erick Erickson > > Perhaps the final piece of SOLR-6491. Once the preferred leadership roles are > assigned, there has to be a command "make it so Mr. Solr". This is something > of a placeholder to collect ideas. One wouldn't want to flood the system with > hundreds of re-assignments at once. Should this be synchronous or asnych? > Should it make the best attempt but not worry about perfection? Should it??? > a collection=name parameter would be required and it would re-elect all the > leaders that were on the 'wrong' node > I'm thinking an optionally allowing one to specify a shard in the case where > you wanted to make a very specific change. Note that there's no need to > specify a particular replica, since there should be only a single > preferredLeader per slice. > This command would do nothing to any slice that did not have a replica with a > preferredLeader role. Likewise it would do nothing if the slice in question > already had the leader role assigned to the node with the preferredLeader > role. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5969) Add Lucene50Codec
[ https://issues.apache.org/jira/browse/LUCENE-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154713#comment-14154713 ] ASF subversion and git services commented on LUCENE-5969: - Commit 1628684 from [~rcmuir] in branch 'dev/branches/lucene5969' [ https://svn.apache.org/r1628684 ] LUCENE-5969: clean up unnecessary back compat and add segment header > Add Lucene50Codec > - > > Key: LUCENE-5969 > URL: https://issues.apache.org/jira/browse/LUCENE-5969 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5969.patch, LUCENE-5969.patch > > > Spinoff from LUCENE-5952: > * Fix .si to write Version as 3 ints, not a String that requires parsing at > read time. > * Lucene42TermVectorsFormat should not use the same codecName as > Lucene41StoredFieldsFormat > It would also be nice if we had a "bumpCodecVersion" script so rolling a new > codec is not so daunting. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5969) Add Lucene50Codec
[ https://issues.apache.org/jira/browse/LUCENE-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154701#comment-14154701 ] ASF subversion and git services commented on LUCENE-5969: - Commit 1628679 from [~rcmuir] in branch 'dev/branches/lucene5969' [ https://svn.apache.org/r1628679 ] LUCENE-5969: clean up unnecessary back compat and add segment header > Add Lucene50Codec > - > > Key: LUCENE-5969 > URL: https://issues.apache.org/jira/browse/LUCENE-5969 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Michael McCandless > Fix For: 5.0, Trunk > > Attachments: LUCENE-5969.patch, LUCENE-5969.patch > > > Spinoff from LUCENE-5952: > * Fix .si to write Version as 3 ints, not a String that requires parsing at > read time. > * Lucene42TermVectorsFormat should not use the same codecName as > Lucene41StoredFieldsFormat > It would also be nice if we had a "bumpCodecVersion" script so rolling a new > codec is not so daunting. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5981) CheckIndex modifies index without write.lock
[ https://issues.apache.org/jira/browse/LUCENE-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-5981. - Resolution: Fixed Fix Version/s: Trunk 5.0 > CheckIndex modifies index without write.lock > > > Key: LUCENE-5981 > URL: https://issues.apache.org/jira/browse/LUCENE-5981 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Fix For: 5.0, Trunk > > Attachments: LUCENE-5981.patch, LUCENE-5981.patch > > > Instead it asks you nicely to "not do that". > Due to the way this is implemented, if you choose to drop corrupt segments, > it should obtain the lock before actually doing any reads too, or it might > lose more than you think or do other strange stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5981) CheckIndex modifies index without write.lock
[ https://issues.apache.org/jira/browse/LUCENE-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154676#comment-14154676 ] ASF subversion and git services commented on LUCENE-5981: - Commit 1628678 from [~rcmuir] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1628678 ] LUCENE-5981: fix CheckIndex to obtain write.lock > CheckIndex modifies index without write.lock > > > Key: LUCENE-5981 > URL: https://issues.apache.org/jira/browse/LUCENE-5981 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-5981.patch, LUCENE-5981.patch > > > Instead it asks you nicely to "not do that". > Due to the way this is implemented, if you choose to drop corrupt segments, > it should obtain the lock before actually doing any reads too, or it might > lose more than you think or do other strange stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-MacOSX (64bit/jdk1.7.0) - Build # 1821 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-MacOSX/1821/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseSerialGC 2 tests failed. REGRESSION: org.apache.solr.TestDistributedGrouping.testDistribSearch Error Message: Request took too long during query expansion. Terminating request. Stack Trace: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Request took too long during query expansion. Terminating request. at __randomizedtesting.SeedInfo.seed([FBAC1CDC1B50BFD4:7A4A92C46C0FDFE8]:0) at org.apache.solr.client.solrj.impl.HttpSolrServer.executeMethod(HttpSolrServer.java:568) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:215) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:211) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:91) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at org.apache.solr.BaseDistributedSearchTestCase.queryServer(BaseDistributedSearchTestCase.java:512) at org.apache.solr.TestDistributedGrouping.simpleQuery(TestDistributedGrouping.java:274) at org.apache.solr.TestDistributedGrouping.doTest(TestDistributedGrouping.java:262) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:875) at sun.reflect.GeneratedMethodAccessor49.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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.luc
[jira] [Commented] (LUCENE-5981) CheckIndex modifies index without write.lock
[ https://issues.apache.org/jira/browse/LUCENE-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154666#comment-14154666 ] ASF subversion and git services commented on LUCENE-5981: - Commit 1628675 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1628675 ] LUCENE-5981: fix CheckIndex to obtain write.lock > CheckIndex modifies index without write.lock > > > Key: LUCENE-5981 > URL: https://issues.apache.org/jira/browse/LUCENE-5981 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-5981.patch, LUCENE-5981.patch > > > Instead it asks you nicely to "not do that". > Due to the way this is implemented, if you choose to drop corrupt segments, > it should obtain the lock before actually doing any reads too, or it might > lose more than you think or do other strange stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5981) CheckIndex modifies index without write.lock
[ https://issues.apache.org/jira/browse/LUCENE-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154648#comment-14154648 ] Michael McCandless commented on LUCENE-5981: +1, thanks Rob! > CheckIndex modifies index without write.lock > > > Key: LUCENE-5981 > URL: https://issues.apache.org/jira/browse/LUCENE-5981 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-5981.patch, LUCENE-5981.patch > > > Instead it asks you nicely to "not do that". > Due to the way this is implemented, if you choose to drop corrupt segments, > it should obtain the lock before actually doing any reads too, or it might > lose more than you think or do other strange stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5981) CheckIndex modifies index without write.lock
[ https://issues.apache.org/jira/browse/LUCENE-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5981: Attachment: LUCENE-5981.patch Updated patch as a simple step. Basically our tests still continue to cheat. > CheckIndex modifies index without write.lock > > > Key: LUCENE-5981 > URL: https://issues.apache.org/jira/browse/LUCENE-5981 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-5981.patch, LUCENE-5981.patch > > > Instead it asks you nicely to "not do that". > Due to the way this is implemented, if you choose to drop corrupt segments, > it should obtain the lock before actually doing any reads too, or it might > lose more than you think or do other strange stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5981) CheckIndex modifies index without write.lock
[ https://issues.apache.org/jira/browse/LUCENE-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154620#comment-14154620 ] Robert Muir commented on LUCENE-5981: - My issue with that approach is that it will make a lot of tests harder to debug. E.g. exception handling tests are calling this directly after getting exception (without closing writer and potentially getting more exceptions). > CheckIndex modifies index without write.lock > > > Key: LUCENE-5981 > URL: https://issues.apache.org/jira/browse/LUCENE-5981 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-5981.patch > > > Instead it asks you nicely to "not do that". > Due to the way this is implemented, if you choose to drop corrupt segments, > it should obtain the lock before actually doing any reads too, or it might > lose more than you think or do other strange stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5986) Don't allow runaway queries from harming Solr cluster health or search performance
[ https://issues.apache.org/jira/browse/SOLR-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154618#comment-14154618 ] Shalin Shekhar Mangar commented on SOLR-5986: - Hi [~anshumg], the CloudExitableDirectoryReaderTest has been failing very frequently on jenkins, can you please take a look? > Don't allow runaway queries from harming Solr cluster health or search > performance > -- > > Key: SOLR-5986 > URL: https://issues.apache.org/jira/browse/SOLR-5986 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Steve Davids >Assignee: Anshum Gupta >Priority: Critical > Fix For: 5.0 > > Attachments: SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, > SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, > SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, SOLR-5986.patch, > SOLR-5986.patch > > > The intent of this ticket is to have all distributed search requests stop > wasting CPU cycles on requests that have already timed out or are so > complicated that they won't be able to execute. We have come across a case > where a nasty wildcard query within a proximity clause was causing the > cluster to enumerate terms for hours even though the query timeout was set to > minutes. This caused a noticeable slowdown within the system which made us > restart the replicas that happened to service that one request, the worst > case scenario are users with a relatively low zk timeout value will have > nodes start dropping from the cluster due to long GC pauses. > [~amccurry] Built a mechanism into Apache Blur to help with the issue in > BLUR-142 (see commit comment for code, though look at the latest code on the > trunk for newer bug fixes). > Solr should be able to either prevent these problematic queries from running > by some heuristic (possibly estimated size of heap usage) or be able to > execute a thread interrupt on all query threads once the time threshold is > met. This issue mirrors what others have discussed on the mailing list: > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200903.mbox/%3c856ac15f0903272054q2dbdbd19kea3c5ba9e105b...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-5.x-Java7 - Build # 2145 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2145/ 1 tests failed. REGRESSION: org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.testDistribSearch Error Message: No live SolrServers available to handle this request:[http://127.0.0.1:45346, http://127.0.0.1:45343, http://127.0.0.1:37130] Stack Trace: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:45346, http://127.0.0.1:45343, http://127.0.0.1:37130] at __randomizedtesting.SeedInfo.seed([B0D616B7E0527FAC:313098AF970D1F90]:0) at org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:322) at org.apache.solr.client.solrj.impl.CloudSolrServer.sendRequest(CloudSolrServer.java:880) at org.apache.solr.client.solrj.impl.CloudSolrServer.requestWithRetryOnStaleState(CloudSolrServer.java:658) at org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:601) at org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.removeAndWaitForLastReplicaGone(DeleteLastCustomShardedReplicaTest.java:117) at org.apache.solr.cloud.DeleteLastCustomShardedReplicaTest.doTest(DeleteLastCustomShardedReplicaTest.java:107) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) 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:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.ev
[jira] [Commented] (LUCENE-5981) CheckIndex modifies index without write.lock
[ https://issues.apache.org/jira/browse/LUCENE-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154601#comment-14154601 ] Robert Muir commented on LUCENE-5981: - OK i see, this guy doesn't actually open readers in the loop. I don't think it should either. I agree, lets just obtain a lock. > CheckIndex modifies index without write.lock > > > Key: LUCENE-5981 > URL: https://issues.apache.org/jira/browse/LUCENE-5981 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-5981.patch > > > Instead it asks you nicely to "not do that". > Due to the way this is implemented, if you choose to drop corrupt segments, > it should obtain the lock before actually doing any reads too, or it might > lose more than you think or do other strange stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.9.0-ea-b28) - Build # 11209 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/11209/ Java: 64bit/jdk1.9.0-ea-b28 -XX:+UseCompressedOops -XX:+UseSerialGC 3 tests failed. REGRESSION: org.apache.solr.cloud.CloudExitableDirectoryReaderTest.testDistribSearch Error Message: no exception matching expected: 400: Request took too long during query expansion. Terminating request. Stack Trace: java.lang.AssertionError: no exception matching expected: 400: Request took too long during query expansion. Terminating request. at __randomizedtesting.SeedInfo.seed([4155FC74EB9A83BF:C0B3726C9CC5E383]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.CloudExitableDirectoryReaderTest.assertFail(CloudExitableDirectoryReaderTest.java:101) at org.apache.solr.cloud.CloudExitableDirectoryReaderTest.doTimeoutTests(CloudExitableDirectoryReaderTest.java:75) at org.apache.solr.cloud.CloudExitableDirectoryReaderTest.doTest(CloudExitableDirectoryReaderTest.java:54) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:869) at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:484) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1618) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:827) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:863) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:365) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:798) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:458) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:738) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:772) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:783) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:65) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[jira] [Commented] (LUCENE-5981) CheckIndex modifies index without write.lock
[ https://issues.apache.org/jira/browse/LUCENE-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154576#comment-14154576 ] Robert Muir commented on LUCENE-5981: - How is it any worse than a normal reader with lockless commits? > CheckIndex modifies index without write.lock > > > Key: LUCENE-5981 > URL: https://issues.apache.org/jira/browse/LUCENE-5981 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-5981.patch > > > Instead it asks you nicely to "not do that". > Due to the way this is implemented, if you choose to drop corrupt segments, > it should obtain the lock before actually doing any reads too, or it might > lose more than you think or do other strange stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5981) CheckIndex modifies index without write.lock
[ https://issues.apache.org/jira/browse/LUCENE-5981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154551#comment-14154551 ] Michael McCandless commented on LUCENE-5981: I think we should obtain the lock even if you will not exorcise? Otherwise you can get false corruption reports? > CheckIndex modifies index without write.lock > > > Key: LUCENE-5981 > URL: https://issues.apache.org/jira/browse/LUCENE-5981 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-5981.patch > > > Instead it asks you nicely to "not do that". > Due to the way this is implemented, if you choose to drop corrupt segments, > it should obtain the lock before actually doing any reads too, or it might > lose more than you think or do other strange stuff. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-6513) Add a collectionsAPI call BALANCESLICEUNIQUE
[ https://issues.apache.org/jira/browse/SOLR-6513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154553#comment-14154553 ] Shalin Shekhar Mangar commented on SOLR-6513: - What's wrong with an API for doing a specific thing like auto re-balance leaders? This sounds way too complicated. > Add a collectionsAPI call BALANCESLICEUNIQUE > > > Key: SOLR-6513 > URL: https://issues.apache.org/jira/browse/SOLR-6513 > Project: Solr > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson > Attachments: SOLR-6513.patch > > > Another sub-task for SOLR-6491. The ability to assign a property on a > node-by-node basis is nice, but tedious to get right for a sysadmin, > especially if there are, say, 100s of nodes hosting a system. This JIRA would > essentially provide an automatic mechanism for assigning a property. This > particular command simply changes the cluster state, it doesn't do anything > like re-assign functions. > My idea for this version is fairly limited. You'd have to specify a > collection and there would be no attempt to, say, evenly distribute the > preferred leader role/property for this collection by looking at _other_ > collections. Or by looking at underlying hardware capabilities. Or > It would be a pretty simple round-robin assignment. About the only > intelligence built in would be to change as few roles/properties as possible. > Let's say that the correct number of nodes for this role turned out to be 3. > Any node currently having 3 properties for this collection would NOT be > changed. Any node having 2 properties would have one added that would be > taken from some node with > 3 properties like this. > This probably needs an optional parameter, something like > "includeInactiveNodes=true|false" > Since this is an arbitrary property, one must specify sliceUnique=true. So > for the "preferredLeader" functionality, one would specify something like: > action=BALANCESLICEUNIQUE&property=preferredLeader&proprety.value=true. > There are checks in this code that require the preferredLeader to have a t/f > value and require that sliceUnique bet true. That said, this can be called on > an arbitrary property that has only one such property per slice. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5982) Tools in misc/ like index splitters need to obtain write.lock
[ https://issues.apache.org/jira/browse/LUCENE-5982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154544#comment-14154544 ] Michael McCandless commented on LUCENE-5982: +1 > Tools in misc/ like index splitters need to obtain write.lock > - > > Key: LUCENE-5982 > URL: https://issues.apache.org/jira/browse/LUCENE-5982 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > > Just to prevent anyone from using these from accidental corruption, we should > obtain it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
