Re: [Lucene.Net] Merging 3.0.3 into Trunk
On 2012-02-28, Christopher Currens wrote: Alright, it's done! 3.0.3 is now merged in with Trunk! Great! Let me know if anyone has any problems. I'll see to running RAT and looking at the line-ends over the next few days so we can get them fixed once and not run into it with the release. Thanks Stefan
[jira] [Commented] (LUCENE-3820) Wrong trailing index calculation in PatternReplaceCharFilter
[ https://issues.apache.org/jira/browse/LUCENE-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13217991#comment-13217991 ] Dawid Weiss commented on LUCENE-3820: - I've committed that thread-name-contains-seed thing. I've also tried to reproduce the long pattern but it's been running on my machine for a few minutes in a tight loop and all of them end below one second. Can you try to reproduce it again? I'm curious what's causing this. I'll add @Ignore once we know what the problem is. Wrong trailing index calculation in PatternReplaceCharFilter Key: LUCENE-3820 URL: https://issues.apache.org/jira/browse/LUCENE-3820 Project: Lucene - Java Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3820.patch, LUCENE-3820.patch, LUCENE-3820_test.patch, LUCENE-3820_test.patch Reimplementation of PatternReplaceCharFilter to pass randomized tests (used to throw exceptions previously). Simplified code, dropped boundary characters, full input buffered for pattern matching. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3162) Continue work on new admin UI
[ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3162: Attachment: (was: SOLR-3162-120227-zookeeper-servlet.patch) Continue work on new admin UI - Key: SOLR-3162 URL: https://issues.apache.org/jira/browse/SOLR-3162 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Erick Erickson Assignee: Erick Erickson There have been more improvements to how the new UI works, but the current open bugs are getting hard to keep straight. This is the new catch-all JIRA for continued improvements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3162) Continue work on new admin UI
[ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3162: Attachment: SOLR-3162.patch Combined Patch, contains: * ZookeeperServlet ** removed Content-Preview ** escaped Quotes * Logging ** Now functional, using SOLR-2459 * Schema-Browser ** Button for loading Info on Demand ** Form to decide how many Terms to load ** Type/Name shown in Plain-Text Continue work on new admin UI - Key: SOLR-3162 URL: https://issues.apache.org/jira/browse/SOLR-3162 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-3162.patch There have been more improvements to how the new UI works, but the current open bugs are getting hard to keep straight. This is the new catch-all JIRA for continued improvements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3171) Hi,
Hi, --- Key: SOLR-3171 URL: https://issues.apache.org/jira/browse/SOLR-3171 Project: Solr Issue Type: Wish Reporter: Hasan Ince -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1052) Deprecate/Remove indexDefaults in favor of mainIndex in solrconfig.xml
[
https://issues.apache.org/jira/browse/SOLR-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218014#comment-13218014
]
Jan Høydahl commented on SOLR-1052:
---
Or maybe even just {{index}}? We already have {{query}} :)
Deprecate/Remove indexDefaults in favor of mainIndex in solrconfig.xml
--
Key: SOLR-1052
URL: https://issues.apache.org/jira/browse/SOLR-1052
Project: Solr
Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Jan Høydahl
Priority: Minor
Labels: solrconfig.xml
Fix For: 3.6, 4.0
Attachments: SOLR-1052-3x.patch, SOLR-1052-3x.patch
Given that we now handle multiple cores via the solr.xml and the discussion
around indexDefaults and mainIndex at
http://www.lucidimagination.com/search/p:solr?q=mainIndex+vs.+indexDefaults
We should deprecate/remove the use of indexDefaults and just rely on
mainIndex, as it doesn't seem to serve any purpose and is confusing to
explain.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3171) Sorting Problem
[ https://issues.apache.org/jira/browse/SOLR-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hasan Ince updated SOLR-3171: - Description: Hi everyone, I have a problem about sorting in index. I have an index with id values such as 1,2,3,4. I am sending a query like ... id = 3 or id = 1 or id = 3 and i want to receive the response that the ordered in the query (3,1,2). How can I do this? Thank you very much for helps. Summary: Sorting Problem (was: Hi,) Sorting Problem --- Key: SOLR-3171 URL: https://issues.apache.org/jira/browse/SOLR-3171 Project: Solr Issue Type: Wish Reporter: Hasan Ince Hi everyone, I have a problem about sorting in index. I have an index with id values such as 1,2,3,4. I am sending a query like ... id = 3 or id = 1 or id = 3 and i want to receive the response that the ordered in the query (3,1,2). How can I do this? Thank you very much for helps. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-3162) Continue work on new admin UI
[ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218007#comment-13218007 ] Stefan Matheis (steffkes) edited comment on SOLR-3162 at 2/28/12 9:15 AM: -- Combined Patch, contains: * ZookeeperServlet ** removed Content-Preview ** escaped Quotes * Cloud-Tab ** First node is automatically expanded * Logging ** Now functional, using SOLR-2459 * Schema-Browser ** Button for loading Info on Demand ** Form to decide how many Terms to load ** Type/Name shown in Plain-Text * Index ** Check for activated Admin-Handlers, display error message otherwise was (Author: steffkes): Combined Patch, contains: * ZookeeperServlet ** removed Content-Preview ** escaped Quotes * Logging ** Now functional, using SOLR-2459 * Schema-Browser ** Button for loading Info on Demand ** Form to decide how many Terms to load ** Type/Name shown in Plain-Text Continue work on new admin UI - Key: SOLR-3162 URL: https://issues.apache.org/jira/browse/SOLR-3162 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-3162.patch There have been more improvements to how the new UI works, but the current open bugs are getting hard to keep straight. This is the new catch-all JIRA for continued improvements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 12543 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/12543/ 1 tests failed. REGRESSION: org.apache.lucene.search.TestSloppyPhraseQuery2.testIncreasingSloppiness3WithHoles Error Message: null Stack Trace: junit.framework.AssertionFailedError at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.search.SearchEquivalenceTestBase.assertSubsetOf(SearchEquivalenceTestBase.java:194) at org.apache.lucene.search.SearchEquivalenceTestBase.assertSubsetOf(SearchEquivalenceTestBase.java:159) at org.apache.lucene.search.TestSloppyPhraseQuery2.testIncreasingSloppiness3WithHoles(TestSloppyPhraseQuery2.java:101) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:715) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:611) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:573) Build Log (for compile errors): [...truncated 1484 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3767) Explore streaming Viterbi search in Kuromoji
[ https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Moen updated LUCENE-3767: --- Attachment: SolrXml-5498.xml Explore streaming Viterbi search in Kuromoji Key: LUCENE-3767 URL: https://issues.apache.org/jira/browse/LUCENE-3767 Project: Lucene - Java Issue Type: Improvement Components: modules/analysis Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 3.6, 4.0 Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch, SolrXml-5498.xml, compound_diffs.txt I've been playing with the idea of changing the Kuromoji viterbi search to be 2 passes (intersect, backtrace) instead of 4 passes (break into sentences, intersect, score, backtrace)... this is very much a work in progress, so I'm just getting my current state up. It's got tons of nocommits, doesn't properly handle the user dict nor extended modes yet, etc. One thing I'm playing with is to add a double backtrace for the long compound tokens, ie, instead of penalizing these tokens so that shorter tokens are picked, leave the scores unchanged but on backtrace take that penalty and use it as a threshold for a 2nd best segmentation... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3767) Explore streaming Viterbi search in Kuromoji
[
https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218026#comment-13218026
]
Christian Moen commented on LUCENE-3767:
Mike,
Thanks a lot for this. I've been taking this patch for a spin and I'm seeing
some exceptions being thrown when indexing some Wikipedia test documents.
I haven't had a chance to analyze this in detail, but when indexing the
attached {{SolrXml-5498.xml}} I'm getting:
{code}
java.lang.ArrayIndexOutOfBoundsException: -69
at
org.apache.lucene.util.RollingCharBuffer.get(RollingCharBuffer.java:98)
at
org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.computePenalty(KuromojiTokenizer.java:236)
at
org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.computeSecondBestThreshold(KuromojiTokenizer.java:227)
at
org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.backtrace(KuromojiTokenizer.java:910)
at
org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.parse(KuromojiTokenizer.java:567)
at
org.apache.lucene.analysis.kuromoji.KuromojiTokenizer.incrementToken(KuromojiTokenizer.java:394)
at
org.apache.lucene.analysis.kuromoji.TestKuromojiTokenizer.doTestBocchan(TestKuromojiTokenizer.java:567)
at
org.apache.lucene.analysis.kuromoji.TestKuromojiTokenizer.testBocchan(TestKuromojiTokenizer.java:528)
...
{code}
I believe you can reproduce this by changing
{{TestKuromojiTokenizer.doTestBocchan()}} to read the attached
{{SolrXml-5498.xml}} instead of {{bocchan.utf-8}}.
Explore streaming Viterbi search in Kuromoji
Key: LUCENE-3767
URL: https://issues.apache.org/jira/browse/LUCENE-3767
Project: Lucene - Java
Issue Type: Improvement
Components: modules/analysis
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 3.6, 4.0
Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch,
LUCENE-3767.patch, SolrXml-5498.xml, compound_diffs.txt
I've been playing with the idea of changing the Kuromoji viterbi
search to be 2 passes (intersect, backtrace) instead of 4 passes
(break into sentences, intersect, score, backtrace)... this is very
much a work in progress, so I'm just getting my current state up.
It's got tons of nocommits, doesn't properly handle the user dict nor
extended modes yet, etc.
One thing I'm playing with is to add a double backtrace for the long
compound tokens, ie, instead of penalizing these tokens so that
shorter tokens are picked, leave the scores unchanged but on backtrace
take that penalty and use it as a threshold for a 2nd best
segmentation...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3830) MappingCharFilter could be improved by switching to an FST.
MappingCharFilter could be improved by switching to an FST. --- Key: LUCENE-3830 URL: https://issues.apache.org/jira/browse/LUCENE-3830 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 4.0 MappingCharFilter stores an overly complex tree-like structure for matching input patterns. The input is a union of fixed strings mapped to a set of fixed strings; an fst matcher would be ideal here and provide both memory and speed improvement I bet. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3156) Check for locks on startup
[
https://issues.apache.org/jira/browse/SOLR-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luca Cavanna updated SOLR-3156:
---
Attachment: SOLR-3156.patch
Hi Hoss,
thanks for your feedback.
{quote}
the one thing i might suggest is adding an ERROR log just before you throw the
exception (i'm in the log early team)
{quote}
I've added the log before throwing exception.
{quote}
trim those solrconfig files down so that they only contain the 5-6 minimum
lines they need inorder for the test to be meaningful
{quote}
I completely agree, I already did a little, but I just did it (a lot) more.
You'll like it now. :)
Check for locks on startup
--
Key: SOLR-3156
URL: https://issues.apache.org/jira/browse/SOLR-3156
Project: Solr
Issue Type: Improvement
Reporter: Luca Cavanna
Attachments: SOLR-3156.patch, SOLR-3156.patch
When using simple or native lockType and the application server is not
shutdown properly (kill -9), you don't notice problems until someone tries to
add or delete a document. In fact, you get errors every time Solr opens a new
IndexWriter on the locked index. I'm aware of the unlockOnStartup option,
but I'd prefer to know and act properly when there's a lock, and I think it
would be better to know on startup, since Solr is not going to work properly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3165) Cannot use DIH in Solrcloud + Zookeeper
[
https://issues.apache.org/jira/browse/SOLR-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-3165:
-
Attachment: SOLR-3165.patch
Here's a stab at fixing this issue. I noticed there were two places where DIH
wanted to access conf dir: the config file (read) and some kind of state file
(read/write) access.
I added ZKPropertiesWriter that writes the contents of the state file into zk.
Cannot use DIH in Solrcloud + Zookeeper
---
Key: SOLR-3165
URL: https://issues.apache.org/jira/browse/SOLR-3165
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 4.0
Reporter: Agnieszka
Attachments: SOLR-3165.patch
There is a problem with configure DIH in Solrcloud + Zookeeper configuration
from wiki:
http://wiki.apache.org/solr/SolrCloud.
Standard configuration in solrconfig.xml:
{code:xml}
requestHandler name=/dataimport
class=org.apache.solr.handler.dataimport.DataImportHandler
lst name=defaults
str name=configdb-data-config.xml/str
/lst
/requestHandler
{code}
After starting solr with zookeeper I've got errors:
{noformat}
Feb 20, 2012 11:30:12 AM org.apache.solr.common.SolrException log
SEVERE: null:org.apache.solr.common.SolrException
at org.apache.solr.core.SolrCore.init(SolrCore.java:606)
at org.apache.solr.core.SolrCore.init(SolrCore.java:490)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:705)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:442)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:313)
at
org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:262)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:98)
at
org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)
at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.mortbay.start.Main.invokeMain(Main.java:194)
at org.mortbay.start.Main.start(Main.java:534)
at org.mortbay.start.Main.start(Main.java:441)
at org.mortbay.start.Main.main(Main.java:119)
Caused by: org.apache.solr.common.SolrException: FATAL: Could not create
importer. DataImporter config invalid
at
org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImportHandler.java:120)
at
org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:542)
at org.apache.solr.core.SolrCore.init(SolrCore.java:601)
... 31 more
Caused by: org.apache.solr.common.cloud.ZooKeeperException:
ZkSolrResourceLoader does not support getConfigDir() - likely, w
at
org.apache.solr.cloud.ZkSolrResourceLoader.getConfigDir(ZkSolrResourceLoader.java:99)
at
org.apache.solr.handler.dataimport.SimplePropertiesWriter.init(SimplePropertiesWriter.java:47)
at
org.apache.solr.handler.dataimport.DataImporter.init(DataImporter.java:112)
at
org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImportHandler.java:114)
... 33 more
{noformat}
But the
[jira] [Commented] (SOLR-3171) Sorting Problem
[ https://issues.apache.org/jira/browse/SOLR-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218064#comment-13218064 ] Luca Cavanna commented on SOLR-3171: Hi, I think this kind of questions should be sent to the solr user mailing list. Have a look [here|http://wiki.apache.org/solr/UsingMailingLists]. Sorting Problem --- Key: SOLR-3171 URL: https://issues.apache.org/jira/browse/SOLR-3171 Project: Solr Issue Type: Wish Reporter: Hasan Ince Hi everyone, I have a problem about sorting in index. I have an index with id values such as 1,2,3,4. I am sending a query like ... id = 3 or id = 1 or id = 3 and i want to receive the response that the ordered in the query (3,1,2). How can I do this? Thank you very much for helps. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3162) Continue work on new admin UI
[
https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218068#comment-13218068
]
Stefan Matheis (steffkes) commented on SOLR-3162:
-
bq. Should we put on the front-page HTTP caching is OFF ?
Yes, good Question .. don't know? Actually the following code in
{{admin/_info.jsp}} is used:
{code}boolean cachingEnabled = !solrConfig.getHttpCachingConfig().isNever304();
{code}
I could try to get the {{httpCaching /}}-Element directly from the
solrconfig, but this is a bit error prone
Continue work on new admin UI
-
Key: SOLR-3162
URL: https://issues.apache.org/jira/browse/SOLR-3162
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis
Affects Versions: 4.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Attachments: SOLR-3162.patch
There have been more improvements to how the new UI works, but the current
open bugs are getting hard to keep straight. This is the new catch-all JIRA
for continued improvements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3162) Continue work on new admin UI
[
https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218072#comment-13218072
]
Stefan Matheis (steffkes) commented on SOLR-3162:
-
Neil created an [Issue|https://github.com/steffkes/solr-admin/issues/4] on my
github repo, regarding the following:
{quote}You can see either an [ ENABLE ] or [ DISABLE ] link.
This link is missing from the new admin page.{quote}
Never used this myself .. any ideas how to integrate this in the admin ui?
Additionally we would need the functionality as a handler/servlet-thingy -
should not be that completed, but perhaps we can combine the tasks?
Enable/Disable as before + possibility to check the current state?
Continue work on new admin UI
-
Key: SOLR-3162
URL: https://issues.apache.org/jira/browse/SOLR-3162
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis
Affects Versions: 4.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Attachments: SOLR-3162.patch
There have been more improvements to how the new UI works, but the current
open bugs are getting hard to keep straight. This is the new catch-all JIRA
for continued improvements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3831) Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE
Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE -- Key: LUCENE-3831 URL: https://issues.apache.org/jira/browse/LUCENE-3831 Project: Lucene - Java Issue Type: Bug Components: core/index Affects Versions: 4.0 Reporter: Alan Woodward Priority: Minor I found this when querying a MemoryIndex using a RegexpQuery wrapped by a SpanMultiTermQueryWrapper. If the regexp doesn't match anything in the index, it gets rewritten to an empty SpanOrQuery with a null field value, which then triggers the NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3831) Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE
[ https://issues.apache.org/jira/browse/LUCENE-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-3831: -- Attachment: mindex-null-field.patch Trivial fix - we just check if the passed in fieldname is null, and if it is, return null. Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE -- Key: LUCENE-3831 URL: https://issues.apache.org/jira/browse/LUCENE-3831 Project: Lucene - Java Issue Type: Bug Components: core/index Affects Versions: 4.0 Reporter: Alan Woodward Priority: Minor Attachments: mindex-null-field.patch I found this when querying a MemoryIndex using a RegexpQuery wrapped by a SpanMultiTermQueryWrapper. If the regexp doesn't match anything in the index, it gets rewritten to an empty SpanOrQuery with a null field value, which then triggers the NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3162) Continue work on new admin UI
[ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218102#comment-13218102 ] Sami Siren commented on SOLR-3162: -- Thanks Stefan for working on this one. I'd like to throw a suggestion into the soup... There's some useful system info that would make a good addition in the ui: http://localhost:8983/solr/collection1/admin/system?wt=json Continue work on new admin UI - Key: SOLR-3162 URL: https://issues.apache.org/jira/browse/SOLR-3162 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-3162.patch There have been more improvements to how the new UI works, but the current open bugs are getting hard to keep straight. This is the new catch-all JIRA for continued improvements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3171) Sorting Problem
[ https://issues.apache.org/jira/browse/SOLR-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-3171. -- Resolution: Invalid Question for user's list. Sorting Problem --- Key: SOLR-3171 URL: https://issues.apache.org/jira/browse/SOLR-3171 Project: Solr Issue Type: Wish Reporter: Hasan Ince Hi everyone, I have a problem about sorting in index. I have an index with id values such as 1,2,3,4. I am sending a query like ... id = 3 or id = 1 or id = 3 and i want to receive the response that the ordered in the query (3,1,2). How can I do this? Thank you very much for helps. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-3162) Continue work on new admin UI
[ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218127#comment-13218127 ] Erick Erickson edited comment on SOLR-3162 at 2/28/12 1:10 PM: --- At least I think this requires SOLR-2459. was (Author: erickerickson): At least I think it does. Continue work on new admin UI - Key: SOLR-3162 URL: https://issues.apache.org/jira/browse/SOLR-3162 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-3162.patch There have been more improvements to how the new UI works, but the current open bugs are getting hard to keep straight. This is the new catch-all JIRA for continued improvements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3162) Continue work on new admin UI
[ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218137#comment-13218137 ] Erick Erickson commented on SOLR-3162: -- Stefan: Yep, that form for a patch file looks good, thanks! On a quick test I'm getting a 404 error when clicking on the Solr Cloud link, don't know if I've got something messed up or not... Continue work on new admin UI - Key: SOLR-3162 URL: https://issues.apache.org/jira/browse/SOLR-3162 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-3162.patch There have been more improvements to how the new UI works, but the current open bugs are getting hard to keep straight. This is the new catch-all JIRA for continued improvements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3162) Continue work on new admin UI
[
https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218140#comment-13218140
]
Stefan Matheis (steffkes) commented on SOLR-3162:
-
Sami, which properties would you like to see there? Mainly those from the
{{system}}-Property, or things like the {{(boot)classpath}} from {{jvm/jmx}} ?
Continue work on new admin UI
-
Key: SOLR-3162
URL: https://issues.apache.org/jira/browse/SOLR-3162
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis
Affects Versions: 4.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Attachments: SOLR-3162.patch
There have been more improvements to how the new UI works, but the current
open bugs are getting hard to keep straight. This is the new catch-all JIRA
for continued improvements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3162) Continue work on new admin UI
[ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218148#comment-13218148 ] Sami Siren commented on SOLR-3162: -- Mainly I would be interested in seeing all the memory/swap related stuff + numbers about current open files + max open files Continue work on new admin UI - Key: SOLR-3162 URL: https://issues.apache.org/jira/browse/SOLR-3162 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-3162.patch There have been more improvements to how the new UI works, but the current open bugs are getting hard to keep straight. This is the new catch-all JIRA for continued improvements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3162) Continue work on new admin UI
[ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218150#comment-13218150 ] Stefan Matheis (steffkes) commented on SOLR-3162: - bq. At least I think this requires SOLR-2459. Yepp, Ryan posted that it was committed in Rev 1292617, don't know why it's still open Continue work on new admin UI - Key: SOLR-3162 URL: https://issues.apache.org/jira/browse/SOLR-3162 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-3162.patch There have been more improvements to how the new UI works, but the current open bugs are getting hard to keep straight. This is the new catch-all JIRA for continued improvements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3767) Explore streaming Viterbi search in Kuromoji
[ https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218154#comment-13218154 ] Michael McCandless commented on LUCENE-3767: Egads, I'll dig... thanks Christian. Explore streaming Viterbi search in Kuromoji Key: LUCENE-3767 URL: https://issues.apache.org/jira/browse/LUCENE-3767 Project: Lucene - Java Issue Type: Improvement Components: modules/analysis Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 3.6, 4.0 Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch, SolrXml-5498.xml, compound_diffs.txt I've been playing with the idea of changing the Kuromoji viterbi search to be 2 passes (intersect, backtrace) instead of 4 passes (break into sentences, intersect, score, backtrace)... this is very much a work in progress, so I'm just getting my current state up. It's got tons of nocommits, doesn't properly handle the user dict nor extended modes yet, etc. One thing I'm playing with is to add a double backtrace for the long compound tokens, ie, instead of penalizing these tokens so that shorter tokens are picked, leave the scores unchanged but on backtrace take that penalty and use it as a threshold for a 2nd best segmentation... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3820) Wrong trailing index calculation in PatternReplaceCharFilter
[
https://issues.apache.org/jira/browse/LUCENE-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218152#comment-13218152
]
Michael McCandless commented on LUCENE-3820:
bq. I've committed that thread-name-contains-seed thing.
Awesome! Using this, I re-beasted and found this seed (was still going after
75 minutes when I killed it...):
{noformat}
ant test -Dtestcase=TestPatternReplaceCharFilter -Dtestmethod=testRandomStrings
-Dtests.seed=-27d641cb49b46a8e:-4b59e6886f1953b6:7d2fb14a457a628
{noformat}
Wrong trailing index calculation in PatternReplaceCharFilter
Key: LUCENE-3820
URL: https://issues.apache.org/jira/browse/LUCENE-3820
Project: Lucene - Java
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Minor
Fix For: 3.6, 4.0
Attachments: LUCENE-3820.patch, LUCENE-3820.patch,
LUCENE-3820_test.patch, LUCENE-3820_test.patch
Reimplementation of PatternReplaceCharFilter to pass randomized tests (used
to throw exceptions previously). Simplified code, dropped boundary
characters, full input buffered for pattern matching.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 1856 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/1856/ No tests ran. Build Log (for compile errors): [...truncated 6241 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3162) Continue work on new admin UI
[ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3162: Attachment: SOLR-3162.patch bq. On a quick test I'm getting a 404 error when clicking on the Solr Cloud link, don't know if I've got something messed up or not... Uh oh, thanks for the hint .. my fault, used the wrong path for the zookeeper-Servlet Continue work on new admin UI - Key: SOLR-3162 URL: https://issues.apache.org/jira/browse/SOLR-3162 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-3162.patch, SOLR-3162.patch There have been more improvements to how the new UI works, but the current open bugs are getting hard to keep straight. This is the new catch-all JIRA for continued improvements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-3831) Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE
[ https://issues.apache.org/jira/browse/LUCENE-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless reassigned LUCENE-3831: -- Assignee: Michael McCandless Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE -- Key: LUCENE-3831 URL: https://issues.apache.org/jira/browse/LUCENE-3831 Project: Lucene - Java Issue Type: Bug Components: core/index Affects Versions: 4.0 Reporter: Alan Woodward Assignee: Michael McCandless Priority: Minor Attachments: mindex-null-field.patch I found this when querying a MemoryIndex using a RegexpQuery wrapped by a SpanMultiTermQueryWrapper. If the regexp doesn't match anything in the index, it gets rewritten to an empty SpanOrQuery with a null field value, which then triggers the NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-3.x - Build # 12553 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12553/ 1 tests failed. REGRESSION: org.apache.lucene.search.TestSloppyPhraseQuery2.testRandomIncreasingSloppiness Error Message: null Stack Trace: junit.framework.AssertionFailedError at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:147) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) at org.apache.lucene.search.SearchEquivalenceTestBase.assertSubsetOf(SearchEquivalenceTestBase.java:183) at org.apache.lucene.search.SearchEquivalenceTestBase.assertSubsetOf(SearchEquivalenceTestBase.java:157) at org.apache.lucene.search.TestSloppyPhraseQuery2.testRandomIncreasingSloppiness(TestSloppyPhraseQuery2.java:183) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:606) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:495) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:400) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:458) Build Log (for compile errors): [...truncated 9811 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3172) luceneMatchVersion of solrconfig-languageidentifier.xml hardcoded to LUCENE_35
luceneMatchVersion of solrconfig-languageidentifier.xml hardcoded to LUCENE_35
--
Key: SOLR-3172
URL: https://issues.apache.org/jira/browse/SOLR-3172
Project: Solr
Issue Type: Improvement
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Should be ${tests.luceneMatchVersion:LUCENE_CURRENT}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3172) luceneMatchVersion of solrconfig-languageidentifier.xml hardcoded to LUCENE_35
[
https://issues.apache.org/jira/browse/SOLR-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-3172.
---
Resolution: Fixed
Fixed on trunk and branch3x
luceneMatchVersion of solrconfig-languageidentifier.xml hardcoded to LUCENE_35
--
Key: SOLR-3172
URL: https://issues.apache.org/jira/browse/SOLR-3172
Project: Solr
Issue Type: Improvement
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Should be ${tests.luceneMatchVersion:LUCENE_CURRENT}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3831) Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE
[ https://issues.apache.org/jira/browse/LUCENE-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218171#comment-13218171 ] Michael McCandless commented on LUCENE-3831: Hmm I don't think the Fields.terms API should be expected to accept null (eg I don't know if the other codecs will NPE). I'd rather fix span queries to not pass the null field. Is this happening in SpanTermQuery.getSpans()? Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE -- Key: LUCENE-3831 URL: https://issues.apache.org/jira/browse/LUCENE-3831 Project: Lucene - Java Issue Type: Bug Components: core/index Affects Versions: 4.0 Reporter: Alan Woodward Assignee: Michael McCandless Priority: Minor Attachments: mindex-null-field.patch I found this when querying a MemoryIndex using a RegexpQuery wrapped by a SpanMultiTermQueryWrapper. If the regexp doesn't match anything in the index, it gets rewritten to an empty SpanOrQuery with a null field value, which then triggers the NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-3.x - Build # 12554 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x/12554/ 1 tests failed. FAILED: org.apache.lucene.search.TestSloppyPhraseQuery2.testRandomIncreasingSloppiness Error Message: null Stack Trace: junit.framework.AssertionFailedError at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:147) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) at org.apache.lucene.search.SearchEquivalenceTestBase.assertSubsetOf(SearchEquivalenceTestBase.java:173) at org.apache.lucene.search.SearchEquivalenceTestBase.assertSubsetOf(SearchEquivalenceTestBase.java:157) at org.apache.lucene.search.TestSloppyPhraseQuery2.testRandomIncreasingSloppiness(TestSloppyPhraseQuery2.java:183) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:606) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:495) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:400) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:458) Build Log (for compile errors): [...truncated 9811 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3831) Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE
[ https://issues.apache.org/jira/browse/LUCENE-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Woodward updated LUCENE-3831: -- Attachment: TestNullFieldAfterRegexpRewrite.java Here's a test case. The error is thrown in SpanQuery.createWeight() when it's called on a bare SpanMultiTermQueryWrapper. It looks as though a simple workaround is to always wrap SpanMultiTermQueryWrapper in a SpanOrQuery. Maybe SpanOrQuery should not have a default constructor, but should require a fieldname if no clauses are supplied? Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE -- Key: LUCENE-3831 URL: https://issues.apache.org/jira/browse/LUCENE-3831 Project: Lucene - Java Issue Type: Bug Components: core/index Affects Versions: 4.0 Reporter: Alan Woodward Assignee: Michael McCandless Priority: Minor Attachments: TestNullFieldAfterRegexpRewrite.java, mindex-null-field.patch I found this when querying a MemoryIndex using a RegexpQuery wrapped by a SpanMultiTermQueryWrapper. If the regexp doesn't match anything in the index, it gets rewritten to an empty SpanOrQuery with a null field value, which then triggers the NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3165) Cannot use DIH in Solrcloud + Zookeeper
[
https://issues.apache.org/jira/browse/SOLR-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218223#comment-13218223
]
Mark Miller commented on SOLR-3165:
---
Nice Sami! I was going to take the same approach.
Longer term I think we want to add a write api to solrresource loader. If
something came from the classpath, it would still be written to the conf area
and later that would override a new read...
Cannot use DIH in Solrcloud + Zookeeper
---
Key: SOLR-3165
URL: https://issues.apache.org/jira/browse/SOLR-3165
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 4.0
Reporter: Agnieszka
Attachments: SOLR-3165.patch
There is a problem with configure DIH in Solrcloud + Zookeeper configuration
from wiki:
http://wiki.apache.org/solr/SolrCloud.
Standard configuration in solrconfig.xml:
{code:xml}
requestHandler name=/dataimport
class=org.apache.solr.handler.dataimport.DataImportHandler
lst name=defaults
str name=configdb-data-config.xml/str
/lst
/requestHandler
{code}
After starting solr with zookeeper I've got errors:
{noformat}
Feb 20, 2012 11:30:12 AM org.apache.solr.common.SolrException log
SEVERE: null:org.apache.solr.common.SolrException
at org.apache.solr.core.SolrCore.init(SolrCore.java:606)
at org.apache.solr.core.SolrCore.init(SolrCore.java:490)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:705)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:442)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:313)
at
org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:262)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:98)
at
org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)
at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.mortbay.start.Main.invokeMain(Main.java:194)
at org.mortbay.start.Main.start(Main.java:534)
at org.mortbay.start.Main.start(Main.java:441)
at org.mortbay.start.Main.main(Main.java:119)
Caused by: org.apache.solr.common.SolrException: FATAL: Could not create
importer. DataImporter config invalid
at
org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImportHandler.java:120)
at
org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:542)
at org.apache.solr.core.SolrCore.init(SolrCore.java:601)
... 31 more
Caused by: org.apache.solr.common.cloud.ZooKeeperException:
ZkSolrResourceLoader does not support getConfigDir() - likely, w
at
org.apache.solr.cloud.ZkSolrResourceLoader.getConfigDir(ZkSolrResourceLoader.java:99)
at
org.apache.solr.handler.dataimport.SimplePropertiesWriter.init(SimplePropertiesWriter.java:47)
at
org.apache.solr.handler.dataimport.DataImporter.init(DataImporter.java:112)
at
org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImportHandler.java:114)
... 33 more
[jira] [Created] (SOLR-3173) Database semantics - insert and update
Database semantics - insert and update -- Key: SOLR-3173 URL: https://issues.apache.org/jira/browse/SOLR-3173 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Fix For: 4.0 In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support the following features inspired by RDBMSs and other NoSql databases. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to INSERT a new document Dnew where Dold.uniqueField is equal to Dnew.uniqueField, then I want a DocumentAlredyExists error. If no such document Dold exists I want Dnew indexed into the solr-core. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to UPDATE a document Dnew where Dold.uniqueField is equal to Dnew.uniqueField I want Dold deleted from and Dnew added to the index (just as it is today).If no such document Dold exists I want nothing to happen (Dnew is not added to the index) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2242) Get distinct count of names for a facet field
[
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218232#comment-13218232
]
Antoine Le Floc'h commented on SOLR-2242:
-
About the distribution issue, it looks like
https://issues.apache.org/jira/browse/SOLR-3134 has some similar thinking as my
post from 03/Jan/12 : show the info per shard. Even though the counter info
cannot be aggregated across shards, knowing what the counter is for each shard
would allow each user to use the info as he wants. It would work in single
shard too.
Get distinct count of names for a facet field
-
Key: SOLR-2242
URL: https://issues.apache.org/jira/browse/SOLR-2242
Project: Solr
Issue Type: New Feature
Components: Response Writers
Affects Versions: 4.0
Reporter: Bill Bell
Assignee: Erick Erickson
Priority: Minor
Fix For: 4.0
Attachments: NumFacetTermsFacetsTest.java,
SOLR-2242-notworkingtest.patch, SOLR-2242.patch, SOLR-2242.patch,
SOLR-2242.patch, SOLR-2242.shard.patch, SOLR-2242.shard.patch,
SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1-fix.patch,
SOLR-2242.solr3.1.patch, SOLR.2242.solr3.1.patch, SOLR.2242.v2.patch
When returning facet.field=name of field you will get a list of matches for
distinct values. This is normal behavior. This patch tells you how many
distinct values you have (# of rows). Use with limit=-1 and mincount=1.
The feature is called namedistinct. Here is an example:
http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solrindent=trueq=*:*facet=truefacet.mincount=1facet.numFacetTerms=2facet.limit=-1facet.field=price
http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solrindent=trueq=*:*facet=truefacet.mincount=1facet.numFacetTerms=0facet.limit=-1facet.field=price
http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solrindent=trueq=*:*facet=truefacet.mincount=1facet.numFacetTerms=1facet.limit=-1facet.field=price
This currently only works on facet.field.
{code}
lst name=facet_fields
lst name=price
int name=numFacetTerms14/int
int name=0.03/intint name=11.51/intint
name=19.951/intint name=74.991/intint name=92.01/intint
name=179.991/intint name=185.01/intint name=279.951/intint
name=329.951/intint name=350.01/intint name=399.01/intint
name=479.951/intint name=649.991/intint name=2199.01/int
/lst
/lst
{code}
Several people use this to get the group.field count (the # of groups).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3140) Make omitNorms default for all numeric field types
[ https://issues.apache.org/jira/browse/SOLR-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218234#comment-13218234 ] Jan Høydahl commented on SOLR-3140: --- Opinions on this? Make omitNorms default for all numeric field types -- Key: SOLR-3140 URL: https://issues.apache.org/jira/browse/SOLR-3140 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Labels: omitNorms Fix For: 4.0 Today norms are enabled for all Solr field types by default, while in Lucene norms are omitted for the numeric types. Propose to make the Solr defaults the same as in Lucene, so that if someone occasionally wants index-side boost for a numeric field type they must say omitNorms=false. This lets us simplify the example schema too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3093) Remove unused features boolTofilterOptimizer and HashDocSet
[ https://issues.apache.org/jira/browse/SOLR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218240#comment-13218240 ] Jan Høydahl commented on SOLR-3093: --- Mark, can you comment on the boolToFilterOptimizer code you commented out? I plan to include this issue in SOLR-1052 since it's all about cleaning up config parsing. Remove unused features boolTofilterOptimizer and HashDocSet --- Key: SOLR-3093 URL: https://issues.apache.org/jira/browse/SOLR-3093 Project: Solr Issue Type: Improvement Reporter: Jan Høydahl Assignee: Jan Høydahl Fix For: 3.6, 4.0 SolrConfig.java still tries to parse boolTofilterOptimizer But the only user of this param was SolrIndexSearcher.java line 366-381 which is commented out. Probably the whole logic should be ripped out, and we fail hard if we find this config option in solrconfig.xml Also, the HashDocSet config option is old and no longer used or needed? There is some code which tries to use it but I believe that since 1.4 there are more efficient ways to do the same. Should we also fail-fast if found in config or only print a warning? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1052) Deprecate/Remove indexDefaults in favor of mainIndex in solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-1052: -- Attachment: SOLR-1052-3x.patch Updated patch with new defaults as stated above. It aborts if both mainIndex and indexConfig are specified and logs warning if only deprecated ones are found. Added a few tests for default checking. Remaining is to clean up other solrconfig.xml files and some tests explicitly testing on the old sections, and to update WIKI. Also, this patch includes SOLR-3140. Pending answer from MarkM about the disabling of boolToFilterOptimizer... Deprecate/Remove indexDefaults in favor of mainIndex in solrconfig.xml -- Key: SOLR-1052 URL: https://issues.apache.org/jira/browse/SOLR-1052 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Jan Høydahl Priority: Minor Labels: solrconfig.xml Fix For: 3.6, 4.0 Attachments: SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch Given that we now handle multiple cores via the solr.xml and the discussion around indexDefaults and mainIndex at http://www.lucidimagination.com/search/p:solr?q=mainIndex+vs.+indexDefaults We should deprecate/remove the use of indexDefaults and just rely on mainIndex, as it doesn't seem to serve any purpose and is confusing to explain. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-1052) Deprecate/Remove indexDefaults in favor of mainIndex in solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-1052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218243#comment-13218243 ] Jan Høydahl edited comment on SOLR-1052 at 2/28/12 2:52 PM: Updated patch with new defaults as stated above. It aborts if both mainIndex and indexConfig are specified and logs warning if only deprecated ones are found. Added a few tests for default checking. Remaining is to clean up other solrconfig.xml files and some tests explicitly testing on the old sections, and to update WIKI. Also, this patch includes SOLR-3093. Pending answer from MarkM about the disabling of boolToFilterOptimizer... was (Author: janhoy): Updated patch with new defaults as stated above. It aborts if both mainIndex and indexConfig are specified and logs warning if only deprecated ones are found. Added a few tests for default checking. Remaining is to clean up other solrconfig.xml files and some tests explicitly testing on the old sections, and to update WIKI. Also, this patch includes SOLR-3140. Pending answer from MarkM about the disabling of boolToFilterOptimizer... Deprecate/Remove indexDefaults in favor of mainIndex in solrconfig.xml -- Key: SOLR-1052 URL: https://issues.apache.org/jira/browse/SOLR-1052 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Jan Høydahl Priority: Minor Labels: solrconfig.xml Fix For: 3.6, 4.0 Attachments: SOLR-1052-3x.patch, SOLR-1052-3x.patch, SOLR-1052-3x.patch Given that we now handle multiple cores via the solr.xml and the discussion around indexDefaults and mainIndex at http://www.lucidimagination.com/search/p:solr?q=mainIndex+vs.+indexDefaults We should deprecate/remove the use of indexDefaults and just rely on mainIndex, as it doesn't seem to serve any purpose and is confusing to explain. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3165) Cannot use DIH in Solrcloud + Zookeeper
[
https://issues.apache.org/jira/browse/SOLR-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218247#comment-13218247
]
Mark Miller commented on SOLR-3165:
---
Took a look at the patch and it looks good to me - only thing I might suggest
is using CoreContainer#isZookeeperAware rather than comparing the zkController
to null, but pretty minor stylistic thing.
Cannot use DIH in Solrcloud + Zookeeper
---
Key: SOLR-3165
URL: https://issues.apache.org/jira/browse/SOLR-3165
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 4.0
Reporter: Agnieszka
Attachments: SOLR-3165.patch
There is a problem with configure DIH in Solrcloud + Zookeeper configuration
from wiki:
http://wiki.apache.org/solr/SolrCloud.
Standard configuration in solrconfig.xml:
{code:xml}
requestHandler name=/dataimport
class=org.apache.solr.handler.dataimport.DataImportHandler
lst name=defaults
str name=configdb-data-config.xml/str
/lst
/requestHandler
{code}
After starting solr with zookeeper I've got errors:
{noformat}
Feb 20, 2012 11:30:12 AM org.apache.solr.common.SolrException log
SEVERE: null:org.apache.solr.common.SolrException
at org.apache.solr.core.SolrCore.init(SolrCore.java:606)
at org.apache.solr.core.SolrCore.init(SolrCore.java:490)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:705)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:442)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:313)
at
org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:262)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:98)
at
org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)
at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.mortbay.start.Main.invokeMain(Main.java:194)
at org.mortbay.start.Main.start(Main.java:534)
at org.mortbay.start.Main.start(Main.java:441)
at org.mortbay.start.Main.main(Main.java:119)
Caused by: org.apache.solr.common.SolrException: FATAL: Could not create
importer. DataImporter config invalid
at
org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImportHandler.java:120)
at
org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:542)
at org.apache.solr.core.SolrCore.init(SolrCore.java:601)
... 31 more
Caused by: org.apache.solr.common.cloud.ZooKeeperException:
ZkSolrResourceLoader does not support getConfigDir() - likely, w
at
org.apache.solr.cloud.ZkSolrResourceLoader.getConfigDir(ZkSolrResourceLoader.java:99)
at
org.apache.solr.handler.dataimport.SimplePropertiesWriter.init(SimplePropertiesWriter.java:47)
at
org.apache.solr.handler.dataimport.DataImporter.init(DataImporter.java:112)
at
org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImportHandler.java:114)
... 33 more
{noformat}
But the db-data-config.xml file exists in
[jira] [Commented] (SOLR-3173) Database semantics - insert and update
[ https://issues.apache.org/jira/browse/SOLR-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218254#comment-13218254 ] Per Steffensen commented on SOLR-3173: -- Impl thoughts: * In solrconfig.xml turn this feature on by added a tag databaseSemantics (probably to updateHandler). When this flag in not turned on update-requests work as always (creates if not exists). With this flag turned on update-requests does not create a document if it does not already exist. Also when this flag is turned on insert-requests are suddenly also possible - they do as update-requets does today, except that they return DocumentAlreadyExist-error if document already exists. * Proper concurrency handling * Be carefull using this feature unless you are running with updateLog turned on (and therefore will never lose already accepted updates/deletes on crash) Database semantics - insert and update -- Key: SOLR-3173 URL: https://issues.apache.org/jira/browse/SOLR-3173 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Labels: RDBMS, insert, nosql, uniqueKey, update Fix For: 4.0 Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support the following features inspired by RDBMSs and other NoSql databases. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to INSERT a new document Dnew where Dold.uniqueField is equal to Dnew.uniqueField, then I want a DocumentAlredyExists error. If no such document Dold exists I want Dnew indexed into the solr-core. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to UPDATE a document Dnew where Dold.uniqueField is equal to Dnew.uniqueField I want Dold deleted from and Dnew added to the index (just as it is today).If no such document Dold exists I want nothing to happen (Dnew is not added to the index) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3173) Database semantics - insert and update
[ https://issues.apache.org/jira/browse/SOLR-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218260#comment-13218260 ] Per Steffensen commented on SOLR-3173: -- See thread Unique key constraint and optimistic locking (versioning) on solr-user mailing list (started 21.02.2012) Database semantics - insert and update -- Key: SOLR-3173 URL: https://issues.apache.org/jira/browse/SOLR-3173 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Labels: RDBMS, insert, nosql, uniqueKey, update Fix For: 4.0 Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support the following features inspired by RDBMSs and other NoSql databases. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to INSERT a new document Dnew where Dold.uniqueField is equal to Dnew.uniqueField, then I want a DocumentAlredyExists error. If no such document Dold exists I want Dnew indexed into the solr-core. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to UPDATE a document Dnew where Dold.uniqueField is equal to Dnew.uniqueField I want Dold deleted from and Dnew added to the index (just as it is today).If no such document Dold exists I want nothing to happen (Dnew is not added to the index) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3831) Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE
[
https://issues.apache.org/jira/browse/LUCENE-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-3831:
---
Attachment: LUCENE-3831.patch
Thanks for the test cases Alan!
I folded those into a patch, added a few {{assert field != null}},
and then fixed SpanWeight to detect when its .getField() is
null and return a null scorer in that case.
I'd like to avoid the API break (changing Span*Query API to force
up-front providing of the field) if we can...
Passing a null fieldname to MemoryFields#terms in MemoryIndex throws a NPE
--
Key: LUCENE-3831
URL: https://issues.apache.org/jira/browse/LUCENE-3831
Project: Lucene - Java
Issue Type: Bug
Components: core/index
Affects Versions: 4.0
Reporter: Alan Woodward
Assignee: Michael McCandless
Priority: Minor
Attachments: LUCENE-3831.patch, TestNullFieldAfterRegexpRewrite.java,
mindex-null-field.patch
I found this when querying a MemoryIndex using a RegexpQuery wrapped by a
SpanMultiTermQueryWrapper. If the regexp doesn't match anything in the
index, it gets rewritten to an empty SpanOrQuery with a null field value,
which then triggers the NPE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-3173) Database semantics - insert and update
[ https://issues.apache.org/jira/browse/SOLR-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218254#comment-13218254 ] Per Steffensen edited comment on SOLR-3173 at 2/28/12 3:22 PM: --- Impl thoughts: * In solrconfig.xml turn this feature on by adding a tag databaseSemantics (probably to updateHandler). When this flag in not turned on update-requests work as always (add documents if not exist). With this flag turned on update-requests do not create a document if it does not already exist. Also when this flag is turned on insert-requests are suddenly also possible - they do as update-requets do today, except that they return DocumentAlreadyExist-error if document already exists. * Proper concurrency handling * Be carefull using this feature unless you are running with updateLog turned on (and therefore will never lose already accepted updates/deletes on crash) was (Author: steff1193): Impl thoughts: * In solrconfig.xml turn this feature on by added a tag databaseSemantics (probably to updateHandler). When this flag in not turned on update-requests work as always (creates if not exists). With this flag turned on update-requests does not create a document if it does not already exist. Also when this flag is turned on insert-requests are suddenly also possible - they do as update-requets does today, except that they return DocumentAlreadyExist-error if document already exists. * Proper concurrency handling * Be carefull using this feature unless you are running with updateLog turned on (and therefore will never lose already accepted updates/deletes on crash) Database semantics - insert and update -- Key: SOLR-3173 URL: https://issues.apache.org/jira/browse/SOLR-3173 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Labels: RDBMS, insert, nosql, uniqueKey, update Fix For: 4.0 Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support the following features inspired by RDBMSs and other NoSql databases. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to INSERT a new document Dnew where Dold.uniqueField is equal to Dnew.uniqueField, then I want a DocumentAlredyExists error. If no such document Dold exists I want Dnew indexed into the solr-core. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to UPDATE a document Dnew where Dold.uniqueField is equal to Dnew.uniqueField I want Dold deleted from and Dnew added to the index (just as it is today).If no such document Dold exists I want nothing to happen (Dnew is not added to the index) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3162) Continue work on new admin UI
[ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218271#comment-13218271 ] Mark Miller commented on SOLR-3162: --- Wishlist item: The zookeeper info has information about the current cluster state, but its not really in a very user friendly consumable form. It would be really great if we had a more graphical representation of cluster using the information from zookeeper. All of the information to build such a view is in the zookeeper servlet. The clusterstate.json file has the layout and state about each node, and the /live_nodes list gives which nodes are considered up and down by zookeeper. Together, this gives the major status of the cluster. So for a cluster that had a clusterstate.json with one collection, 2 shards, and 2 nodes for each shard, you might imagine seeing 4 circles arranged in a square under the heading collection1. There would be a row of circles for each shard and a column for each replica. One of the circles would represent a shard entry that did not have a node_name under /live_nodes, so it would be black. Another circle would represent a shard entry that had a node_name that was under/live_nodes and had a state of active so it would be green. Another circle would be good with /live_nodes but have a state of recoverying, so it would be yellow. The final circle would be good with /live_nodes but have a state of recovery_failed, so it would be red. At a glance, you could roughly see what your cluster looked like, and what state it was in. Then of course you could also add more, but this would be the basics. Just an idea ;) Continue work on new admin UI - Key: SOLR-3162 URL: https://issues.apache.org/jira/browse/SOLR-3162 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-3162.patch, SOLR-3162.patch There have been more improvements to how the new UI works, but the current open bugs are getting hard to keep straight. This is the new catch-all JIRA for continued improvements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3162) Continue work on new admin UI
[ https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218272#comment-13218272 ] Mark Miller commented on SOLR-3162: --- Wishlist item: The zookeeper info has information about the current cluster state, but its not really in a very user friendly consumable form. It would be really great if we had a more graphical representation of cluster using the information from zookeeper. All of the information to build such a view is in the zookeeper servlet. The clusterstate.json file has the layout and state about each node, and the /live_nodes list gives which nodes are considered up and down by zookeeper. Together, this gives the major status of the cluster. So for a cluster that had a clusterstate.json with one collection, 2 shards, and 2 nodes for each shard, you might imagine seeing 4 circles arranged in a square under the heading collection1. There would be a row of circles for each shard and a column for each replica. One of the circles would represent a shard entry that did not have a node_name under /live_nodes, so it would be black. Another circle would represent a shard entry that had a node_name that was under/live_nodes and had a state of active so it would be green. Another circle would be good with /live_nodes but have a state of recoverying, so it would be yellow. The final circle would be good with /live_nodes but have a state of recovery_failed, so it would be red. At a glance, you could roughly see what your cluster looked like, and what state it was in. Then of course you could also add more, but this would be the basics. Just an idea ;) Continue work on new admin UI - Key: SOLR-3162 URL: https://issues.apache.org/jira/browse/SOLR-3162 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-3162.patch, SOLR-3162.patch There have been more improvements to how the new UI works, but the current open bugs are getting hard to keep straight. This is the new catch-all JIRA for continued improvements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 3.6, 4.0 Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-3832: Attachment: LUCENE-3832.patch A patch with ported stringunion. Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 3.6, 4.0 Attachments: LUCENE-3832.patch Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218297#comment-13218297 ] Michael McCandless commented on LUCENE-3832: +1 Then we can remove the class from test-framework and cutover all uses to this new one? Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 3.6, 4.0 Attachments: LUCENE-3832.patch Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218304#comment-13218304 ] Kayode Odeyemi commented on SOLR-599: - Here's a working patch based off the above patch: https://github.com/charyorde/lucene-solr/blob/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/impl/contrib/SimpleHttpSolrServer.java Lightweight SolrJ client Key: SOLR-599 URL: https://issues.apache.org/jira/browse/SOLR-599 Project: Solr Issue Type: Improvement Components: clients - java Reporter: Shalin Shekhar Mangar Assignee: Noble Paul Priority: Minor Fix For: 3.6, 4.0 Attachments: SOLR-599.patch SolrJ provides a SolrServer implementation backed by commons-httpclient which introduces many dependency jars (commons-codec, commons-io and commons-logging). Apart from that SolrJ also uses StAX API for XML parsing which introduces dependencies like stax-api, stax and stax-utils. This enhancement will add a SolrServer implementation backed by java.net.HttpUrlConnection and will use BinaryResponseParser as the default response parser. Using this basic implementation out of the box would require no dependencies on either commons-httpclient or StAX. The only dependency would be on solr-commons making this a very lightweight and distribution friendly Java client for Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3168) numberToKeep backups doesn't ever keep more than 1
[ https://issues.apache.org/jira/browse/SOLR-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer resolved SOLR-3168. -- Resolution: Fixed Committed r1294703 (Trunk) r1294718 (3.x). Thanks, Neil. numberToKeep backups doesn't ever keep more than 1 Key: SOLR-3168 URL: https://issues.apache.org/jira/browse/SOLR-3168 Project: Solr Issue Type: Bug Components: replication (java) Affects Versions: 3.5, 4.0 Reporter: James Dyer Assignee: James Dyer Priority: Trivial Fix For: 3.6, 4.0 Attachments: SOLR-3168.patch On SOLR-2578, Neil Hooey pointed out a silly mistake in SnapShooter.java in that I forgot to increment a counter variable in the case the user wants to keep more than 1 backup. I will attach a patch for this 1-line fix. I do not intend to amend the unit test as this fix is easy to understand. Also, the test case is already very complex and long-running. I will commit shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3033) numberToKeep on replication handler does not work with backupAfter
[ https://issues.apache.org/jira/browse/SOLR-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer resolved SOLR-3033. -- Resolution: Fixed Fix Version/s: 3.6 - Committed r1294702 (trunk) r1294718 (3.x). - Updated the Wiki with explanation of the new parameter Thanks for reporting this Torsten. numberToKeep on replication handler does not work with backupAfter -- Key: SOLR-3033 URL: https://issues.apache.org/jira/browse/SOLR-3033 Project: Solr Issue Type: Bug Components: replication (java) Affects Versions: 3.5 Environment: openjdk 1.6, linux 3.x Reporter: Torsten Krah Assignee: James Dyer Fix For: 3.6 Attachments: SOLR-3033.patch, SOLR-3033.patch Configured my replication handler like this: requestHandler name=/replication class=solr.ReplicationHandler lst name=master str name=replicateAfterstartup/str str name=replicateAftercommit/str str name=replicateAfteroptimize/str str name=confFileselevate.xml,schema.xml,spellings.txt,stopwords.txt,stopwords_de.txt,stopwords_en.txt,synonyms_de.txt,synonyms.txt/str str name=backupAfteroptimize/str str name=numberToKeep1/str /lst /requestHandler So after optimize a snapshot should be taken, this works. But numberToKeep is ignored, snapshots are increasing with each call to optimize and are kept forever. Seems this settings have no effect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218329#comment-13218329 ] Dawid Weiss commented on LUCENE-3832: - Huh? Sorry, I don't get you -- what do you mean? Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 3.6, 4.0 Attachments: LUCENE-3832.patch Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3173) Database semantics - insert and update
[ https://issues.apache.org/jira/browse/SOLR-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218327#comment-13218327 ] Steven Rowe commented on SOLR-3173: --- Hi Per, I've added you to the JIRA Solr contributor group, which enables you to be assigned to JIRA issues. Database semantics - insert and update -- Key: SOLR-3173 URL: https://issues.apache.org/jira/browse/SOLR-3173 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Labels: RDBMS, insert, nosql, uniqueKey, update Fix For: 4.0 Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support the following features inspired by RDBMSs and other NoSql databases. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to INSERT a new document Dnew where Dold.uniqueField is equal to Dnew.uniqueField, then I want a DocumentAlredyExists error. If no such document Dold exists I want Dnew indexed into the solr-core. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to UPDATE a document Dnew where Dold.uniqueField is equal to Dnew.uniqueField I want Dold deleted from and Dnew added to the index (just as it is today).If no such document Dold exists I want nothing to happen (Dnew is not added to the index) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
[ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218331#comment-13218331 ] David Smiley commented on SOLR-3161: Hoss, In your view, is there any value in retaining the requestDispatcher handleSelect=true setting and requestHandler default=true setting for trunk? They seem legacy to me; I've never messed with them and I doubt anyone does but I don't know. Whatever their defaults may be or should be, I think their presence complicates keeping things simple, yet I'm unsure if their omission would result in any real loss of capability. I'm wondering what you think of my simplified proposal where I started saying What I would like to see is for it to be brain-dead simple...). Use of 'qt' should be restricted to searching and should not start with a '/' - Key: SOLR-3161 URL: https://issues.apache.org/jira/browse/SOLR-3161 Project: Solr Issue Type: Improvement Components: search, web gui Reporter: David Smiley Assignee: David Smiley Fix For: 3.6, 4.0 I haven't yet looked at the code involved for suggestions here; I'm speaking based on how I think things should work and not work, based on intuitiveness and security. In general I feel it is best practice to use '/' leading request handler names and not use qt, but I don't hate it enough when used in limited (search-only) circumstances to propose its demise. But if someone proposes its deprecation that then I am +1 for that. Here is my proposal: Solr should error if the parameter qt is supplied with a leading '/'. (trunk only) Solr should only honor qt if the target request handler extends solr.SearchHandler. The new admin UI should only use 'qt' when it has to. For the query screen, it could present a little pop-up menu of handlers to choose from, including /select?qt=mycustom for handlers that aren't named with a leading '/'. This choice should be positioned at the top. And before I forget, me or someone should investigate if there are any similar security problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined above. Does anyone foresee any problems with this proposal? On a related subject, I think the notion of a default request handler is bad - the default=true thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it would be clearer to use requestHandler name=/select class=solr.SearchHandler instead of what's there now. The delta is to put the leading '/' on this request handler name, and remove the default attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218338#comment-13218338 ] Uwe Schindler commented on LUCENE-3832: --- In test-framework is a helper method to build a Daciuk/Mihov automaton. With the patch, this somehow makes TermsFilter from contrib obsolete or should we maybe port that to an AutomatonQuery / MTQWF(AutomatonQuery)? If it simply subclasses AQ it could be more performant if the array has terms which are following each other in terms index. Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 3.6, 4.0 Attachments: LUCENE-3832.patch Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[
https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218341#comment-13218341
]
Michael McCandless commented on LUCENE-3832:
Sorry, what I meant was: we already have (and use, from tests only) this
algorithm, in
{{lucene/test-framework/src/java/org/apache/lucene/util/automaton/DaciukMihovAutomatonBuilder.java}}.
I agree we should promote it to core: it seems quite useful!
Actually I think there are slight differences vs the attached patch (looks like
Robert cutover to CharsRef/BytesRef), so I guess we need to reconcile those...
or maybe just move the existing one from test-framework to
StringUnionOperations (if there are no *important* differences :) ).
Port BasicAutomata.stringUnion from Brics to Lucene
---
Key: LUCENE-3832
URL: https://issues.apache.org/jira/browse/LUCENE-3832
Project: Lucene - Java
Issue Type: Improvement
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 3.6, 4.0
Attachments: LUCENE-3832.patch
Brics has my code to build Automaton from a set of sorted strings in one step
(Daciuk/Mihov's algorithm again). This should be easily portable to Lucene
and is quite useful.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 1828 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/1828/ 1 tests failed. REGRESSION: org.apache.lucene.search.TestSloppyPhraseQuery2.testRepetitiveIncreasingSloppiness3WithHoles Error Message: null Stack Trace: junit.framework.AssertionFailedError at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:165) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.apache.lucene.search.SearchEquivalenceTestBase.assertSubsetOf(SearchEquivalenceTestBase.java:204) at org.apache.lucene.search.SearchEquivalenceTestBase.assertSubsetOf(SearchEquivalenceTestBase.java:159) at org.apache.lucene.search.TestSloppyPhraseQuery2.testRepetitiveIncreasingSloppiness3WithHoles(TestSloppyPhraseQuery2.java:171) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:715) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:611) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:511) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:573) Build Log (for compile errors): [...truncated 1935 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
[ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-3161: --- Attachment: SOLR-3161-dispatching-request-handler.patch Use of 'qt' should be restricted to searching and should not start with a '/' - Key: SOLR-3161 URL: https://issues.apache.org/jira/browse/SOLR-3161 Project: Solr Issue Type: Improvement Components: search, web gui Reporter: David Smiley Assignee: David Smiley Fix For: 3.6, 4.0 Attachments: SOLR-3161-dispatching-request-handler.patch I haven't yet looked at the code involved for suggestions here; I'm speaking based on how I think things should work and not work, based on intuitiveness and security. In general I feel it is best practice to use '/' leading request handler names and not use qt, but I don't hate it enough when used in limited (search-only) circumstances to propose its demise. But if someone proposes its deprecation that then I am +1 for that. Here is my proposal: Solr should error if the parameter qt is supplied with a leading '/'. (trunk only) Solr should only honor qt if the target request handler extends solr.SearchHandler. The new admin UI should only use 'qt' when it has to. For the query screen, it could present a little pop-up menu of handlers to choose from, including /select?qt=mycustom for handlers that aren't named with a leading '/'. This choice should be positioned at the top. And before I forget, me or someone should investigate if there are any similar security problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined above. Does anyone foresee any problems with this proposal? On a related subject, I think the notion of a default request handler is bad - the default=true thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it would be clearer to use requestHandler name=/select class=solr.SearchHandler instead of what's there now. The delta is to put the leading '/' on this request handler name, and remove the default attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
[
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218356#comment-13218356
]
Erik Hatcher commented on SOLR-3161:
I just attached a patch as an example along the lines of what Hoss proposed. I
removed default=true, renamed search to /select, and set
handleSelect=false. Then I added some request handlers:
* lazy - a lazy loaded search request handler
* notlazy - a concrete (not lazy loaded) search request handler
* /dispatch - a DispatchingRequestHandler that uses qt to look up a non-lazy
loaded *SearchRequestHandler* and dispatches to that
* /handlers - just a quick/easy way for me to see the defined request
handlers (using the handlers.vm) template
Here are some requests and their effect:
http://localhost:8983/solr/handlers
{code}
- [/admin/plugins] - org.apache.solr.handler.admin.PluginInfoHandler@428d5aad
- [/admin/system] - org.apache.solr.handler.admin.SystemInfoHandler@4e3c35fd
- [notlazy] - org.apache.solr.handler.component.SearchHandler@52fc9d2b
- [/admin/file] -
org.apache.solr.handler.admin.ShowFileRequestHandler@46b29c9d
- [/dispatch] -
org.apache.solr.handler.component.DispatchingRequestHandler@78482bad
- [/admin/luke] - org.apache.solr.handler.admin.LukeRequestHandler@4a2ba88c
- [/update/javabin] -
org.apache.solr.handler.BinaryUpdateRequestHandler@7846a55e
- [/update] - org.apache.solr.handler.XmlUpdateRequestHandler@6612fc02
- [/terms] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@685f1ba8
- [/admin/threads] - org.apache.solr.handler.admin.ThreadDumpHandler@3c10e820
- [/replication] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@79f7abae
- [/analysis/field] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@73286b10
- [lazy] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@628d2280
- [/browse] - org.apache.solr.handler.component.SearchHandler@50c7833c
- [/admin/ping] - org.apache.solr.handler.PingRequestHandler@3e5646a5
- [/analysis/document] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@5da5e65f
- [/select] - org.apache.solr.handler.component.SearchHandler@36b79701
- [/admin/mbeans] -
org.apache.solr.handler.admin.SolrInfoMBeanHandler@4f1adeb7
- [/update/csv] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@6d13e8f3
- [/handlers] - org.apache.solr.handler.DumpRequestHandler@3622e177
- [/elevate] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@2c006765
- [/update/xslt] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@4e842e74
- [/update/json] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@4805e9f1
- [/get] - org.apache.solr.handler.RealTimeGetHandler@7c41f227
- [/update/extract] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@4d811e2c
- [/admin/properties] -
org.apache.solr.handler.admin.PropertiesRequestHandler@57e40274
- [tvrh] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@3a5d3ac0
- [/spell] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@3ebc312f
- [/debug/dump] - org.apache.solr.handler.DumpRequestHandler@354124d6
{code}
http://localhost:8983/solr/select?q=*:*
- returns our tried and true Solr response
http://localhost:8983/solr/dispatch?q=*:*qt=lazy
- returns HTTP 400 with Must be a SearchHandler: lazy
http://localhost:8983/solr/dispatch?q=*:*qt=notlazy
- returns HTTP 200 using the notlazy request handler's response
And of course you can with this patch, but maybe that's a silly to allow, do
this request http://localhost:8983/solr/dispatch?q=*:*qt=/select
- which dispatches to /select, basically the same as
http://localhost:8983/solr/select?q=*:*
I personally really like the idea of qt not being special at all, yet if you do
want to use something like that that you wire in a DispatchingRequestHandler.
In fact, I'll go so far as to say that Solr's main dispatching filter shouldn't
use any query string parameters, and only request handlers themselves use them.
(that begs the question about wt, but there's HTTP mechanisms for specifying
the format you desire a resource in :). I'll digress on that last point.
The gist here is that with some simple config tweaks and a dispatcher, you can
have your cake and eat it too.
Use of 'qt' should be restricted to searching and should not start with a '/'
-
Key: SOLR-3161
URL: https://issues.apache.org/jira/browse/SOLR-3161
Project: Solr
Issue Type: Improvement
Components: search, web gui
Reporter: David Smiley
Assignee: David Smiley
Fix For: 3.6, 4.0
Attachments:
[jira] [Issue Comment Edited] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
[
https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218356#comment-13218356
]
Erik Hatcher edited comment on SOLR-3161 at 2/28/12 5:06 PM:
-
I just attached a patch as an example along the lines of what Hoss proposed. I
removed default=true, renamed search to /select, and set
handleSelect=false. Then I added some request handlers:
* lazy - a lazy loaded search request handler
* notlazy - a concrete (not lazy loaded) search request handler
* /dispatch - a DispatchingRequestHandler that uses qt to look up a non-lazy
loaded *SearchRequestHandler* and dispatches to that
* /handlers - just a quick/easy way for me to see the defined request
handlers (using the handlers.vm) template
Here are some requests and their effect:
http://localhost:8983/solr/handlers
{code}
- [/admin/plugins] - org.apache.solr.handler.admin.PluginInfoHandler@428d5aad
- [/admin/system] - org.apache.solr.handler.admin.SystemInfoHandler@4e3c35fd
- [notlazy] - org.apache.solr.handler.component.SearchHandler@52fc9d2b
- [/admin/file] -
org.apache.solr.handler.admin.ShowFileRequestHandler@46b29c9d
- [/dispatch] -
org.apache.solr.handler.component.DispatchingRequestHandler@78482bad
- [/admin/luke] - org.apache.solr.handler.admin.LukeRequestHandler@4a2ba88c
- [/update/javabin] -
org.apache.solr.handler.BinaryUpdateRequestHandler@7846a55e
- [/update] - org.apache.solr.handler.XmlUpdateRequestHandler@6612fc02
- [/terms] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@685f1ba8
- [/admin/threads] - org.apache.solr.handler.admin.ThreadDumpHandler@3c10e820
- [/replication] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@79f7abae
- [/analysis/field] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@73286b10
- [lazy] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@628d2280
- [/browse] - org.apache.solr.handler.component.SearchHandler@50c7833c
- [/admin/ping] - org.apache.solr.handler.PingRequestHandler@3e5646a5
- [/analysis/document] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@5da5e65f
- [/select] - org.apache.solr.handler.component.SearchHandler@36b79701
- [/admin/mbeans] -
org.apache.solr.handler.admin.SolrInfoMBeanHandler@4f1adeb7
- [/update/csv] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@6d13e8f3
- [/handlers] - org.apache.solr.handler.DumpRequestHandler@3622e177
- [/elevate] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@2c006765
- [/update/xslt] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@4e842e74
- [/update/json] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@4805e9f1
- [/get] - org.apache.solr.handler.RealTimeGetHandler@7c41f227
- [/update/extract] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@4d811e2c
- [/admin/properties] -
org.apache.solr.handler.admin.PropertiesRequestHandler@57e40274
- [tvrh] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@3a5d3ac0
- [/spell] -
org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper@3ebc312f
- [/debug/dump] - org.apache.solr.handler.DumpRequestHandler@354124d6
{code}
http://localhost:8983/solr/select?q=*:*
- returns our tried and true Solr response
http://localhost:8983/solr/dispatch?q=*:*qt=lazy
- returns HTTP 400 with Must be a SearchHandler: lazy
http://localhost:8983/solr/dispatch?q=*:*qt=notlazy
- returns HTTP 200 using the notlazy request handler's response
And of course you can with this patch, but maybe that's silly to allow, do this
request http://localhost:8983/solr/dispatch?q=*:*qt=/select
- which dispatches to /select, basically the same as
http://localhost:8983/solr/select?q=*:*
I personally really like the idea of qt not being special at all, yet if you do
want to use something like that that you wire in a DispatchingRequestHandler.
In fact, I'll go so far as to say that Solr's main dispatching filter shouldn't
use any query string parameters, and only request handlers themselves use them.
(that begs the question about wt, but there's HTTP mechanisms for specifying
the format you desire a resource in :). I'll digress on that last point.
The gist here is that with some simple config tweaks and a dispatcher, you can
have your cake and eat it too.
was (Author: ehatcher):
I just attached a patch as an example along the lines of what Hoss
proposed. I removed default=true, renamed search to /select, and set
handleSelect=false. Then I added some request handlers:
* lazy - a lazy loaded search request handler
* notlazy - a concrete (not lazy loaded) search request handler
* /dispatch - a DispatchingRequestHandler that uses qt to look up a non-lazy
loaded *SearchRequestHandler* and
[jira] [Created] (SOLR-3174) Visualize Cluster State
Visualize Cluster State --- Key: SOLR-3174 URL: https://issues.apache.org/jira/browse/SOLR-3174 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley It would be great to visualize the cluster state in the new UI. See Mark's wish: https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3174) Visualize Cluster State
[ https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218362#comment-13218362 ] Ryan McKinley commented on SOLR-3174: - There are a few libraries that could make this relativly straightforward and good looking: http://flare.prefuse.org/demo http://jsplumb.org/jquery/chartDemo.html http://neyric.github.com/wireit/ Visualize Cluster State --- Key: SOLR-3174 URL: https://issues.apache.org/jira/browse/SOLR-3174 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley It would be great to visualize the cluster state in the new UI. See Mark's wish: https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3157) custom logging
[ https://issues.apache.org/jira/browse/SOLR-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218398#comment-13218398 ] Hoss Man commented on SOLR-3157: Yonik: your changes in r1294212 break the SolrCore.execute log format conventions we've had in place since SOLR-267, which breaks some log processing code i have (and since the whole point of SOLR-267 was to make it easy for people to write log parses, i'm guessing i'm not the only one) Notably: * you changed the path and params key=val pairs so they no longer include the key, just the val -- this doesn't really make sense to me since the whole point of those log lines is that they are suppose to be consistent and easy to parse. * you removed the webapp key=val pair completely (comment says multiple webaps are no longer best practise but that doesn't mean people don't use them or that we should just suddenly stop logging them. custom logging -- Key: SOLR-3157 URL: https://issues.apache.org/jira/browse/SOLR-3157 Project: Solr Issue Type: Test Reporter: Yonik Seeley Priority: Blocker Attachments: SOLR-3157.patch, jetty_threadgroup.patch We need custom logging to decipher tests with multiple core containers, cores, in a single JVM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Lucene.Net] Official stance on API changes between major versions
I *really* don't mean to be a bother to anyone, but I'd like to continue work on this. I feel that until I can get a better sense of how the group feels about this, I can't make much progress. Perhaps this radio silence is just because this email thread got lost in among the others. On Fri, Feb 24, 2012 at 6:50 PM, Prescott Nasser geobmx...@hotmail.comwrote: Im not against breaking compatibility when changing the version number to a new major 2 - 3. Im not sure how others feel. Matching Java access modifiers seems like the right move. That said, what if we mark obsolete in 3.0.3 and when we make the jump to 4.0 wipe them out? In my head we shouldn't spend too much time cleaning up 3.0.3 aside from bug fixes if were just going to swap it for 4.0 in the near future. There has to be a break at some point, making it with a major release is the best place to make it. Sent from my Windows Phone From: Christopher Currens Sent: 2/24/2012 2:45 PM To: lucene-net-...@lucene.apache.org Subject: [Lucene.Net] Official stance on API changes between major versions A bit of background about what I've been doing lately on the project. Because we've now confirmed that the .NET 3.0.3 branch is a completed port of Java 3.0.3 version, I've been spending time trying to work on some of the bugs and improvements that are assigned to this version. There wasn't any real discussion about the actual features, I just created some (based on mailing list discussions) and assigned them to the 3.0.3 release. The improvements I've been working on lately are ones that have bugged me specifically since I've started using Lucene.NET. I've worked on https://issues.apache.org/jira/browse/LUCENENET-468 and https://issues.apache.org/jira/browse/LUCENENET-470 so far. LUCENENET-740 is pretty much completed, all of the classes that implemented Closeable() now implement IDisposable, having a public void Dispose() and/or protected virtual void Dispose(bool disposing), depending if the class is sealed or not. What is left to do on that issue would be to make sure that all of the tests are a) overriding the protected dispose method as needed and b) are actually calling Dispose or are in a using statement. I've done quite a bit of work on LUCENENET-468, as well, though it is going far slower than 470, because there's a lot more that needs to be done and a bit more carefully, if I don't want to break anyone's code when they move to 3.0. I'm not doing them in any particular order, I'm really just running VS2010 code analysis (Rule CA1024 only, actually) and changing the ones suggested and ones I happen across to use Properties. I've also spent some time trying to wrap public fields in public properties. However, this one in particular has been posing some problems for me, and really brings me to the point of this email. Due to the way most class members are named (there's a lot of redundancy), I'm finding it difficult to move forward with some of these refactoring without breaking backwards compatibility or adding more things to change in regards to LUCENE-446 and CLS compliance. For classes that are specifically marked internal, this of course, hasn't been a problem, I just make the breaking change and fix it other places in the library. This is, of course, a problem with class that are public, including classes that *should not* be marked public but are anyway. It's a little off topic, but we stray far sometimes from the access modifiers defined on the java classes. I've found that nearly all cases were because they were needed for the NUnit tests. That problem no longer exists in 3.0.3, as the Test library can now access those types in the core assembly. I personally feel that whenever we find an difference in access modifiers, we change it to match java, however, if customers are using that, well, now they can't. That's issue number one that I wanted to discuss with the group. Going back to the difficulties in .NET-ifying the API, often times if I want to convert a Get[name]()/Set[name]() group or individual method to a property, the resulting property name will conflict with an already existing public field, another method with the exact same name, or the name of the enclosing type itself. The latter can't easily be solved, so I'm not fretting too much about it. The first two are easier to solve, but not without breaking backwards compatibility for some users. Now, the API between 2.x and 3.x differs greatly, so some customers *may* have to make changes anyway. However, that's not a good rule, since most, if not all, of the breaking changes made to Lucene.NET were first obsoleted for a period of time, and thus they were given plenty of warning to change their code. Unfortunately, with these changes, we haven't given them the same notice. So far, I've been trying my best to make sure that all changes that have been
[jira] [Updated] (LUCENE-2632) FilteringCodec, TeeCodec, TeeDirectory
[
https://issues.apache.org/jira/browse/LUCENE-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrzej Bialecki updated LUCENE-2632:
--
Attachment: LUCENE-2632.patch
Updated patch, based on Robert's version:
* catch up with trunk,
* tweak WriteFilter api to be more convenient and useful,
* add javadocs,
* add initialSync functionality to TeeDirectory to sync existing files on
open, and add a corresponding test.
All tests pass.
FilteringCodec, TeeCodec, TeeDirectory
--
Key: LUCENE-2632
URL: https://issues.apache.org/jira/browse/LUCENE-2632
Project: Lucene - Java
Issue Type: New Feature
Components: core/index
Affects Versions: 4.0
Reporter: Andrzej Bialecki
Attachments: LUCENE-2632.patch, LUCENE-2632.patch, LUCENE-2632.patch,
LUCENE-2632.patch
This issue adds two new Codec implementations:
* TeeCodec: there have been attempts in the past to implement parallel
writing to multiple indexes so that they are all synchronized. This was
however complicated due to the complexity of IndexWriter/SegmentMerger logic.
The solution presented here offers a similar functionality but working on a
different level - as the name suggests, the TeeCodec duplicates index data
into multiple output Directories.
* TeeDirectory (used also in TeeCodec) is a simple abstraction to perform
Directory operations on several directories in parallel (effectively
mirroring their data). Optionally it's possible to specify a set of suffixes
of files that should be mirrored so that non-matching files are skipped.
* FilteringCodec is related in a remote way to the ideas of index pruning
presented in LUCENE-1812 and the concept of tiered search. Since we can use
TeeCodec to write to multiple output Directories in a synchronized way, we
could also filter out or modify some of the data that is being written. The
FilteringCodec provides this functionality, so that you can use like this:
{code}
IndexWriter -- TeeCodec
| |
| +-- StandardCodec -- Directory1
+-- FilteringCodec -- StandardCodec -- Directory2
{code}
The end result of this chain is two indexes that are kept in sync - one is
the full regular index, and the other one is a filtered index.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3162) Continue work on new admin UI
[
https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218444#comment-13218444
]
Erik Hatcher commented on SOLR-3162:
Quoting from a comment above:
bq. ... Additionally we would need the functionality as a
handler/servlet-thingy ...
This is where the, tada, VelocityResponseWriter could really help here. Rather
than raw *data* having to come from Ajax calls, through a Velocity template you
can get at pretty much _anything_ from the SolrCore and configuration, and then
use that to generate a response (even, say, an x = '$whatever' kinda variable
into JavaScript. For example:
{code}
never304 = $request.core.solrConfig.httpCachingConfig.never304
{code}
You could get this using an out of the box request like this:
http://localhost:8983/solr/select?wt=velocityv.template=foov.template.foo=never304%20=%20$request.core.solrConfig.httpCachingConfig.never304
(though of course I'd recommend templates be created from this under
conf/velocity rather than passed in via the request). The point is, everything
can be gathered when you're inside Solr, but requires explicit exposing of
these inner details to make the data available cleanly for this
Ajax-the-data-generate-UI-in-JavaScript approach.
Continue work on new admin UI
-
Key: SOLR-3162
URL: https://issues.apache.org/jira/browse/SOLR-3162
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis
Affects Versions: 4.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Attachments: SOLR-3162.patch, SOLR-3162.patch
There have been more improvements to how the new UI works, but the current
open bugs are getting hard to keep straight. This is the new catch-all JIRA
for continued improvements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-3162) Continue work on new admin UI
[
https://issues.apache.org/jira/browse/SOLR-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218444#comment-13218444
]
Erik Hatcher edited comment on SOLR-3162 at 2/28/12 6:39 PM:
-
Quoting from a comment above:
bq. ... Additionally we would need the functionality as a
handler/servlet-thingy ...
This is where the, tada, VelocityResponseWriter could really help here. Rather
than raw *data* having to come from Ajax calls, through a Velocity template you
can get at pretty much _anything_ from the SolrCore and configuration, and then
use that to generate a response (even, say, an x = '$whatever' kinda variable
into JavaScript. For example:
{code}
never304 = $request.core.solrConfig.httpCachingConfig.never304
{code}
You could get this using an out of the box request like this:
http://localhost:8983/solr/select?q=*:*wt=velocityv.template=foov.template.foo=never304%20=%20$request.core.solrConfig.httpCachingConfig.never304
(though of course I'd recommend templates be created from this under
conf/velocity rather than passed in via the request). The point is, everything
can be gathered when you're inside Solr, but requires explicit exposing of
these inner details to make the data available cleanly for this
Ajax-the-data-generate-UI-in-JavaScript approach.
was (Author: ehatcher):
Quoting from a comment above:
bq. ... Additionally we would need the functionality as a
handler/servlet-thingy ...
This is where the, tada, VelocityResponseWriter could really help here. Rather
than raw *data* having to come from Ajax calls, through a Velocity template you
can get at pretty much _anything_ from the SolrCore and configuration, and then
use that to generate a response (even, say, an x = '$whatever' kinda variable
into JavaScript. For example:
{code}
never304 = $request.core.solrConfig.httpCachingConfig.never304
{code}
You could get this using an out of the box request like this:
http://localhost:8983/solr/select?wt=velocityv.template=foov.template.foo=never304%20=%20$request.core.solrConfig.httpCachingConfig.never304
(though of course I'd recommend templates be created from this under
conf/velocity rather than passed in via the request). The point is, everything
can be gathered when you're inside Solr, but requires explicit exposing of
these inner details to make the data available cleanly for this
Ajax-the-data-generate-UI-in-JavaScript approach.
Continue work on new admin UI
-
Key: SOLR-3162
URL: https://issues.apache.org/jira/browse/SOLR-3162
Project: Solr
Issue Type: Improvement
Components: Schema and Analysis
Affects Versions: 4.0
Reporter: Erick Erickson
Assignee: Erick Erickson
Attachments: SOLR-3162.patch, SOLR-3162.patch
There have been more improvements to how the new UI works, but the current
open bugs are getting hard to keep straight. This is the new catch-all JIRA
for continued improvements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3140) Make omitNorms default for all numeric field types
[ https://issues.apache.org/jira/browse/SOLR-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218465#comment-13218465 ] Erik Hatcher commented on SOLR-3140: +1, simpler is better. Make omitNorms default for all numeric field types -- Key: SOLR-3140 URL: https://issues.apache.org/jira/browse/SOLR-3140 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Labels: omitNorms Fix For: 4.0 Today norms are enabled for all Solr field types by default, while in Lucene norms are omitted for the numeric types. Propose to make the Solr defaults the same as in Lucene, so that if someone occasionally wants index-side boost for a numeric field type they must say omitNorms=false. This lets us simplify the example schema too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3149) Update obsolete schema.xml in example-DIH
[ https://issues.apache.org/jira/browse/SOLR-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-3149: - Attachment: SOLR-3149.patch Yusuke, Thanks for pointing this out. Would you mind applying this patch and trying out all of the examples to be sure they still work? (I was having some trouble getting them all to run in my enviornment). I've both updated the schemas and pared them down quite a bit to (mostly) only contain needed features. There is also a new note to look for the main example config for more options. If this seems good and all the examples still run ok I'll commit. Update obsolete schema.xml in example-DIH - Key: SOLR-3149 URL: https://issues.apache.org/jira/browse/SOLR-3149 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 3.5, 4.0 Reporter: Yusuke Yanbe Priority: Minor Labels: dataimportHandler, documentaion, newbie Attachments: SOLR-3149.patch Original Estimate: 3h Remaining Estimate: 3h The version of example/example-DIH/solr/db/conf/schema.xml is 1.1 (too old) where example/solr/conf/schema.xml is 1.4. I believe that it is important to keep all schema.xml up to date for newbies. The example/example-DIH/solr/db/conf/schema.xml will be referred as primary hints for newbies because most of them may want to try import some data from their preexisting DB or something first, referring [1]. Even DataImportHandler tutorial itself can be done without problem, obsolete schema.xml may confusing for them. Typical difference of new and old schema.xml is existence of explanation of *TrieField. Because old one's default types are solr.IntField or solr.DateField and no mention of this. Consequently, when they try range queries or boosting query based on old schema.xml, they may face unintended slow response or error. [1] http://wiki.apache.org/solr/DataImportHandler#Full_Import_Example -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218485#comment-13218485 ] Dawid Weiss commented on LUCENE-3832: - I don't know if the original version is a derivative of what I placed in the patch or not (I wrote the one originally in brics). There will be ordering differences between the one based on char and UTF8 so it's not exactly the same; somebody should perhaps look at it from a wider perspective. If you have spare cycles, feel free to take over -- this was really a 5 minute effort and I can't take a deeper look at it at the moment. Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 3.6, 4.0 Attachments: LUCENE-3832.patch Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [Lucene.Net] Merging 3.0.3 into Trunk
I meant to merge, its on my to do list, might take me some time - just started a new job Sent from my Windows Phone From: Christopher Currens Sent: 2/28/2012 10:36 AM To: lucene-net-...@lucene.apache.org Subject: [Lucene.Net] Merging 3.0.3 into Trunk Now that we've release 2.9.4g, are we at a point to where we can merge the 3.0.3 branch in with Trunk? Any thoughts on that either way? Thanks, Christopher
[jira] [Commented] (SOLR-599) Lightweight SolrJ client
[ https://issues.apache.org/jira/browse/SOLR-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218495#comment-13218495 ] Jan Høydahl commented on SOLR-599: -- This is great, Kayode. Would you be willing to donate your code to Solr? If so, please upload the java file, or even better, a patch file, to this ticket, and tick the ASF license checkbox. Then we must decide how to package this. I think power users may still need the full commonsHTTP thing (if they require SSL support or other advanced stuff) but having an official client without all the deps would be nice. Lightweight SolrJ client Key: SOLR-599 URL: https://issues.apache.org/jira/browse/SOLR-599 Project: Solr Issue Type: Improvement Components: clients - java Reporter: Shalin Shekhar Mangar Assignee: Noble Paul Priority: Minor Fix For: 3.6, 4.0 Attachments: SOLR-599.patch SolrJ provides a SolrServer implementation backed by commons-httpclient which introduces many dependency jars (commons-codec, commons-io and commons-logging). Apart from that SolrJ also uses StAX API for XML parsing which introduces dependencies like stax-api, stax and stax-utils. This enhancement will add a SolrServer implementation backed by java.net.HttpUrlConnection and will use BinaryResponseParser as the default response parser. Using this basic implementation out of the box would require no dependencies on either commons-httpclient or StAX. The only dependency would be on solr-commons making this a very lightweight and distribution friendly Java client for Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [Lucene.Net] Merging 3.0.3 into Trunk
No sweat, if we're ready to merge it in, I can do it, all while trying not to break everything! :) On Tue, Feb 28, 2012 at 11:12 AM, Prescott Nasser geobmx...@hotmail.comwrote: I meant to merge, its on my to do list, might take me some time - just started a new job Sent from my Windows Phone From: Christopher Currens Sent: 2/28/2012 10:36 AM To: lucene-net-...@lucene.apache.org Subject: [Lucene.Net] Merging 3.0.3 into Trunk Now that we've release 2.9.4g, are we at a point to where we can merge the 3.0.3 branch in with Trunk? Any thoughts on that either way? Thanks, Christopher
[jira] [Commented] (LUCENE-3820) Wrong trailing index calculation in PatternReplaceCharFilter
[ https://issues.apache.org/jira/browse/LUCENE-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218515#comment-13218515 ] Dawid Weiss commented on LUCENE-3820: - Yep, nice catch. That test case causes a beautiful exponential time pattern to be generated (I've added it as an @Ignored test :). I limited the input size to 40 characters. With such input it should be possible to traverse the entire search space, even if it's exponential. I don't see a way to easily verify if a pattern is exponential or not (without resigning from certain types of patterns). Wrong trailing index calculation in PatternReplaceCharFilter Key: LUCENE-3820 URL: https://issues.apache.org/jira/browse/LUCENE-3820 Project: Lucene - Java Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3820.patch, LUCENE-3820.patch, LUCENE-3820_test.patch, LUCENE-3820_test.patch Reimplementation of PatternReplaceCharFilter to pass randomized tests (used to throw exceptions previously). Simplified code, dropped boundary characters, full input buffered for pattern matching. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
[ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218521#comment-13218521 ] David Smiley commented on SOLR-3161: Erik, Cool. I hope you verified that /select?qt=/ fails. What are your thoughts on my question to Hoss? Use of 'qt' should be restricted to searching and should not start with a '/' - Key: SOLR-3161 URL: https://issues.apache.org/jira/browse/SOLR-3161 Project: Solr Issue Type: Improvement Components: search, web gui Reporter: David Smiley Assignee: David Smiley Fix For: 3.6, 4.0 Attachments: SOLR-3161-dispatching-request-handler.patch I haven't yet looked at the code involved for suggestions here; I'm speaking based on how I think things should work and not work, based on intuitiveness and security. In general I feel it is best practice to use '/' leading request handler names and not use qt, but I don't hate it enough when used in limited (search-only) circumstances to propose its demise. But if someone proposes its deprecation that then I am +1 for that. Here is my proposal: Solr should error if the parameter qt is supplied with a leading '/'. (trunk only) Solr should only honor qt if the target request handler extends solr.SearchHandler. The new admin UI should only use 'qt' when it has to. For the query screen, it could present a little pop-up menu of handlers to choose from, including /select?qt=mycustom for handlers that aren't named with a leading '/'. This choice should be positioned at the top. And before I forget, me or someone should investigate if there are any similar security problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined above. Does anyone foresee any problems with this proposal? On a related subject, I think the notion of a default request handler is bad - the default=true thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it would be clearer to use requestHandler name=/select class=solr.SearchHandler instead of what's there now. The delta is to put the leading '/' on this request handler name, and remove the default attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-3.x-java7 - Build # 1859 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-3.x-java7/1859/ 1 tests failed. REGRESSION: org.apache.lucene.search.TestSloppyPhraseQuery2.testIncreasingSloppiness3WithHoles Error Message: null Stack Trace: junit.framework.AssertionFailedError at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:147) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50) at org.apache.lucene.search.SearchEquivalenceTestBase.assertSubsetOf(SearchEquivalenceTestBase.java:173) at org.apache.lucene.search.SearchEquivalenceTestBase.assertSubsetOf(SearchEquivalenceTestBase.java:157) at org.apache.lucene.search.TestSloppyPhraseQuery2.testIncreasingSloppiness3WithHoles(TestSloppyPhraseQuery2.java:101) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:606) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:495) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:400) at org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:458) Build Log (for compile errors): [...truncated 9803 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-3173) Database semantics - insert and update
[ https://issues.apache.org/jira/browse/SOLR-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Per Steffensen reassigned SOLR-3173: Assignee: Per Steffensen Database semantics - insert and update -- Key: SOLR-3173 URL: https://issues.apache.org/jira/browse/SOLR-3173 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Assignee: Per Steffensen Labels: RDBMS, insert, nosql, uniqueKey, update Fix For: 4.0 Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support the following features inspired by RDBMSs and other NoSql databases. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to INSERT a new document Dnew where Dold.uniqueField is equal to Dnew.uniqueField, then I want a DocumentAlredyExists error. If no such document Dold exists I want Dnew indexed into the solr-core. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to UPDATE a document Dnew where Dold.uniqueField is equal to Dnew.uniqueField I want Dold deleted from and Dnew added to the index (just as it is today).If no such document Dold exists I want nothing to happen (Dnew is not added to the index) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3161) Use of 'qt' should be restricted to searching and should not start with a '/'
[ https://issues.apache.org/jira/browse/SOLR-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218530#comment-13218530 ] Erik Hatcher commented on SOLR-3161: bq. I hope you verified that /select?qt=/ Did you mean that literally, as a single /? Anyway, with my patch (handleSelect=false and /select replacing the default search request handler), qt is nothing special. So /select?qt=/ is the same as /select since /select handler itself ignores qt. bq. What are your thoughts on my question to Hoss? IMO, if we're going the way of this DispatchingRequestHandler, then handleSelect should always be false and there should be no default request handler. Just map what you want to /select to make it the default since that's what the convention is. Use of 'qt' should be restricted to searching and should not start with a '/' - Key: SOLR-3161 URL: https://issues.apache.org/jira/browse/SOLR-3161 Project: Solr Issue Type: Improvement Components: search, web gui Reporter: David Smiley Assignee: David Smiley Fix For: 3.6, 4.0 Attachments: SOLR-3161-dispatching-request-handler.patch I haven't yet looked at the code involved for suggestions here; I'm speaking based on how I think things should work and not work, based on intuitiveness and security. In general I feel it is best practice to use '/' leading request handler names and not use qt, but I don't hate it enough when used in limited (search-only) circumstances to propose its demise. But if someone proposes its deprecation that then I am +1 for that. Here is my proposal: Solr should error if the parameter qt is supplied with a leading '/'. (trunk only) Solr should only honor qt if the target request handler extends solr.SearchHandler. The new admin UI should only use 'qt' when it has to. For the query screen, it could present a little pop-up menu of handlers to choose from, including /select?qt=mycustom for handlers that aren't named with a leading '/'. This choice should be positioned at the top. And before I forget, me or someone should investigate if there are any similar security problems with the shards.qt parameter. Perhaps shards.qt can abide by the same rules outlined above. Does anyone foresee any problems with this proposal? On a related subject, I think the notion of a default request handler is bad - the default=true thing. Honestly I'm not sure what it does, since I noticed Solr trunk redirects '/solr/' to the new admin UI at '/solr/#/'. Assuming it doesn't do anything useful anymore, I think it would be clearer to use requestHandler name=/select class=solr.SearchHandler instead of what's there now. The delta is to put the leading '/' on this request handler name, and remove the default attribute. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3829) Lucene40 codec's DocValues DirectSource impls aren't thread-safe
[ https://issues.apache.org/jira/browse/LUCENE-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218542#comment-13218542 ] Simon Willnauer commented on LUCENE-3829: - wait, I think your test is wrong. DV consumer should pull a source directly from DV per thread. An instance is not threadsafe per-se. if you pull an in-memory source you can simply share it but the interface doesn't guarantee this. you can simply pull the in-memory source in each thread and you get the same instance since it is cached. The same is true for the on-disk source since it is not cached. I clone the IndexInput in getDirectSource() to prevent this problem. Lucene40 codec's DocValues DirectSource impls aren't thread-safe Key: LUCENE-3829 URL: https://issues.apache.org/jira/browse/LUCENE-3829 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Fix For: 4.0 Attachments: LUCENE-3829.patch Our DirectSource impls hold IndexInput(s) open against the dat/idx files, which we then seek + read when loading a specific document's value. But this is in no way protected against multiple threads I think...? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3173) Database semantics - insert and update
[ https://issues.apache.org/jira/browse/SOLR-3173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218571#comment-13218571 ] Yonik Seeley commented on SOLR-3173: Here's an idea: we already have a _version_ field for documents (that can also be passed in the URL for other things like deletes), we simply reuse that. Positive versions are adds, negative versions are deletes. If a document comes into the shad leader and already has a _version_, then it's considered an optimistic concurrency request... the document should be replacing an existing document with exactly that version. If the _version_ passed is negative, then the document should not already exist (all deleted documents are considered equal). No new config needed, and optimistic concurrency can be selected on a per-request basis to the same handler. Database semantics - insert and update -- Key: SOLR-3173 URL: https://issues.apache.org/jira/browse/SOLR-3173 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Assignee: Per Steffensen Labels: RDBMS, insert, nosql, uniqueKey, update Fix For: 4.0 Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support the following features inspired by RDBMSs and other NoSql databases. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to INSERT a new document Dnew where Dold.uniqueField is equal to Dnew.uniqueField, then I want a DocumentAlredyExists error. If no such document Dold exists I want Dnew indexed into the solr-core. * Given a solr-core with a schema containing a uniqueKey-field uniqueField and a document Dold, when trying to UPDATE a document Dnew where Dold.uniqueField is equal to Dnew.uniqueField I want Dold deleted from and Dnew added to the index (just as it is today).If no such document Dold exists I want nothing to happen (Dnew is not added to the index) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-3360) Move FieldCache to IndexReader
[
https://issues.apache.org/jira/browse/LUCENE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn van Groningen closed LUCENE-3360.
-
Resolution: Won't Fix
Closing this issue since it would only couple the FieldCache and IndexReader
instead to decouple this for the new direction that is being explored in
LUCENE-3729.
Move FieldCache to IndexReader
--
Key: LUCENE-3360
URL: https://issues.apache.org/jira/browse/LUCENE-3360
Project: Lucene - Java
Issue Type: Improvement
Reporter: Martijn van Groningen
Fix For: 3.6, 4.0
Attachments: LUCENE-3360-3x.patch, LUCENE-3360-3x.patch,
LUCENE-3360-3x.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch, LUCENE-3360.patch,
LUCENE-3360.patch
Move the static FieldCache.DEFAULT field instance to atomic IndexReaders, so
that FieldCache insanity caused by the WeakHashMap no longer occurs.
* Add a new method to IndexReader that by default throws an UOE:
{code}public FieldCache getFieldCache(){code}
* The SegmentReader implements this method and returns its own internal
FieldCache implementation. This implementation just uses a
HashMapEntryT,Object to store entries.
* The SlowMultiReaderWrapper implements this method as well and basically
behaves the same as the current FieldCacheImpl.
This issue won't solve the insanity that comes from inconsistent usage of a
single field (for example retrieve both int[] and DocTermIndex for the same
field).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3140) Make omitNorms default for all numeric field types
[ https://issues.apache.org/jira/browse/SOLR-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218600#comment-13218600 ] Tommaso Teofili commented on SOLR-3140: --- yes big +1 Make omitNorms default for all numeric field types -- Key: SOLR-3140 URL: https://issues.apache.org/jira/browse/SOLR-3140 Project: Solr Issue Type: Improvement Components: Schema and Analysis Reporter: Jan Høydahl Labels: omitNorms Fix For: 4.0 Today norms are enabled for all Solr field types by default, while in Lucene norms are omitted for the numeric types. Propose to make the Solr defaults the same as in Lucene, so that if someone occasionally wants index-side boost for a numeric field type they must say omitNorms=false. This lets us simplify the example schema too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3174) Visualize Cluster State
[ https://issues.apache.org/jira/browse/SOLR-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218602#comment-13218602 ] Tommaso Teofili commented on SOLR-3174: --- yes this'd be a very nice improvement Visualize Cluster State --- Key: SOLR-3174 URL: https://issues.apache.org/jira/browse/SOLR-3174 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley It would be great to visualize the cluster state in the new UI. See Mark's wish: https://issues.apache.org/jira/browse/SOLR-3162?focusedCommentId=13218272page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13218272 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
DocValues for FieldCache API?
The DocValues.Source API looks straight forward for int/float/bytes; what are the thoughts on other types? How would we get double values? Or a general Object like Shape (for spatial queries) Is there (or should there be) any relation to FunctionValues? ryan - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3820) Wrong trailing index calculation in PatternReplaceCharFilter
[ https://issues.apache.org/jira/browse/LUCENE-3820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-3820. Resolution: Fixed Thanks Dawid! Wrong trailing index calculation in PatternReplaceCharFilter Key: LUCENE-3820 URL: https://issues.apache.org/jira/browse/LUCENE-3820 Project: Lucene - Java Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3820.patch, LUCENE-3820.patch, LUCENE-3820_test.patch, LUCENE-3820_test.patch Reimplementation of PatternReplaceCharFilter to pass randomized tests (used to throw exceptions previously). Simplified code, dropped boundary characters, full input buffered for pattern matching. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3829) Lucene40 codec's DocValues DirectSource impls aren't thread-safe
[ https://issues.apache.org/jira/browse/LUCENE-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-3829. Resolution: Invalid Duh, thanks Simon ;) Once I fixed the test to use the API correctly, it passes! Lucene40 codec's DocValues DirectSource impls aren't thread-safe Key: LUCENE-3829 URL: https://issues.apache.org/jira/browse/LUCENE-3829 Project: Lucene - Java Issue Type: Bug Reporter: Michael McCandless Fix For: 4.0 Attachments: LUCENE-3829.patch Our DirectSource impls hold IndexInput(s) open against the dat/idx files, which we then seek + read when loading a specific document's value. But this is in no way protected against multiple threads I think...? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3824) TermOrdVal/DocValuesComparator does too much work in compareBottom
[ https://issues.apache.org/jira/browse/LUCENE-3824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-3824. Resolution: Fixed TermOrdVal/DocValuesComparator does too much work in compareBottom -- Key: LUCENE-3824 URL: https://issues.apache.org/jira/browse/LUCENE-3824 Project: Lucene - Java Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Priority: Minor Fix For: 3.6, 4.0 Attachments: LUCENE-3824.patch We now have logic to fall back to by-value comparison, when the bottom slot is not from the current reader. But this is silly, because if the bottom slot is from a different reader, it means the tie-break case is not possible (since the current reader didn't have the bottom value), so when the incoming ord equals the bottom ord we should always return x 0. I added a new random string sort test case to TestSort... I also renamed DocValues.SortedSource.getByValue - getOrdByValue and cleaned up some whitespace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3767) Explore streaming Viterbi search in Kuromoji
[ https://issues.apache.org/jira/browse/LUCENE-3767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-3767: --- Attachment: LUCENE-3767.patch New patch, fixing the exc Christian found: the 2nd best search was corrupting the bestIDX on the backtrace in the case where a compound wasn't selected. I also set a limit on the max UNK word length, and pulled the limits into static final private constants. I was able to parse the 2012/02/20 jaenwiki export with this (see commented out test case in TestKuromojiTokenizer). I think it's ready (again!). Explore streaming Viterbi search in Kuromoji Key: LUCENE-3767 URL: https://issues.apache.org/jira/browse/LUCENE-3767 Project: Lucene - Java Issue Type: Improvement Components: modules/analysis Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 3.6, 4.0 Attachments: LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch, LUCENE-3767.patch, SolrXml-5498.xml, compound_diffs.txt I've been playing with the idea of changing the Kuromoji viterbi search to be 2 passes (intersect, backtrace) instead of 4 passes (break into sentences, intersect, score, backtrace)... this is very much a work in progress, so I'm just getting my current state up. It's got tons of nocommits, doesn't properly handle the user dict nor extended modes yet, etc. One thing I'm playing with is to add a double backtrace for the long compound tokens, ie, instead of penalizing these tokens so that shorter tokens are picked, leave the scores unchanged but on backtrace take that penalty and use it as a threshold for a 2nd best segmentation... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3165) Cannot use DIH in Solrcloud + Zookeeper
[
https://issues.apache.org/jira/browse/SOLR-3165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Serba updated SOLR-3165:
---
Attachment: SOLR-3165.patch
I updated Sami's patch to store dataimport property file under collection
directory in zk and name it after data import handler (the same way it is
stored in local filesystem)
Cannot use DIH in Solrcloud + Zookeeper
---
Key: SOLR-3165
URL: https://issues.apache.org/jira/browse/SOLR-3165
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 4.0
Reporter: Agnieszka
Attachments: SOLR-3165.patch, SOLR-3165.patch
There is a problem with configure DIH in Solrcloud + Zookeeper configuration
from wiki:
http://wiki.apache.org/solr/SolrCloud.
Standard configuration in solrconfig.xml:
{code:xml}
requestHandler name=/dataimport
class=org.apache.solr.handler.dataimport.DataImportHandler
lst name=defaults
str name=configdb-data-config.xml/str
/lst
/requestHandler
{code}
After starting solr with zookeeper I've got errors:
{noformat}
Feb 20, 2012 11:30:12 AM org.apache.solr.common.SolrException log
SEVERE: null:org.apache.solr.common.SolrException
at org.apache.solr.core.SolrCore.init(SolrCore.java:606)
at org.apache.solr.core.SolrCore.init(SolrCore.java:490)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:705)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:442)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:313)
at
org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:262)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:98)
at
org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at
org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1282)
at
org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518)
at
org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:499)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at
org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:224)
at
org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:985)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.mortbay.start.Main.invokeMain(Main.java:194)
at org.mortbay.start.Main.start(Main.java:534)
at org.mortbay.start.Main.start(Main.java:441)
at org.mortbay.start.Main.main(Main.java:119)
Caused by: org.apache.solr.common.SolrException: FATAL: Could not create
importer. DataImporter config invalid
at
org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImportHandler.java:120)
at
org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:542)
at org.apache.solr.core.SolrCore.init(SolrCore.java:601)
... 31 more
Caused by: org.apache.solr.common.cloud.ZooKeeperException:
ZkSolrResourceLoader does not support getConfigDir() - likely, w
at
org.apache.solr.cloud.ZkSolrResourceLoader.getConfigDir(ZkSolrResourceLoader.java:99)
at
org.apache.solr.handler.dataimport.SimplePropertiesWriter.init(SimplePropertiesWriter.java:47)
at
org.apache.solr.handler.dataimport.DataImporter.init(DataImporter.java:112)
at
org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImportHandler.java:114)
... 33 more
{noformat}
But the db-data-config.xml file exists in Zookeeper:
{noformat}
[zk:
[jira] [Commented] (SOLR-3157) custom logging
[ https://issues.apache.org/jira/browse/SOLR-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218704#comment-13218704 ] Yonik Seeley commented on SOLR-3157: Log format changes seem a lot less important than actual request/response formats? IMO, it's actually higher importance that we have better logging for ourselves so we can more easily debug our tests. Maybe there's a way I can log different things when using the test formatter and restore the production log format to it's former glory. custom logging -- Key: SOLR-3157 URL: https://issues.apache.org/jira/browse/SOLR-3157 Project: Solr Issue Type: Test Reporter: Yonik Seeley Priority: Blocker Attachments: SOLR-3157.patch, jetty_threadgroup.patch We need custom logging to decipher tests with multiple core containers, cores, in a single JVM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3825) Please push maven snapshots to repositories.apache.org again
[ https://issues.apache.org/jira/browse/LUCENE-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218764#comment-13218764 ] Benson Margulies commented on LUCENE-3825: -- Is the result of this blocked on the jail break? :-) Please push maven snapshots to repositories.apache.org again Key: LUCENE-3825 URL: https://issues.apache.org/jira/browse/LUCENE-3825 Project: Lucene - Java Issue Type: Improvement Components: general/build Affects Versions: 4.0 Reporter: Benson Margulies Attachments: LUCENE-3825-add-scm-to-poms-trunk.patch Once upon a time, snapshots of the lucene trunk went into the snapshot repo at repositories.apache.org. No longer. Instead, they just sit at: https://builds.apache.org//job/Lucene-Solr-Maven-trunk/lastSuccessfulBuild/artifact/maven_artifacts/ Unfortunately, Jenkins makes a rather mediocre maven repo. the maven-wagon-plugin can't copy it and Nexus can't proxy it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3825) Please push maven snapshots to repositories.apache.org again
[ https://issues.apache.org/jira/browse/LUCENE-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218776#comment-13218776 ] Steven Rowe commented on LUCENE-3825: - bq. Is the result of this blocked on the jail break? :) I don't know what you mean by jail break? I'm waiting for someone to enable Nexus access for Lucene: INFRA-4497 - I had planned to hassle them after a week had gone by with no action (it's only been a day or two so far). Please push maven snapshots to repositories.apache.org again Key: LUCENE-3825 URL: https://issues.apache.org/jira/browse/LUCENE-3825 Project: Lucene - Java Issue Type: Improvement Components: general/build Affects Versions: 4.0 Reporter: Benson Margulies Attachments: LUCENE-3825-add-scm-to-poms-trunk.patch Once upon a time, snapshots of the lucene trunk went into the snapshot repo at repositories.apache.org. No longer. Instead, they just sit at: https://builds.apache.org//job/Lucene-Solr-Maven-trunk/lastSuccessfulBuild/artifact/maven_artifacts/ Unfortunately, Jenkins makes a rather mediocre maven repo. the maven-wagon-plugin can't copy it and Nexus can't proxy it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3825) Please push maven snapshots to repositories.apache.org again
[ https://issues.apache.org/jira/browse/LUCENE-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218780#comment-13218780 ] Benson Margulies commented on LUCENE-3825: -- I was referring to Uwe's email about stopping all builds due to 1.6 versus 1.6 issues in the jail. Please push maven snapshots to repositories.apache.org again Key: LUCENE-3825 URL: https://issues.apache.org/jira/browse/LUCENE-3825 Project: Lucene - Java Issue Type: Improvement Components: general/build Affects Versions: 4.0 Reporter: Benson Margulies Attachments: LUCENE-3825-add-scm-to-poms-trunk.patch Once upon a time, snapshots of the lucene trunk went into the snapshot repo at repositories.apache.org. No longer. Instead, they just sit at: https://builds.apache.org//job/Lucene-Solr-Maven-trunk/lastSuccessfulBuild/artifact/maven_artifacts/ Unfortunately, Jenkins makes a rather mediocre maven repo. the maven-wagon-plugin can't copy it and Nexus can't proxy it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3825) Please push maven snapshots to repositories.apache.org again
[ https://issues.apache.org/jira/browse/LUCENE-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13218781#comment-13218781 ] Benson Margulies commented on LUCENE-3825: -- Not that it's especially my business, but how did the snapshots get pushed historically to nexus if you didn't have access to nexus? Please push maven snapshots to repositories.apache.org again Key: LUCENE-3825 URL: https://issues.apache.org/jira/browse/LUCENE-3825 Project: Lucene - Java Issue Type: Improvement Components: general/build Affects Versions: 4.0 Reporter: Benson Margulies Attachments: LUCENE-3825-add-scm-to-poms-trunk.patch Once upon a time, snapshots of the lucene trunk went into the snapshot repo at repositories.apache.org. No longer. Instead, they just sit at: https://builds.apache.org//job/Lucene-Solr-Maven-trunk/lastSuccessfulBuild/artifact/maven_artifacts/ Unfortunately, Jenkins makes a rather mediocre maven repo. the maven-wagon-plugin can't copy it and Nexus can't proxy it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
