[jira] [Assigned] (SOLR-7854) Remove ZkStateReader.updateClusterState(false)
[ https://issues.apache.org/jira/browse/SOLR-7854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-7854: --- Assignee: Shalin Shekhar Mangar Remove ZkStateReader.updateClusterState(false) -- Key: SOLR-7854 URL: https://issues.apache.org/jira/browse/SOLR-7854 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 5.2.1 Reporter: Scott Blum Assignee: Shalin Shekhar Mangar Priority: Minor Labels: easyfix, newbie Attachments: SOLR-7854.patch Original Estimate: 2h Remaining Estimate: 2h `updateClusterState(false)` as far as I can tell has zero callers. It's super pointless anyway, because `updateClusterState(true)` is being used mostly from test code and in places where someone is trying to force a reload from ZK (for whatever reason). There's no point in asking for a deferred update when ZkStateReader is already going to keep itself in sync anyway. -- 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-MacOSX (64bit/jdk1.8.0) - Build # 2566 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2566/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.lucene.TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([7B063949A8B1F445:FC8784E4AC918E41]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.lucene.TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler(TestMergeSchedulerExternal.java:116) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) 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:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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:54) 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 696 lines...] [junit4] Suite: org.apache.lucene.TestMergeSchedulerExternal [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestMergeSchedulerExternal -Dtests.method=testSubclassConcurrentMergeScheduler -Dtests.seed=7B063949A8B1F445 -Dtests.slow=true -Dtests.locale=ja_JP -Dtests.timezone=Australia/Perth -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] FAILURE 0.74s J1 | TestMergeSchedulerExternal.testSubclassConcurrentMergeScheduler [junit4] Throwable #1: java.lang.AssertionError [junit4]at
Lucene / Solr and Topic Modeling?
Hey Folks, Does anyone know of a good ALv2 compatible approach to Lucene and to topic modeling? I’m looking to not have to do it post-facto e.g. with a specific library, but to actually perform topic modeling like LDA (or something else) while building the index. The topic modeling needs to be scalable and dynamic - e.g., if I change a query on years, the topics should be updated accordingly. Is this possible with Lucene? I’ve found this: https://github.com/stepthom/lucene-lda But it seems like it stopped short of the calls to actual topic modeling e.g., with MALLET, etc. Thanks for any help here. Cheers, Chris ++ Chris Mattmann, Ph.D. Chief Architect Instrument Software and Science Data Systems Section (398) NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 168-519, Mailstop: 168-527 Email: chris.a.mattm...@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Associate Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7849) Secure Inter-node communication in a standard mechanism
[
https://issues.apache.org/jira/browse/SOLR-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650095#comment-14650095
]
Noble Paul commented on SOLR-7849:
--
bq. How will node B be able to lookup the public key from core admin API of
node A if A requires B to also authenticate? Perhaps publish pub-key through ZK
instead of core admin?
The public-key will be available at every node through a standard end-point e.g
{{/admin/cores/key}} which will always be unprotected
bq.What should happen in multi-DC case; would cross cluster communication be
treated as internal?
That mechanism will have to be sorted out. Not a part of this ticket
e.g : node-A in DC1 cluster wants to lookup node-P in DC2 cluster. We will
publish the zk address of DC2 cluster in ZK of DC1 cluster and vice versa. This
way node-A will trust al nodes in DC2 cluster as well
bq.What would original-user-principal be in case the action is initiated by
Solr and not an external request?
It will be a standard string like {{'$'}} which means the node itself is the
principal
Secure Inter-node communication in a standard mechanism
Key: SOLR-7849
URL: https://issues.apache.org/jira/browse/SOLR-7849
Project: Solr
Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul
Relying on every Authentication plugin to secure the internode communication
is error prone. Solr can standardize the authentication so that only the
first request that comes from outside the cluster needs to be authenticated
by the authentication plugin
The scheme to protect the communication will be as follows
* Every Solr node creates a an RSA key pair
* The private key is kept private and the public key is made available
through a core admin API
* If authentication is enabled , every outgoing request will carry an extra
header {{ SolrAuth : nodename
encrypt_with_pvt_key(original-user-principal timestamp) }}
* If authentication is enabled {{SolrDispatchFilter}} would look for this
header and see the nodename
** If the public key of the nodename is available in cache , make a request
to the node and fetch the public key
** If the public key has changed (because of a server restart) decryption
fails and the public keyis fetched again
* If the decryption succeeds , the user-name is set to what the header has
encoded
--
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-2522) add syntax for selecting the min or max of a multivalued field in value source functions
[
https://issues.apache.org/jira/browse/SOLR-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649459#comment-14649459
]
ASF subversion and git services commented on SOLR-2522:
---
Commit 1693628 from hoss...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1693628 ]
SOLR-2522: new two argument option for the existing field() function; picks the
min/max value of a docValues field to use as a ValueSource:
field(field_name,min) and field(field_name,max) (merge r1693625)
add syntax for selecting the min or max of a multivalued field in value
source functions
Key: SOLR-2522
URL: https://issues.apache.org/jira/browse/SOLR-2522
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Hoss Man
Attachments: SOLR-2522.patch, SOLR-2522.patch, SOLR-2522.patch
Initial request...
bq. Switch max() and min() functions to work on multiValued fields so we can
do sort=min(fieldname) asc and the sort would work on multiValued fields...
...this specific syntax has been spun off into SOLR-7853, but the underlying
functionality s being implemented here using a new optional second argument
to the {{field()}} function: {{field(multivalued_field_name,min)}} and
{{field(multivalued_field_name,max)}}.
--
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-5868) JoinUtil support for NUMERIC docValues fields
[ https://issues.apache.org/jira/browse/LUCENE-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649363#comment-14649363 ] marc schipperheyn commented on LUCENE-5868: --- I'd vote for it. JoinUtil support for NUMERIC docValues fields -- Key: LUCENE-5868 URL: https://issues.apache.org/jira/browse/LUCENE-5868 Project: Lucene - Core Issue Type: New Feature Reporter: Mikhail Khludnev Assignee: Mikhail Khludnev Priority: Minor while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at least. I plan to provide test/patch. It might be important, because Solr's join can do that. Please vote if you care! -- 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: [JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.8.0) - Build # 2564 - Failure!
Can we please disable these CDCR tests? Looks like no one is actively trying to fix them. On Fri, Jul 31, 2015 at 9:49 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2564/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests Error Message: Timeout while trying to assert update logs @ collection=source_collection Stack Trace: java.lang.AssertionError: Timeout while trying to assert update logs @ collection=source_collection at __randomizedtesting.SeedInfo.seed([404A5D9C92A7051A:482A28B09DA92D11]:0) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.assertNumberOfTlogFiles(CdcrReplicationDistributedZkTest.java:644) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestUpdateLogSynchronisation(CdcrReplicationDistributedZkTest.java:384) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:50) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) 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:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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:54) at
[jira] [Resolved] (SOLR-2522) add syntax for selecting the min or max of a multivalued field in value source functions
[
https://issues.apache.org/jira/browse/SOLR-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-2522.
Resolution: Fixed
Fix Version/s: Trunk
5.3
add syntax for selecting the min or max of a multivalued field in value
source functions
Key: SOLR-2522
URL: https://issues.apache.org/jira/browse/SOLR-2522
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Hoss Man
Fix For: 5.3, Trunk
Attachments: SOLR-2522.patch, SOLR-2522.patch, SOLR-2522.patch
Initial request...
bq. Switch max() and min() functions to work on multiValued fields so we can
do sort=min(fieldname) asc and the sort would work on multiValued fields...
...this specific syntax has been spun off into SOLR-7853, but the underlying
functionality s being implemented here using a new optional second argument
to the {{field()}} function: {{field(multivalued_field_name,min)}} and
{{field(multivalued_field_name,max)}}.
--
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-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-5756: - Attachment: SOLR-5756-vs-5.2.1.patch Initial stab at something working, based on 5.2.1. Haven't run through test suite yet. A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-5756-vs-5.2.1.patch SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-trunk-Linux (32bit/jdk1.9.0-ea-b60) - Build # 13677 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13677/ Java: 32bit/jdk1.9.0-ea-b60 -server -XX:+UseSerialGC -Djava.locale.providers=JRE,SPI 1 tests failed. FAILED: org.apache.solr.cloud.ShardSplitTest.test Error Message: Timeout occured while waiting response from server at: http://127.0.0.1:53429/yvwji Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: http://127.0.0.1:53429/yvwji at __randomizedtesting.SeedInfo.seed([3B456047290870EC:B3115F9D87F41D14]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:572) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.ShardSplitTest.splitShard(ShardSplitTest.java:490) at org.apache.solr.cloud.ShardSplitTest.incompleteOrOverlappingCustomRangeTest(ShardSplitTest.java:111) at org.apache.solr.cloud.ShardSplitTest.test(ShardSplitTest.java:76) 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:502) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) 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:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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:54) at
[jira] [Commented] (LUCENE-5868) JoinUtil support for NUMERIC docValues fields
[ https://issues.apache.org/jira/browse/LUCENE-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649469#comment-14649469 ] Mikhail Khludnev commented on LUCENE-5868: -- [~mschipperheyn] what's your usecase? why you can't use SORTED? do you need to join cross cores? Have you had a look at OrdinalMap join? JoinUtil support for NUMERIC docValues fields -- Key: LUCENE-5868 URL: https://issues.apache.org/jira/browse/LUCENE-5868 Project: Lucene - Core Issue Type: New Feature Reporter: Mikhail Khludnev Assignee: Mikhail Khludnev Priority: Minor while polishing SOLR-6234 I found that JoinUtil can't join int dv fields at least. I plan to provide test/patch. It might be important, because Solr's join can do that. Please vote if you care! -- 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-7823) TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async collection-creation (sometimes)
[ https://issues.apache.org/jira/browse/SOLR-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649354#comment-14649354 ] ASF subversion and git services commented on SOLR-7823: --- Commit 1693616 from [~cpoerschke] in branch 'dev/trunk' [ https://svn.apache.org/r1693616 ] SOLR-7823: TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async collection-creation (sometimes) TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async collection-creation (sometimes) --- Key: SOLR-7823 URL: https://issues.apache.org/jira/browse/SOLR-7823 Project: Solr Issue Type: Test Reporter: Christine Poerschke Assignee: Christine Poerschke Priority: Minor github pull request with proposed changes to follow -- 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-7823) TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async collection-creation (sometimes)
[ https://issues.apache.org/jira/browse/SOLR-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649450#comment-14649450 ] ASF subversion and git services commented on SOLR-7823: --- Commit 1693627 from [~cpoerschke] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1693627 ] SOLR-7823: TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async collection-creation (sometimes) TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async collection-creation (sometimes) --- Key: SOLR-7823 URL: https://issues.apache.org/jira/browse/SOLR-7823 Project: Solr Issue Type: Test Reporter: Christine Poerschke Assignee: Christine Poerschke Priority: Minor github pull request with proposed changes to follow -- 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-MacOSX (64bit/jdk1.8.0) - Build # 2564 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2564/ Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests Error Message: Timeout while trying to assert update logs @ collection=source_collection Stack Trace: java.lang.AssertionError: Timeout while trying to assert update logs @ collection=source_collection at __randomizedtesting.SeedInfo.seed([404A5D9C92A7051A:482A28B09DA92D11]:0) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.assertNumberOfTlogFiles(CdcrReplicationDistributedZkTest.java:644) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestUpdateLogSynchronisation(CdcrReplicationDistributedZkTest.java:384) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests(CdcrReplicationDistributedZkTest.java:50) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) 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:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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:54) 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] (SOLR-2522) add syntax for selecting the min or max of a multivalued field in value source functions
[
https://issues.apache.org/jira/browse/SOLR-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649424#comment-14649424
]
ASF subversion and git services commented on SOLR-2522:
---
Commit 1693625 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1693625 ]
SOLR-2522: new two argument option for the existing field() function; picks the
min/max value of a docValues field to use as a ValueSource:
field(field_name,min) and field(field_name,max)
add syntax for selecting the min or max of a multivalued field in value
source functions
Key: SOLR-2522
URL: https://issues.apache.org/jira/browse/SOLR-2522
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Hoss Man
Attachments: SOLR-2522.patch, SOLR-2522.patch, SOLR-2522.patch
Initial request...
bq. Switch max() and min() functions to work on multiValued fields so we can
do sort=min(fieldname) asc and the sort would work on multiValued fields...
...this specific syntax has been spun off into SOLR-7853, but the underlying
functionality s being implemented here using a new optional second argument
to the {{field()}} function: {{field(multivalued_field_name,min)}} and
{{field(multivalued_field_name,max)}}.
--
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 (32bit/jdk1.8.0_51) - Build # 5087 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5087/ Java: 32bit/jdk1.8.0_51 -server -XX:+UseG1GC 3 tests failed. FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.test Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([CDF0CB945A41E5FF:45A4F44EF4BD8807]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.allTests(CloudSolrClientTest.java:257) at org.apache.solr.client.solrj.impl.CloudSolrClientTest.test(CloudSolrClientTest.java:114) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:110) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) 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:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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:54) 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
cwiki.apache.org edit right for cpoerschke
Hi, Could i be added also please? This would initially just be for updating https://cwiki.apache.org/confluence/display/solr/Collections+API?src=search w.r.t. https://issues.apache.org/jira/i#browse/SOLR-7766 when that is committed (hopefully early next week). Thanks, Christine From: dev@lucene.apache.org At: Jul 30 2015 20:43:12 To: dev@lucene.apache.org Subject: Re:cwiki.a.org edit right for mkhludnev Hello, Would you let mkhludnev (not mkhl) to edit https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide ? Thanks! -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics
Re: cwiki.apache.org edit right for cpoerschke
Hi Christine, I would have added you when I added Mikhail, but autocomplete doesn’t turn up anything when trying to add permission for you. Do you have a Confluence account? If not, go here and make one: https://cwiki.apache.org/confluence/signup.action and then let us know what it is. If you already have a Confluence account, what is it? Steve www.lucidworks.com On Jul 31, 2015, at 1:30 PM, Christine Poerschke (BLOOMBERG/ LONDON) cpoersc...@bloomberg.net wrote: Hi, Could i be added also please? This would initially just be for updating https://cwiki.apache.org/confluence/display/solr/Collections+API?src=search w.r.t. https://issues.apache.org/jira/i#browse/SOLR-7766 when that is committed (hopefully early next week). Thanks, Christine From: dev@lucene.apache.org At: Jul 30 2015 20:43:12 To: dev@lucene.apache.org Subject: Re:cwiki.a.org edit right for mkhludnev Hello, Would you let mkhludnev (not mkhl) to edit https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide ? Thanks! -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: cwiki.apache.org edit right for cpoerschke
Okay, I’ve added permissions for you, so you should now be able to edit. - Steve On Jul 31, 2015, at 2:00 PM, Christine Poerschke (BLOOMBERG/ LONDON) cpoersc...@bloomberg.net wrote: Hi Steve, oops, apologies, my mistake, created myself a Confluence account now. Thanks, Christine - Original Message - From: sar...@gmail.com To: Christine Poerschke (BLOOMBERG/ LONDON), dev@lucene.apache.org At: Jul 31 2015 18:47:42 Hi Christine, I would have added you when I added Mikhail, but autocomplete doesn’t turn up anything when trying to add permission for you. Do you have a Confluence account? If not, go here and make one: https://cwiki.apache.org/confluence/signup.action and then let us know what it is. If you already have a Confluence account, what is it? Steve www.lucidworks.com On Jul 31, 2015, at 1:30 PM, Christine Poerschke (BLOOMBERG/ LONDON) cpoersc...@bloomberg.net wrote: Hi, Could i be added also please? This would initially just be for updating https://cwiki.apache.org/confluence/display/solr/Collections+API?src=search w.r.t. https://issues.apache.org/jira/i#browse/SOLR-7766 when that is committed (hopefully early next week). Thanks, Christine From: dev@lucene.apache.org At: Jul 30 2015 20:43:12 To: dev@lucene.apache.org Subject: Re:cwiki.a.org edit right for mkhludnev Hello, Would you let mkhludnev (not mkhl) to edit https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide ? Thanks! -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7854) Remove ZkStateReader.updateClusterState(false)
Scott Blum created SOLR-7854: Summary: Remove ZkStateReader.updateClusterState(false) Key: SOLR-7854 URL: https://issues.apache.org/jira/browse/SOLR-7854 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 5.2.1 Reporter: Scott Blum Priority: Minor `updateClusterState(false)` as I can tell has zero callers. It's super pointless anyway, because `updateClusterState(true)` is being used mostly from test code and in places where someone is trying to force a reload from ZK (for whatever reason). There's no point in asking for a deferred update when ZkStateReader is already going to keep itself in sync anyway. -- 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-7854) Remove ZkStateReader.updateClusterState(false)
[ https://issues.apache.org/jira/browse/SOLR-7854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-7854: - Description: `updateClusterState(false)` as far as I can tell has zero callers. It's super pointless anyway, because `updateClusterState(true)` is being used mostly from test code and in places where someone is trying to force a reload from ZK (for whatever reason). There's no point in asking for a deferred update when ZkStateReader is already going to keep itself in sync anyway. was: `updateClusterState(false)` as I can tell has zero callers. It's super pointless anyway, because `updateClusterState(true)` is being used mostly from test code and in places where someone is trying to force a reload from ZK (for whatever reason). There's no point in asking for a deferred update when ZkStateReader is already going to keep itself in sync anyway. Remove ZkStateReader.updateClusterState(false) -- Key: SOLR-7854 URL: https://issues.apache.org/jira/browse/SOLR-7854 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 5.2.1 Reporter: Scott Blum Priority: Minor Labels: easyfix, newbie Original Estimate: 2h Remaining Estimate: 2h `updateClusterState(false)` as far as I can tell has zero callers. It's super pointless anyway, because `updateClusterState(true)` is being used mostly from test code and in places where someone is trying to force a reload from ZK (for whatever reason). There's no point in asking for a deferred update when ZkStateReader is already going to keep itself in sync anyway. -- 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-7854) Remove ZkStateReader.updateClusterState(false)
[ https://issues.apache.org/jira/browse/SOLR-7854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649644#comment-14649644 ] Mark Miller commented on SOLR-7854: --- updateClusterState(false) use to be used a lot to prevent silly rapid updates faster than was useful. Long ago, someone removed it's use but never cleaned it up fully. Remove ZkStateReader.updateClusterState(false) -- Key: SOLR-7854 URL: https://issues.apache.org/jira/browse/SOLR-7854 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 5.2.1 Reporter: Scott Blum Priority: Minor Labels: easyfix, newbie Original Estimate: 2h Remaining Estimate: 2h `updateClusterState(false)` as far as I can tell has zero callers. It's super pointless anyway, because `updateClusterState(true)` is being used mostly from test code and in places where someone is trying to force a reload from ZK (for whatever reason). There's no point in asking for a deferred update when ZkStateReader is already going to keep itself in sync anyway. -- 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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649651#comment-14649651
]
Mark Miller commented on SOLR-7766:
---
replicationFactor can also be used as a target for things like autoAddReplicas.
I think the empty createNodeSet makes a lot more sense.
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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 (32bit/jdk1.8.0_51) - Build # 5088 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5088/
Java: 32bit/jdk1.8.0_51 -client -XX:+UseSerialGC
1 tests failed.
FAILED: org.apache.lucene.store.TestNativeFSLockFactory.testStressLocks
Error Message:
Captured an uncaught exception in thread: Thread[id=1702, name=Thread-1267,
state=RUNNABLE, group=TGRP-TestNativeFSLockFactory]
Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught
exception in thread: Thread[id=1702, name=Thread-1267, state=RUNNABLE,
group=TGRP-TestNativeFSLockFactory]
at
__randomizedtesting.SeedInfo.seed([732AB104B012668E:2D1BFFF9ACBEAEE8]:0)
Caused by: java.lang.AssertionError: hit unexpected NoSuchFileException:
file=_o.cfs
at __randomizedtesting.SeedInfo.seed([732AB104B012668E]:0)
at
org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:750)
at
org.apache.lucene.index.IndexFileDeleter.deletePendingFiles(IndexFileDeleter.java:528)
at
org.apache.lucene.index.IndexFileDeleter.decRef(IndexFileDeleter.java:636)
at
org.apache.lucene.index.IndexFileDeleter.close(IndexFileDeleter.java:470)
at
org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2080)
at org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1067)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1109)
at
org.apache.lucene.store.BaseLockFactoryTestCase$WriterThread.run(BaseLockFactoryTestCase.java:221)
Build Log:
[...truncated 1685 lines...]
[junit4] Suite: org.apache.lucene.store.TestNativeFSLockFactory
[junit4] 2 jul 31, 2015 10:32:17 PM
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
uncaughtException
[junit4] 2 WARNING: Uncaught exception in thread:
Thread[Thread-1267,5,TGRP-TestNativeFSLockFactory]
[junit4] 2 java.lang.AssertionError: hit unexpected NoSuchFileException:
file=_o.cfs
[junit4] 2at
__randomizedtesting.SeedInfo.seed([732AB104B012668E]:0)
[junit4] 2at
org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:750)
[junit4] 2at
org.apache.lucene.index.IndexFileDeleter.deletePendingFiles(IndexFileDeleter.java:528)
[junit4] 2at
org.apache.lucene.index.IndexFileDeleter.decRef(IndexFileDeleter.java:636)
[junit4] 2at
org.apache.lucene.index.IndexFileDeleter.close(IndexFileDeleter.java:470)
[junit4] 2at
org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2080)
[junit4] 2at
org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1067)
[junit4] 2at
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1109)
[junit4] 2at
org.apache.lucene.store.BaseLockFactoryTestCase$WriterThread.run(BaseLockFactoryTestCase.java:221)
[junit4] 2
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TestNativeFSLockFactory -Dtests.method=testStressLocks
-Dtests.seed=732AB104B012668E -Dtests.slow=true -Dtests.locale=sr_ME_#Latn
-Dtests.timezone=Asia/Tehran -Dtests.asserts=true -Dtests.file.encoding=Cp1252
[junit4] ERROR 2.18s J1 | TestNativeFSLockFactory.testStressLocks
[junit4] Throwable #1:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught
exception in thread: Thread[id=1702, name=Thread-1267, state=RUNNABLE,
group=TGRP-TestNativeFSLockFactory]
[junit4]at
__randomizedtesting.SeedInfo.seed([732AB104B012668E:2D1BFFF9ACBEAEE8]:0)
[junit4] Caused by: java.lang.AssertionError: hit unexpected
NoSuchFileException: file=_o.cfs
[junit4]at
__randomizedtesting.SeedInfo.seed([732AB104B012668E]:0)
[junit4]at
org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:750)
[junit4]at
org.apache.lucene.index.IndexFileDeleter.deletePendingFiles(IndexFileDeleter.java:528)
[junit4]at
org.apache.lucene.index.IndexFileDeleter.decRef(IndexFileDeleter.java:636)
[junit4]at
org.apache.lucene.index.IndexFileDeleter.close(IndexFileDeleter.java:470)
[junit4]at
org.apache.lucene.index.IndexWriter.rollbackInternal(IndexWriter.java:2080)
[junit4]at
org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1067)
[junit4]at
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1109)
[junit4]at
org.apache.lucene.store.BaseLockFactoryTestCase$WriterThread.run(BaseLockFactoryTestCase.java:221)
[junit4] IGNOR/A 0.01s J1 | TestNativeFSLockFactory.testDeleteLockFile
[junit4] Assumption #1: test requires the ability to delete a locked
file(throwable: java.io.IOException: cannot delete file: test.lock, a virus
scanner has it open)
[junit4] 2 NOTE: test params are: codec=Asserting(Lucene53):
{content=FSTOrd50}, docValues:{}, sim=DefaultSimilarity, locale=sr_ME_#Latn,
[jira] [Closed] (SOLR-5662) {!parent} parser with scoreMode
[
https://issues.apache.org/jira/browse/SOLR-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev closed SOLR-5662.
--
Resolution: Duplicate
address it at SOLR-5882
{!parent} parser with scoreMode
---
Key: SOLR-5662
URL: https://issues.apache.org/jira/browse/SOLR-5662
Project: Solr
Issue Type: Improvement
Affects Versions: 4.5, 4.6
Reporter: Moritz Munte
Priority: Minor
ToParentBlockJoinQuery has support for different score modes, but {!parent}
parser has None mode hardcoded without an option to change it.
It would be usefull if there is a parameter to change the score mode or set a
reasonable default.
--
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-6234) Scoring modes for query time join
[
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649489#comment-14649489
]
Cassandra Targett commented on SOLR-6234:
-
[~mkhludnev]. First, thanks so much for proactively updating the Ref Guide with
your changes.
I hope you don't mind too much, but I modified your text in a few ways:
* The online version of the Ref Guide is always for the upcoming release of
Solr, and as such we don't spend a lot of time describing how features used to
work. While I understand that causes some confusion from time-to-time, a major
problem with the old Solr Wiki was the attempt to maintain documentation for
older versions of Solr along with the changes along the way. Personally, I find
no harm mentioning when a feature was introduced, but at that point our
convention is to remove documentation for the old behavior (unless, of course,
the section is describing how to migrate to the new behavior).
* With this general guideline, on the Uploading Data with Index Handlers page I
flipped the emphasis to note the need to use the score parameter when deleting
with the Join QP to avoid the error, and omitted the reference to 5.3 because
the guide is for 5.3 already, and the section we're pointing to says the param
was introduced in 5.3.
* I re-worded the text a bit to provide more context for a less-expert user.
* Standardized phrasings - i.e., plain Solr is usually referred to as
standalone Solr.
Scoring modes for query time join
--
Key: SOLR-6234
URL: https://issues.apache.org/jira/browse/SOLR-6234
Project: Solr
Issue Type: New Feature
Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Mikhail Khludnev
Labels: features, patch, test
Fix For: 5.3
Attachments: SOLR-6234-javadocsfix.patch, SOLR-6234.patch,
SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch,
SOLR-6234.patch, SOLR-6234.patch, otherHandler.patch
it adds ability to call Lucene's JoinUtil by specifying local param, ie
\{!join score=...} It supports:
- {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
- -supports {{b=100}} param to pass {{Query.setBoost()}}- postponed till
SOLR-7814.
- -{{multiVals=true|false}} is introduced- YAGNI, let me know otherwise.
- there is a test coverage for cross core join case.
- so far it joins string and multivalue string fields (Sorted, SortedSet,
Binary), but not Numerics DVs. follow-up LUCENE-5868
--
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-6234) Scoring modes for query time join
[
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev resolved SOLR-6234.
Resolution: Fixed
Scoring modes for query time join
--
Key: SOLR-6234
URL: https://issues.apache.org/jira/browse/SOLR-6234
Project: Solr
Issue Type: New Feature
Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Mikhail Khludnev
Labels: features, patch, test
Fix For: 5.3
Attachments: SOLR-6234-javadocsfix.patch, SOLR-6234.patch,
SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch,
SOLR-6234.patch, SOLR-6234.patch, otherHandler.patch
it adds ability to call Lucene's JoinUtil by specifying local param, ie
\{!join score=...} It supports:
- {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
- -supports {{b=100}} param to pass {{Query.setBoost()}}- postponed till
SOLR-7814.
- -{{multiVals=true|false}} is introduced- YAGNI, let me know otherwise.
- there is a test coverage for cross core join case.
- so far it joins string and multivalue string fields (Sorted, SortedSet,
Binary), but not Numerics DVs. follow-up LUCENE-5868
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke reassigned SOLR-7766:
-
Assignee: Christine Poerschke (was: Ramkumar Aiyengar)
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-5756: - Attachment: SOLR-5756-vs-5.2.1.patch (couple of comments and fixed one thing) A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-5756-vs-5.2.1.patch, SOLR-5756-vs-5.2.1.patch SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- 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-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-5756: - Attachment: (was: SOLR-5756-vs-5.2.1.patch) A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-5756-vs-5.2.1.patch SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- 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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649509#comment-14649509
]
Christine Poerschke commented on SOLR-7766:
---
Rebasing patch against latest trunk (to include SOLR-7823 changes), existing
patch fails {{async=...}} tests.
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-5756: - Attachment: SOLR-5756-vs-5.2.1.patch (more bugfixes... will tests pass?) A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-5756-vs-5.2.1.patch SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- 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-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-5756: - Attachment: (was: SOLR-5756-vs-5.2.1.patch) A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-5756-vs-5.2.1.patch SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- 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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649646#comment-14649646
]
Shalin Shekhar Mangar commented on SOLR-7766:
-
How about replicationFactor=0 instead of an empty createNodeSet parameter?
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649660#comment-14649660
]
Shalin Shekhar Mangar commented on SOLR-7766:
-
bq. replicationFactor can also be used as a target for things like
autoAddReplicas. I think the empty createNodeSet makes a lot more sense.
You forget that we now have a modify collection API which lets you change the
replication factor among other things. Specifying an empty parameter to change
the behavior of an API seems very hacky to me. An empty parameter should either
have no effect or it should result in an error.
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649677#comment-14649677
]
Mark Miller commented on SOLR-7766:
---
bq. API seems very hacky to me.
What's the hack exactly?
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649701#comment-14649701
]
Christine Poerschke commented on SOLR-7766:
---
Alrightly, let's go for {{createNodeSet=someSpecialValue}} - i will have a look
around (on Monday) to see if 'empty' vs. 'EMPTY' vs. 'NONE' there is a
precedent already, so that for consistency the same could be used here? Thanks
[~shalinmangar] and [~markrmil...@gmail.com] for your input!
PS: github pull request now updated (still has createNodeSet= though, will be
updating both code and the newly added test case to use the special value).
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-6234) Scoring modes for query time join
[
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-6234:
---
Attachment: SOLR-6234-trunk-CHANGES-fix.patch
[~hossman_luc...@fucit.org] does it make sense?
Scoring modes for query time join
--
Key: SOLR-6234
URL: https://issues.apache.org/jira/browse/SOLR-6234
Project: Solr
Issue Type: New Feature
Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Mikhail Khludnev
Labels: features, patch, test
Fix For: 5.3
Attachments: SOLR-6234-javadocsfix.patch,
SOLR-6234-trunk-CHANGES-fix.patch, SOLR-6234.patch, SOLR-6234.patch,
SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch,
SOLR-6234.patch, otherHandler.patch
it adds ability to call Lucene's JoinUtil by specifying local param, ie
\{!join score=...} It supports:
- {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
- -supports {{b=100}} param to pass {{Query.setBoost()}}- postponed till
SOLR-7814.
- -{{multiVals=true|false}} is introduced- YAGNI, let me know otherwise.
- there is a test coverage for cross core join case.
- so far it joins string and multivalue string fields (Sorted, SortedSet,
Binary), but not Numerics DVs. follow-up LUCENE-5868
--
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
Understanding performance degradation in range queries between Solr 5.2.1 and 4.10.4
Hi, I'm seeing some query performance degradation between 4.10.4 and 5.2.1. It doesn't happen with all the queries, but for queries like range queries on fields with many different values the average time in 5.2.1 is worse than in 4.10.4. Is anyone seeing something similar? Test Details: * Single thread running queries continuously. I run the test twice for each Solr version. * JMeter running on my laptop, Solr running on EC2, on an m3.xlarge instance with all the defaults but with 5G heap. Index in local disk (SSD) * Plain Solr releases, nothing custom. Single Solr core, not in SolrCloud mode, no distributed search. * allCountries geonames dataset (~8M small docs). No updates during the test. Index Size is around 1.1GB for Solr 5.2.1 and 1.3GB for Solr 4.10.4 (fits entirely in RAM) * jdk1.8.0_45 Queries: 3k boolean queries (generated with terms from the dataset) with range queries as filters on tlongitude and tlatitude fields with randomly generated bounds, e.g. q=name:foo OR name:barfq=tlongitude:[W TO X]fq=tlatitude:[Y TO Z] Fields are: field name=tlatitude type=tdouble/ field name=tlongitude type=tdouble/ Field Type: fieldType name=tdouble class=solr.TrieDoubleField precisionStep=8 positionIncrementGap=0/ In this case, Solr 4.10.4 was between 20% to 30% faster than 5.2.1 in average. http://snag.gy/2yPPM.jpg Doing only the boolean queries show no performance difference between 4.10 and 5.2, same thing if I do filters on a string field instead of the range queries. When using double field type (precisionStep=0), the difference was bigger: longitude/latitude fields: field name=longitude type=double docValues=true/ field name=latitude type=double docValues=true/ fieldType name=double class=solr.TrieDoubleField precisionStep=0 positionIncrementGap=0/ http://snag.gy/Vi5uk.jpg I understand this is not the best field type definition for range queries, I'm just trying to understand the difference between the two versions and why. Performance was OK when doing range queries on the population field (long), but that field doesn't have many different values, only 300k out of the 8.3M docs have the population field with a value different to 0. On the other hand, doing range queries on the _version_ field did show a graph similar to the previous one: field name=_version_ type=long indexed=true stored=true/ fieldType name=long class=solr.TrieLongField precisionStep=0 positionIncrementGap=0/ http://snag.gy/4tc7e.jpg Any idea what could be causing this? Is this expected after some known change? With Solr 4.10, a single CPU core remains high during the test (close to 100%), but with Solr 5.2, different cores go up and down in utilization continuously. That's probably because of the different Jetty version I suppose. GC pattern looks similar in both. For both Solr versions I'm using the settings that ship with Solr (in solr.in.sh) except for Xmx and Xms
[jira] [Commented] (SOLR-7850) Move user customization out of solr.in.* scripts
[
https://issues.apache.org/jira/browse/SOLR-7850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649824#comment-14649824
]
Shawn Heisey commented on SOLR-7850:
I've now used the install_solr_service script on my dev server. Overall, I
think it does a good job, and some of what I initially thought was strange (in
particular the solr.in.* script), makes much more sense now.
[~thelabdude], I will collect my thoughts and try to present some coherent
bikeshedding. I don't expect everyone to agree with my ideas, but I do firmly
believe that having the conversation is helpful.
Move user customization out of solr.in.* scripts
Key: SOLR-7850
URL: https://issues.apache.org/jira/browse/SOLR-7850
Project: Solr
Issue Type: Improvement
Components: scripts and tools
Affects Versions: 5.2.1
Reporter: Shawn Heisey
Priority: Minor
I've seen a fair number of users customizing solr.in.* scripts to make
changes to their Solr installs. I think the documentation suggests this,
though I haven't confirmed.
One possible problem with this is that we might make changes in those scripts
which such a user would want in their setup, but if they replace the script
with the one in the new version, they will lose their customizations.
I propose instead that we have the startup script look for and utilize a user
customization script, in a similar manner to linux init scripts that look for
/etc/default/packagename, but are able to function without it. I'm not
entirely sure where the script should live or what it should be called. One
idea is server/etc/userconfig.\{sh,cmd\} ... but I haven't put a lot of
thought into it yet.
If the internal behavior of our scripts is largely replaced by a small java
app as detailed in SOLR-7043, then the same thing should apply there -- have
a config file for a user to specify settings, but work perfectly if that
config file is absent.
--
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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649679#comment-14649679
]
Christine Poerschke commented on SOLR-7766:
---
I agree re: the differentiation between {{createNodeSet}} missing and
{{createNodeSet=}} present-and-empty is very subtle. Would a special value e.g.
{{createNodeSet=EMPTY}} be clearer?
The way i read
[OverseerCollectionProcessor.java|https://github.com/apache/lucene-solr/blob/trunk/solr/core/src/java/org/apache/solr/cloud/OverseerCollectionProcessor.java]
line 2233 currently an empty parameter would result in an error, right? [Draft
Collections API
docs|https://cwiki.apache.org/confluence/display/solr/Collections+API?src=search]
list 'empty' as the default though (should it be 'blank box' as for 'async'?).
Will update github pull request against latest trunk (with createNodeSet=)
shortly and definitely hold off on any commits until agreement on how to
request coreless collection creation is reached.
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-5756: - Attachment: (was: SOLR-5756-vs-5.2.1.patch) A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-5756-vs-5.2.1.patch SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- 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-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-5756: - Attachment: SOLR-5756-vs-5.2.1.patch I think the tests are actually passing now. A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-5756-vs-5.2.1.patch SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- 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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649780#comment-14649780
]
Mark Miller commented on SOLR-7766:
---
I think EMPTY is probably the right choice - I was just shooting from the hip
with none.
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-5022) PermGen exhausted test failures on Jenkins.
[ https://issues.apache.org/jira/browse/SOLR-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649816#comment-14649816 ] ASF subversion and git services commented on SOLR-5022: --- Commit 1693649 from [~thetaphi] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1693649 ] SOLR-5022: Limit permgen settings to Hotspot/OpenJDK PermGen exhausted test failures on Jenkins. --- Key: SOLR-5022 URL: https://issues.apache.org/jira/browse/SOLR-5022 Project: Solr Issue Type: Test Components: Tests Reporter: Mark Miller Assignee: Uwe Schindler Priority: Critical Fix For: 5.3 Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, SOLR-5022.patch, intern-count-win.txt -- 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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649672#comment-14649672
]
Mark Miller edited comment on SOLR-7766 at 7/31/15 7:17 PM:
No, I know you can change it.
It simply doesn't make sense to me like I said. You are not asking for a target
replication factor of 0. You are asking that no nodes get a core. Having an
empty createNodeSet matches the intent much more than messing with replication
factor.
was (Author: markrmil...@gmail.com):
No, I know you can change it.
It simply doesn't make sense to me like you I said. You are not asking for a
target replication factor of 0. You are asking that no nodes get a core. Having
an empty createNodeSet matches the intent much more than messing with
replication factor.
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649685#comment-14649685
]
Shalin Shekhar Mangar commented on SOLR-7766:
-
bq. Would a special value e.g. createNodeSet=EMPTY be clearer?
Yeah, createNodeSet=EMPTY or createNodeSet=NONE would be much clearer than an
empty parameter.
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-7819) ZkController.ensureReplicaInLeaderInitiatedRecovery does not respect retryOnConnLoss
[ https://issues.apache.org/jira/browse/SOLR-7819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-7819: Attachment: SOLR-7819.patch This patch moves all LIR related activity inside the LIR thread. The LIR thread now publishes LIR state, publishes node state and then starts a recovery loop depending on whether LIR state was published successfully or if it failed because of session expiry or connection loss. The indexing thread only consults the local replica map to ensure that only 1 LIR thread is started for any given replica. This ensures that the indexing thread never needs to wait for ZK operations needed for LIR. All tests pass except for HttpPartitionTest.testLeaderInitiatedRecoveryCRUD whose assumptions about the LIR workflow are no longer correct. Still running more tests. ZkController.ensureReplicaInLeaderInitiatedRecovery does not respect retryOnConnLoss Key: SOLR-7819 URL: https://issues.apache.org/jira/browse/SOLR-7819 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 5.2, 5.2.1 Reporter: Shalin Shekhar Mangar Labels: Jepsen Fix For: 5.3, Trunk Attachments: SOLR-7819.patch, SOLR-7819.patch SOLR-7245 added a retryOnConnLoss parameter to ZkController.ensureReplicaInLeaderInitiatedRecovery so that indexing threads do not hang during a partition on ZK operations. However, some of those changes were unintentionally reverted by SOLR-7336 in 5.2. I found this while running Jepsen tests on 5.2.1 where a hung update managed to put a leader into a 'down' state (I'm still investigating and will open a separate issue about this problem). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649672#comment-14649672
]
Mark Miller commented on SOLR-7766:
---
No, I know you can change it.
It simply doesn't make sense to me like you I said. You are not asking for a
target replication factor of 0. You are asking that no nodes get a core. Having
an empty createNodeSet matches the intent much more than messing with
replication factor.
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649696#comment-14649696
]
Mark Miller commented on SOLR-7766:
---
Consensus reached.
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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: svn commit: r1693101 - in /lucene/dev/branches/branch_5x: ./ dev-tools/ lucene/ lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/ lucene/analysis/common/src/java/org/apache
Oh.. yet another one mess. Would you mind to check https://issues.apache.org/jira/secure/attachment/12748235/SOLR-6234-trunk-CHANGES-fix.patch ? On Fri, Jul 31, 2015 at 9:00 PM, Chris Hostetter hossman_luc...@fucit.org wrote: Mikhail: something doesn't make sense about the CHANGES.txt entry for this after the merge (I noticed doing a subsequent merge) On the 5x branch SOLR-6234 is in the New Features section of 5.3, but on trunk it's in Other Changes of 6.0. : Date: Tue, 28 Jul 2015 14:44:17 - : From: m...@apache.org : Reply-To: dev@lucene.apache.org : To: comm...@lucene.apache.org : Subject: svn commit: r1693101 - in /lucene/dev/branches/branch_5x: ./ : dev-tools/ lucene/ : lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/ : lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/ : lucene/analysis/common/... : : Author: mkhl : Date: Tue Jul 28 14:44:15 2015 : New Revision: 1693101 : : URL: http://svn.apache.org/r1693101 : Log: : SOLR-6234: Scoring for query time join : : Added: : lucene/dev/branches/branch_5x/solr/core/src/java/org/apache/solr/search/ScoreJoinQParserPlugin.java : - copied unchanged from r1693092, lucene/dev/trunk/solr/core/src/java/org/apache/solr/search/join/ScoreJoinQParserPlugin.java : lucene/dev/branches/branch_5x/solr/core/src/test-files/solr/collection1/conf/schema-docValuesJoin.xml : - copied unchanged from r1693092, lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/schema-docValuesJoin.xml : lucene/dev/branches/branch_5x/solr/core/src/test/org/apache/solr/TestCrossCoreJoin.java : - copied unchanged from r1693092, lucene/dev/trunk/solr/core/src/test/org/apache/solr/TestCrossCoreJoin.java : lucene/dev/branches/branch_5x/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPNoScore.java : - copied unchanged from r1693092, lucene/dev/trunk/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPNoScore.java : lucene/dev/branches/branch_5x/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPScore.java : - copied unchanged from r1693092, lucene/dev/trunk/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPScore.java : Modified: : lucene/dev/branches/branch_5x/ (props changed) : lucene/dev/branches/branch_5x/dev-tools/ (props changed) : lucene/dev/branches/branch_5x/lucene/ (props changed) : lucene/dev/branches/branch_5x/lucene/BUILD.txt (props changed) : lucene/dev/branches/branch_5x/lucene/CHANGES.txt (props changed) : lucene/dev/branches/branch_5x/lucene/JRE_VERSION_MIGRATION.txt (props changed) : lucene/dev/branches/branch_5x/lucene/LICENSE.txt (props changed) : lucene/dev/branches/branch_5x/lucene/MIGRATE.txt (props changed) : lucene/dev/branches/branch_5x/lucene/NOTICE.txt (props changed) : lucene/dev/branches/branch_5x/lucene/README.txt (props changed) : lucene/dev/branches/branch_5x/lucene/SYSTEM_REQUIREMENTS.txt (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/Lucene47WordDelimiterFilter.java (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/ASCIITLD.jflex-macro (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/SUPPLEMENTARY.jflex-macro (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/StandardTokenizerImpl40.java (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/StandardTokenizerImpl40.jflex (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/UAX29URLEmailTokenizerImpl40.java (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/UAX29URLEmailTokenizerImpl40.jflex (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/package.html (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/test/org/apache/lucene/analysis/miscellaneous/TestLucene47WordDelimiterFilter.java (props changed) : lucene/dev/branches/branch_5x/lucene/backward-codecs/ (props changed) : lucene/dev/branches/branch_5x/lucene/benchmark/ (props changed) : lucene/dev/branches/branch_5x/lucene/build.xml (props changed) : lucene/dev/branches/branch_5x/lucene/classification/ (props changed) : lucene/dev/branches/branch_5x/lucene/classification/build.xml (props changed) : lucene/dev/branches/branch_5x/lucene/classification/ivy.xml (props changed) :
[jira] [Commented] (SOLR-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649684#comment-14649684
]
Mark Miller commented on SOLR-7766:
---
bq. createNodeSet=EMPTY be clearer?
lol - cross post with my edit. I would prefer that to abusing replicationFactor.
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649677#comment-14649677
]
Mark Miller edited comment on SOLR-7766 at 7/31/15 7:23 PM:
bq. API seems very hacky to me.
What's the hack exactly?
* If the issue is really just an empty param (something I don't agree is a
hack), you could simply have a special keyword of createNodeSet=none.
was (Author: markrmil...@gmail.com):
bq. API seems very hacky to me.
What's the hack exactly?
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-7766) support creation of a coreless collection
[
https://issues.apache.org/jira/browse/SOLR-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649701#comment-14649701
]
Christine Poerschke edited comment on SOLR-7766 at 7/31/15 7:35 PM:
Alrighty, let's go for {{createNodeSet=someSpecialValue}} - i will have a look
around (on Monday) to see if 'empty' vs. 'EMPTY' vs. 'NONE' there is a
precedent already, so that for consistency the same could be used here? Thanks
[~shalinmangar] and [~markrmil...@gmail.com] for your input!
PS: github pull request now updated (still has createNodeSet= though, will be
updating both code and the newly added test case to use the special value).
was (Author: cpoerschke):
Alrightly, let's go for {{createNodeSet=someSpecialValue}} - i will have a look
around (on Monday) to see if 'empty' vs. 'EMPTY' vs. 'NONE' there is a
precedent already, so that for consistency the same could be used here? Thanks
[~shalinmangar] and [~markrmil...@gmail.com] for your input!
PS: github pull request now updated (still has createNodeSet= though, will be
updating both code and the newly added test case to use the special value).
support creation of a coreless collection
-
Key: SOLR-7766
URL: https://issues.apache.org/jira/browse/SOLR-7766
Project: Solr
Issue Type: New Feature
Reporter: Christine Poerschke
Assignee: Christine Poerschke
Priority: Minor
Attachments: SOLR-7766.patch
By supplying a deliberately empty create node set (via
{{.../solr/admin/collections?action=CREATEcreateNodeSet=name=myCollection...}})
the collection can be created in the usual manner but it will just not yet
contain any cores for any of its shards. Later on
{{.../solr/admin/collections?wt=jsonaction=ADDREPLICAcollection=myCollection...}}
calls can create cores as and when and where required.
github pull request with proposed changes to follow.
--
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-6710) GeoPointField should use full 64 bit encoding
Nicholas Knize created LUCENE-6710: -- Summary: GeoPointField should use full 64 bit encoding Key: LUCENE-6710 URL: https://issues.apache.org/jira/browse/LUCENE-6710 Project: Lucene - Core Issue Type: Improvement Reporter: Nicholas Knize Current GeoPointField uses 31 bits for each lat and long, respectively. This causes a precision error for the maximum bounds for 2D mapping applications (e.g., instead of maximum of 180, 90 the max value handled is 179.99, 89.99). This issue improves precision for the full 2D map boundaries by using the full 32 bit range for lat/lon values, resulting in a morton hash using the full 64 bit range. -- 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-6234) Scoring modes for query time join
[
https://issues.apache.org/jira/browse/SOLR-6234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649878#comment-14649878
]
Mikhail Khludnev commented on SOLR-6234:
Impl notes:
* toString() is a little bit odd, it looks like
{code}
debug: {
rawquerystring: {!join from=id to=manu_id_s score=max
fromIndex=products}inc,
querystring: {!join from=id to=manu_id_s score=max
fromIndex=products}inc,
parsedquery: OtherCoreJoinQuery(OtherCoreJoinQuery [fromIndex=products,
fromCoreOpenTime=1438087133575 extends SameCoreJoinQuery [fromQuery=text:inc,
fromField=id, toField=manu_id_s, scoreMode=Max]]),
parsedquery_toString: OtherCoreJoinQuery [fromIndex=products,
fromCoreOpenTime=1438087133575 extends SameCoreJoinQuery [fromQuery=text:inc,
fromField=id, toField=manu_id_s, scoreMode=Max]],
explain: {
{code}
Let me know if you need to change it.
* for cross core join: when you commit into {{fromIndex}} query cache entry
equality is determined by coreOpenTime() which is obtained from
{{System.currentTimeMillis()}} it might cause some issues on edge
cases/plarforms (that's why it wasn't covered with test), but this approach was
inherited from \{!join}. Raise an issue if it's significant to you.
Scoring modes for query time join
--
Key: SOLR-6234
URL: https://issues.apache.org/jira/browse/SOLR-6234
Project: Solr
Issue Type: New Feature
Components: query parsers
Affects Versions: 5.3
Reporter: Mikhail Khludnev
Assignee: Mikhail Khludnev
Labels: features, patch, test
Fix For: 5.3
Attachments: SOLR-6234-javadocsfix.patch,
SOLR-6234-trunk-CHANGES-fix.patch, SOLR-6234.patch, SOLR-6234.patch,
SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch, SOLR-6234.patch,
SOLR-6234.patch, otherHandler.patch
it adds ability to call Lucene's JoinUtil by specifying local param, ie
\{!join score=...} It supports:
- {{score=none|avg|max|total}} local param (passed as ScoreMode to JoinUtil)
- -supports {{b=100}} param to pass {{Query.setBoost()}}- postponed till
SOLR-7814.
- -{{multiVals=true|false}} is introduced- YAGNI, let me know otherwise.
- there is a test coverage for cross core join case.
- so far it joins string and multivalue string fields (Sorted, SortedSet,
Binary), but not Numerics DVs. follow-up LUCENE-5868
--
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-6704) GeoPointInBBox/Distance queries can throw OOME
[ https://issues.apache.org/jira/browse/LUCENE-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6704: --- Attachment: LUCENE-6704.patch Updated patch includes the following: * reduces number of ranges by up to 100x (for very large queries) * adds unit test that causes an OOME on current trunk. This test is marked as NIGHTLY because it is a large query that can slow each beast iteration by a few seconds. * moves 32 bit encoding changes to LUCENE-6710 GeoPointInBBox/Distance queries can throw OOME -- Key: LUCENE-6704 URL: https://issues.apache.org/jira/browse/LUCENE-6704 Project: Lucene - Core Issue Type: Bug Reporter: Nicholas Knize Attachments: LUCENE-6704.patch, LUCENE-6704.patch After investigating LUCENE-6685 the performance issues and improvements related to GeoPointInBBox/Distance queries could be categorized into two separate issues: 1. OOME caused by an unnecessary number of ranges computed for Point Distance Queries (bug in the GeoPointTermEnum base class where the bounding box was used for intersections instead of the point radius) 2. API improvements providing configurable detail parameters. This issue addresses 1. LUCENE-6685 will further investigate the need for 2 (after working 1 and correcting for unnecessary range detail, it looks like 2 may not be needed) -- 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: cwiki.apache.org edit right for cpoerschke
Hi Steve, oops, apologies, my mistake, created myself a Confluence account now. Thanks, Christine - Original Message - From: sar...@gmail.com To: Christine Poerschke (BLOOMBERG/ LONDON), dev@lucene.apache.org At: Jul 31 2015 18:47:42 Hi Christine, I would have added you when I added Mikhail, but autocomplete doesn’t turn up anything when trying to add permission for you. Do you have a Confluence account? If not, go here and make one: https://cwiki.apache.org/confluence/signup.action and then let us know what it is. If you already have a Confluence account, what is it? Steve www.lucidworks.com On Jul 31, 2015, at 1:30 PM, Christine Poerschke (BLOOMBERG/ LONDON) cpoersc...@bloomberg.net wrote: Hi, Could i be added also please? This would initially just be for updating https://cwiki.apache.org/confluence/display/solr/Collections+API?src=search w.r.t. https://issues.apache.org/jira/i#browse/SOLR-7766 when that is committed (hopefully early next week). Thanks, Christine From: dev@lucene.apache.org At: Jul 30 2015 20:43:12 To: dev@lucene.apache.org Subject: Re:cwiki.a.org edit right for mkhludnev Hello, Would you let mkhludnev (not mkhl) to edit https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide ? Thanks! -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1693101 - in /lucene/dev/branches/branch_5x: ./ dev-tools/ lucene/ lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/ lucene/analysis/common/src/java/org/apache
Mikhail: something doesn't make sense about the CHANGES.txt entry for this after the merge (I noticed doing a subsequent merge) On the 5x branch SOLR-6234 is in the New Features section of 5.3, but on trunk it's in Other Changes of 6.0. : Date: Tue, 28 Jul 2015 14:44:17 - : From: m...@apache.org : Reply-To: dev@lucene.apache.org : To: comm...@lucene.apache.org : Subject: svn commit: r1693101 - in /lucene/dev/branches/branch_5x: ./ : dev-tools/ lucene/ : lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/ : lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/ : lucene/analysis/common/... : : Author: mkhl : Date: Tue Jul 28 14:44:15 2015 : New Revision: 1693101 : : URL: http://svn.apache.org/r1693101 : Log: : SOLR-6234: Scoring for query time join : : Added: : lucene/dev/branches/branch_5x/solr/core/src/java/org/apache/solr/search/ScoreJoinQParserPlugin.java : - copied unchanged from r1693092, lucene/dev/trunk/solr/core/src/java/org/apache/solr/search/join/ScoreJoinQParserPlugin.java : lucene/dev/branches/branch_5x/solr/core/src/test-files/solr/collection1/conf/schema-docValuesJoin.xml : - copied unchanged from r1693092, lucene/dev/trunk/solr/core/src/test-files/solr/collection1/conf/schema-docValuesJoin.xml : lucene/dev/branches/branch_5x/solr/core/src/test/org/apache/solr/TestCrossCoreJoin.java : - copied unchanged from r1693092, lucene/dev/trunk/solr/core/src/test/org/apache/solr/TestCrossCoreJoin.java : lucene/dev/branches/branch_5x/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPNoScore.java : - copied unchanged from r1693092, lucene/dev/trunk/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPNoScore.java : lucene/dev/branches/branch_5x/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPScore.java : - copied unchanged from r1693092, lucene/dev/trunk/solr/core/src/test/org/apache/solr/search/join/TestScoreJoinQPScore.java : Modified: : lucene/dev/branches/branch_5x/ (props changed) : lucene/dev/branches/branch_5x/dev-tools/ (props changed) : lucene/dev/branches/branch_5x/lucene/ (props changed) : lucene/dev/branches/branch_5x/lucene/BUILD.txt (props changed) : lucene/dev/branches/branch_5x/lucene/CHANGES.txt (props changed) : lucene/dev/branches/branch_5x/lucene/JRE_VERSION_MIGRATION.txt (props changed) : lucene/dev/branches/branch_5x/lucene/LICENSE.txt (props changed) : lucene/dev/branches/branch_5x/lucene/MIGRATE.txt (props changed) : lucene/dev/branches/branch_5x/lucene/NOTICE.txt (props changed) : lucene/dev/branches/branch_5x/lucene/README.txt (props changed) : lucene/dev/branches/branch_5x/lucene/SYSTEM_REQUIREMENTS.txt (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/miscellaneous/Lucene47WordDelimiterFilter.java (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/ASCIITLD.jflex-macro (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/SUPPLEMENTARY.jflex-macro (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/StandardTokenizerImpl40.java (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/StandardTokenizerImpl40.jflex (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/UAX29URLEmailTokenizerImpl40.java (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/UAX29URLEmailTokenizerImpl40.jflex (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/java/org/apache/lucene/analysis/standard/std40/package.html (props changed) : lucene/dev/branches/branch_5x/lucene/analysis/common/src/test/org/apache/lucene/analysis/miscellaneous/TestLucene47WordDelimiterFilter.java (props changed) : lucene/dev/branches/branch_5x/lucene/backward-codecs/ (props changed) : lucene/dev/branches/branch_5x/lucene/benchmark/ (props changed) : lucene/dev/branches/branch_5x/lucene/build.xml (props changed) : lucene/dev/branches/branch_5x/lucene/classification/ (props changed) : lucene/dev/branches/branch_5x/lucene/classification/build.xml (props changed) : lucene/dev/branches/branch_5x/lucene/classification/ivy.xml (props changed) : lucene/dev/branches/branch_5x/lucene/classification/src/ (props changed) : lucene/dev/branches/branch_5x/lucene/codecs/ (props changed) : lucene/dev/branches/branch_5x/lucene/common-build.xml (props changed) :
[jira] [Updated] (LUCENE-6710) GeoPointField should use full 64 bit encoding
[ https://issues.apache.org/jira/browse/LUCENE-6710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6710: --- Attachment: LUCENE-6710.patch Patch to use full 64 bit precision for morton encoding, unit test included. GeoPointField should use full 64 bit encoding - Key: LUCENE-6710 URL: https://issues.apache.org/jira/browse/LUCENE-6710 Project: Lucene - Core Issue Type: Improvement Reporter: Nicholas Knize Attachments: LUCENE-6710.patch Current GeoPointField uses 31 bits for each lat and long, respectively. This causes a precision error for the maximum bounds for 2D mapping applications (e.g., instead of maximum of 180, 90 the max value handled is 179.99, 89.99). This issue improves precision for the full 2D map boundaries by using the full 32 bit range for lat/lon values, resulting in a morton hash using the full 64 bit range. -- 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-5147) Support child documents in DIH
[ https://issues.apache.org/jira/browse/SOLR-5147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649904#comment-14649904 ] Mikhail Khludnev commented on SOLR-5147: [~r_harish] it should. Support child documents in DIH -- Key: SOLR-5147 URL: https://issues.apache.org/jira/browse/SOLR-5147 Project: Solr Issue Type: Sub-task Reporter: Vadim Kirilchuk Assignee: Noble Paul Fix For: 5.1, Trunk Attachments: SOLR-5147-5x.patch, SOLR-5147.patch, SOLR-5147.patch, dih-oome-fix.patch DIH should be able to index hierarchical documents, i.e. it should be able to work with SolrInputDocuments#addChildDocument. There was patch in SOLR-3076: https://issues.apache.org/jira/secure/attachment/12576960/dih-3076.patch But it is not uptodate and far from being complete. -- 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-6647) Add GeoHash String Utilities to core GeoUtils
[ https://issues.apache.org/jira/browse/LUCENE-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6647: --- Attachment: LUCENE-6647.patch bq. can you open a new issue whose sole purpose is to cutover to full 32 bit precision for lat/lon? LUCENE-6710 adds full 32 bit precision decoupling this issue from LUCENE-6704. Patch attached to make GeoHashUtils bit precision independent. Unit test provided. Add GeoHash String Utilities to core GeoUtils - Key: LUCENE-6647 URL: https://issues.apache.org/jira/browse/LUCENE-6647 Project: Lucene - Core Issue Type: New Feature Reporter: Nicholas Knize Attachments: LUCENE-6647.patch, LUCENE-6647.patch, LUCENE-6647.patch, LUCENE-6647.patch GeoPointField uses morton encoding to efficiently pack lat/lon values into a single long. GeoHashing effectively does the same thing but uses base 32 encoding to represent this long value as a human readable string. Many user applications already use the string representation of the hash. This issue simply adds the base32 string representation of the already computed morton 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-7854) Remove ZkStateReader.updateClusterState(false)
[ https://issues.apache.org/jira/browse/SOLR-7854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Blum updated SOLR-7854: - Attachment: SOLR-7854.patch Simple patch against trunk. (Would like to backport also) Remove ZkStateReader.updateClusterState(false) -- Key: SOLR-7854 URL: https://issues.apache.org/jira/browse/SOLR-7854 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 5.2.1 Reporter: Scott Blum Priority: Minor Labels: easyfix, newbie Attachments: SOLR-7854.patch Original Estimate: 2h Remaining Estimate: 2h `updateClusterState(false)` as far as I can tell has zero callers. It's super pointless anyway, because `updateClusterState(true)` is being used mostly from test code and in places where someone is trying to force a reload from ZK (for whatever reason). There's no point in asking for a deferred update when ZkStateReader is already going to keep itself in sync anyway. -- 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-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648849#comment-14648849 ] Shalin Shekhar Mangar commented on SOLR-5756: - [~dragonsinth] - I am 'shalin' on irc A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- 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-5756) A utility API to move collections from internal to external
[ https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648794#comment-14648794 ] Noble Paul commented on SOLR-5756: -- always prefer 'state.json' . A utility API to move collections from internal to external --- Key: SOLR-5756 URL: https://issues.apache.org/jira/browse/SOLR-5756 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul SOLR-5473 allows creation of collection with state stored outside of clusterstate.json. We would need an API to move existing 'internal' collections outside -- 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: Understanding performance degradation in range queries between Solr 5.2.1 and 4.10.4
Hi Tomás, I suspect this might be related to LUCENE-5938. We changed the default rewrite method for multi-term queries to load documents into a sparse bit set first first, and only upgrade to a dense bit set when we know many documents match. When there are lots of terms to intersect, then we end up spending significant cpu time to build the sparse bit set to eventually upgrade to a dense bit set like before. This might be what you are seeing. You might see the issue less with the population field because it has fewer unique values, so postings lists are longer and the DocIdSet building logic can upgrade quicker to a dense bit set. Mike noticed this slowness when working on BDK trees and we changed this first phase to use a plain int[] array that we sort and deduplicate instead of a more fancy sparse bit set (LUCENE-6645), which seemed to make things faster. Would it be possible for you to also check a 5.3 snapshot? On Fri, Jul 31, 2015 at 10:51 PM, Tomás Fernández Löbbe tomasflo...@gmail.com wrote: Hi, I'm seeing some query performance degradation between 4.10.4 and 5.2.1. It doesn't happen with all the queries, but for queries like range queries on fields with many different values the average time in 5.2.1 is worse than in 4.10.4. Is anyone seeing something similar? Test Details: * Single thread running queries continuously. I run the test twice for each Solr version. * JMeter running on my laptop, Solr running on EC2, on an m3.xlarge instance with all the defaults but with 5G heap. Index in local disk (SSD) * Plain Solr releases, nothing custom. Single Solr core, not in SolrCloud mode, no distributed search. * allCountries geonames dataset (~8M small docs). No updates during the test. Index Size is around 1.1GB for Solr 5.2.1 and 1.3GB for Solr 4.10.4 (fits entirely in RAM) * jdk1.8.0_45 Queries: 3k boolean queries (generated with terms from the dataset) with range queries as filters on tlongitude and tlatitude fields with randomly generated bounds, e.g. q=name:foo OR name:barfq=tlongitude:[W TO X]fq=tlatitude:[Y TO Z] Fields are: field name=tlatitude type=tdouble/ field name=tlongitude type=tdouble/ Field Type: fieldType name=tdouble class=solr.TrieDoubleField precisionStep=8 positionIncrementGap=0/ In this case, Solr 4.10.4 was between 20% to 30% faster than 5.2.1 in average. http://snag.gy/2yPPM.jpg Doing only the boolean queries show no performance difference between 4.10 and 5.2, same thing if I do filters on a string field instead of the range queries. When using double field type (precisionStep=0), the difference was bigger: longitude/latitude fields: field name=longitude type=double docValues=true/ field name=latitude type=double docValues=true/ fieldType name=double class=solr.TrieDoubleField precisionStep=0 positionIncrementGap=0/ http://snag.gy/Vi5uk.jpg I understand this is not the best field type definition for range queries, I'm just trying to understand the difference between the two versions and why. Performance was OK when doing range queries on the population field (long), but that field doesn't have many different values, only 300k out of the 8.3M docs have the population field with a value different to 0. On the other hand, doing range queries on the _version_ field did show a graph similar to the previous one: field name=_version_ type=long indexed=true stored=true/ fieldType name=long class=solr.TrieLongField precisionStep=0 positionIncrementGap=0/ http://snag.gy/4tc7e.jpg Any idea what could be causing this? Is this expected after some known change? With Solr 4.10, a single CPU core remains high during the test (close to 100%), but with Solr 5.2, different cores go up and down in utilization continuously. That's probably because of the different Jetty version I suppose. GC pattern looks similar in both. For both Solr versions I'm using the settings that ship with Solr (in solr.in.sh) except for Xmx and Xms -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7849) Secure Inter-node communication in a standard mechanism
[
https://issues.apache.org/jira/browse/SOLR-7849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14650012#comment-14650012
]
Jan Høydahl commented on SOLR-7849:
---
Interesting idea. How will node B be able to lookup the public key from core
admin API of node A if A requires B to also authenticate? Perhaps publish
pub-key through ZK instead of core admin?
What should happen in multi-DC case; would cross cluster communication be
treated as internal? What would original-user-principal be in case the
action is initiated by Solr and not an external request?
Secure Inter-node communication in a standard mechanism
Key: SOLR-7849
URL: https://issues.apache.org/jira/browse/SOLR-7849
Project: Solr
Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul
Relying on every Authentication plugin to secure the internode communication
is error prone. Solr can standardize the authentication so that only the
first request that comes from outside the cluster needs to be authenticated
by the authentication plugin
The scheme to protect the communication will be as follows
* Every Solr node creates a an RSA key pair
* The private key is kept private and the public key is made available
through a core admin API
* If authentication is enabled , every outgoing request will carry an extra
header {{ SolrAuth : nodename
encrypt_with_pvt_key(original-user-principal timestamp) }}
* If authentication is enabled {{SolrDispatchFilter}} would look for this
header and see the nodename
** If the public key of the nodename is available in cache , make a request
to the node and fetch the public key
** If the public key has changed (because of a server restart) decryption
fails and the public keyis fetched again
* If the decryption succeeds , the user-name is set to what the header has
encoded
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-7855) OverseerCollectionProcessor: separate general task management from collection message handling
Gregory Chanan created SOLR-7855: Summary: OverseerCollectionProcessor: separate general task management from collection message handling Key: SOLR-7855 URL: https://issues.apache.org/jira/browse/SOLR-7855 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Gregory Chanan Assignee: Gregory Chanan While working on SOLR-7789, I realized it would be easier if I split up the OverseerCollectionProcessor into two parts: 1) General handling of tasks (work queues, etc) 2) Processing a collection handler request I haven't decided whether the ConfigSet should have its own processor, i.e. OverseerConfigSetProcessor or reuse at least the thread for the OverseerCollectionProcessor, but in either case this refactoring will be helpful. That is, if the ConfigSet processing has its own processing, I can reuse the general handling of tasks part. If the ConfigSet processing reuses the OverseerCollectionProcessing thread, I won't complicate the implementation with ConfigSet operations. -- 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-7846) QTs with $variable does not work with query parameter substitution
[
https://issues.apache.org/jira/browse/SOLR-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649989#comment-14649989
]
Jan Høydahl commented on SOLR-7846:
---
Perhaps what we need is a generic way to escape the ${} syntax in XML files. A
simple \${} could work, but is perhaps dangerous because many places Windows
file paths may contain sysprop expansion, e.g. C:\$\{dir\}\foo.
QTs with $variable does not work with query parameter substitution
--
Key: SOLR-7846
URL: https://issues.apache.org/jira/browse/SOLR-7846
Project: Solr
Issue Type: Bug
Reporter: Bill Bell
http://yonik.com/solr-query-parameter-substitution/
This is not working as part of QTs in solrconfig.xml due to XML System
Property Substitution getting confused in SOLR 5.2.1.
Cannot load the core, since ${value} is being used for XML parameters for
system property substitution.
https://wiki.apache.org/solr/SolrConfigXml#System_property_substitution
Can we support both?
str name=pspecPS127/str
str name=hqval1hosp_quality_spec_boost:${pspec}/str
This does not work since it thinks it is a System Property.
We can check System Property and if not defined assume it is in Query, or
have a new parameter?
{noformat}
${variable} - for System Properties
${{variable}} - for Query Parameters?
{noformat}
Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6704) GeoPointInBBox/Distance queries can throw OOME
[ https://issues.apache.org/jira/browse/LUCENE-6704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649889#comment-14649889 ] Nicholas Knize edited comment on LUCENE-6704 at 7/31/15 9:38 PM: - Updated patch includes the following: * reduces number of ranges by up to 100x (for very large queries) * adds unit test that causes an OOME on current trunk. This test is marked as NIGHTLY because it is a large query that can slow each beast iteration by a few seconds. * moves 32 bit encoding changes to LUCENE-6710 * resets GeoPointDistanceQuery to final was (Author: nknize): Updated patch includes the following: * reduces number of ranges by up to 100x (for very large queries) * adds unit test that causes an OOME on current trunk. This test is marked as NIGHTLY because it is a large query that can slow each beast iteration by a few seconds. * moves 32 bit encoding changes to LUCENE-6710 GeoPointInBBox/Distance queries can throw OOME -- Key: LUCENE-6704 URL: https://issues.apache.org/jira/browse/LUCENE-6704 Project: Lucene - Core Issue Type: Bug Reporter: Nicholas Knize Attachments: LUCENE-6704.patch, LUCENE-6704.patch After investigating LUCENE-6685 the performance issues and improvements related to GeoPointInBBox/Distance queries could be categorized into two separate issues: 1. OOME caused by an unnecessary number of ranges computed for Point Distance Queries (bug in the GeoPointTermEnum base class where the bounding box was used for intersections instead of the point radius) 2. API improvements providing configurable detail parameters. This issue addresses 1. LUCENE-6685 will further investigate the need for 2 (after working 1 and correcting for unnecessary range detail, it looks like 2 may not be needed) -- 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-6664) Replace SynonymFilter with SynonymGraphFilter
[
https://issues.apache.org/jira/browse/LUCENE-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648907#comment-14648907
]
Michael McCandless commented on LUCENE-6664:
Thinking about this more, I think it's sort of silly to only expose the always
flattened synonym filter because that's really no better than today: you still
can't search multi-token synonyms correctly, and there are small differences in
how the graph corruption happens.
So I'd like to go back to the 2nd patch, where both filters are public. I'll
mark them experimental...
Replace SynonymFilter with SynonymGraphFilter
-
Key: LUCENE-6664
URL: https://issues.apache.org/jira/browse/LUCENE-6664
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 5.3, Trunk
Attachments: LUCENE-6664.patch, LUCENE-6664.patch, LUCENE-6664.patch,
usa.png, usa_flat.png
Spinoff from LUCENE-6582.
I created a new SynonymGraphFilter (to replace the current buggy
SynonymFilter), that produces correct graphs (does no graph
flattening itself). I think this makes it simpler.
This means you must add the FlattenGraphFilter yourself, if you are
applying synonyms during indexing.
Index-time syn expansion is a necessarily lossy graph transformation
when multi-token (input or output) synonyms are applied, because the
index does not store {{posLength}}, so there will always be phrase
queries that should match but do not, and then phrase queries that
should not match but do.
http://blog.mikemccandless.com/2012/04/lucenes-tokenstreams-are-actually.html
goes into detail about this.
However, with this new SynonymGraphFilter, if instead you do synonym
expansion at query time (and don't do the flattening), and you use
TermAutomatonQuery (future: somehow integrated into a query parser),
or maybe just enumerate all paths and make union of PhraseQuery, you
should get 100% correct matches (not sure about proper scoring
though...).
This new syn filter still cannot consume an arbitrary graph.
--
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-6697) Use 1D KD tree for alternative to postings based numeric range filters
[
https://issues.apache.org/jira/browse/LUCENE-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648942#comment-14648942
]
Michael McCandless commented on LUCENE-6697:
bq. I also changed search-time to an iterative impl (vs recursive before)
Actually once nice benefit of this is it's easy to estimate up front how many
hits we'll have, so I can call {{grow}} up front. I'll add that and commit
soon...
Use 1D KD tree for alternative to postings based numeric range filters
--
Key: LUCENE-6697
URL: https://issues.apache.org/jira/browse/LUCENE-6697
Project: Lucene - Core
Issue Type: New Feature
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: LUCENE-6697.patch, LUCENE-6697.patch, LUCENE-6697.patch
Today Lucene uses postings to index a numeric value at multiple
precision levels for fast range searching. It's somewhat costly: each
numeric value is indexed with multiple terms (4 terms by default)
... I think a dedicated 1D BKD tree should be more compact and perform
better.
It should also easily generalize beyond 64 bits to arbitrary byte[],
e.g. for LUCENE-5596, but I haven't explored that here.
A 1D BKD tree just sorts all values, and then indexes adjacent leaf
blocks of size 512-1024 (by default) values per block, and their
docIDs, into a fully balanced binary tree. Building the range filter
is then just a recursive walk through this tree.
It's the same structure we use for 2D lat/lon BKD tree, just with 1D
instead. I implemented it as a DocValuesFormat that also writes the
numeric tree on the side.
--
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-6629) Random 7200 seconds build timeouts / infinite loops in Lucene tests?
[
https://issues.apache.org/jira/browse/LUCENE-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648940#comment-14648940
]
Michael McCandless commented on LUCENE-6629:
Woops, you're right [~dawid.weiss]! It also stalls for me ... so this is just
SimpleText being slow (as expected).
Random 7200 seconds build timeouts / infinite loops in Lucene tests?
Key: LUCENE-6629
URL: https://issues.apache.org/jira/browse/LUCENE-6629
Project: Lucene - Core
Issue Type: Bug
Reporter: Michael McCandless
Attachments: 54457_consoleText.txt
I'm not sure what's going on here, but every so often a Jenkins run will fail
with a build timeout (7200 seconds) with stack traces that do not look like
deadlock. They never reproduce for me.
We really need to improve test infra here, so that each HEARTBEAT we also got
1) full thread stacks and 2) total CPU usage of the process as reported by
the ManagementBean APIs ... this would shed more light on whether the JVM is
somehow hung vs our bug (infinite loop). But infinite loop seems most likely
... the stacks always seem to be somewhere spooky.
We should try to gather recent Jenkins runs where this is happening, here, to
see if there are patterns / we can get to the root cause.
Anyway, this happened to me on my old beast box, which runs the nightly ant
test times graphs:
http://people.apache.org/~mikemccand/lucenebench/antcleantest.html
The 2015/06/27 data point is missing because it failed with this timeout:
{noformat}
[junit4] Suite: org.apache.lucene.search.TestDocValuesRewriteMethod
[junit4] 2 ??? 28, 2015 7:01:29 ?
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
[junit4] 2 WARNING: Suite execution timed out:
org.apache.lucene.search.TestDocValuesRewriteMethod
[junit4] 21) Thread[id=1, name=main, state=WAITING, group=main]
[junit4] 2 at java.lang.Object.wait(Native Method)
[junit4] 2 at java.lang.Thread.join(Thread.java:1245)
[junit4] 2 at java.lang.Thread.join(Thread.java:1319)
[junit4] 2 at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:578)
[junit4] 2 at
com.carrotsearch.randomizedtesting.RandomizedRunner.run(RandomizedRunner.java:444)
[junit4] 2 at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:199)
[junit4] 2 at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:310)
[junit4] 2 at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)
[junit4] 22) Thread[id=213,
name=TEST-TestDocValuesRewriteMethod.testRegexps-seed#[C2DDF486BB909D8],
state=RUNNABLE, group=TGRP-TestDocValuesRewriteMethod]
[junit4] 2 at
org.apache.lucene.util.automaton.Operations.getLiveStates(Operations.java:900)
[junit4] 2 at
org.apache.lucene.util.automaton.Operations.hasDeadStates(Operations.java:389)
[junit4] 2 at
org.apache.lucene.util.automaton.Automata.makeString(Automata.java:517)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:579)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:519)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:510)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:466)
[junit4] 2 at
org.apache.lucene.search.RegexpQuery.init(RegexpQuery.java:109)
[junit4] 2 at
org.apache.lucene.search.RegexpQuery.init(RegexpQuery.java:79)
[junit4] 2 at
org.apache.lucene.search.TestDocValuesRewriteMethod.assertSame(TestDocValuesRewriteMethod.java:117)
[junit4] 2 at
org.apache.lucene.search.TestDocValuesRewriteMethod.testRegexps(TestDocValuesRewriteMethod.java:109)
[junit4] 2 at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4] 2 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit4] 2 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4] 2 at java.lang.reflect.Method.invoke(Method.java:497)
[junit4] 2 at
[jira] [Commented] (LUCENE-6697) Use 1D KD tree for alternative to postings based numeric range filters
[ https://issues.apache.org/jira/browse/LUCENE-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648955#comment-14648955 ] Michael McCandless commented on LUCENE-6697: bq. it's easy to estimate up front how many hits we'll have, so I can call grow up front This gives a nice speedup: ~5.2 sec down to ~4.7 sec for the 225 bbox lats around London benchmark. Use 1D KD tree for alternative to postings based numeric range filters -- Key: LUCENE-6697 URL: https://issues.apache.org/jira/browse/LUCENE-6697 Project: Lucene - Core Issue Type: New Feature Reporter: Michael McCandless Assignee: Michael McCandless Attachments: LUCENE-6697.patch, LUCENE-6697.patch, LUCENE-6697.patch Today Lucene uses postings to index a numeric value at multiple precision levels for fast range searching. It's somewhat costly: each numeric value is indexed with multiple terms (4 terms by default) ... I think a dedicated 1D BKD tree should be more compact and perform better. It should also easily generalize beyond 64 bits to arbitrary byte[], e.g. for LUCENE-5596, but I haven't explored that here. A 1D BKD tree just sorts all values, and then indexes adjacent leaf blocks of size 512-1024 (by default) values per block, and their docIDs, into a fully balanced binary tree. Building the range filter is then just a recursive walk through this tree. It's the same structure we use for 2D lat/lon BKD tree, just with 1D instead. I implemented it as a DocValuesFormat that also writes the numeric tree on the side. -- 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-6647) Add GeoHash String Utilities to core GeoUtils
[ https://issues.apache.org/jira/browse/LUCENE-6647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648962#comment-14648962 ] Michael McCandless commented on LUCENE-6647: bq. This fixes the issue where the max lat/lon was not decoding to the correct precision leading to the failure posted above. Hmm can you open a new issue whose sole purpose is to cutover to full 32 bit precision for lat/lon? LUCENE-6704 is about avoiding OOME (or is the full 32 precision necessary to avoid OOME?) ... then we can decouple these issues? It's hard enough keeping track of all the in-flight patches without some depending on others... Add GeoHash String Utilities to core GeoUtils - Key: LUCENE-6647 URL: https://issues.apache.org/jira/browse/LUCENE-6647 Project: Lucene - Core Issue Type: New Feature Reporter: Nicholas Knize Attachments: LUCENE-6647.patch, LUCENE-6647.patch, LUCENE-6647.patch GeoPointField uses morton encoding to efficiently pack lat/lon values into a single long. GeoHashing effectively does the same thing but uses base 32 encoding to represent this long value as a human readable string. Many user applications already use the string representation of the hash. This issue simply adds the base32 string representation of the already computed morton 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] [Assigned] (SOLR-7823) TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async collection-creation (sometimes)
[ https://issues.apache.org/jira/browse/SOLR-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke reassigned SOLR-7823: - Assignee: Christine Poerschke TestMiniSolrCloudCluster.testCollectionCreateSearchDelete async collection-creation (sometimes) --- Key: SOLR-7823 URL: https://issues.apache.org/jira/browse/SOLR-7823 Project: Solr Issue Type: Test Reporter: Christine Poerschke Assignee: Christine Poerschke Priority: Minor github pull request with proposed changes to follow -- 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-6629) Random 7200 seconds build timeouts / infinite loops in Lucene tests?
[
https://issues.apache.org/jira/browse/LUCENE-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648919#comment-14648919
]
Dawid Weiss commented on LUCENE-6629:
-
To me it looks like it's just churning a lot of data and using simple text
codec? I tried running on of the repros locally and it also stalls.
Random 7200 seconds build timeouts / infinite loops in Lucene tests?
Key: LUCENE-6629
URL: https://issues.apache.org/jira/browse/LUCENE-6629
Project: Lucene - Core
Issue Type: Bug
Reporter: Michael McCandless
Attachments: 54457_consoleText.txt
I'm not sure what's going on here, but every so often a Jenkins run will fail
with a build timeout (7200 seconds) with stack traces that do not look like
deadlock. They never reproduce for me.
We really need to improve test infra here, so that each HEARTBEAT we also got
1) full thread stacks and 2) total CPU usage of the process as reported by
the ManagementBean APIs ... this would shed more light on whether the JVM is
somehow hung vs our bug (infinite loop). But infinite loop seems most likely
... the stacks always seem to be somewhere spooky.
We should try to gather recent Jenkins runs where this is happening, here, to
see if there are patterns / we can get to the root cause.
Anyway, this happened to me on my old beast box, which runs the nightly ant
test times graphs:
http://people.apache.org/~mikemccand/lucenebench/antcleantest.html
The 2015/06/27 data point is missing because it failed with this timeout:
{noformat}
[junit4] Suite: org.apache.lucene.search.TestDocValuesRewriteMethod
[junit4] 2 ??? 28, 2015 7:01:29 ?
com.carrotsearch.randomizedtesting.ThreadLeakControl$2 evaluate
[junit4] 2 WARNING: Suite execution timed out:
org.apache.lucene.search.TestDocValuesRewriteMethod
[junit4] 21) Thread[id=1, name=main, state=WAITING, group=main]
[junit4] 2 at java.lang.Object.wait(Native Method)
[junit4] 2 at java.lang.Thread.join(Thread.java:1245)
[junit4] 2 at java.lang.Thread.join(Thread.java:1319)
[junit4] 2 at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:578)
[junit4] 2 at
com.carrotsearch.randomizedtesting.RandomizedRunner.run(RandomizedRunner.java:444)
[junit4] 2 at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:199)
[junit4] 2 at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:310)
[junit4] 2 at
com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)
[junit4] 22) Thread[id=213,
name=TEST-TestDocValuesRewriteMethod.testRegexps-seed#[C2DDF486BB909D8],
state=RUNNABLE, group=TGRP-TestDocValuesRewriteMethod]
[junit4] 2 at
org.apache.lucene.util.automaton.Operations.getLiveStates(Operations.java:900)
[junit4] 2 at
org.apache.lucene.util.automaton.Operations.hasDeadStates(Operations.java:389)
[junit4] 2 at
org.apache.lucene.util.automaton.Automata.makeString(Automata.java:517)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:579)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:519)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.findLeaves(RegExp.java:617)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.toAutomatonInternal(RegExp.java:510)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:495)
[junit4] 2 at
org.apache.lucene.util.automaton.RegExp.toAutomaton(RegExp.java:466)
[junit4] 2 at
org.apache.lucene.search.RegexpQuery.init(RegexpQuery.java:109)
[junit4] 2 at
org.apache.lucene.search.RegexpQuery.init(RegexpQuery.java:79)
[junit4] 2 at
org.apache.lucene.search.TestDocValuesRewriteMethod.assertSame(TestDocValuesRewriteMethod.java:117)
[junit4] 2 at
org.apache.lucene.search.TestDocValuesRewriteMethod.testRegexps(TestDocValuesRewriteMethod.java:109)
[junit4] 2 at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4] 2 at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit4] 2 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4] 2 at java.lang.reflect.Method.invoke(Method.java:497)
[junit4] 2 at
[JENKINS] Lucene-Solr-5.x-Windows (32bit/jdk1.8.0_51) - Build # 4958 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Windows/4958/ Java: 32bit/jdk1.8.0_51 -client -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.handler.dataimport.TestContentStreamDataSource.testCommitWithin Error Message: expected:0 but was:2 Stack Trace: java.lang.AssertionError: expected:0 but was:2 at __randomizedtesting.SeedInfo.seed([DF65E081378DC1C5:65B78FF9B4A32FD0]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.handler.dataimport.TestContentStreamDataSource.testCommitWithin(TestContentStreamDataSource.java:97) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) 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:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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:54) 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 14988 lines...] [junit4] Suite:
[jira] [Commented] (LUCENE-6620) Ignored statement
[
https://issues.apache.org/jira/browse/LUCENE-6620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648975#comment-14648975
]
Christine Poerschke commented on LUCENE-6620:
-
{{Compile.java}} is in {{lucene/analysis/stempel/src/java/org/egothor/stemmer}}
directory.
currently the code does this:
{code}
args[0].toUpperCase(Locale.ROOT);
...
multi = args[0].charAt(qq) == 'M';
{code}
was something like this intended perhaps?
{code}
... = args[0].toUpperCase(Locale.ROOT);
{code}
Ignored statement
-
Key: LUCENE-6620
URL: https://issues.apache.org/jira/browse/LUCENE-6620
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Affects Versions: Trunk
Reporter: Rishabh Patel
Priority: Trivial
{code:title=Compile.java|borderStyle=solid}
public static void main(java.lang.String[] args) throws Exception {
...
args[0].toUpperCase(Locale.ROOT);
...
}
{code}
In the file {{Compile.java}}, the argument string does not get capitalized.
Is this statement redundant?
--
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-6648) AnalyzingInfixLookupFactory always highlights suggestions
[
https://issues.apache.org/jira/browse/SOLR-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14648905#comment-14648905
]
Arcadius Ahouansou commented on SOLR-6648:
--
Would be nice if highlight was a query-time parameter where clients could
choose whether they want it or not.
AnalyzingInfixLookupFactory always highlights suggestions
-
Key: SOLR-6648
URL: https://issues.apache.org/jira/browse/SOLR-6648
Project: Solr
Issue Type: Sub-task
Affects Versions: 4.9, 4.9.1, 4.10, 4.10.1
Reporter: Varun Thacker
Assignee: Tomás Fernández Löbbe
Labels: suggester
Fix For: 5.1, Trunk
Attachments: SOLR-6648-v4.10.3.patch, SOLR-6648.patch
When using AnalyzingInfixLookupFactory suggestions always return with the
match term as highlighted and 'allTermsRequired' is always set to true.
We should be able to configure those.
Steps to reproduce -
schema additions
{code}
searchComponent name=suggest class=solr.SuggestComponent
lst name=suggester
str name=namemySuggester/str
str name=lookupImplAnalyzingInfixLookupFactory/str
str name=dictionaryImplDocumentDictionaryFactory/str
str name=fieldsuggestField/str
str name=weightFieldweight/str
str name=suggestAnalyzerFieldTypetextSuggest/str
/lst
/searchComponent
requestHandler name=/suggest class=solr.SearchHandler startup=lazy
lst name=defaults
str name=suggesttrue/str
str name=suggest.count10/str
/lst
arr name=components
strsuggest/str
/arr
/requestHandler
{code}
solrconfig changes -
{code}
fieldType class=solr.TextField name=textSuggest
positionIncrementGap=100
analyzer
tokenizer class=solr.StandardTokenizerFactory/
filter class=solr.StandardFilterFactory/
filter class=solr.LowerCaseFilterFactory/
/analyzer
/fieldType
field name=suggestField type=textSuggest indexed=true
stored=true/
{code}
Add 3 documents -
{code}
curl http://localhost:8983/solr/update/json?commit=true -H
'Content-type:application/json' -d '
[ {id : 1, suggestField : bass fishing}, {id : 2, suggestField
: sea bass}, {id : 3, suggestField : sea bass fishing} ]
'
{code}
Query -
{code}
http://localhost:8983/solr/collection1/suggest?suggest.build=truesuggest.dictionary=mySuggesterq=basswt=jsonindent=on
{code}
Response
{code}
{
responseHeader:{
status:0,
QTime:25},
command:build,
suggest:{mySuggester:{
bass:{
numFound:3,
suggestions:[{
term:bbass/b fishing,
weight:0,
payload:},
{
term:sea bbass/b,
weight:0,
payload:},
{
term:sea bbass/b fishing,
weight:0,
payload:}]
{code}
The problem is in SolrSuggester Line 200 where we say lookup.lookup()
This constructor does not take allTermsRequired and doHighlight since it's
only tuneable to AnalyzingInfixSuggester and not the other lookup
implementations.
If different Lookup implementations have different params as their
constructors, these sort of issues will always keep happening. Maybe we
should not keep it generic and do instanceof checks and set params
accordingly?
--
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: Strange comment in CdcrReplicationHandlerTest.java
Ah okay, my bad then.. On 29 Jul 2015 21:28, Uwe Schindler u...@thetaphi.de wrote: RAT would only fail if the license header is missing completely. I don't think it checks for copyright notices. If there is no license header, we should check our RAT config! What does it list as license for that file? Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Wednesday, July 29, 2015 7:36 PM To: dev@lucene.apache.org Subject: Re: Strange comment in CdcrReplicationHandlerTest.java Yeah, I wondered that myself. On Wed, Jul 29, 2015 at 1:35 PM, Ramkumar R. Aiyengar andyetitmo...@gmail.com wrote: Hmm.. I would have expected rat to fail this in precommit actually.. On 29 Jul 2015 18:01, Timothy Potter thelabd...@gmail.com wrote: Why is this in the code? /** * Copyright (c) 2015 Renaud Delbru. All Rights Reserved. */ package org.apache.solr.cloud; - 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6621) two unused variables in analysis/stempel/src/java/org/egothor/stemmer/Compile.java
[
https://issues.apache.org/jira/browse/LUCENE-6621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke resolved LUCENE-6621.
-
Resolution: Fixed
Thanks Rishabh!
two unused variables in
analysis/stempel/src/java/org/egothor/stemmer/Compile.java
--
Key: LUCENE-6621
URL: https://issues.apache.org/jira/browse/LUCENE-6621
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Affects Versions: Trunk
Reporter: Rishabh Patel
Assignee: Christine Poerschke
Priority: Trivial
Fix For: 5.3, Trunk
{code:title=Compile.java|borderStyle=solid}
public static void main(java.lang.String[] args) throws Exception {
...
for (int i = 1; i args.length; i++) {
// System.out.println([ + args[i] + ]);
Diff diff = new Diff();
int stems = 0;
int words = 0;
...
{code}
In the file {{Compile.java}}, the variables {{stems}} and {{words}} are
unused.
Although {{words}} gets incremented further in the file, it does not get
referenced or used elsewhere.
{{stems}} is neither incremented nor used elsewhere in the project.
Are these variables redundant?
--
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-5022) PermGen exhausted test failures on Jenkins.
[ https://issues.apache.org/jira/browse/SOLR-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-5022: Attachment: SOLR-5022-permgen.patch Patch for branch_5x. I will commit this now. PermGen exhausted test failures on Jenkins. --- Key: SOLR-5022 URL: https://issues.apache.org/jira/browse/SOLR-5022 Project: Solr Issue Type: Test Components: Tests Reporter: Mark Miller Assignee: Uwe Schindler Priority: Critical Fix For: 5.3 Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, SOLR-5022.patch, intern-count-win.txt -- 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-5022) PermGen exhausted test failures on Jenkins.
[ https://issues.apache.org/jira/browse/SOLR-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649018#comment-14649018 ] ASF subversion and git services commented on SOLR-5022: --- Commit 1693560 from [~thetaphi] in branch 'dev/trunk' [ https://svn.apache.org/r1693560 ] SOLR-5022: Merged revision(s) 1693559 from lucene/dev/branches/branch_5x: cleanup outdated Java 7 stuff PermGen exhausted test failures on Jenkins. --- Key: SOLR-5022 URL: https://issues.apache.org/jira/browse/SOLR-5022 Project: Solr Issue Type: Test Components: Tests Reporter: Mark Miller Assignee: Uwe Schindler Priority: Critical Fix For: 5.3 Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, SOLR-5022.patch, intern-count-win.txt -- 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 (32bit/jdk1.8.0_51) - Build # 13493 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13493/ Java: 32bit/jdk1.8.0_51 -server -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.DeleteShardTest.test Error Message: Timeout occured while waiting response from server at: https://127.0.0.1:38217 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occured while waiting response from server at: https://127.0.0.1:38217 at __randomizedtesting.SeedInfo.seed([16ACA470EE580FE1:9EF89BAA40A46219]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:572) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:234) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:226) at org.apache.solr.client.solrj.SolrClient.request(SolrClient.java:1220) at org.apache.solr.cloud.DeleteShardTest.deleteShard(DeleteShardTest.java:122) at org.apache.solr.cloud.DeleteShardTest.test(DeleteShardTest.java:64) 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:497) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1627) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:836) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:872) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:886) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:966) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:941) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) 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:845) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:781) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:792) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) 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:54) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at
[jira] [Commented] (SOLR-5022) PermGen exhausted test failures on Jenkins.
[ https://issues.apache.org/jira/browse/SOLR-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14649009#comment-14649009 ] ASF subversion and git services commented on SOLR-5022: --- Commit 1693559 from [~thetaphi] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1693559 ] SOLR-5022: On Java 7 raise permgen for running tests PermGen exhausted test failures on Jenkins. --- Key: SOLR-5022 URL: https://issues.apache.org/jira/browse/SOLR-5022 Project: Solr Issue Type: Test Components: Tests Reporter: Mark Miller Assignee: Uwe Schindler Priority: Critical Fix For: 5.3 Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, SOLR-5022.patch, intern-count-win.txt -- 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-5022) PermGen exhausted test failures on Jenkins.
[ https://issues.apache.org/jira/browse/SOLR-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved SOLR-5022. - Resolution: Fixed PermGen exhausted test failures on Jenkins. --- Key: SOLR-5022 URL: https://issues.apache.org/jira/browse/SOLR-5022 Project: Solr Issue Type: Test Components: Tests Reporter: Mark Miller Assignee: Uwe Schindler Priority: Critical Fix For: 5.3 Attachments: SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, SOLR-5022-permgen.patch, SOLR-5022.patch, intern-count-win.txt -- 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
