Re: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome! - Mark On Tue, Jul 21, 2015 at 10:39 AM Shawn Heisey apa...@elyograg.org wrote: On 7/21/2015 1:21 AM, Adrien Grand wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Congratulations and welcome to the group! Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Mark about.me/markrmiller
[jira] [Commented] (SOLR-7806) SolrCloud to use 127.0.01 instead of localhost
[ https://issues.apache.org/jira/browse/SOLR-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635221#comment-14635221 ] Uwe Schindler commented on SOLR-7806: - -1 to this patch, because it makes use of Solr impossible on IPv6-only configurations. localhost is neutral (one could also argue to use ::1 instead of 127.0.0.1). SolrCloud to use 127.0.01 instead of localhost -- Key: SOLR-7806 URL: https://issues.apache.org/jira/browse/SOLR-7806 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 5.2.1 Environment: Linux Mac OS X Reporter: Arcadius Ahouansou Attachments: SOLR-7806.patch A colleague is having an issue very similar to the one described at http://muddyazian.blogspot.co.uk/2015/03/how-to-get-solr-500-quick-start.html He is running on the latest Arch Linux, and he gets that issue only when he connects to the office network. We also have another case when this happens only when a colleague is connected to the office network via VPN from his mac. I have looked around IMHO, the usage of 'localhost' in the solr code base may be leading to this kind of issues where the resolved IP is not route-able. Does it make any sense to replace all usage of 'localhost' in the code base by 127.0.01? -- 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: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome Mikhail! Mike McCandless http://blog.mikemccandless.com On Tue, Jul 21, 2015 at 3:21 AM, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7806) SolrCloud to use 127.0.01 instead of localhost
[ https://issues.apache.org/jira/browse/SOLR-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635201#comment-14635201 ] Arcadius Ahouansou commented on SOLR-7806: -- Please see attached patch [~markrmil...@gmail.com] SolrCloud to use 127.0.01 instead of localhost -- Key: SOLR-7806 URL: https://issues.apache.org/jira/browse/SOLR-7806 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 5.2.1 Environment: Linux Mac OS X Reporter: Arcadius Ahouansou Attachments: SOLR-7806.patch A colleague is having an issue very similar to the one described at http://muddyazian.blogspot.co.uk/2015/03/how-to-get-solr-500-quick-start.html He is running on the latest Arch Linux, and he gets that issue only when he connects to the office network. We also have another case when this happens only when a colleague is connected to the office network via VPN from his mac. I have looked around IMHO, the usage of 'localhost' in the solr code base may be leading to this kind of issues where the resolved IP is not route-able. Does it make any sense to replace all usage of 'localhost' in the code base by 127.0.01? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0_60-ea-b21) - Build # 13554 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13554/ Java: 32bit/jdk1.8.0_60-ea-b21 -server -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.BasicDistributedZkTest.test Error Message: commitWithin did not work on node: http://127.0.0.1:51986/collection1 expected:68 but was:67 Stack Trace: java.lang.AssertionError: commitWithin did not work on node: http://127.0.0.1:51986/collection1 expected:68 but was:67 at __randomizedtesting.SeedInfo.seed([DE54AE50096BF924:5600918AA79794DC]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.solr.cloud.BasicDistributedZkTest.test(BasicDistributedZkTest.java:332) 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:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) 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
[GitHub] lucene-solr pull request: SOLR-7816: timeAllowed parameter ignored...
GitHub user cpoerschke opened a pull request: https://github.com/apache/lucene-solr/pull/192 SOLR-7816: timeAllowed parameter ignored edge-case bug? for https://issues.apache.org/jira/i#browse/SOLR-7816 You can merge this pull request into a Git repository by running: $ git pull https://github.com/bloomberg/lucene-solr trunk-time-allowed-edge-case Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/192.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #192 commit 5147dd906f4fe7b054e525f36937bc1640e373de Author: Christine Poerschke cpoersc...@bloomberg.net Date: 2015-07-21T15:42:21Z [notes] SOLR-: timeAllowed parameter ignored edge-case bug? 'ant test -Dtestcase=ExitableDirectoryReaderTest -Dtests.method=testTimeAllowed' to see the notes --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: timeAllowed parameter ignored edge-case bug?
https://issues.apache.org/jira/i#browse/SOLR-7816 raised to track this. Yes, the issue only surfaces if queryResultsCache is configured and filterCache is not configured. I agree, this should not affect (m)any real users, just points towards opportunity to split/refactor somehow - i stumbled across this as part of SOLR-5730 when trying to see how/where the EarlyTerminatingSortingCollector should be added. -Christine - Original Message - From: hossman_luc...@fucit.org To: Christine Poerschke (BLOOMBERG/ LONDON), dev@lucene.apache.org At: Jul 21 2015 00:32:23 : In the scenario outlined below, the second run's timeAllowed parameter : is unexpectedly ignored. Could this be intentionally so somehow (q vs. : fq processing?, Collector vs. LeafCollector?, DocList vs. DocSet?), or : is it an edge-case bug? Based on your description (didn't re-review the code directly) it sounds like an oversight with timeAllowed -- probably overlooked because of the oddity of having a queryResultCache but not filterCache (correct me if i'm wrong, but it sounds like this bug won't surface if both queryResultsCache filterCache are enabled -- or both disabled -- correct?) ... probably doesn't affect (m)any real users because of this. Sounds like we should split out the build part of buildAndRunCollectorChain into it's own method and re-use it in getDocSet (although it seems like that will almost certainly require some API changes to propogate the QueryCommand context down) Christine: can you file this as a Jira so we don't lose track of it? : : Regards, : : Christine : : --- : : solrconfig characteristics: : * a queryResultsCache is configured : * no filterCache is configured : : query characteristics: : * q parameter present : * at least one fq parameter present : * sort parameter present (and does not require the score field) : * GET_DOCSET flag is set e.g. via the StatsComponent i.e. stats=true parameter : : runtime characteristics: : * first run of the query gets a queryResultsCache-miss and respects timeAllowed : * second run gets a queryResultsCache-hit and ignores timeAllowed (but still :makes use of the lucene IndexSearcher) : : code path execution details (first run): : * SolrIndexSearcher.search calls getDocListC : * getDocListC called queryResultCache.get which found nothing : * getDocListC calls getDocListAndSetNC : * getDocListAndSetNC calls buildAndRunCollectorChain : * buildAndRunCollectorChain constructs TimeLimitingCollector : : code path execution details (second run): : * SolrIndexSearcher.search calls getDocListC : * getDocListC called queryResultCache.get which found something : * getDocListC calls getDocSet(ListQuery queries) : * getDocSet(ListQuery queries) iterates over IndexSearcher.leafContexts : - : To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org : For additional commands, e-mail: dev-h...@lucene.apache.org : : -Hoss http://www.lucidworks.com/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7765) TokenizerChain without char filters cause NPE in luke request handler
[
https://issues.apache.org/jira/browse/SOLR-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635385#comment-14635385
]
ASF subversion and git services commented on SOLR-7765:
---
Commit 1692170 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1692170 ]
SOLR-7765: Hardened the behavior of TokenizerChain when null arguments are used
in constructor. This prevents NPEs in some code paths.
TokenizerChain without char filters cause NPE in luke request handler
-
Key: SOLR-7765
URL: https://issues.apache.org/jira/browse/SOLR-7765
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1
Reporter: Konstantin Gribov
Assignee: Hoss Man
Priority: Minor
Attachments: SOLR-7765.patch, SOLR-7765.patch, SOLR-7765.patch
{{TokenizerChain}} created using 2-arg constructor has {{null}} in
{{charFilters}}, so {{LukeRequestHandler}} throws NPE on iterating it.
Will create PR in a couple of minutes.
--
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-7765) TokenizerChain without char filters cause NPE in luke request handler
[
https://issues.apache.org/jira/browse/SOLR-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635438#comment-14635438
]
ASF subversion and git services commented on SOLR-7765:
---
Commit 1692174 from hoss...@apache.org in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1692174 ]
SOLR-7765: Hardened the behavior of TokenizerChain when null arguments are used
in constructor. This prevents NPEs in some code paths. (merge r1692170)
TokenizerChain without char filters cause NPE in luke request handler
-
Key: SOLR-7765
URL: https://issues.apache.org/jira/browse/SOLR-7765
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1
Reporter: Konstantin Gribov
Assignee: Hoss Man
Priority: Minor
Attachments: SOLR-7765.patch, SOLR-7765.patch, SOLR-7765.patch
{{TokenizerChain}} created using 2-arg constructor has {{null}} in
{{charFilters}}, so {{LukeRequestHandler}} throws NPE on iterating it.
Will create PR in a couple of minutes.
--
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-7765) TokenizerChain methods may return null depending on how constructor is called -- causes NPE in luke request handler
[
https://issues.apache.org/jira/browse/SOLR-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-7765:
---
Description:
{{TokenizerChain}} created using 2-arg constructor has {{null}} in
{{charFilters}}, so {{LukeRequestHandler}} throws NPE on iterating it.
{{TokenizerChain}} constructor's should be hardened to do explicit null checks,
throwing early NPE where appropriate (tokenizer factory), or initializing
internal arrays to have 0 length when optional (factories for char filters and
token filters)
was:
{{TokenizerChain}} created using 2-arg constructor has {{null}} in
{{charFilters}}, so {{LukeRequestHandler}} throws NPE on iterating it.
Will create PR in a couple of minutes.
Summary: TokenizerChain methods may return null depending on how
constructor is called -- causes NPE in luke request handler (was:
TokenizerChain without char filters cause NPE in luke request handler)
TokenizerChain methods may return null depending on how constructor is called
-- causes NPE in luke request handler
---
Key: SOLR-7765
URL: https://issues.apache.org/jira/browse/SOLR-7765
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1
Reporter: Konstantin Gribov
Assignee: Hoss Man
Priority: Minor
Attachments: SOLR-7765.patch, SOLR-7765.patch, SOLR-7765.patch
{{TokenizerChain}} created using 2-arg constructor has {{null}} in
{{charFilters}}, so {{LukeRequestHandler}} throws NPE on iterating it.
{{TokenizerChain}} constructor's should be hardened to do explicit null
checks, throwing early NPE where appropriate (tokenizer factory), or
initializing internal arrays to have 0 length when optional (factories for
char filters and token filters)
--
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: Welcome Mikhail Khludnev as Lucene/Solr committer
Congratulations! On Tue, Jul 21, 2015 at 12:31 PM, Joel Bernstein joels...@gmail.com wrote: Congratulations Mikhail! Joel Bernstein http://joelsolr.blogspot.com/ On Tue, Jul 21, 2015 at 12:39 PM, Michael McCandless luc...@mikemccandless.com wrote: Welcome Mikhail! Mike McCandless http://blog.mikemccandless.com On Tue, Jul 21, 2015 at 3:21 AM, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7816) timeAllowed parameter ignored edge-case bug (queryResultsCache=yes,filterCache=no)
[ https://issues.apache.org/jira/browse/SOLR-7816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635488#comment-14635488 ] ASF GitHub Bot commented on SOLR-7816: -- GitHub user cpoerschke opened a pull request: https://github.com/apache/lucene-solr/pull/192 SOLR-7816: timeAllowed parameter ignored edge-case bug? for https://issues.apache.org/jira/i#browse/SOLR-7816 You can merge this pull request into a Git repository by running: $ git pull https://github.com/bloomberg/lucene-solr trunk-time-allowed-edge-case Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/192.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #192 commit 5147dd906f4fe7b054e525f36937bc1640e373de Author: Christine Poerschke cpoersc...@bloomberg.net Date: 2015-07-21T15:42:21Z [notes] SOLR-: timeAllowed parameter ignored edge-case bug? 'ant test -Dtestcase=ExitableDirectoryReaderTest -Dtests.method=testTimeAllowed' to see the notes timeAllowed parameter ignored edge-case bug (queryResultsCache=yes,filterCache=no) -- Key: SOLR-7816 URL: https://issues.apache.org/jira/browse/SOLR-7816 Project: Solr Issue Type: Bug Reporter: Christine Poerschke Priority: Minor dev mailing list reference: http://markmail.org/message/3ttwppsbtia4e56t --- solrconfig characteristics: * a queryResultsCache is configured * no filterCache is configured query characteristics: * q parameter present * at least one fq parameter present * sort parameter present (and does not require the score field) * GET_DOCSET flag is set e.g. via the StatsComponent i.e. stats=true parameter --- github pull request with notes/reproduce debug trace 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] (SOLR-7816) timeAllowed parameter ignored edge-case bug (queryResultsCache=yes,filterCache=no)
Christine Poerschke created SOLR-7816: - Summary: timeAllowed parameter ignored edge-case bug (queryResultsCache=yes,filterCache=no) Key: SOLR-7816 URL: https://issues.apache.org/jira/browse/SOLR-7816 Project: Solr Issue Type: Bug Reporter: Christine Poerschke Priority: Minor dev mailing list reference: http://markmail.org/message/3ttwppsbtia4e56t --- solrconfig characteristics: * a queryResultsCache is configured * no filterCache is configured query characteristics: * q parameter present * at least one fq parameter present * sort parameter present (and does not require the score field) * GET_DOCSET flag is set e.g. via the StatsComponent i.e. stats=true parameter --- github pull request with notes/reproduce debug trace 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: Parsing and indexing parts of the input file paths
If this is only for search, then an analysis chain could be crafted, likely with the pattern regex filter in the mix, to pull out pieces of the path. How will you know the prefix of the file though? There’s also the ability to do this sort of thing in an update processor, most easily using the script update processor, using a bit of JavaScript to pull out the piece(s) you want to index (and even store at this point). — Erik Hatcher, Senior Solutions Architect http://www.lucidworks.com http://www.lucidworks.com/ On Jul 21, 2015, at 1:31 PM, Andrew Musselman andrew.mussel...@gmail.com wrote: Dear user and dev lists, We are loading files from a directory and would like to index a portion of each file path as a field as well as the text inside the file. E.g., on HDFS we have this file path: /user/andrew/1234/1234/file.pdf And we would like the 1234 token parsed from the file path and indexed as an additional field that can be searched on. From my initial searches I can't see how to do this easily, so would I need to write some custom code, or a plugin? Thanks!
Parsing and indexing parts of the input file paths
Dear user and dev lists, We are loading files from a directory and would like to index a portion of each file path as a field as well as the text inside the file. E.g., on HDFS we have this file path: /user/andrew/1234/1234/file.pdf And we would like the 1234 token parsed from the file path and indexed as an additional field that can be searched on. From my initial searches I can't see how to do this easily, so would I need to write some custom code, or a plugin? Thanks!
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
Congratulations Mikhail! Joel Bernstein http://joelsolr.blogspot.com/ On Tue, Jul 21, 2015 at 12:39 PM, Michael McCandless luc...@mikemccandless.com wrote: Welcome Mikhail! Mike McCandless http://blog.mikemccandless.com On Tue, Jul 21, 2015 at 3:21 AM, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - 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] (SOLR-7765) TokenizerChain methods may return null depending on how constructor is called -- causes NPE in luke request handler
[
https://issues.apache.org/jira/browse/SOLR-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-7765.
Resolution: Fixed
Fix Version/s: Trunk
5.3
Thanks for rasiing this issue and helping out with the tests Konstantin,
bq. Is there any reason to use reversed order in ifs...
It's just a defensive coding habbit i developed from doing a lot of C and perl
coding in my early years as a developer ... trained my brain to default to
putting constants on the left in comparisons in cause i misstype = instead of
== or =
TokenizerChain methods may return null depending on how constructor is called
-- causes NPE in luke request handler
---
Key: SOLR-7765
URL: https://issues.apache.org/jira/browse/SOLR-7765
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1
Reporter: Konstantin Gribov
Assignee: Hoss Man
Priority: Minor
Fix For: 5.3, Trunk
Attachments: SOLR-7765.patch, SOLR-7765.patch, SOLR-7765.patch
{{TokenizerChain}} created using 2-arg constructor has {{null}} in
{{charFilters}}, so {{LukeRequestHandler}} throws NPE on iterating it.
{{TokenizerChain}} constructor's should be hardened to do explicit null
checks, throwing early NPE where appropriate (tokenizer factory), or
initializing internal arrays to have 0 length when optional (factories for
char filters and token filters)
--
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-7816) timeAllowed parameter ignored edge-case bug (queryResultsCache=yes,filterCache=no)
[
https://issues.apache.org/jira/browse/SOLR-7816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635491#comment-14635491
]
Christine Poerschke commented on SOLR-7816:
---
debug trace extract:
{code}
SolrIndexSearcher.constructor pretendMode=1
SolrIndexSearcher.constructor pretend that no filterCache is configured
SolrIndexSearcher.search(QueryResult qr, QueryCommand cmd) called
SolrIndexSearcher.getDocListC(QueryResult qr, QueryCommand cmd) called
SolrIndexSearcher.getDocListAndSetNC(QueryResult qr, QueryCommand cmd) called
SolrIndexSearcher.getProcessedFilter(DocSet setFilter, ListQuery queries)
called
SolrIndexSearcher.getProcessedFilter - there is no cache: don't pull bitsets
SolrIndexSearcher.buildAndRunCollectorChain(...) called
TimeLimitingCollector.constructor(...ticksAllowed=10001) called
SolrIndexSearcher.buildAndRunCollectorChain(...) call IndexSearcher.search
# should have seen TimeLimitingCollector.constructor and IndexSearcher.search
calls
SolrIndexSearcher.search(QueryResult qr, QueryCommand cmd) called
SolrIndexSearcher.getDocListC(QueryResult qr, QueryCommand cmd) called
SolrIndexSearcher.getDocSet(ListQuery queries) called
SolrIndexSearcher.getProcessedFilter(DocSet setFilter, ListQuery queries)
called
SolrIndexSearcher.getProcessedFilter - there is no cache: don't pull bitsets
SolrIndexSearcher.getProcessedFilter - there is no cache: don't pull bitsets
SolrIndexSearcher.getDocSet(ListQuery queries) iterate over
IndexSearcher.leafContexts
([LeafReaderContext(FilterLeafReader(Uninverting(_0(6.0.0):c297)) docBase=0
ord=0)])
# if IndexSearcher.leafContexts were iterated over then should have seen
TimeLimitingCollector.constructor use also
{code}
timeAllowed parameter ignored edge-case bug
(queryResultsCache=yes,filterCache=no)
--
Key: SOLR-7816
URL: https://issues.apache.org/jira/browse/SOLR-7816
Project: Solr
Issue Type: Bug
Reporter: Christine Poerschke
Priority: Minor
dev mailing list reference: http://markmail.org/message/3ttwppsbtia4e56t
---
solrconfig characteristics:
* a queryResultsCache is configured
* no filterCache is configured
query characteristics:
* q parameter present
* at least one fq parameter present
* sort parameter present (and does not require the score field)
* GET_DOCSET flag is set e.g. via the StatsComponent i.e. stats=true
parameter
---
github pull request with notes/reproduce debug trace 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-7742) Support for Immutable ConfigSets
[ https://issues.apache.org/jira/browse/SOLR-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Chanan updated SOLR-7742: - Attachment: SOLR-7742log.patch Here's a patch to improve the logging: - Makes it more obvious it's not an error, i.e. says assuming default properties - Only prints the exception message, not the stacktrace Support for Immutable ConfigSets Key: SOLR-7742 URL: https://issues.apache.org/jira/browse/SOLR-7742 Project: Solr Issue Type: New Feature Reporter: Gregory Chanan Assignee: Gregory Chanan Fix For: 5.3, Trunk Attachments: SOLR-7742, SOLR-7742.patch, SOLR-7742log.patch See the discussion in SOLR-5955; to properly support collection templates that can be specified as the starting point for a collection configuration, we need support for ConfigSets that are immutable. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.8.0_45) - Build # 5052 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5052/
Java: 64bit/jdk1.8.0_45 -XX:+UseCompressedOops -XX:+UseG1GC
1 tests failed.
FAILED: org.apache.lucene.store.TestSimpleFSLockFactory.testStressLocks
Error Message:
Captured an uncaught exception in thread: Thread[id=712, name=Thread-500,
state=RUNNABLE, group=TGRP-TestSimpleFSLockFactory]
Stack Trace:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught
exception in thread: Thread[id=712, name=Thread-500, state=RUNNABLE,
group=TGRP-TestSimpleFSLockFactory]
at
__randomizedtesting.SeedInfo.seed([D84E895A7ED9E6D6:867FC7A762752EB0]:0)
Caused by: java.lang.AssertionError: hit unexpected NoSuchFileException:
file=_m.cfs
at __randomizedtesting.SeedInfo.seed([D84E895A7ED9E6D6]: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.IndexWriter.finishCommit(IndexWriter.java:3020)
at
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2970)
at org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1066)
at org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1109)
at
org.apache.lucene.store.BaseLockFactoryTestCase$WriterThread.run(BaseLockFactoryTestCase.java:221)
Build Log:
[...truncated 1022 lines...]
[junit4] Suite: org.apache.lucene.store.TestSimpleFSLockFactory
[junit4] 2 de jul. 21, 2015 9:12:46 PM
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
uncaughtException
[junit4] 2 WARNING: Uncaught exception in thread:
Thread[Thread-500,5,TGRP-TestSimpleFSLockFactory]
[junit4] 2 java.lang.AssertionError: hit unexpected NoSuchFileException:
file=_m.cfs
[junit4] 2at
__randomizedtesting.SeedInfo.seed([D84E895A7ED9E6D6]: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.IndexWriter.finishCommit(IndexWriter.java:3020)
[junit4] 2at
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2970)
[junit4] 2at
org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1066)
[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=TestSimpleFSLockFactory -Dtests.method=testStressLocks
-Dtests.seed=D84E895A7ED9E6D6 -Dtests.slow=true -Dtests.locale=ca_ES
-Dtests.timezone=America/Indiana/Knox -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1
[junit4] ERROR 2.96s J1 | TestSimpleFSLockFactory.testStressLocks
[junit4] Throwable #1:
com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught
exception in thread: Thread[id=712, name=Thread-500, state=RUNNABLE,
group=TGRP-TestSimpleFSLockFactory]
[junit4]at
__randomizedtesting.SeedInfo.seed([D84E895A7ED9E6D6:867FC7A762752EB0]:0)
[junit4] Caused by: java.lang.AssertionError: hit unexpected
NoSuchFileException: file=_m.cfs
[junit4]at
__randomizedtesting.SeedInfo.seed([D84E895A7ED9E6D6]: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.IndexWriter.finishCommit(IndexWriter.java:3020)
[junit4]at
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2970)
[junit4]at
org.apache.lucene.index.IndexWriter.shutdown(IndexWriter.java:1066)
[junit4]at
org.apache.lucene.index.IndexWriter.close(IndexWriter.java:1109)
[junit4]at
org.apache.lucene.store.BaseLockFactoryTestCase$WriterThread.run(BaseLockFactoryTestCase.java:221)
[junit4] 2 NOTE: test params are: codec=Asserting(Lucene53):
{content=PostingsFormat(name=LuceneVarGapDocFreqInterval)}, docValues:{},
sim=RandomSimilarityProvider(queryNorm=false,coord=yes): {content=DFR GL1},
locale=ca_ES, timezone=America/Indiana/Knox
[junit4] 2 NOTE: Windows 7 6.1 amd64/Oracle Corporation 1.8.0_45
(64-bit)/cpus=3,threads=1,free=304611952,total=331350016
[junit4]
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 13373 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13373/ Java: 64bit/jdk1.7.0_80 -XX:-UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 62386 lines...] BUILD FAILED /home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:536: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:443: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/extra-targets.xml:105: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/extra-targets.xml:122: java.lang.OutOfMemoryError: PermGen space at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:449) at java.net.URLClassLoader.access$100(URLClassLoader.java:71) at java.net.URLClassLoader$1.run(URLClassLoader.java:361) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:425) at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:677) at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:787) at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:775) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2625) at java.lang.Class.getDeclaredMethods(Class.java:1868) at org.codehaus.groovy.reflection.stdclasses.CachedSAMClass$1.run(CachedSAMClass.java:104) at org.codehaus.groovy.reflection.stdclasses.CachedSAMClass$1.run(CachedSAMClass.java:102) at java.security.AccessController.doPrivileged(Native Method) at org.codehaus.groovy.reflection.stdclasses.CachedSAMClass.getDeclaredMethods(CachedSAMClass.java:102) at org.codehaus.groovy.reflection.stdclasses.CachedSAMClass.getAbstractMethods(CachedSAMClass.java:120) at org.codehaus.groovy.reflection.stdclasses.CachedSAMClass.getSAMMethod(CachedSAMClass.java:186) at org.codehaus.groovy.reflection.ClassInfo.isSAM(ClassInfo.java:359) at org.codehaus.groovy.reflection.ClassInfo.createCachedClass(ClassInfo.java:349) at org.codehaus.groovy.reflection.ClassInfo.access$700(ClassInfo.java:41) at org.codehaus.groovy.reflection.ClassInfo$LazyCachedClassRef.initValue(ClassInfo.java:497) at org.codehaus.groovy.reflection.ClassInfo$LazyCachedClassRef.initValue(ClassInfo.java:488) at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:49) at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:36) at org.codehaus.groovy.reflection.ClassInfo.getCachedClass(ClassInfo.java:111) at org.codehaus.groovy.reflection.ReflectionCache.getCachedClass(ReflectionCache.java:110) at org.codehaus.groovy.reflection.ParameterTypes.getParametersTypes0(ParameterTypes.java:81) Total time: 61 minutes 38 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7742) Support for Immutable ConfigSets
[ https://issues.apache.org/jira/browse/SOLR-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14636061#comment-14636061 ] Gregory Chanan commented on SOLR-7742: -- ok, that isn't indicative of an error, it's just logged at info level giving info about where it looked for the properties (it's not an error to not find the properties). I agree it's not ideal because people tend to assume something is serious when they see a stacktrace. Support for Immutable ConfigSets Key: SOLR-7742 URL: https://issues.apache.org/jira/browse/SOLR-7742 Project: Solr Issue Type: New Feature Reporter: Gregory Chanan Assignee: Gregory Chanan Fix For: 5.3, Trunk Attachments: SOLR-7742, SOLR-7742.patch See the discussion in SOLR-5955; to properly support collection templates that can be specified as the starting point for a collection configuration, we need support for ConfigSets that are immutable. -- 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-7441) Improve overall robustness of the Streaming stack: Streaming API, Streaming Expressions, Parallel SQL
[ https://issues.apache.org/jira/browse/SOLR-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14636176#comment-14636176 ] Gus Heck commented on SOLR-7441: [~joel.bernstein] thx for reviewing this in and carrying it forward. I got behind on my list mail and didn't see your comments. Sorry! Improve overall robustness of the Streaming stack: Streaming API, Streaming Expressions, Parallel SQL - Key: SOLR-7441 URL: https://issues.apache.org/jira/browse/SOLR-7441 Project: Solr Issue Type: Improvement Affects Versions: 5.1 Reporter: Erick Erickson Assignee: Joel Bernstein Priority: Minor Attachments: SOLR-7441.patch, SOLR-7441.patch, SOLR-7441.patch, SOLR-7441.patch It's harder than it could be to figure out what the error is when using Streaming Aggregation. For instance if you specify an fl parameter for a field that doesn't exist it's hard to figure out that's the cause. This is true even if you look in the Solr logs. I'm not quite sure whether it'd be possible to report this at the client level or not, but it seems at least we could repor something more helpful in the Solr logs. -- 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-7441) Improve overall robustness of the Streaming stack: Streaming API, Streaming Expressions, Parallel SQL
[ https://issues.apache.org/jira/browse/SOLR-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14636178#comment-14636178 ] Gus Heck commented on SOLR-7441: Also, if you or anyone reading this has the karma, please disable the gus.h...@olin.edu account. Mail to it (and thus the inline references you used here) don't actually reach me. I haven't worked there since 2004, and there is no way for me to regain control of that account using that address. Improve overall robustness of the Streaming stack: Streaming API, Streaming Expressions, Parallel SQL - Key: SOLR-7441 URL: https://issues.apache.org/jira/browse/SOLR-7441 Project: Solr Issue Type: Improvement Affects Versions: 5.1 Reporter: Erick Erickson Assignee: Joel Bernstein Priority: Minor Attachments: SOLR-7441.patch, SOLR-7441.patch, SOLR-7441.patch, SOLR-7441.patch It's harder than it could be to figure out what the error is when using Streaming Aggregation. For instance if you specify an fl parameter for a field that doesn't exist it's hard to figure out that's the cause. This is true even if you look in the Solr logs. I'm not quite sure whether it'd be possible to report this at the client level or not, but it seems at least we could repor something more helpful in the Solr logs. -- 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 # 2534 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/2534/ Java: 64bit/jdk1.8.0 -XX:+UseCompressedOops -XX:+UseParallelGC 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([FA6717C1ABDFB670:F20762EDA4D19E7B]: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:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) 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
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_45) - Build # 13552 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13552/ Java: 64bit/jdk1.8.0_45 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTests Error Message: Timeout waiting for CDCR replication to complete @source_collection:shard2 Stack Trace: java.lang.RuntimeException: Timeout waiting for CDCR replication to complete @source_collection:shard2 at __randomizedtesting.SeedInfo.seed([1EF978C134121804:16990DED3B1C300F]:0) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForReplicationToComplete(BaseCdcrDistributedZkTest.java:732) at org.apache.solr.cloud.CdcrReplicationDistributedZkTest.doTestUpdateLogSynchronisation(CdcrReplicationDistributedZkTest.java:362) 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:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) 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
[jira] [Commented] (SOLR-7742) Support for Immutable ConfigSets
[ https://issues.apache.org/jira/browse/SOLR-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635708#comment-14635708 ] Noble Paul commented on SOLR-7742: -- Yes I see this error often Support for Immutable ConfigSets Key: SOLR-7742 URL: https://issues.apache.org/jira/browse/SOLR-7742 Project: Solr Issue Type: New Feature Reporter: Gregory Chanan Assignee: Gregory Chanan Fix For: 5.3, Trunk Attachments: SOLR-7742, SOLR-7742.patch See the discussion in SOLR-5955; to properly support collection templates that can be specified as the starting point for a collection configuration, we need support for ConfigSets that are immutable. -- 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-7742) Support for Immutable ConfigSets
[
https://issues.apache.org/jira/browse/SOLR-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635703#comment-14635703
]
Anshum Gupta commented on SOLR-7742:
Hi Greg, I've been seeing a lot of Exceptions like the one below after this
commit
{code}
org.apache.solr.core.SolrResourceNotFoundException: Can't find resource
'configsetprops.json' in classpath or '/configs/conf1',
cwd=/Users/anshumgupta/workspace/lucene-trunk/solr/build/solr-core/test/J0
[junit4] 2at
org.apache.solr.cloud.ZkSolrResourceLoader.openResource(ZkSolrResourceLoader.java:99)
[junit4] 2at
org.apache.solr.core.ConfigSetProperties.readFromResourceLoader(ConfigSetProperties.java:49)
[junit4] 2at
org.apache.solr.core.ConfigSetService.createConfigSetProperties(ConfigSetService.java:114)
[junit4] 2at
org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:76)
[junit4] 2at
org.apache.solr.core.CoreContainer.create(CoreContainer.java:668)
[junit4] 2at
org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:397)
[junit4] 2at
org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:388)
[junit4] 2at
java.util.concurrent.FutureTask.run(FutureTask.java:266)
[junit4] 2at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$1.run(ExecutorUtil.java:156)
[junit4] 2at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[junit4] 2at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[junit4] 2at java.lang.Thread.run(Thread.java:745)
{code}
P.S: I've noticed this while running the tests generally.
Support for Immutable ConfigSets
Key: SOLR-7742
URL: https://issues.apache.org/jira/browse/SOLR-7742
Project: Solr
Issue Type: New Feature
Reporter: Gregory Chanan
Assignee: Gregory Chanan
Fix For: 5.3, Trunk
Attachments: SOLR-7742, SOLR-7742.patch
See the discussion in SOLR-5955; to properly support collection templates
that can be specified as the starting point for a collection configuration,
we need support for ConfigSets that are immutable.
--
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-7817) Move solr.test.sys.prop(1|2) out of the generic solrconfig.xml that's used by most tests
Anshum Gupta created SOLR-7817: -- Summary: Move solr.test.sys.prop(1|2) out of the generic solrconfig.xml that's used by most tests Key: SOLR-7817 URL: https://issues.apache.org/jira/browse/SOLR-7817 Project: Solr Issue Type: Test Reporter: Anshum Gupta Priority: Minor We have solr.test.sys.prop1 and solr.test.sys.prop2 system properties in the widely used solrconfig.xml and it would make sense to move these to a different solrconfig which can be used by the tests that need this. Setting this system property in the test base class isn't good, specially as writing a new test that doesn't extend on the existing test base classes requires the knowledge of setting these if you want to use the widely used solrconfig.xml. Here's another conversation about the same from 2007: http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200703.mbox/%3cc68e39170703291430w5a57f603p7f0b7412d7cbb...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5379) Query-time multi-word synonym expansion
[ https://issues.apache.org/jira/browse/SOLR-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635899#comment-14635899 ] Timothy Garafola commented on SOLR-5379: Is there a status on this issue? Did it get moved forward to 5.x? Is it available in 4.10? Query-time multi-word synonym expansion --- Key: SOLR-5379 URL: https://issues.apache.org/jira/browse/SOLR-5379 Project: Solr Issue Type: Improvement Components: query parsers Reporter: Tien Nguyen Manh Labels: multi-word, queryparser, synonym Fix For: 4.9, Trunk Attachments: conf-test-files-4_8_1.patch, quoted-4_8_1.patch, quoted.patch, solr-5379-version-4.10.3.patch, synonym-expander-4_8_1.patch, synonym-expander.patch While dealing with synonym at query time, solr failed to work with multi-word synonyms due to some reasons: - First the lucene queryparser tokenizes user query by space so it split multi-word term into two terms before feeding to synonym filter, so synonym filter can't recognized multi-word term to do expansion - Second, if synonym filter expand into multiple terms which contains multi-word synonym, The SolrQueryParseBase currently use MultiPhraseQuery to handle synonyms. But MultiPhraseQuery don't work with term have different number of words. For the first one, we can extend quoted all multi-word synonym in user query so that lucene queryparser don't split it. There are a jira task related to this one https://issues.apache.org/jira/browse/LUCENE-2605. For the second, we can replace MultiPhraseQuery by an appropriate BoleanQuery SHOULD which contains multiple PhraseQuery in case tokens stream have multi-word synonym. -- 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-6685) GeoPointInBBox/Distance queries should have safeguards
[ https://issues.apache.org/jira/browse/LUCENE-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicholas Knize updated LUCENE-6685: --- Attachment: LUCENE-6685.patch Updated patch iincludes the following improvements: * Dynamically compute detail level based on query size (includes min/max bounds on detail level) * Remove unnecessary ranges from PointDistanceQuery GeoPointInBBox/Distance queries should have safeguards -- Key: LUCENE-6685 URL: https://issues.apache.org/jira/browse/LUCENE-6685 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Fix For: 5.3, Trunk Attachments: LUCENE-6685.patch, LUCENE-6685.patch, LUCENE-6685.patch These queries build a big list of term ranges, where the size of the list is in proportion to how many cells of the space filling curve are crossed by the perimeter of the query (I think?). This can easily be 100s of MBs for a big enough query ... not to mention slow to enumerate (we still do this again for each segment). I think the queries should have safeguards, much like we have maxDeterminizedStates for Automaton based queries, to prevent accidental OOMEs. But I think longer term we should either change the ranges to be enumerated on-demand and never stored in entirety (like NumericRangeTermsEnum), or change the query so it has a fixed budget of how many cells it's allowed to visit and then within a crossing cell it uses doc values to post-filter. -- 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-6547) Add dateline crossing support to GeoPointInBBox and GeoPointDistance Queries
[ https://issues.apache.org/jira/browse/LUCENE-6547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635860#comment-14635860 ] Nicholas Knize commented on LUCENE-6547: bq. The test was very slow with the * 1000 random radius ... I'm not sure why? There were unnecessary ranges being computed for the GeoPointDistance query. This has been fixed in the latest patch for LUCENE-6685. Add dateline crossing support to GeoPointInBBox and GeoPointDistance Queries Key: LUCENE-6547 URL: https://issues.apache.org/jira/browse/LUCENE-6547 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Nicholas Knize Fix For: 5.3, Trunk Attachments: LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch, LUCENE-6547.patch The current GeoPointInBBoxQuery only supports bounding boxes that are within the standard -180:180 longitudinal bounds. While its perfectly fine to require users to split dateline crossing bounding boxes in two, GeoPointDistanceQuery should support distance queries that cross the dateline. Since morton encoding doesn't support unwinding this issue will add dateline crossing to GeoPointInBBoxQuery and GeoPointDistanceQuery classes. -- 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-6685) GeoPointInBBox/Distance queries should have safeguards
[ https://issues.apache.org/jira/browse/LUCENE-6685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635858#comment-14635858 ] Nicholas Knize edited comment on LUCENE-6685 at 7/21/15 9:41 PM: - Updated patch iincludes the following improvements: * Dynamically compute detail level based on query size (includes min/max bounds on detail level) * Remove unnecessary ranges from PointDistanceQuery * Updated javadocs was (Author: nknize): Updated patch iincludes the following improvements: * Dynamically compute detail level based on query size (includes min/max bounds on detail level) * Remove unnecessary ranges from PointDistanceQuery GeoPointInBBox/Distance queries should have safeguards -- Key: LUCENE-6685 URL: https://issues.apache.org/jira/browse/LUCENE-6685 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Fix For: 5.3, Trunk Attachments: LUCENE-6685.patch, LUCENE-6685.patch, LUCENE-6685.patch These queries build a big list of term ranges, where the size of the list is in proportion to how many cells of the space filling curve are crossed by the perimeter of the query (I think?). This can easily be 100s of MBs for a big enough query ... not to mention slow to enumerate (we still do this again for each segment). I think the queries should have safeguards, much like we have maxDeterminizedStates for Automaton based queries, to prevent accidental OOMEs. But I think longer term we should either change the ranges to be enumerated on-demand and never stored in entirety (like NumericRangeTermsEnum), or change the query so it has a fixed budget of how many cells it's allowed to visit and then within a crossing cell it uses doc values to post-filter. -- 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-7560) Parallel SQL Support
[ https://issues.apache.org/jira/browse/SOLR-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635770#comment-14635770 ] Joel Bernstein commented on SOLR-7560: -- Just wrapped up the work on SOLR-7441 which really makes the SQL interface much more robust and user friendly when errors occur. I think the SQL work is ready to backport to the 5x branch. Parallel SQL Support Key: SOLR-7560 URL: https://issues.apache.org/jira/browse/SOLR-7560 Project: Solr Issue Type: New Feature Components: clients - java, search Reporter: Joel Bernstein Fix For: 5.3 Attachments: SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch, SOLR-7560.patch This ticket provides support for executing *Parallel SQL* queries across SolrCloud collections. The SQL engine will be built on top of the Streaming API (SOLR-7082), which provides support for *parallel relational algebra* and *real-time map-reduce*. Basic design: 1) A new SQLHandler will be added to process SQL requests. The SQL statements will be compiled to live Streaming API objects for parallel execution across SolrCloud worker nodes. 2) SolrCloud collections will be abstracted as *Relational Tables*. 3) The Presto SQL parser will be used to parse the SQL statements. 4) A JDBC thin client will be added as a Solrj client. This ticket will focus on putting the framework in place and providing basic SELECT support and GROUP BY aggregate support. Future releases will build on this framework to provide additional SQL features. -- 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-7742) Support for Immutable ConfigSets
[ https://issues.apache.org/jira/browse/SOLR-7742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635730#comment-14635730 ] Gregory Chanan commented on SOLR-7742: -- Do you have a specific test case I can look at? Support for Immutable ConfigSets Key: SOLR-7742 URL: https://issues.apache.org/jira/browse/SOLR-7742 Project: Solr Issue Type: New Feature Reporter: Gregory Chanan Assignee: Gregory Chanan Fix For: 5.3, Trunk Attachments: SOLR-7742, SOLR-7742.patch See the discussion in SOLR-5955; to properly support collection templates that can be specified as the starting point for a collection configuration, we need support for ConfigSets that are immutable. -- 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_45) - Build # 5051 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/5051/ Java: 32bit/jdk1.8.0_45 -server -XX:+UseG1GC 2 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest Error Message: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] Stack Trace: java.lang.AssertionError: ObjectTracker found 1 object(s) that were not released!!! [TransactionLog] at __randomizedtesting.SeedInfo.seed([D9A9A80C8F0C73BF]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNull(Assert.java:551) at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:235) 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$5.evaluate(RandomizedRunner.java:799) 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) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.HttpPartitionTest Error Message: Could not remove the following files (in the order of attempts): C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_D9A9A80C8F0C73BF-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1\data\tlog\tlog.000: java.nio.file.FileSystemException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_D9A9A80C8F0C73BF-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1\data\tlog\tlog.000: The process cannot access the file because it is being used by another process. C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_D9A9A80C8F0C73BF-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1\data\tlog: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_D9A9A80C8F0C73BF-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1\data\tlog C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_D9A9A80C8F0C73BF-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1\data: java.nio.file.DirectoryNotEmptyException: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_D9A9A80C8F0C73BF-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1\data C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J1\temp\solr.cloud.HttpPartitionTest_D9A9A80C8F0C73BF-001\control-001\cores\c8n_1x2_leader_session_loss_shard1_replica1:
[jira] [Commented] (SOLR-7441) Improve overall robustness of the Streaming stack: Streaming API, Streaming Expressions, Parallel SQL
[ https://issues.apache.org/jira/browse/SOLR-7441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635758#comment-14635758 ] ASF subversion and git services commented on SOLR-7441: --- Commit 1692193 from [~joel.bernstein] in branch 'dev/trunk' [ https://svn.apache.org/r1692193 ] SOLR-7441:Improve overall robustness of the Streaming stack: Streaming API, Streaming Expressions, Parallel SQL Improve overall robustness of the Streaming stack: Streaming API, Streaming Expressions, Parallel SQL - Key: SOLR-7441 URL: https://issues.apache.org/jira/browse/SOLR-7441 Project: Solr Issue Type: Improvement Affects Versions: 5.1 Reporter: Erick Erickson Assignee: Joel Bernstein Priority: Minor Attachments: SOLR-7441.patch, SOLR-7441.patch, SOLR-7441.patch, SOLR-7441.patch It's harder than it could be to figure out what the error is when using Streaming Aggregation. For instance if you specify an fl parameter for a field that doesn't exist it's hard to figure out that's the cause. This is true even if you look in the Solr logs. I'm not quite sure whether it'd be possible to report this at the client level or not, but it seems at least we could repor something more helpful in the Solr logs. -- 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: Parsing and indexing parts of the input file paths
Erik, thanks; the prefix starting with /user/andrew/ will be known, and can be put into config, let's assume. Would this be config-only or would it require some code, and could you point to some classes I can start with if I need to write code, and some up-to-date docs? Same for the update processor, is there an example I could read? On Tue, Jul 21, 2015 at 11:19 AM, Erik Hatcher erik.hatc...@gmail.com wrote: If this is only for search, then an analysis chain could be crafted, likely with the pattern regex filter in the mix, to pull out pieces of the path. How will you know the prefix of the file though? There’s also the ability to do this sort of thing in an update processor, most easily using the script update processor, using a bit of JavaScript to pull out the piece(s) you want to index (and even store at this point). — Erik Hatcher, Senior Solutions Architect http://www.lucidworks.com On Jul 21, 2015, at 1:31 PM, Andrew Musselman andrew.mussel...@gmail.com wrote: Dear user and dev lists, We are loading files from a directory and would like to index a portion of each file path as a field as well as the text inside the file. E.g., on HDFS we have this file path: /user/andrew/1234/1234/file.pdf And we would like the 1234 token parsed from the file path and indexed as an additional field that can be searched on. From my initial searches I can't see how to do this easily, so would I need to write some custom code, or a plugin? Thanks!
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0_60-ea-b21) - Build # 13553 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/13553/ Java: 64bit/jdk1.8.0_60-ea-b21 -XX:+UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest Error Message: There are still nodes recoverying - waited for 330 seconds Stack Trace: java.lang.AssertionError: There are still nodes recoverying - waited for 330 seconds at __randomizedtesting.SeedInfo.seed([AAD1A27A9CD8CB7E:D951ADEF163D8C7]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:172) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:133) at org.apache.solr.cloud.AbstractDistribZkTestBase.waitForRecoveriesToFinish(AbstractDistribZkTestBase.java:128) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.waitForRecoveriesToFinish(BaseCdcrDistributedZkTest.java:465) at org.apache.solr.cloud.BaseCdcrDistributedZkTest.clearSourceCollection(BaseCdcrDistributedZkTest.java:319) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTestPartialReplicationAfterPeerSync(CdcrReplicationHandlerTest.java:158) at org.apache.solr.cloud.CdcrReplicationHandlerTest.doTest(CdcrReplicationHandlerTest.java:53) 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:963) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) 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
Welcome Mikhail Khludnev as Lucene/Solr committer
I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6668) Optimize SortedSet/SortedNumeric storage for the few unique sets use-case
[ https://issues.apache.org/jira/browse/LUCENE-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634735#comment-14634735 ] ASF subversion and git services commented on LUCENE-6668: - Commit 1692061 from [~jpountz] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1692061 ] LUCENE-6668: Added table encoding to sorted set/numeric doc values. Optimize SortedSet/SortedNumeric storage for the few unique sets use-case - Key: LUCENE-6668 URL: https://issues.apache.org/jira/browse/LUCENE-6668 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-6668.patch, LUCENE-6668.patch Robert suggested this idea: if there are few unique sets of values, we could build a lookup table and then map each doc to an ord in this table, just like we already do for table compression for numerics. I think this is especially compelling given that SortedSet/SortedNumeric are our two only doc values types that use O(maxDoc) memory because of the offsets map. When this new strategy is used, memory usage could be bounded to a constant. -- 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-5.x-Linux (32bit/jdk1.7.0_80) - Build # 13364 - Failure!
This is because of my commit, I tested with Java 8 which has a default
method for remove() on the contrary to Java 7. I'll fix.
On Tue, Jul 21, 2015 at 10:28 AM, Policeman Jenkins Server
jenk...@thetaphi.de wrote:
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13364/
Java: 32bit/jdk1.7.0_80 -server -XX:+UseConcMarkSweepGC
No tests ran.
Build Log:
[...truncated 399 lines...]
[javac] Compiling 735 source files to
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/classes/java
[javac]
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50DocValuesConsumer.java:591:
error: anonymous
org.apache.lucene.codecs.lucene50.Lucene50DocValuesConsumer$1$1 is not
abstract and does not override abstract method remove() in Iterator
[javac] return new IteratorNumber() {
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 1 error
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:536: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:484: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:61: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/extra-targets.xml:39: The
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build.xml:50: The
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:525:
The following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:1956:
Compile failed; see the compiler error output for details.
Total time: 7 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Publisher 'Publish JUnit test result report' failed: No test report
files were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
Adrien
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome Mikhail! On Jul 21, 2015 10:23 AM, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
Congrats, Mikhail! On Jul 21, 2015, at 4:21 PM, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - 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
[JENKINS] Lucene-Solr-5.x-Linux (32bit/jdk1.7.0_80) - Build # 13364 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13364/
Java: 32bit/jdk1.7.0_80 -server -XX:+UseConcMarkSweepGC
No tests ran.
Build Log:
[...truncated 399 lines...]
[javac] Compiling 735 source files to
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build/core/classes/java
[javac]
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/core/src/java/org/apache/lucene/codecs/lucene50/Lucene50DocValuesConsumer.java:591:
error: anonymous
org.apache.lucene.codecs.lucene50.Lucene50DocValuesConsumer$1$1 is not
abstract and does not override abstract method remove() in Iterator
[javac] return new IteratorNumber() {
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 1 error
BUILD FAILED
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:536: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:484: The following
error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:61: The following error
occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/extra-targets.xml:39: The
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/build.xml:50: The
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:525: The
following error occurred while executing this line:
/home/jenkins/workspace/Lucene-Solr-5.x-Linux/lucene/common-build.xml:1956:
Compile failed; see the compiler error output for details.
Total time: 7 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
ERROR: Publisher 'Publish JUnit test result report' failed: No test report
files were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6690) Speed up MultiTermsEnum.next()
[
https://issues.apache.org/jira/browse/LUCENE-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634897#comment-14634897
]
Martijn van Groningen commented on LUCENE-6690:
---
+1 this looks great. I test it out on an index with a single doc values field
with 100M unique values and 42 segments and the rebuilding time dropped from
~17000 ms to ~10800ms.
Speed up MultiTermsEnum.next()
--
Key: LUCENE-6690
URL: https://issues.apache.org/jira/browse/LUCENE-6690
Project: Lucene - Core
Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
Attachments: LUCENE-6690.patch, OrdinalMapBuildBench.java
OrdinalMap is very useful when computing top terms on a multi-index segment.
However I've seen it being occasionally slow to build, which was either
making facets (when the ordinals map is computed lazily) or reopen (when
computed eagerly) slow. So out of curiosity, I tried to profile ordinal map
building on a simple index: 10M random strings of length between 0 and 20
stored as a SORTED doc values field. The index has 19 segments. The
bottleneck was MultiTermsEnum.next() (by far) due to lots of BytesRef
comparisons (UTF8SortedAsUnicodeComparator).
MultiTermsEnum stores sub enums in two different places:
- top: a simple array containing all enums on the current term
- queue: a queue for enums that are not exhausted yet but beyond the current
term.
A non-exhausted enum is in exactly one of these data-structures. When moving
to the next term, MultiTermsEnum advances all enums in {{top}}, then adds
them to {{queue}} and finally, pops all enum that are on the same term back
into {{top}}.
We could save reorderings of the priority queue by not removing entries from
the priority queue and then calling updateTop to advance enums which are on
the current term. This is already what we do for disjunctions of doc IDs in
DISIPriorityQueue.
On the index described above and current trunk, building an OrdinalMap has to
call UTF8SortedAsUnicodeComparator.compare 80114820 times and runs in 1.9 s.
With the change, it calls UTF8SortedAsUnicodeComparator.compare 36900694
times, BytesRef.equals 16297638 times and runs in 1.4s (~26% faster).
--
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: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome Mikhail! On Tue, Jul 21, 2015 at 8:21 AM, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Not sent from my iPhone or my Blackberry or anyone else's
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome, Mikhail! Alan Woodward www.flax.co.uk On 21 Jul 2015, at 08:21, Adrien Grand wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6674) J9 assertion / crash in tests
[
https://issues.apache.org/jira/browse/LUCENE-6674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634941#comment-14634941
]
Brijesh Nekkare commented on LUCENE-6674:
-
We would also need the coredump to be jextracted as detailed at
http://www-01.ibm.com/support/docview.wss?uid=swg21577379
J9 assertion / crash in tests
-
Key: LUCENE-6674
URL: https://issues.apache.org/jira/browse/LUCENE-6674
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
{quote}
06:45:04.031 0x2518500j9mm.107* ** ASSERTION FAILED ** at
ParallelScavenger.cpp:3053: ((false
(_extensions-objectModel.isRemembered(objectPtr
{quote}
http://build-eu-00.elastic.co/job/lucene_linux_java8_64_test_only/55153/consoleFull
--
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-7639) Bring MLTQParser at par with the MLT Handler w.r.t supported options
[ https://issues.apache.org/jira/browse/SOLR-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Wille updated SOLR-7639: - Attachment: (was: SOLR-7639-use-defaults.patch) Bring MLTQParser at par with the MLT Handler w.r.t supported options Key: SOLR-7639 URL: https://issues.apache.org/jira/browse/SOLR-7639 Project: Solr Issue Type: Improvement Reporter: Anshum Gupta Assignee: Anshum Gupta Fix For: 5.3 Attachments: SOLR-7639-add-boost-and-exclude-current.patch, SOLR-7639.patch, SOLR-7639.patch As of now, there are options that the MLT Handler supports which the QParser doesn't. It would be good to have the QParser tap into everything that's supported. -- 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-7639) Bring MLTQParser at par with the MLT Handler w.r.t supported options
[ https://issues.apache.org/jira/browse/SOLR-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Wille updated SOLR-7639: - Attachment: SOLR-7639-add-boost-and-exclude-current.patch Bring MLTQParser at par with the MLT Handler w.r.t supported options Key: SOLR-7639 URL: https://issues.apache.org/jira/browse/SOLR-7639 Project: Solr Issue Type: Improvement Reporter: Anshum Gupta Assignee: Anshum Gupta Fix For: 5.3 Attachments: SOLR-7639-add-boost-and-exclude-current.patch, SOLR-7639-add-boost-and-exclude-current.patch, SOLR-7639.patch, SOLR-7639.patch As of now, there are options that the MLT Handler supports which the QParser doesn't. It would be good to have the QParser tap into everything that's supported. -- 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-7639) Bring MLTQParser at par with the MLT Handler w.r.t supported options
[
https://issues.apache.org/jira/browse/SOLR-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634984#comment-14634984
]
Jens Wille commented on SOLR-7639:
--
I've updated the {{SOLR-7639-add-boost-and-exclude-current}} patch for
{{CloudMLTQParser}}. Anything else I can do?
Bring MLTQParser at par with the MLT Handler w.r.t supported options
Key: SOLR-7639
URL: https://issues.apache.org/jira/browse/SOLR-7639
Project: Solr
Issue Type: Improvement
Reporter: Anshum Gupta
Assignee: Anshum Gupta
Fix For: 5.3
Attachments: SOLR-7639-add-boost-and-exclude-current.patch,
SOLR-7639-add-boost-and-exclude-current.patch, SOLR-7639.patch,
SOLR-7639.patch
As of now, there are options that the MLT Handler supports which the QParser
doesn't. It would be good to have the QParser tap into everything that's
supported.
--
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-7756) NPE in ExactStatsCache when a term doesn't exist on a shard
[
https://issues.apache.org/jira/browse/SOLR-7756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634841#comment-14634841
]
Anshum Gupta commented on SOLR-7756:
Thanks Varun. Looks good. Here are a few suggestions:
* You should reset solr.test.sys.* system properties during teardown.
* It'd be good to refactor the test a little bit (nothing pressing)
* Do we really need 3 shards in the test? I think we can do with just 2 and
save time for the test run.
There's also a bunch of formatting changes that's a part of the patch. I just
glanced through it, but in case it's something that's not required, it'd be
good to not refactor those.
P.S: If the current formatting is screwed up, by all means clean it up.
NPE in ExactStatsCache when a term doesn't exist on a shard
---
Key: SOLR-7756
URL: https://issues.apache.org/jira/browse/SOLR-7756
Project: Solr
Issue Type: Bug
Reporter: Varun Thacker
Fix For: 5.3
Attachments: SOLR-7756.patch, SOLR-7756.patch, SOLR-7756.patch,
SOLR-7756.patch
If a term doesn't exist on a shard {{ExactStatsCache#getPerShardTermStats}}
throws an NullPointerException.
Attaching a test and a patch shortly.
--
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: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome Mikhail! -Stefan On Tuesday, July 21, 2015 at 9:21 AM, Adrien Grand wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org (mailto:dev-unsubscr...@lucene.apache.org) For additional commands, e-mail: dev-h...@lucene.apache.org (mailto:dev-h...@lucene.apache.org)
[jira] [Commented] (SOLR-7715) Remove IgnoreAcceptDocsQuery
[ https://issues.apache.org/jira/browse/SOLR-7715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634778#comment-14634778 ] ASF subversion and git services commented on SOLR-7715: --- Commit 1692067 from [~jpountz] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1692067 ] SOLR-7715: Removed IgnoreAcceptDocsQuery. Remove IgnoreAcceptDocsQuery Key: SOLR-7715 URL: https://issues.apache.org/jira/browse/SOLR-7715 Project: Solr Issue Type: Task Reporter: Adrien Grand Priority: Minor While reviewing how queries apply acceptDocs, I noticed that Solr has org.apache.solr.search.join.IgnoreAcceptDocsQuery, but it looks unused. Should we remove it? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7815) Remove LuceneQueryOptimizer
[ https://issues.apache.org/jira/browse/SOLR-7815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634791#comment-14634791 ] ASF subversion and git services commented on SOLR-7815: --- Commit 1692070 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1692070 ] SOLR-7815: Removed LuceneQueryOptimizer. Remove LuceneQueryOptimizer --- Key: SOLR-7815 URL: https://issues.apache.org/jira/browse/SOLR-7815 Project: Solr Issue Type: Task Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: SOLR-7815.patch I noticed that I introduced a bug in this class when refactoring BooleanQuery to be immutable (using the builder as a cache key instead of the query itself). But then I noticed that this class is actually never used, so let's remove it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6668) Optimize SortedSet/SortedNumeric storage for the few unique sets use-case
[ https://issues.apache.org/jira/browse/LUCENE-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634785#comment-14634785 ] ASF subversion and git services commented on LUCENE-6668: - Commit 1692069 from [~jpountz] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1692069 ] LUCENE-6668: Add missing Iterator.remove() implementation. Optimize SortedSet/SortedNumeric storage for the few unique sets use-case - Key: LUCENE-6668 URL: https://issues.apache.org/jira/browse/LUCENE-6668 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-6668.patch, LUCENE-6668.patch Robert suggested this idea: if there are few unique sets of values, we could build a lookup table and then map each doc to an ord in this table, just like we already do for table compression for numerics. I think this is especially compelling given that SortedSet/SortedNumeric are our two only doc values types that use O(maxDoc) memory because of the offsets map. When this new strategy is used, memory usage could be bounded to a constant. -- 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-7715) Remove IgnoreAcceptDocsQuery
[ https://issues.apache.org/jira/browse/SOLR-7715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634788#comment-14634788 ] Adrien Grand commented on SOLR-7715: There also was a commit on trunk but I wrongly labeled it as LUCENE-7715 instead of SOLR-7715: http://svn.apache.org/r1692062 Remove IgnoreAcceptDocsQuery Key: SOLR-7715 URL: https://issues.apache.org/jira/browse/SOLR-7715 Project: Solr Issue Type: Task Reporter: Adrien Grand Priority: Minor While reviewing how queries apply acceptDocs, I noticed that Solr has org.apache.solr.search.join.IgnoreAcceptDocsQuery, but it looks unused. Should we remove it? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-6668) Optimize SortedSet/SortedNumeric storage for the few unique sets use-case
[ https://issues.apache.org/jira/browse/LUCENE-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved LUCENE-6668. -- Resolution: Fixed Fix Version/s: 5.3 Optimize SortedSet/SortedNumeric storage for the few unique sets use-case - Key: LUCENE-6668 URL: https://issues.apache.org/jira/browse/LUCENE-6668 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 Attachments: LUCENE-6668.patch, LUCENE-6668.patch Robert suggested this idea: if there are few unique sets of values, we could build a lookup table and then map each doc to an ord in this table, just like we already do for table compression for numerics. I think this is especially compelling given that SortedSet/SortedNumeric are our two only doc values types that use O(maxDoc) memory because of the offsets map. When this new strategy is used, memory usage could be bounded to a constant. -- 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-7715) Remove IgnoreAcceptDocsQuery
[ https://issues.apache.org/jira/browse/SOLR-7715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved SOLR-7715. Resolution: Fixed Assignee: Adrien Grand Fix Version/s: 5.3 Remove IgnoreAcceptDocsQuery Key: SOLR-7715 URL: https://issues.apache.org/jira/browse/SOLR-7715 Project: Solr Issue Type: Task Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 While reviewing how queries apply acceptDocs, I noticed that Solr has org.apache.solr.search.join.IgnoreAcceptDocsQuery, but it looks unused. Should we remove it? -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-7815) Remove LuceneQueryOptimizer
[ https://issues.apache.org/jira/browse/SOLR-7815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved SOLR-7815. Resolution: Fixed Fix Version/s: 5.3 Thanks Hoss for adding context and reviewing the patch. Remove LuceneQueryOptimizer --- Key: SOLR-7815 URL: https://issues.apache.org/jira/browse/SOLR-7815 Project: Solr Issue Type: Task Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 Attachments: SOLR-7815.patch I noticed that I introduced a bug in this class when refactoring BooleanQuery to be immutable (using the builder as a cache key instead of the query itself). But then I noticed that this class is actually never used, so let's remove it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7815) Remove LuceneQueryOptimizer
[ https://issues.apache.org/jira/browse/SOLR-7815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634793#comment-14634793 ] ASF subversion and git services commented on SOLR-7815: --- Commit 1692073 from [~jpountz] in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1692073 ] SOLR-7815: Removed LuceneQueryOptimizer. Remove LuceneQueryOptimizer --- Key: SOLR-7815 URL: https://issues.apache.org/jira/browse/SOLR-7815 Project: Solr Issue Type: Task Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.3 Attachments: SOLR-7815.patch I noticed that I introduced a bug in this class when refactoring BooleanQuery to be immutable (using the builder as a cache key instead of the query itself). But then I noticed that this class is actually never used, so let's remove it. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
congrats and welcome! Tommaso 2015-07-21 9:21 GMT+02:00 Adrien Grand jpou...@gmail.com: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-6668) Optimize SortedSet/SortedNumeric storage for the few unique sets use-case
[ https://issues.apache.org/jira/browse/LUCENE-6668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14634660#comment-14634660 ] ASF subversion and git services commented on LUCENE-6668: - Commit 1692058 from [~jpountz] in branch 'dev/trunk' [ https://svn.apache.org/r1692058 ] LUCENE-6668: Added table encoding to sorted set/numeric doc values. Optimize SortedSet/SortedNumeric storage for the few unique sets use-case - Key: LUCENE-6668 URL: https://issues.apache.org/jira/browse/LUCENE-6668 Project: Lucene - Core Issue Type: Improvement Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-6668.patch, LUCENE-6668.patch Robert suggested this idea: if there are few unique sets of values, we could build a lookup table and then map each doc to an ord in this table, just like we already do for table compression for numerics. I think this is especially compelling given that SortedSet/SortedNumeric are our two only doc values types that use O(maxDoc) memory because of the offsets map. When this new strategy is used, memory usage could be bounded to a constant. -- 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: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome, Mikhail! On Tue, Jul 21, 2015 at 3:21 PM, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Han Jiang Team of Search Engine and Web Mining, School of Electronic Engineering and Computer Science, Peking University, China
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome and congratulations, Mikhail! Dawid On Tue, Jul 21, 2015 at 9:27 AM, Shai Erera ser...@gmail.com wrote: Welcome Mikhail! On Jul 21, 2015 10:23 AM, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - 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
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
Congrats! On Tue, Jul 21, 2015 at 12:21 AM, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome Mikhail! Koji On 2015/07/21 16:21, Adrien Grand wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
Congrats Mikhail! -Yonik On Tue, Jul 21, 2015 at 3:21 AM, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - 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
RE: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome Mikhail! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Adrien Grand [mailto:jpou...@gmail.com] Sent: Tuesday, July 21, 2015 9:22 AM To: dev@lucene.apache.org; Mikhail Khludnev Subject: Welcome Mikhail Khludnev as Lucene/Solr committer I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - 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
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome! Well deserved Mikhail! On Tue, Jul 21, 2015 at 10:24 AM Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome Mikhail! On Tue, Jul 21, 2015 at 12:51 PM, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Regards, Shalin Shekhar Mangar. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7765) TokenizerChain without char filters cause NPE in luke request handler
[
https://issues.apache.org/jira/browse/SOLR-7765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635043#comment-14635043
]
Konstantin Gribov commented on SOLR-7765:
-
Fixing this in {{TokenizerChain}} itself seems better to me.
Is there any reason to use reversed order in ifs (like {{if (0
cfiltfacs.length)}})? It looks quite strange since most of lucene solr code
use more usual {{if (var 0)}} style.
TokenizerChain without char filters cause NPE in luke request handler
-
Key: SOLR-7765
URL: https://issues.apache.org/jira/browse/SOLR-7765
Project: Solr
Issue Type: Bug
Affects Versions: 5.2.1
Reporter: Konstantin Gribov
Assignee: Hoss Man
Priority: Minor
Attachments: SOLR-7765.patch, SOLR-7765.patch, SOLR-7765.patch
{{TokenizerChain}} created using 2-arg constructor has {{null}} in
{{charFilters}}, so {{LukeRequestHandler}} throws NPE on iterating it.
Will create PR in a couple of minutes.
--
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-6691) tweak SortingMergePolicy.getSortDescription
[
https://issues.apache.org/jira/browse/LUCENE-6691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635084#comment-14635084
]
ASF GitHub Bot commented on LUCENE-6691:
GitHub user cpoerschke opened a pull request:
https://github.com/apache/lucene-solr/pull/191
LUCENE-6691: tweak SortingMergePolicy.getSortDescription
for https://issues.apache.org/jira/i#browse/LUCENE-6691
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/bloomberg/lucene-solr
trunk-SortingMergePolicy-isSorted
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/lucene-solr/pull/191.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #191
commit 4626b4977f384ce9dc103531ace566da17c93205
Author: Christine Poerschke cpoersc...@bloomberg.net
Date: 2015-07-16T19:42:21Z
lucene: add EarlyTerminatingSortingCollector.terminatedEarly() method
commit 6b7a11c0ced960f80152aed2c582cfaa6217c0af
Author: Christine Poerschke cpoersc...@bloomberg.net
Date: 2015-07-17T15:46:39Z
lucene: add TestEarlyTerminatingSortingCollector.testTerminatedEarly()
commit 2afd60f6d29b5d4759a3eaf6ed1aef22a368bedb
Author: Christine Poerschke cpoersc...@bloomberg.net
Date: 2015-07-20T12:54:04Z
lucene: tweak SortingMergePolicy.getSortDescription(LeafReader reader)
tweak SortingMergePolicy.getSortDescription
---
Key: LUCENE-6691
URL: https://issues.apache.org/jira/browse/LUCENE-6691
Project: Lucene - Core
Issue Type: Test
Reporter: Christine Poerschke
Priority: Minor
Building tests for SOLR-5730 identified that early termination can be omitted
for sorted segments because the {{LeafReader}} concerned is not a
{{SegmentReader}} - github pull request to illustrate to follow:
* the {{TestEarlyTerminatingSortingCollector.testTerminatedEarly}} test uses
a wrapped reader in the same way as {{SolrIndexSearcher}}
* the {{SortingMergePolicy.getSortDescription}} change (assuming it is a
valid change to make) fixes that particular test only
* {{ExitableDirectoryReader}} and {{UninvertingReader}} wrap could perhaps
also be added in {{LuceneTestCase.wrapReader}} ?
LUCENE-6065 remove foreign readers from merge, fix LeafReader instead.
also concerns SortingMergePolicy.
--
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-6691) tweak SortingMergePolicy.getSortDescription
Christine Poerschke created LUCENE-6691:
---
Summary: tweak SortingMergePolicy.getSortDescription
Key: LUCENE-6691
URL: https://issues.apache.org/jira/browse/LUCENE-6691
Project: Lucene - Core
Issue Type: Test
Reporter: Christine Poerschke
Priority: Minor
Building tests for SOLR-5730 identified that early termination can be omitted
for sorted segments because the {{LeafReader}} concerned is not a
{{SegmentReader}} - github pull request to illustrate to follow:
* the {{TestEarlyTerminatingSortingCollector.testTerminatedEarly}} test uses a
wrapped reader in the same way as {{SolrIndexSearcher}}
* the {{SortingMergePolicy.getSortDescription}} change (assuming it is a valid
change to make) fixes that particular test only
* {{ExitableDirectoryReader}} and {{UninvertingReader}} wrap could perhaps also
be added in {{LuceneTestCase.wrapReader}} ?
LUCENE-6065 remove foreign readers from merge, fix LeafReader instead. also
concerns SortingMergePolicy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] lucene-solr pull request: LUCENE-6691: tweak SortingMergePolicy.ge...
GitHub user cpoerschke opened a pull request: https://github.com/apache/lucene-solr/pull/191 LUCENE-6691: tweak SortingMergePolicy.getSortDescription for https://issues.apache.org/jira/i#browse/LUCENE-6691 You can merge this pull request into a Git repository by running: $ git pull https://github.com/bloomberg/lucene-solr trunk-SortingMergePolicy-isSorted Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/191.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #191 commit 4626b4977f384ce9dc103531ace566da17c93205 Author: Christine Poerschke cpoersc...@bloomberg.net Date: 2015-07-16T19:42:21Z lucene: add EarlyTerminatingSortingCollector.terminatedEarly() method commit 6b7a11c0ced960f80152aed2c582cfaa6217c0af Author: Christine Poerschke cpoersc...@bloomberg.net Date: 2015-07-17T15:46:39Z lucene: add TestEarlyTerminatingSortingCollector.testTerminatedEarly() commit 2afd60f6d29b5d4759a3eaf6ed1aef22a368bedb Author: Christine Poerschke cpoersc...@bloomberg.net Date: 2015-07-20T12:54:04Z lucene: tweak SortingMergePolicy.getSortDescription(LeafReader reader) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome Mikhail! Steve www.lucidworks.com On Tuesday, July 21, 2015, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org javascript:; For additional commands, e-mail: dev-h...@lucene.apache.org javascript:;
[jira] [Updated] (SOLR-7692) Implement BasicAuth based impl for the new Authentication/Authorization APIs
[
https://issues.apache.org/jira/browse/SOLR-7692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-7692:
-
Attachment: SOLR-7692.patch
some cleanup
Implement BasicAuth based impl for the new Authentication/Authorization APIs
Key: SOLR-7692
URL: https://issues.apache.org/jira/browse/SOLR-7692
Project: Solr
Issue Type: New Feature
Reporter: Noble Paul
Assignee: Noble Paul
Attachments: SOLR-7692.patch, SOLR-7692.patch, SOLR-7692.patch,
SOLR-7692.patch, SOLR-7692.patch, SOLR-7692.patch, SOLR-7692.patch,
SOLR-7692.patch
This involves various components
h2. Authentication
A basic auth based authentication filter. This should retrieve the user
credentials from ZK. The user name and sha1 hash of password should be
stored in ZK
sample authentication json
{code:javascript}
{
authentication:{
class: solr.BasicAuthPlugin,
users :{
john :09fljnklnoiuy98 buygujkjnlk,
david:f678njfgfjnklno iuy9865ty,
pete: 87ykjnklndfhjh8 98uyiy98,
}
}
}
{code}
h2. authorization plugin
This would store the roles of various users and their privileges in ZK
sample authorization.json
{code:javascript}
{
authorization: {
class: solr.ZKAuthorization,
roles :{
admin : [john]
guest : [john, david,pete]
}
permissions: {
collection-edit: {
role: admin
},
coreadmin:{
role:admin
},
config-edit: {
//all collections
role: admin,
method:POST
},
schema-edit: {
roles: admin,
method:POST
},
update: {
//all collections
role: dev
},
mycoll_update: {
collection: mycoll,
path:[/update/*],
role: [somebody]
}
}
}
}
{code}
We will also need to provide APIs to create users and assign them roles
--
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: Welcome Mikhail Khludnev as Lucene/Solr committer
Welcome Mikhail! On Tue, Jul 21, 2015, at 02:47 PM, Han Jiang wrote: Welcome, Mikhail! On Tue, Jul 21, 2015 at 3:21 PM, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Han Jiang Team of Search Engine and Web Mining, School of Electronic Engineering and Computer Science, Peking University, China
[JENKINS] Lucene-Solr-5.x-Linux (64bit/jdk1.7.0_80) - Build # 13367 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/13367/ Java: 64bit/jdk1.7.0_80 -XX:+UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 62361 lines...] BUILD FAILED /home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:536: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/build.xml:443: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/extra-targets.xml:105: The following error occurred while executing this line: /home/jenkins/workspace/Lucene-Solr-5.x-Linux/extra-targets.xml:122: java.lang.OutOfMemoryError: PermGen space at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:800) at org.apache.tools.ant.AntClassLoader.defineClassFromData(AntClassLoader.java:1124) at org.apache.tools.ant.AntClassLoader.getClassFromStream(AntClassLoader.java:1295) at org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1351) at org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1311) at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1064) at java.lang.ClassLoader.loadClass(ClassLoader.java:358) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125) at embedded_script_in__home_jenkins_workspace_Lucene_Solr_5_dot_x_Linux_extra_targets_dot_xml.run(embedded_script_in__home_jenkins_workspace_Lucene_Solr_5_dot_x_Linux_extra_targets_dot_xml:9) at org.codehaus.groovy.ant.Groovy.parseAndRunScript(Groovy.java:501) at org.codehaus.groovy.ant.Groovy.execGroovy(Groovy.java:448) at org.codehaus.groovy.ant.Groovy.execute(Groovy.java:313) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:398) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) Total time: 62 minutes 52 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
Thanks for the best birthday present I’ve ever had! bio: I grew up at the Far East of Russia, it’s really far - it’s beyond China. I’ve got engineer degree, work in transportation and geodesy, which I miss so much now. I start with C++, then learned Java, and moved into Saint-Petersburg at the North-West. I met Solr 1.4 at 2010, after programming enterprise applications for a few years. Now I work with search in Grid Dynamics, where we focus mostly on retail industry, which has own specifics. My favorite topics in search: Joins, Facets, Scorers, Codecs, and DataImportHandler. I spoke at the conferences couple times a year, blog rarely and post to G+. In my free time, I’m keeping fit: mostly swimming, attending rock concerts, and researching something with my daughter. Thanks you again for this honor! I’ll do my best to be accurate and responsible. On Tue, Jul 21, 2015 at 4:47 PM, Han Jiang jiangha...@gmail.com wrote: Welcome, Mikhail! On Tue, Jul 21, 2015 at 3:21 PM, Adrien Grand jpou...@gmail.com wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Mikhail, it's tradition that you introduce yourself with a brief bio. Your handle mkhl has already added to the “lucene LDAP group, so you now have commit privileges. Please test this by adding yourself to the committers section of the Who We Are page on the website: http://lucene.apache.org/whoweare.html (use the ASF CMS bookmarklet at the bottom of the page here: https://cms.apache.org/#bookmark - more info here http://www.apache.org/dev/cms.html). Congratulations and welcome! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Han Jiang Team of Search Engine and Web Mining, School of Electronic Engineering and Computer Science, Peking University, China -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics http://www.griddynamics.com mkhlud...@griddynamics.com
Re: Welcome Mikhail Khludnev as Lucene/Solr committer
On 7/21/2015 1:21 AM, Adrien Grand wrote: I'm pleased to announce that Mikhail Khludnev has accepted the PMC's invitation to become a committer. Congratulations and welcome to the group! Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7806) SolrCloud to use 127.0.01 instead of localhost
[ https://issues.apache.org/jira/browse/SOLR-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14635198#comment-14635198 ] Arcadius Ahouansou commented on SOLR-7806: -- I have taken note [~anders5737] SolrCloud to use 127.0.01 instead of localhost -- Key: SOLR-7806 URL: https://issues.apache.org/jira/browse/SOLR-7806 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 5.2.1 Environment: Linux Mac OS X Reporter: Arcadius Ahouansou Attachments: SOLR-7806.patch A colleague is having an issue very similar to the one described at http://muddyazian.blogspot.co.uk/2015/03/how-to-get-solr-500-quick-start.html He is running on the latest Arch Linux, and he gets that issue only when he connects to the office network. We also have another case when this happens only when a colleague is connected to the office network via VPN from his mac. I have looked around IMHO, the usage of 'localhost' in the solr code base may be leading to this kind of issues where the resolved IP is not route-able. Does it make any sense to replace all usage of 'localhost' in the code base by 127.0.01? -- 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-7806) SolrCloud to use 127.0.01 instead of localhost
[ https://issues.apache.org/jira/browse/SOLR-7806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arcadius Ahouansou updated SOLR-7806: - Attachment: SOLR-7806.patch Initial patch with localhost changed to 127.0.0.1 SolrCloud to use 127.0.01 instead of localhost -- Key: SOLR-7806 URL: https://issues.apache.org/jira/browse/SOLR-7806 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 5.2.1 Environment: Linux Mac OS X Reporter: Arcadius Ahouansou Attachments: SOLR-7806.patch A colleague is having an issue very similar to the one described at http://muddyazian.blogspot.co.uk/2015/03/how-to-get-solr-500-quick-start.html He is running on the latest Arch Linux, and he gets that issue only when he connects to the office network. We also have another case when this happens only when a colleague is connected to the office network via VPN from his mac. I have looked around IMHO, the usage of 'localhost' in the solr code base may be leading to this kind of issues where the resolved IP is not route-able. Does it make any sense to replace all usage of 'localhost' in the code base by 127.0.01? -- 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
