[jira] Commented: (SOLR-1873) Commit Solr Cloud to trunk
[ https://issues.apache.org/jira/browse/SOLR-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12856087#action_12856087 ] Mark Miller commented on SOLR-1873: --- As I wrap up the remaining work here, one issue looms: We are going to need to move Hudson to Java 6 before this can be committed. > Commit Solr Cloud to trunk > -- > > Key: SOLR-1873 > URL: https://issues.apache.org/jira/browse/SOLR-1873 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 > Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: log4j-over-slf4j-1.5.5.jar, SOLR-1873.patch, > SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, zookeeper-3.2.2.jar > > > This is a real hassle - I didn't merge up to trunk before all the svn > scrambling, so integrating cloud is now a bit difficult. I'm running through > and just preparing a commit by hand though (applying changes/handling > conflicts a file at a time). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SOLR-632) Upgrade bundled Jetty with latest from vendor
[ https://issues.apache.org/jira/browse/SOLR-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-632. -- Assignee: Mark Miller (was: Erik Hatcher) Resolution: Fixed I'm going to call this done - we are now on 6.1.22 - though now 6.1.23 is out :) > Upgrade bundled Jetty with latest from vendor > - > > Key: SOLR-632 > URL: https://issues.apache.org/jira/browse/SOLR-632 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Norberto Meijome >Assignee: Mark Miller >Priority: Minor > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > The Jetty that is bundled for the example application is version 6.1.3, which > is over a year old. > We should upgrade Jetty to the latest, 6.1.11. > I am not sure how to attach a patch to remove files, so these are the steps : > Using as base the root of 'apache-solr-nightly': > DELETE: > example/lib/jetty-6.1.3.jar > example/lib/jetty-util-6.1.3.jar > example/lib/servlet-api-2.5-6.1.3.jar > ADD > example/lib/jetty-6.1.11.jar > example/lib/jetty-util-6.1.11.jar > example/lib/servlet-api-2.5-6.1.11.jar > --- > The files to be added can be found in Jetty's binary distribution file : > http://dist.codehaus.org/jetty/jetty-6.1.11/jetty-6.1.11.zip > I couldn't find any noticeable changes in jetty.xml that should be carried > over. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-1873) Commit Solr Cloud to trunk
[ https://issues.apache.org/jira/browse/SOLR-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1873: -- Attachment: SOLR-1873.patch I had missed merging necessary changes to QueryElevation component - this patch adds that piece as well as resolves a good chunk of nocommit issues. > Commit Solr Cloud to trunk > -- > > Key: SOLR-1873 > URL: https://issues.apache.org/jira/browse/SOLR-1873 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 > Reporter: Mark Miller > Assignee: Mark Miller > Fix For: 1.5 > > Attachments: log4j-over-slf4j-1.5.5.jar, SOLR-1873.patch, > SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, zookeeper-3.2.2.jar > > > This is a real hassle - I didn't merge up to trunk before all the svn > scrambling, so integrating cloud is now a bit difficult. I'm running through > and just preparing a commit by hand though (applying changes/handling > conflicts a file at a time). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SOLR-1327) Allow special Filters to access, modify, and/or add Fields to/on a Solr Document
[ https://issues.apache.org/jira/browse/SOLR-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-1327. --- Fix Version/s: (was: 1.5) Resolution: Duplicate > Allow special Filters to access, modify, and/or add Fields to/on a Solr > Document > > > Key: SOLR-1327 > URL: https://issues.apache.org/jira/browse/SOLR-1327 > Project: Solr > Issue Type: New Feature > Reporter: Mark Miller >Priority: Minor > > Add a special Filter type that causes the field its in to be pre-analyzed - > when this happens, the Filter can work with the Solr Document and modify it > based on the tokens it sees. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SOLR-1436) Consider changing multi-term queries to use CONSTANT_SCORE_AUTO_REWRITE_DEFAULT
[ https://issues.apache.org/jira/browse/SOLR-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-1436. --- Assignee: Mark Miller Resolution: Fixed Hmm...the description of this is messed up - anyway, I just looked and I actually did this months ago - must have forgotten about the issue. > Consider changing multi-term queries to use > CONSTANT_SCORE_AUTO_REWRITE_DEFAULT > > > Key: SOLR-1436 > URL: https://issues.apache.org/jira/browse/SOLR-1436 > Project: Solr > Issue Type: Improvement > Reporter: Mark Miller > Assignee: Mark Miller >Priority: Minor > > They are CONSTANT_SCORE_AUTO_REWRITE_DEFAULT now, but > ConstantScoreBooleanQueryRewrite can be faster and > CONSTANT_SCORE_AUTO_REWRITE_DEFAULT is likely the best setting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-1851) luceneAutoCommit no longer has any effect - remove it from config
[ https://issues.apache.org/jira/browse/SOLR-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855781#action_12855781 ] Mark Miller commented on SOLR-1851: --- I didnt take the setting out solr/contrib/dataimporthandler/src/test/resources/solr/conf/ dataimport-solrconfig.xml , because I cannot seem to update that file. > luceneAutoCommit no longer has any effect - remove it from config > - > > Key: SOLR-1851 > URL: https://issues.apache.org/jira/browse/SOLR-1851 > Project: Solr > Issue Type: Bug > Reporter: Mark Miller > Assignee: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1851.patch > > > missed this on the upgrade to Lucene trunk - Lucene no longer has autocommit > - so it now has no effect in Solr - needs to be removed with a warning if its > found. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SOLR-1534) Remove QueryWrapper
[ https://issues.apache.org/jira/browse/SOLR-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-1534. --- Resolution: Fixed did this some time ago > Remove QueryWrapper > --- > > Key: SOLR-1534 > URL: https://issues.apache.org/jira/browse/SOLR-1534 > Project: Solr > Issue Type: Task > Reporter: Mark Miller >Priority: Minor > Attachments: SOLR-1534.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SOLR-1851) luceneAutoCommit no longer has any effect - remove it from config
[ https://issues.apache.org/jira/browse/SOLR-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-1851. --- Resolution: Fixed > luceneAutoCommit no longer has any effect - remove it from config > - > > Key: SOLR-1851 > URL: https://issues.apache.org/jira/browse/SOLR-1851 > Project: Solr > Issue Type: Bug > Reporter: Mark Miller > Assignee: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1851.patch > > > missed this on the upgrade to Lucene trunk - Lucene no longer has autocommit > - so it now has no effect in Solr - needs to be removed with a warning if its > found. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SOLR-1873) Commit Solr Cloud to trunk
[ https://issues.apache.org/jira/browse/SOLR-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855765#action_12855765 ] Mark Miller edited comment on SOLR-1873 at 4/11/10 5:14 PM: Up to trunk and clean up some tests...all tests pass but nocommits remain. was (Author: markrmil...@gmail.com): Up to trunk and clean up some tests...all tests pass but commits remain. > Commit Solr Cloud to trunk > -- > > Key: SOLR-1873 > URL: https://issues.apache.org/jira/browse/SOLR-1873 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 > Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: log4j-over-slf4j-1.5.5.jar, SOLR-1873.patch, > SOLR-1873.patch, SOLR-1873.patch, zookeeper-3.2.2.jar > > > This is a real hassle - I didn't merge up to trunk before all the svn > scrambling, so integrating cloud is now a bit difficult. I'm running through > and just preparing a commit by hand though (applying changes/handling > conflicts a file at a time). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-1873) Commit Solr Cloud to trunk
[ https://issues.apache.org/jira/browse/SOLR-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1873: -- Attachment: SOLR-1873.patch Up to trunk and clean up some tests...all tests pass but commits remain. > Commit Solr Cloud to trunk > -- > > Key: SOLR-1873 > URL: https://issues.apache.org/jira/browse/SOLR-1873 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 > Reporter: Mark Miller > Assignee: Mark Miller > Fix For: 1.5 > > Attachments: log4j-over-slf4j-1.5.5.jar, SOLR-1873.patch, > SOLR-1873.patch, SOLR-1873.patch, zookeeper-3.2.2.jar > > > This is a real hassle - I didn't merge up to trunk before all the svn > scrambling, so integrating cloud is now a bit difficult. I'm running through > and just preparing a commit by hand though (applying changes/handling > conflicts a file at a time). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SOLR-1839) If the stress tests in BaseDistributedSearchTestCase fail, the test still passes
[ https://issues.apache.org/jira/browse/SOLR-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-1839. --- Assignee: Mark Miller Resolution: Fixed > If the stress tests in BaseDistributedSearchTestCase fail, the test still > passes > > > Key: SOLR-1839 > URL: https://issues.apache.org/jira/browse/SOLR-1839 > Project: Solr > Issue Type: Bug > Reporter: Mark Miller > Assignee: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1839.patch > > > In the past, you would not likely notice these failures at all - as they > would not be printed to the console, but rather just go to the test-results. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SOLR-1840) DistributedSpellCheckComponentTest appears to actually fail under the stress test
[ https://issues.apache.org/jira/browse/SOLR-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-1840. --- Assignee: Mark Miller Resolution: Fixed > DistributedSpellCheckComponentTest appears to actually fail under the stress > test > - > > Key: SOLR-1840 > URL: https://issues.apache.org/jira/browse/SOLR-1840 > Project: Solr > Issue Type: Bug > Components: spellchecker > Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1840.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-1840) DistributedSpellCheckComponentTest appears to actually fail under the stress test
[ https://issues.apache.org/jira/browse/SOLR-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1840: -- Attachment: SOLR-1840.patch Because each query would trigger a spellcheck index rebuild, the test was stomping all over itself during the stress test. This patch fixes that, and has the code for the attached issue so that these failures will cause junit test failures as the should in the future. > DistributedSpellCheckComponentTest appears to actually fail under the stress > test > - > > Key: SOLR-1840 > URL: https://issues.apache.org/jira/browse/SOLR-1840 > Project: Solr > Issue Type: Bug > Components: spellchecker > Reporter: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1840.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SOLR-1877) Investigate unclosed Reader in IndexBasedSpellCheck
Investigate unclosed Reader in IndexBasedSpellCheck --- Key: SOLR-1877 URL: https://issues.apache.org/jira/browse/SOLR-1877 Project: Solr Issue Type: Bug Reporter: Mark Miller Priority: Minor Fix For: 1.5 Looks like IndexBasedSpellcheck creates a Reader that it passes to HighFrequencyDictionary that never gets closed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-1877) Investigate unclosed Reader in IndexBasedSpellCheck
[ https://issues.apache.org/jira/browse/SOLR-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1877: -- Component/s: spellchecker > Investigate unclosed Reader in IndexBasedSpellCheck > --- > > Key: SOLR-1877 > URL: https://issues.apache.org/jira/browse/SOLR-1877 > Project: Solr > Issue Type: Bug > Components: spellchecker > Reporter: Mark Miller >Priority: Minor > Fix For: 1.5 > > > Looks like IndexBasedSpellcheck creates a Reader that it passes to > HighFrequencyDictionary that never gets closed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SOLR-1873) Commit Solr Cloud to trunk
[ https://issues.apache.org/jira/browse/SOLR-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855662#action_12855662 ] Mark Miller commented on SOLR-1873: --- Sweet - all tests now pass - done to just the nocommits. > Commit Solr Cloud to trunk > -- > > Key: SOLR-1873 > URL: https://issues.apache.org/jira/browse/SOLR-1873 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 > Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: log4j-over-slf4j-1.5.5.jar, SOLR-1873.patch, > SOLR-1873.patch, zookeeper-3.2.2.jar > > > This is a real hassle - I didn't merge up to trunk before all the svn > scrambling, so integrating cloud is now a bit difficult. I'm running through > and just preparing a commit by hand though (applying changes/handling > conflicts a file at a time). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-1873) Commit Solr Cloud to trunk
[ https://issues.apache.org/jira/browse/SOLR-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1873: -- Attachment: SOLR-1873.patch fixes the distrib spellcheck failure > Commit Solr Cloud to trunk > -- > > Key: SOLR-1873 > URL: https://issues.apache.org/jira/browse/SOLR-1873 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 > Reporter: Mark Miller > Assignee: Mark Miller > Fix For: 1.5 > > Attachments: log4j-over-slf4j-1.5.5.jar, SOLR-1873.patch, > SOLR-1873.patch, zookeeper-3.2.2.jar > > > This is a real hassle - I didn't merge up to trunk before all the svn > scrambling, so integrating cloud is now a bit difficult. I'm running through > and just preparing a commit by hand though (applying changes/handling > conflicts a file at a time). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-1873) Commit Solr Cloud to trunk
[ https://issues.apache.org/jira/browse/SOLR-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1873: -- Attachment: zookeeper-3.2.2.jar log4j-over-slf4j-1.5.5.jar > Commit Solr Cloud to trunk > -- > > Key: SOLR-1873 > URL: https://issues.apache.org/jira/browse/SOLR-1873 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 > Reporter: Mark Miller > Assignee: Mark Miller > Fix For: 1.5 > > Attachments: log4j-over-slf4j-1.5.5.jar, SOLR-1873.patch, > zookeeper-3.2.2.jar > > > This is a real hassle - I didn't merge up to trunk before all the svn > scrambling, so integrating cloud is now a bit difficult. I'm running through > and just preparing a commit by hand though (applying changes/handling > conflicts a file at a time). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SOLR-1873) Commit Solr Cloud to trunk
[ https://issues.apache.org/jira/browse/SOLR-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1873: -- Attachment: SOLR-1873.patch Still a lot to do, but after a couple days work, getting pretty close. left: a bunch of nocommits I've added Distrib spelleck and Distrib TermsComponent do not pass tests > Commit Solr Cloud to trunk > -- > > Key: SOLR-1873 > URL: https://issues.apache.org/jira/browse/SOLR-1873 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 > Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1873.patch > > > This is a real hassle - I didn't merge up to trunk before all the svn > scrambling, so integrating cloud is now a bit difficult. I'm running through > and just preparing a commit by hand though (applying changes/handling > conflicts a file at a time). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SOLR-1873) Commit Solr Cloud to trunk
Commit Solr Cloud to trunk -- Key: SOLR-1873 URL: https://issues.apache.org/jira/browse/SOLR-1873 Project: Solr Issue Type: New Feature Affects Versions: 1.4 Reporter: Mark Miller Assignee: Mark Miller Fix For: 1.5 This is a real hassle - I didn't merge up to trunk before all the svn scrambling, so integrating cloud is now a bit difficult. I'm running through and just preparing a commit by hand though (applying changes/handling conflicts a file at a time). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1238) exception in solrJ when authentication is used
[
https://issues.apache.org/jira/browse/SOLR-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855127#action_12855127
]
Mark Miller commented on SOLR-1238:
---
isRepeatable means the payload stream can be read more than once. This can be
necessary due to authentication and io errors. It doesn't mean that if you send
an index command and it fails in Solr that the index command will be sent
again. This is at the HTTP layer.
It also doesn't mean, please do retries - it simply means that the data can be
read more than once, so you can do what's appropriate (retrying on re-triable
errors) rather than failing with this exception - many times you can not reread
a stream unless you provide a mechanism to get a fresh stream.
Basically - I'm not seeing the problem you are about retries.
What is possibly happening here:
The HTTPClient sends the request with the payload, which gets read - but its an
authenticated zone, so the client is challenged - it responds again with the
username/password and the payload - which fails on the next read. Thats just a
guess. Perhaps its just an authentication/io anomaly that a retry is often used
to correct.
Based on the info I have though, I'm not convinced that failing and reporting
the error is the right way to go.
> exception in solrJ when authentication is used
> --
>
> Key: SOLR-1238
> URL: https://issues.apache.org/jira/browse/SOLR-1238
> Project: Solr
> Issue Type: Bug
> Components: clients - java
>Affects Versions: 1.3
>Reporter: Noble Paul
>Priority: Minor
> Attachments: SOLR-1238.patch
>
>
> see the thread http://markmail.org/thread/w36ih2fnphbubian
> {code}
> I am facing getting error when I am using Authentication in Solr. I
> followed Wiki. The error doesnot appear when I searching. Below is the
> code snippet and the error.
> Please note I am using Solr 1.4 Development build from SVN.
>HttpClient client=new HttpClient();
>AuthScope scope = new
> AuthScope(AuthScope.ANY_HOST,AuthScope.ANY_PORT,null, null);
>client.getState().setCredentials(scope,new
> UsernamePasswordCredentials("guest", "guest"));
>SolrServer server =new
> CommonsHttpSolrServer("http://localhost:8983/solr",client);
>SolrInputDocument doc1=new SolrInputDocument();
>//Add fields to the document
>doc1.addField("employeeid", "1237");
>doc1.addField("employeename", "Ann");
>doc1.addField("employeeunit", "etc");
>doc1.addField("employeedoj", "1995-11-31T23:59:59Z");
>server.add(doc1);
> Exception in thread "main"
> org.apache.solr.client.solrj.SolrServerException:
> org.apache.commons.httpclient.ProtocolException: Unbuffered entity
> enclosing request can not be repeated.
>at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:468)
>at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:242)
>at
> org.apache.solr.client.solrj.request.UpdateRequest.process(UpdateRequest.java:259)
>at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:63)
>at test.SolrAuthenticationTest.(SolrAuthenticationTest.java:49)
>at test.SolrAuthenticationTest.main(SolrAuthenticationTest.java:113)
> Caused by: org.apache.commons.httpclient.ProtocolException: Unbuffered
> entity enclosing request can not be repeated.
>at
> org.apache.commons.httpclient.methods.EntityEnclosingMethod.writeRequestBody(EntityEnclosingMethod.java:487)
>at
> org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114)
>at
> org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)
>at
> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
>at
> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
>at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
>at
> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
>at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:415)
>... 5 more.
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Merging Solr Cloud into trunk
I'd like to merge solr cloud into trunk - I think there may be some more polish to do, but its pretty close, and back compatible if you choose not to run in "zookeeper" mode. I think the next step for this first phase (there are still many features to add) is to get it in trunk so we can get some wider use / feedback. Its time to start baking this thing at a hotter temp. Thoughts? -- - Mark http://www.lucidimagination.com
FYI: Solr Trunk To be Very Briefly Broken
FYI: Uwe is going to merge the Lucene flex branch soon, and as a result, Solr trunk will very briefly have an issue: https://issues.apache.org/jira/browse/LUCENE-2370 -- - Mark http://www.lucidimagination.com
[jira] Updated: (SOLR-1866) Test bug - JettyWebappTest: plugin classes do not have access to webapp libs
[ https://issues.apache.org/jira/browse/SOLR-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1866: -- Attachment: SOLR-1866.patch Another possible fix. Simple - but includes some libs that don't actually end up in the webapp as it uses all the libs in /lib > Test bug - JettyWebappTest: plugin classes do not have access to webapp libs > > > Key: SOLR-1866 > URL: https://issues.apache.org/jira/browse/SOLR-1866 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Priority: Minor > Attachments: SOLR-1866.patch > > > The JettyWebappTest straddles example and src/webapp in a way that the Plugin > classloader's parent WebappClassloader points to src/webapp which has no libs > dir. This can cause problems - eg its a problem with the current velocity > setup - though the issue has been skirted by removing slf logging references. > Probably the best solution is to run off the webapp - but I wonder if its > worth depending on building the webapp for tests when all of them don't need > it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1866) Test bug - JettyWebappTest: plugin classes do not have access to webapp libs
Test bug - JettyWebappTest: plugin classes do not have access to webapp libs Key: SOLR-1866 URL: https://issues.apache.org/jira/browse/SOLR-1866 Project: Solr Issue Type: Bug Reporter: Mark Miller Priority: Minor The JettyWebappTest straddles example and src/webapp in a way that the Plugin classloader's parent WebappClassloader points to src/webapp which has no libs dir. This can cause problems - eg its a problem with the current velocity setup - though the issue has been skirted by removing slf logging references. Probably the best solution is to run off the webapp - but I wonder if its worth depending on building the webapp for tests when all of them don't need it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1801) Delete record by id which is inserted using dedupe processor
[ https://issues.apache.org/jira/browse/SOLR-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1801: -- Issue Type: Improvement (was: Bug) Not sure if it was this guy or not, but someone was on the user list with this in the past - Rather than a bug, I think they were looking for an improvement - getting the id back on posting a document when that id is generated (say by the dedupe processor). This is actually somewhat standard behavior for a REST POST call. You can always make the signature field something other than the id field though. Not always ideal, but one option. > Delete record by id which is inserted using dedupe processor > > > Key: SOLR-1801 > URL: https://issues.apache.org/jira/browse/SOLR-1801 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.4 >Reporter: Subroto Sanyal > Fix For: 1.5 > > > A record added with unique key generated by dedupe processor can't be deleted > using "delete by id" as the id is generated by hashing and is unknown to the > user. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1659) Get off deprecated Lucene API's to clear the way for a move to Lucene 3.0 +
[ https://issues.apache.org/jira/browse/SOLR-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-1659. --- Resolution: Fixed this is resolved on the new merged lucene/solr trunk (part of first update) > Get off deprecated Lucene API's to clear the way for a move to Lucene 3.0 + > --- > > Key: SOLR-1659 > URL: https://issues.apache.org/jira/browse/SOLR-1659 > Project: Solr > Issue Type: Task >Reporter: Mark Miller > Attachments: SOLR-1659.patch, SOLR-1659.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1851) luceneAutoCommit no longer has any effect - remove it from config
[ https://issues.apache.org/jira/browse/SOLR-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1851: -- Attachment: SOLR-1851.patch > luceneAutoCommit no longer has any effect - remove it from config > - > > Key: SOLR-1851 > URL: https://issues.apache.org/jira/browse/SOLR-1851 > Project: Solr > Issue Type: Bug > Reporter: Mark Miller > Assignee: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1851.patch > > > missed this on the upgrade to Lucene trunk - Lucene no longer has autocommit > - so it now has no effect in Solr - needs to be removed with a warning if its > found. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1851) luceneAutoCommit no longer has any effect - remove it from config
luceneAutoCommit no longer has any effect - remove it from config - Key: SOLR-1851 URL: https://issues.apache.org/jira/browse/SOLR-1851 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 1.5 missed this on the upgrade to Lucene trunk - Lucene no longer has autocommit - so it now has no effect in Solr - needs to be removed with a warning if its found. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-896) Solr Query Parser Plugin for Mark Miller's Qsol Parser
[ https://issues.apache.org/jira/browse/SOLR-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850539#action_12850539 ] Mark Miller commented on SOLR-896: -- Yeah, I'll try and do that soon. Chris was thinking about taking it and putting it up on google code, but not sure where he is with that idea. > Solr Query Parser Plugin for Mark Miller's Qsol Parser > -- > > Key: SOLR-896 > URL: https://issues.apache.org/jira/browse/SOLR-896 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Chris Harris > Attachments: SOLR-896.patch, SOLR-896.patch > > > An extremely basic plugin to get the Qsol query parser > (http://www.myhardshadow.com/qsol.php) working in Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: build.xml and lucene test code
Yeah, there are things we can do to improve some of this (uptodatetask or something?) - Uwe has some ideas the other day. - Mark http://www.lucidimagination.com (mobile) On Mar 26, 2010, at 1:53 AM, Robert Muir wrote: I noticed that for whatever reason, solr's build.xml doesnt detect if lucene's test code is out of date. (I am fooling around with LUCENE-1709 where we will try to do the same parallel test execution for Lucene, as in Solr, and was moving the special formatter to lucene when i noticed this). Don't have any ideas how to fix, but just wanted to mention it so its not forgotten. worst case, if/when we resolve LUCENE-1709, you will have to run ant clean first... but I am sure there is some better ant trickery to detect this situation, maybe just another task dependency. -- Robert Muir rcm...@gmail.com
Re: ZooKeeper Logging
On 03/25/2010 11:27 AM, Mark Miller wrote: On 03/25/2010 11:22 AM, Igor Motov wrote: I wonder if it would make sense to replace log4j-1.2.15.jar in the lib directory of the cloud branch with log4j-over-slf4j-1.5.5.jar. SOLR is already using SLF4J for its logging and log4j-over-slf4j bridge would redirect all ZooKeeper log messages into the same SLF4J logging stream. I did it in my setup and and it helped me a lot when I ran into issues with my ZooKeeper configuration. Thank you, Igor Yeah, this is a great idea - been meaning to look into this since Uwe mentioned to me that it was possible the other week. Hadn't realized these bridge jars existed previously. Yonik had started looking into getting the ZooKeeper project to switch to SLF4J, but this is a great solution for now. Hmm - I've done this for now - but this is going to need some good documentation at the least. It works great for Solr in it's default state (using util logging) - but you don't want this jar if you choose to use the log4j connector. Otherwise they loop back and forth with each other. -- - Mark http://www.lucidimagination.com
Re: ZooKeeper Logging
On 03/25/2010 11:22 AM, Igor Motov wrote: I wonder if it would make sense to replace log4j-1.2.15.jar in the lib directory of the cloud branch with log4j-over-slf4j-1.5.5.jar. SOLR is already using SLF4J for its logging and log4j-over-slf4j bridge would redirect all ZooKeeper log messages into the same SLF4J logging stream. I did it in my setup and and it helped me a lot when I ran into issues with my ZooKeeper configuration. Thank you, Igor Yeah, this is a great idea - been meaning to look into this since Uwe mentioned to me that it was possible the other week. Hadn't realized these bridge jars existed previously. Yonik had started looking into getting the ZooKeeper project to switch to SLF4J, but this is a great solution for now. -- - Mark http://www.lucidimagination.com
Re: CloudSolrServer dependency on ZkController in the cloud branch
On 03/24/2010 06:43 PM, Igor Motov wrote: I was experimenting with the latest (r919455) revision of the cloud branch and noticed a dependency between CloudSolrServer and ZkController. It looks like CloudSolrServer is still using two constants from ZkController: NODE_NAME and URL_PROP. After moving these two constants to ZkStateReader, I was able to remove the following line from build.xml and successfully rebuild the project: I can submit a patch for this change. However, I am not sure if openning a bug in Jira would be the right way to contribute to the cloud branch. Thank you, Igor Thanks Igor! No need for a JIRA issue - I have just taken care of it! Very much appreciated. -- - Mark http://www.lucidimagination.com
[jira] Created: (SOLR-1840) DistributedSpellCheckComponentTest appears to actually fail under the stress test
DistributedSpellCheckComponentTest appears to actually fail under the stress test - Key: SOLR-1840 URL: https://issues.apache.org/jira/browse/SOLR-1840 Project: Solr Issue Type: Bug Components: spellchecker Reporter: Mark Miller Fix For: 1.5 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1840) DistributedSpellCheckComponentTest appears to actually fail under the stress test
[ https://issues.apache.org/jira/browse/SOLR-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848985#action_12848985 ] Mark Miller commented on SOLR-1840: --- The following exceptions were thrown by threads: [junit] *** Thread: Thread-12 *** [junit] junit.framework.AssertionFailedError: .spellcheck.suggestions.size()==0,1skipped=0,0 [junit] at junit.framework.Assert.fail(Assert.java:47) [junit] at org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:503) [junit] at org.apache.solr.BaseDistributedSearchTestCase$5.run(BaseDistributedSearchTestCase.java:271) [junit] *** Thread: Thread-21 *** [junit] junit.framework.AssertionFailedError: .spellcheck.suggestions.correctlySpelled!=toyata (unordered or missing) [junit] at junit.framework.Assert.fail(Assert.java:47) [junit] at org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:503) [junit] at org.apache.solr.BaseDistributedSearchTestCase$5.run(BaseDistributedSearchTestCase.java:271) [junit] *** Thread: Thread-20 *** [junit] junit.framework.AssertionFailedError: .spellcheck.suggestions.correctlySpelled!=toyata (unordered or missing) [junit] at junit.framework.Assert.fail(Assert.java:47) [junit] at org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:503) [junit] at org.apache.solr.BaseDistributedSearchTestCase$5.run(BaseDistributedSearchTestCase.java:271) [junit] *** Thread: Thread-22 *** [junit] junit.framework.AssertionFailedError: .spellcheck.suggestions.correctlySpelled!=bluo (unordered or missing) [junit] at junit.framework.Assert.fail(Assert.java:47) [junit] at org.apache.solr.BaseDistributedSearchTestCase.compareResponses(BaseDistributedSearchTestCase.java:503) [junit] at org.apache.solr.BaseDistributedSearchTestCase$5.run(BaseDistributedSearchTestCase.java:271) etc, etc, etc > DistributedSpellCheckComponentTest appears to actually fail under the stress > test > - > > Key: SOLR-1840 > URL: https://issues.apache.org/jira/browse/SOLR-1840 > Project: Solr > Issue Type: Bug > Components: spellchecker >Reporter: Mark Miller > Fix For: 1.5 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1840) DistributedSpellCheckComponentTest appears to actually fail under the stress test
[ https://issues.apache.org/jira/browse/SOLR-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848986#action_12848986 ] Mark Miller commented on SOLR-1840: --- See the linked issue to enable this test failure > DistributedSpellCheckComponentTest appears to actually fail under the stress > test > - > > Key: SOLR-1840 > URL: https://issues.apache.org/jira/browse/SOLR-1840 > Project: Solr > Issue Type: Bug > Components: spellchecker >Reporter: Mark Miller > Fix For: 1.5 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1839) If the stress tests in BaseDistributedSearchTestCase fail, the test still passes
[ https://issues.apache.org/jira/browse/SOLR-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1839: -- Attachment: SOLR-1839.patch This patch will expose the issue and the Distrib spelling component test will now fail > If the stress tests in BaseDistributedSearchTestCase fail, the test still > passes > > > Key: SOLR-1839 > URL: https://issues.apache.org/jira/browse/SOLR-1839 > Project: Solr > Issue Type: Bug > Reporter: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1839.patch > > > In the past, you would not likely notice these failures at all - as they > would not be printed to the console, but rather just go to the test-results. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1839) If the stress tests in BaseDistributedSearchTestCase fail, the test still passes
If the stress tests in BaseDistributedSearchTestCase fail, the test still passes Key: SOLR-1839 URL: https://issues.apache.org/jira/browse/SOLR-1839 Project: Solr Issue Type: Bug Reporter: Mark Miller Fix For: 1.5 In the past, you would not likely notice these failures at all - as they would not be printed to the console, but rather just go to the test-results. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-632) Upgrade bundled Jetty with latest from vendor
[ https://issues.apache.org/jira/browse/SOLR-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848332#action_12848332 ] Mark Miller commented on SOLR-632: -- I'm trying out this upgrade (to 6.1.22) on newtrunk - seems like a nice time to get this done > Upgrade bundled Jetty with latest from vendor > - > > Key: SOLR-632 > URL: https://issues.apache.org/jira/browse/SOLR-632 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Norberto Meijome >Assignee: Erik Hatcher >Priority: Minor > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > The Jetty that is bundled for the example application is version 6.1.3, which > is over a year old. > We should upgrade Jetty to the latest, 6.1.11. > I am not sure how to attach a patch to remove files, so these are the steps : > Using as base the root of 'apache-solr-nightly': > DELETE: > example/lib/jetty-6.1.3.jar > example/lib/jetty-util-6.1.3.jar > example/lib/servlet-api-2.5-6.1.3.jar > ADD > example/lib/jetty-6.1.11.jar > example/lib/jetty-util-6.1.11.jar > example/lib/servlet-api-2.5-6.1.11.jar > --- > The files to be added can be found in Jetty's binary distribution file : > http://dist.codehaus.org/jetty/jetty-6.1.11/jetty-6.1.11.zip > I couldn't find any noticeable changes in jetty.xml that should be carried > over. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1833) ShowFileRequestHandle should allow you to specify which files can be viewed, not just which cannot be viewed
ShowFileRequestHandle should allow you to specify which files can be viewed, not just which cannot be viewed Key: SOLR-1833 URL: https://issues.apache.org/jira/browse/SOLR-1833 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Mark Miller Priority: Minor Fix For: 1.5 In many cases I wouldn't want to come up with every file I want hidden - especially when new files may be added in the future - often you would want to explicitly say which files can be viewed - this is how the old gettableFiles used to work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: rough outline of where Solr's going
On 03/18/2010 09:27 PM, Chris Hostetter wrote: : Sorry about the following non serious reply: : : It hasn't seemed to hurt the most popular software in the world to be way : worse than that ;) : : 1, 2, 3, NT, 95, 98, 98SE, ME, CE, 2000, XP, 2003, Vista, 2008, 7 (by who's a) 2000 came out before ME b) NT, CE, and 2003 (a server edition) were all "forks" designed for differnet usages. c) If you're willing to pony up enough cash to match the marketing budget spent for *any* one of those version schema transitions then I will happily back you up on naming the version any-freaking-thing you want. I'll seriously vote to call it "Apache Solr Miller Edition" if you pay for the billboards -Hoss Heh - I knew some of that ordering was off - I basically just listed from memory - I don't have a clue when CE was born. Its not as simple as just forks though - eventually NT merged with the consumer line in XP, and 2003, 2008 also came from NT. These forks cross lines, so who is to say which way you count the versions :) And I missed 2000 server. Seriously though, I'm not concerned with what the next version of Solr will be - I'm sure you guys will work it out, and I'm sure the users will figure it out. Me, I don't care - though I would like to remove deprecations. -- - Mark http://www.lucidimagination.com
[jira] Commented: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
[ https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847176#action_12847176 ] Mark Miller commented on SOLR-1817: --- bq. Maybe we should just kill the whole concept, and have SolrCore initialization fail fast and propogate any type of Exception up to CoreContainer? Heh - I can't say I'm against this idea. It really does seem safer to force the user to address the problem. Take a problem plugin out of the config - or fix it. It has always been hard for me to imagine the case where I just didn't care if some things could not load (who knows which ones), but I just want to run anyway with what I can. It really seems like a niche need. It just becomes a lot harder to realize that there is a problem - something that I wanted to work is now not working - other things might be. Who knows when I will be alerted. But if the whole thing is just down ... So I'm on board with whatever you'd like to do. Attempt to fix these issues, or just drop it all together. I kind of like the idea of dropping it. > Fix Solr error reporting to work correctly with multicore > - > > Key: SOLR-1817 > URL: https://issues.apache.org/jira/browse/SOLR-1817 > Project: Solr > Issue Type: Bug > Affects Versions: 1.4 >Reporter: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1817.patch, SOLR-1817.patch, SOLR-1817.patch > > > Here is a rough patch that attempts to fix how error reporting works with > multi-core (not in terms of logs, but what you see on an http request). > The patch is not done - more to consider and havn't worked with how this > changes solrconfigs abortOnConfigurationError, but the basics are here. > If you attempt to access the path of a core that could not load, you are > shown the errors that kept the core from properly loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: rough outline of where Solr's going
On 03/18/2010 02:49 PM, Chris Hostetter wrote: Use 3.1 and developers in the know will understand that i's because we're using LuceneJava 3.1; but uninformed users *might* be confused as to why it jumped to a (seemingly) arbitrary number. Sorry about the following non serious reply: It hasn't seemed to hurt the most popular software in the world to be way worse than that ;) 1, 2, 3, NT, 95, 98, 98SE, ME, CE, 2000, XP, 2003, Vista, 2008, 7 (by who's count in what manner?). -- - Mark http://www.lucidimagination.com
Re: lucene and solr trunk
Alight, so we have implemented Hoss' suggestion here on the lucene/solr merged dev branch at lucene/solr/branches/newtrunk. Feel free to check it out and give some feedback. We also roughly have Solr running on Lucene trunk - eg compiling Solr will first compile lucene and run off those compiled class files. Running dist or example in Solr will grab Lucene's jars and put them in the war. This still needs further love, but it works. There is also a top level build.xml with two targets: clean, and test. Clean will clean both Lucene and Solr, and test will run tests for both Lucene and Solr. Thanks to everyone that contributed to getting all this working! -- - Mark http://www.lucidimagination.com On 03/17/2010 12:40 PM, Mark Miller wrote: Okay, so this looks good to me (a few others seemed to like it - though Lucene-Dev was somehow dropped earlier) - lets try this out on the branch? (then we can get rid of that "horrible" branch name ;) ) Anyone on the current branch object to having to do a quick svn switch? On 03/16/2010 06:46 PM, Chris Hostetter wrote: : Otis, yes, I think so, eventually. But that's gonna take much more discussion. : : I don't think this initial cutover should try to "solve" how modules : will be organized, yet... we'll get there, eventually. But we should at least consider it, and not move in a direction that's distinct from the ultimate goal of better refactoring (especailly since that was one of the main goals of unifying development efforts) Here's my concrete suggestion that could be done today (for simplicity: $svn = https://svn.apache.org/repos/asf/lucene)... svn mv $svn/java/trunk $svn/java/tmp-migration svn mkdir $svn/java/trunk svn mv $svn/solr/trunk $svn/java/trunk/solr svn mv $svn/java/tmp-migration $svn/java/trunk/core At which point: 0. People who want to work only on "Lucene-Java" can start checking out $svn/java/trunk/core (i'm pretty sure existing checkouts will continue to work w/o any changes, the svn info should just update itself) 1. build files can be added to (the new) $svn/java/trunk to build ./core followed by ./solr 2. the build files in $svn/java/trunk/solr can be modified to look at ../core/ to find lucene jars 3. people who care about Solr (including all committers) should start checking out and building all of $svn/java/trunk 4. Long term, we could choose to branch all of $svn/java/trunk for releases ... AND/OR we could choose to branch specific modules (ie: solr) independently (with modifications to the build files on those branches to pull in their dependencies from alternate locations 5. Long term, we can start refactoring additional "modules" out of $svn/java/trunk/solr and $svn/java/trunk/core (like $svn/java/trunk/core/contrib) into their own directory in $svn/java/trunk 6. Long term, people who want to work on more then just "core" but don't care about certain "modules" (like solr) can do a simple non-recursive checkout of $svn/java/trunk and then do full checkouts of whatever modules they care about (Please note: I'm just trying to list things we *could* do if we go this route, i'm not advocating that we *should* do any of these things) I can't think of any objections people have raised to any of the previous suggestions which apply to this suggestion. Is there anything people can think of that would be useful, but not possible, if we go this route? -Hoss
Re: lucene and solr trunk
On 03/17/2010 12:46 PM, Robert Muir wrote: On Wed, Mar 17, 2010 at 12:40 PM, Mark Miller wrote: Okay, so this looks good to me (a few others seemed to like it - though Lucene-Dev was somehow dropped earlier) - lets try this out on the branch? (then we can get rid of that "horrible" branch name ;) ) Anyone on the current branch object to having to do a quick svn switch? +1 I've moved solr to newtrunk/solr for to experiment with this layout. -- - Mark http://www.lucidimagination.com
Re: lucene and solr trunk
Okay, so this looks good to me (a few others seemed to like it - though Lucene-Dev was somehow dropped earlier) - lets try this out on the branch? (then we can get rid of that "horrible" branch name ;) ) Anyone on the current branch object to having to do a quick svn switch? On 03/16/2010 06:46 PM, Chris Hostetter wrote: : Otis, yes, I think so, eventually. But that's gonna take much more discussion. : : I don't think this initial cutover should try to "solve" how modules : will be organized, yet... we'll get there, eventually. But we should at least consider it, and not move in a direction that's distinct from the ultimate goal of better refactoring (especailly since that was one of the main goals of unifying development efforts) Here's my concrete suggestion that could be done today (for simplicity: $svn = https://svn.apache.org/repos/asf/lucene)... svn mv $svn/java/trunk $svn/java/tmp-migration svn mkdir $svn/java/trunk svn mv $svn/solr/trunk $svn/java/trunk/solr svn mv $svn/java/tmp-migration $svn/java/trunk/core At which point: 0. People who want to work only on "Lucene-Java" can start checking out $svn/java/trunk/core (i'm pretty sure existing checkouts will continue to work w/o any changes, the svn info should just update itself) 1. build files can be added to (the new) $svn/java/trunk to build ./core followed by ./solr 2. the build files in $svn/java/trunk/solr can be modified to look at ../core/ to find lucene jars 3. people who care about Solr (including all committers) should start checking out and building all of $svn/java/trunk 4. Long term, we could choose to branch all of $svn/java/trunk for releases ... AND/OR we could choose to branch specific modules (ie: solr) independently (with modifications to the build files on those branches to pull in their dependencies from alternate locations 5. Long term, we can start refactoring additional "modules" out of $svn/java/trunk/solr and $svn/java/trunk/core (like $svn/java/trunk/core/contrib) into their own directory in $svn/java/trunk 6. Long term, people who want to work on more then just "core" but don't care about certain "modules" (like solr) can do a simple non-recursive checkout of $svn/java/trunk and then do full checkouts of whatever modules they care about (Please note: I'm just trying to list things we *could* do if we go this route, i'm not advocating that we *should* do any of these things) I can't think of any objections people have raised to any of the previous suggestions which apply to this suggestion. Is there anything people can think of that would be useful, but not possible, if we go this route? -Hoss -- - Mark http://www.lucidimagination.com
[jira] Commented: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
[ https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846244#action_12846244 ] Mark Miller commented on SOLR-1817: --- U - I'm sorry - I'm being confusing - it wasn't to get the corename - it was to get the corecontainer the register the error. This will end up fine though - because thats an error that will end up being tracked by the core rather than the container based upon what you laid out above. > Fix Solr error reporting to work correctly with multicore > - > > Key: SOLR-1817 > URL: https://issues.apache.org/jira/browse/SOLR-1817 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1817.patch, SOLR-1817.patch, SOLR-1817.patch > > > Here is a rough patch that attempts to fix how error reporting works with > multi-core (not in terms of logs, but what you see on an http request). > The patch is not done - more to consider and havn't worked with how this > changes solrconfigs abortOnConfigurationError, but the basics are here. > If you attempt to access the path of a core that could not load, you are > shown the errors that kept the core from properly loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
[ https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846242#action_12846242 ] Mark Miller commented on SOLR-1817: --- bq. That is the issue where that possible NPE is - getting access to the core name. bq.Just ot be clear: it's not just the core name - you've got code that assumes a SolrCore.getCoreDescriptor() will allways be non null, but that's not allways going to be true. Right - I'm just saying that I'm doing that to get the corename - I realize the issue with it, but I need the corename. So when we solve how we are going to handle needing the core name where we don't have it and need to register an error, hopefully that will apply here too and we won't need the core descriptor. Thats what I was thinking at least - now I realize that's dumb - I can just do solrcore.getName() - wasn't thinking clearly when I put that in I guess. My bad. > Fix Solr error reporting to work correctly with multicore > - > > Key: SOLR-1817 > URL: https://issues.apache.org/jira/browse/SOLR-1817 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1817.patch, SOLR-1817.patch, SOLR-1817.patch > > > Here is a rough patch that attempts to fix how error reporting works with > multi-core (not in terms of logs, but what you see on an http request). > The patch is not done - more to consider and havn't worked with how this > changes solrconfigs abortOnConfigurationError, but the basics are here. > If you attempt to access the path of a core that could not load, you are > shown the errors that kept the core from properly loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
[
https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846240#action_12846240
]
Mark Miller commented on SOLR-1817:
---
bq. In either case: why do we need to specificly test for "admin" shouldn't
that code path just fall through regardless of the patch? ie:
Just a simple way to get what I needed working. I use that corename later to
get the exceptions for the core. The second code block below that comes later.
So normally, any core that cannot be found, it will then look for the "" core.
This includes when you goto solr/admin. When you try to go to solr/admin it
first tries to
get the admin core - when it cannot find it, it falls into the first block
below and gets the "" core. This is so that it can put it in the request for
the jsp to access. Then when
it doesn't find the handler, it just falls through and the jsp ends up handling
it. But that fall through only makes sense when the path is solr/admin. It just
didn't hurt when it
was /solr/somecorethatdoesntexist - cause you end up with a 404 anyway - so it
doesn't matter that the wrong core was put into the request.
{code}
if (core == null && errors == null) {
corename="";
core=cores.getCore(corename);
}
{code}
{code}
List errors = cores.getSevereErrors(corename);
{code}
So it doesn't really affect anything if you only drop in there and get the ""
if the core it was looking for was admin. *but* with my current logic - if you
have multiple cores, and the "" core could not load (so it has errors), and you
then try and go to solr/corethatdoesnotexist - if it drops into that first
block and sets the corename to "", later it will print the "" core errors. When
you really wanted to see a 404.
So its a simple work around for that - and because that first block was only
helpful in the solr/admin case, it should still work.
I don't know that this is all how things should end up - I think this was all
originally kind of messy - like I said, my first step was getting every url to
do what I would expect given a combination of default cores and other cores,
and one or the other not working - and trying to access cores that don't exist.
Hope thats a better explanation.
> Fix Solr error reporting to work correctly with multicore
> -
>
> Key: SOLR-1817
> URL: https://issues.apache.org/jira/browse/SOLR-1817
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Mark Miller
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1817.patch, SOLR-1817.patch, SOLR-1817.patch
>
>
> Here is a rough patch that attempts to fix how error reporting works with
> multi-core (not in terms of logs, but what you see on an http request).
> The patch is not done - more to consider and havn't worked with how this
> changes solrconfigs abortOnConfigurationError, but the basics are here.
> If you attempt to access the path of a core that could not load, you are
> shown the errors that kept the core from properly loading.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
[ https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846225#action_12846225 ] Mark Miller commented on SOLR-1817: --- bq. why is "admin" suddenly a magic alias for "" in SolrDispatchFilter? (line 196) Okay, looking closer, I think its this - if you go to a path for a core name eg /solr/core1, and it there is no core, and so there where no errors, if its drops in the there, the core name will change to "" - and at the bottom of that method when it prints out the erorrs, it will get the errors for core "". If if the default core couldnt load, any path that should get you a 404, will actually show the default core errors. That check is actually just there so that if you ask for solr/admin, you will end up getting the "" core - so it makes sense to only allow it in if the corename is admin anyway. Though I have never really liked that logic where it looks for the admin core and when it can't find it it drops to the "" core. > Fix Solr error reporting to work correctly with multicore > - > > Key: SOLR-1817 > URL: https://issues.apache.org/jira/browse/SOLR-1817 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1817.patch, SOLR-1817.patch, SOLR-1817.patch > > > Here is a rough patch that attempts to fix how error reporting works with > multi-core (not in terms of logs, but what you see on an http request). > The patch is not done - more to consider and havn't worked with how this > changes solrconfigs abortOnConfigurationError, but the basics are here. > If you attempt to access the path of a core that could not load, you are > shown the errors that kept the core from properly loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
[ https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846219#action_12846219 ] Mark Miller commented on SOLR-1817: --- bq. two of the places you removed "adds" to SolrConfig.severErrors are in IndexSchema, Yeah, actually locally I had put those back for now - I didnt really mean to leave that in the patch - I originally started by removing SolrConfig.severErrors and trying to work stop using it, and I just removed those - but easy to lose track of fixing those points so I had put them back. bq. why is "admin" suddenly a magic alias for "" in SolrDispatchFilter? (line 196) I had to do that to get /solr from displaying exceptions when the default core couldn't load I think - that and another change. That is all kind of weird right now anyway - when the dispatchFilter sees /solr/admin, it actually looks for a core named admin - and just doesn't (hopefully) find it, so that it can continue and actually load the admin page. But anyway, at the bottom of that method, if /solr/admin could not be loaded, I actually need to look for severe errors from the "" core - not the admin core. So right now it's simply a workaround for that case. It would normally fall into that if statement anyway - because trying to get the 'admin' core would return null. But in this case, I only want it to fall in if it sees admin - otherwise - ugg, I can't remember, but something doesn't work right - I'd have to get back into it - I spent a bunch of time using the debugger and trying all the different paths to figure out how to get each case to work. I setup a default core and another core and took turns breaking one or the other. bq. the big comment about servlet container behavior... Indeed, that needs to go. > Fix Solr error reporting to work correctly with multicore > - > > Key: SOLR-1817 > URL: https://issues.apache.org/jira/browse/SOLR-1817 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1817.patch, SOLR-1817.patch, SOLR-1817.patch > > > Here is a rough patch that attempts to fix how error reporting works with > multi-core (not in terms of logs, but what you see on an http request). > The patch is not done - more to consider and havn't worked with how this > changes solrconfigs abortOnConfigurationError, but the basics are here. > If you attempt to access the path of a core that could not load, you are > shown the errors that kept the core from properly loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
[ https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846208#action_12846208 ] Mark Miller commented on SOLR-1817: --- 1 and 2) I agree - this is part of the big open issue I think is left here - how to properly deal with abortOnServerConfError. So far I havn't really dabbled there. Currently, I don't think any of that works in a manner that is very friendly with Embedded Solr. Its really focused on http - its not great for tests either. I do think we should differentiate between the two types of errors as well - in fact, I think most of the errors where you can still continue still use SolrConfig.severeErrors because some of them don't have access to the core name. That is the issue where that possible NPE is - getting access to the core name. I'm not sure what the right solution for these cases is yet. I think figuring all this out will help with the issue yonik recently filed as well - where it will continue if it couldn't load a filter and possibly index incorrectly. That should be a show stopper error. 3) yes - I agree - it would be great to see a list of the cores that could not load - then you could click them or something and see the exception page. > Fix Solr error reporting to work correctly with multicore > - > > Key: SOLR-1817 > URL: https://issues.apache.org/jira/browse/SOLR-1817 > Project: Solr > Issue Type: Bug > Affects Versions: 1.4 >Reporter: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1817.patch, SOLR-1817.patch, SOLR-1817.patch > > > Here is a rough patch that attempts to fix how error reporting works with > multi-core (not in terms of logs, but what you see on an http request). > The patch is not done - more to consider and havn't worked with how this > changes solrconfigs abortOnConfigurationError, but the basics are here. > If you attempt to access the path of a core that could not load, you are > shown the errors that kept the core from properly loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: lucene and solr trunk
On 03/16/2010 06:46 PM, Chris Hostetter wrote: Here's my concrete suggestion that could be done today +1 -- - Mark http://www.lucidimagination.com
[jira] Commented: (SOLR-1803) ExtractingRequestHandler does not propagate multiple values to a multi-valued field
[ https://issues.apache.org/jira/browse/SOLR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845697#action_12845697 ] Mark Miller commented on SOLR-1803: --- bq. Actually the problem is that the effect of combining params and generated values is not defined well. Your tests and summary don't appear to try and cover this ... should we update the Title and Description? bq. I suggest that the semantics should be, "a param is treated exactly like a generated field". Have you tested that this is not the case? When I look at the code, it appears to me that it does what your proposed semantics say - params are treated like generated fields when adding multiple fields or concatenating - I have not tested this, but thats what the code looks like its doing ... > ExtractingRequestHandler does not propagate multiple values to a multi-valued > field > --- > > Key: SOLR-1803 > URL: https://issues.apache.org/jira/browse/SOLR-1803 > Project: Solr > Issue Type: Bug > Components: contrib - Solr Cell (Tika extraction) >Reporter: Lance Norskog >Priority: Minor > Attachments: display-extracting-bug.patch > > > When multiple values for one field are extracted from a document, only the > last value is stored in the document. If one or more values are given as > parameters, those values are all stored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: lucene and solr trunk
On 03/15/2010 11:28 PM, Yonik Seeley wrote: So, we have a few options on where to put Solr's new trunk: Solr moves to Lucene's trunk: /java/trunk, /java/trunk/sol +1. With the goal of merged dev, merged tests, this looks the best to me. Simple to do patches that span both, simple to setup Solr to use Lucene trunk rather than jars. Short paths. Simple. I like it. -- - Mark http://www.lucidimagination.com
Re: welcome new lucene/solr committers
Sorry - hit a bad keyboard short cut and sent this mid way through writing it - please disregard and read the followup. On 03/15/2010 07:21 PM, Mark Miller wrote: On 03/15/2010 07:14 PM, Chris Hostetter wrote: : Development on branches/solr to get on lucene trunk is progressing at : a furious (nay... ferocious) pace, pushed by the "not new, but new to : solr" committers. Feels great to have everyone on the same team! I feel like i must have missed out on some sort of discussion -- what was the motivation behind creating a branch for this? (as opposed to just using solr/trunk, since it seemed like there was a clear concensus from all the solr devs (in the merge discussion) that the next major solr release should be in sync with Lucene 3.x) Because getting Solr on Lucene 3.x is a combination of a bunch of issues and patches - robert and I were trying to juggle them all and it was major annoying. So we made a branch that we could commit crappy stuff too fast and furious to get things up to speed and iterate. This branch is basically the culmination of all the patches, plus whatever else we needed. Also: why such a horrible branch name? ... seems more then a little vague. God don't ask. As Robert and I were looking for a place for a branch, it came up in #Lucene irc chat that we should put it in a certain place. It turns out, that certain place caused a raucous. Uwe popped up and said something like: REVERT!! REVERT!! -Hoss -- - Mark http://www.lucidimagination.com
Re: welcome new lucene/solr committers
On 03/15/2010 07:14 PM, Chris Hostetter wrote: : Development on branches/solr to get on lucene trunk is progressing at : a furious (nay... ferocious) pace, pushed by the "not new, but new to : solr" committers. Feels great to have everyone on the same team! I feel like i must have missed out on some sort of discussion -- what was the motivation behind creating a branch for this? (as opposed to just using solr/trunk, since it seemed like there was a clear concensus from all the solr devs (in the merge discussion) that the next major solr release should be in sync with Lucene 3.x) Because getting Solr on Lucene 3.x is a combination of a bunch of issues and patches - robert and I were trying to juggle them all and it was major annoying. So we made a branch that we could commit crappy stuff too fast and furious to get things up to speed and iterate. This branch is basically the culmination of all the patches, plus whatever else we needed. Also: why such a horrible branch name? ... seems more then a little vague. God don't ask. As Robert and I were looking for a place for a branch, it came up in #Lucene irc chat that we should put it in a certain place. It turns out, that certain place caused a raucous. For one, Uwe popped up and said something like: REVERT!! REVERT!! REVERT!! REVERT!! REVERT!! So while it made some sense to call it solr in the unspoken place that it was, I was in such a hurry to move it I just left the name. Now it would require everyone svn switching to change it, so we have just left it for now. Renames and moves are easy in svn though, so I'm sure we could organize something better - we just meant for this to be a very temporary scratch pad to play with what was need to get up to Lucene trunk. We haven't meant to do anything official is why we havn't dropped onto the dev-list - we were just looking for a branch to hash out these patches. Now its up to everyone what we do with this branch. -Hoss -- - Mark http://www.lucidimagination.com
Re: removal of deprecated HtmlStrip*Tokenizer factories
On 03/15/2010 05:24 PM, Paul Borgermans wrote: On Mon, Mar 15, 2010 at 9:39 PM, Robert Muir wrote: Hello, Is there any concern with removing the deprecated HtmlStrip*Tokenizer factories? Maybe a communication issue, you need to read the source code or javadocs to know it is deprecated It is certainly deprecated ;) These can be done with CharFilter instead and they have some problems with lucene's trunk. Personally, I don't object, but then one should consider bumping Solr to 2.0 along with the removal of other deprecated API's/features And of course adapt the wiki page as well http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters Looking like the next version of Solr will actually be 3.1. Or whatever the next version of Lucene is. So its a great time to remove deprecations IMO. Best regards Paul If no one objects, I'd like to remove these in the branch. Otherwise, Uwe tells me there is some way to make them work if need be. Thanks! -- Robert Muir rcm...@gmail.com -- - Mark http://www.lucidimagination.com
[jira] Commented: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
[ https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845013#action_12845013 ] Mark Miller commented on SOLR-1817: --- Just did a check - solr.xml errors will also be displayed - no matter what path you access. So the main thing to work out is the continue stuff. I'm kind of thinking it should apply to each core (like it used to), and there should be another setting in solr.xml that continues if a core can't load, or fails if any can't load. > Fix Solr error reporting to work correctly with multicore > - > > Key: SOLR-1817 > URL: https://issues.apache.org/jira/browse/SOLR-1817 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1817.patch, SOLR-1817.patch, SOLR-1817.patch > > > Here is a rough patch that attempts to fix how error reporting works with > multi-core (not in terms of logs, but what you see on an http request). > The patch is not done - more to consider and havn't worked with how this > changes solrconfigs abortOnConfigurationError, but the basics are here. > If you attempt to access the path of a core that could not load, you are > shown the errors that kept the core from properly loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
[ https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1817: -- Attachment: SOLR-1817.patch More of the solution. If you access localhost:8983/solr it will now show the cores list (those that loaded) rather than the default cores errors (if it didn't load). That takes care of most of the core path handling from what I can see - trying to access cores that don't exist gives 404 - trying to access cores that couldn't load shows the error, trying to access anything that should work, should work. Accessing /solr shows the core list. The open points remain. > Fix Solr error reporting to work correctly with multicore > - > > Key: SOLR-1817 > URL: https://issues.apache.org/jira/browse/SOLR-1817 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1817.patch, SOLR-1817.patch, SOLR-1817.patch > > > Here is a rough patch that attempts to fix how error reporting works with > multi-core (not in terms of logs, but what you see on an http request). > The patch is not done - more to consider and havn't worked with how this > changes solrconfigs abortOnConfigurationError, but the basics are here. > If you attempt to access the path of a core that could not load, you are > shown the errors that kept the core from properly loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1818) SqlEntityProcessor should do something (like throw an error) if DOT_PATTERN is not matched
SqlEntityProcessor should do something (like throw an error) if DOT_PATTERN is
not matched
--
Key: SOLR-1818
URL: https://issues.apache.org/jira/browse/SOLR-1818
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Reporter: Mark Miller
Priority: Trivial
Fix For: 1.5
Looking like we should do something if DOT_PATTERN does not match a primary key
(rather then get the resulting nullpointer exception) - I'm not really up on
DIH, so I'm not sure if that is something we never expect to see, but even in
that case it might be nice to add an else throw illegalstate or something with
a "we should never get here" comment - just for future DIH devs.
{code}
Object val = context.resolve("dataimporter.delta." + primaryKey);
if (val == null) {
Matcher m = DOT_PATTERN.matcher(primaryKey);
if (m.find()) {
val = context.resolve("dataimporter.delta." + m.group(1));
}
}
sb.append(primaryKey).append(" = ");
if (val instanceof Number) {
sb.append(val.toString());
} else {
sb.append("'").append(val.toString()).append("'");
}
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: DIH - Out of Memory error when using CachedsqlEntityProcessor
On 03/13/2010 06:26 PM, Mark Miller wrote: I don't really follow DataImportHandler, but it looks like its using an unbounded cache (simple HashMap). Perhaps we should make the cache size configurable? The impl seems a little odd - the caching occurs in the base class - so caching impls that extends it don't really have full control - they just kind of "turn on" the caching in the base class? Kind of an odd approach - to cache you have to turn on the cache support in the base class and impl a couple custom methods as well? Looking a little closer, really it seems like all of the caching support should be lifted out of EntityProcessorBase and into something like CachedEntityProcessorBase. Not a huge deal, but a cleaner design I think. There is no real need for anyone looking at EntityProcessorBase to think about caching. Then caching impls can either extend that for some base support, or just cache in a completely different way - without the "default caching" kind of always being in the chain (even though it's technically "off"). -- - Mark http://www.lucidimagination.com
[jira] Updated: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
[ https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1817: -- Attachment: SOLR-1817.patch Okay, prob done playing for a bit - this patch mostly fixes the issue where there is an error loading the default core - it will show you the error and other cores will work. Main prob with it is that at /solr, instead seeing a list of cores that did load (like if the error was not with the default core), you see the default core error. Getting closer though - need to resolve that, as well as some other cruft - certain situations still use SolrConfig.severErrors - hopefully just issues with solr.xml - or anything else higher than a Core level problem - that all still needs to be checked and fleshed out though. > Fix Solr error reporting to work correctly with multicore > - > > Key: SOLR-1817 > URL: https://issues.apache.org/jira/browse/SOLR-1817 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 > Reporter: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1817.patch, SOLR-1817.patch > > > Here is a rough patch that attempts to fix how error reporting works with > multi-core (not in terms of logs, but what you see on an http request). > The patch is not done - more to consider and havn't worked with how this > changes solrconfigs abortOnConfigurationError, but the basics are here. > If you attempt to access the path of a core that could not load, you are > shown the errors that kept the core from properly loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
[ https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844951#action_12844951 ] Mark Miller commented on SOLR-1817: --- current patch - still doesn't work right if the problem is with the default core > Fix Solr error reporting to work correctly with multicore > - > > Key: SOLR-1817 > URL: https://issues.apache.org/jira/browse/SOLR-1817 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1817.patch > > > Here is a rough patch that attempts to fix how error reporting works with > multi-core (not in terms of logs, but what you see on an http request). > The patch is not done - more to consider and havn't worked with how this > changes solrconfigs abortOnConfigurationError, but the basics are here. > If you attempt to access the path of a core that could not load, you are > shown the errors that kept the core from properly loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
[ https://issues.apache.org/jira/browse/SOLR-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1817: -- Attachment: SOLR-1817.patch > Fix Solr error reporting to work correctly with multicore > - > > Key: SOLR-1817 > URL: https://issues.apache.org/jira/browse/SOLR-1817 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 > Reporter: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1817.patch > > > Here is a rough patch that attempts to fix how error reporting works with > multi-core (not in terms of logs, but what you see on an http request). > The patch is not done - more to consider and havn't worked with how this > changes solrconfigs abortOnConfigurationError, but the basics are here. > If you attempt to access the path of a core that could not load, you are > shown the errors that kept the core from properly loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1817) Fix Solr error reporting to work correctly with multicore
Fix Solr error reporting to work correctly with multicore - Key: SOLR-1817 URL: https://issues.apache.org/jira/browse/SOLR-1817 Project: Solr Issue Type: Bug Affects Versions: 1.4 Reporter: Mark Miller Priority: Minor Fix For: 1.5 Attachments: SOLR-1817.patch Here is a rough patch that attempts to fix how error reporting works with multi-core (not in terms of logs, but what you see on an http request). The patch is not done - more to consider and havn't worked with how this changes solrconfigs abortOnConfigurationError, but the basics are here. If you attempt to access the path of a core that could not load, you are shown the errors that kept the core from properly loading. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1743) error reporting is rendering "404 missing core name in path" for all type of errors
[ https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12844227#action_12844227 ] Mark Miller commented on SOLR-1743: --- This looks good to me as a first step - tested with both config and schema errors. Would be nice if single core with the solr.xml also worked, but no biggie - we can fix with the rest of multi-core. bq. Note for no good reason what so ever, Well, I think it was supposed to work (even though the whole idea is kind of broken anway), cause it attempted to, so reason is prob a bug ... > error reporting is rendering "404 missing core name in path" for all type of > errors > --- > > Key: SOLR-1743 > URL: https://issues.apache.org/jira/browse/SOLR-1743 > Project: Solr > Issue Type: Bug > Components: Build > Environment: all > Reporter: Marcin >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch, > SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.restore14behavior.patch > > > despite the error in schema syntax or any other type of error you will always > get: > "404 missing core name in path" communicate. > cheers, > /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1802) Make Solr work with IndexReaderFactory implementations that return MultiReader
[ https://issues.apache.org/jira/browse/SOLR-1802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843855#action_12843855 ] Mark Miller commented on SOLR-1802: --- Hey John, Depending on what you are trying to do, you may look at the work around that was used in SOLR-1366. Its not generic, but it may work for your use case. > Make Solr work with IndexReaderFactory implementations that return MultiReader > -- > > Key: SOLR-1802 > URL: https://issues.apache.org/jira/browse/SOLR-1802 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 >Reporter: John Wang > > When an IndexReaderFactory returns an instance of MultiReader, various places > in Solr try to call reader.directory() and reader.getVersion, which results > an UnsupportedOperationException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1659) Get off deprecated Lucene API's to clear the way for a move to Lucene 3.0 +
[ https://issues.apache.org/jira/browse/SOLR-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1659: -- Attachment: SOLR-1659.patch To trunk - updates things that have changed, and some previous workarounds not needed with Lucene 3.01 as opposed to 3.0 > Get off deprecated Lucene API's to clear the way for a move to Lucene 3.0 + > --- > > Key: SOLR-1659 > URL: https://issues.apache.org/jira/browse/SOLR-1659 > Project: Solr > Issue Type: Task >Reporter: Mark Miller > Attachments: SOLR-1659.patch, SOLR-1659.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1674) improve analysis tests, cut over to new API
[ https://issues.apache.org/jira/browse/SOLR-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843611#action_12843611 ] Mark Miller commented on SOLR-1674: --- I've committed the speed up patch, thanks Robert! Leaving open for posInc tests > improve analysis tests, cut over to new API > --- > > Key: SOLR-1674 > URL: https://issues.apache.org/jira/browse/SOLR-1674 > Project: Solr > Issue Type: Test > Components: Schema and Analysis >Reporter: Robert Muir >Assignee: Mark Miller > Attachments: SOLR-1674.patch, SOLR-1674.patch, SOLR-1674_speedup.patch > > > This patch > * converts all analysis tests to use the new tokenstream api > * converts most tests to use the more stringent assertion mechanisms from > lucene > * adds new tests to improve coverage > Most bugs found by more stringent testing have been fixed, with the exception > of SynonymFilter. > The problems with this filter are more serious, the previous tests were > essentially a no-op. > The new tests for SynonymFilter test the current behavior, but have FIXMEs > with what I think the old test wanted to expect in the comments. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1803) ExtractingRequestHandler does not propagate multiple values to a multi-valued field
[ https://issues.apache.org/jira/browse/SOLR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843372#action_12843372 ] Mark Miller commented on SOLR-1803: --- Strike number one - didn't realize that the test schema for extraction is 1.0 - multivalued by default it is. So I'd address 2 and 3: add the values "value1" and "value2". That will get the test passing. You'd still need to device a test to tell you its making a mulivalue rather than concatenating as well. > ExtractingRequestHandler does not propagate multiple values to a multi-valued > field > --- > > Key: SOLR-1803 > URL: https://issues.apache.org/jira/browse/SOLR-1803 > Project: Solr > Issue Type: Bug > Components: contrib - Solr Cell (Tika extraction) >Reporter: Lance Norskog >Priority: Minor > Attachments: display-extracting-bug.patch > > > When multiple values for one field are extracted from a document, only the > last value is stored in the document. If one or more values are given as > parameters, those values are all stored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1803) ExtractingRequestHandler does not propagate multiple values to a multi-valued field
[ https://issues.apache.org/jira/browse/SOLR-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843367#action_12843367 ] Mark Miller commented on SOLR-1803: --- A few comments: 1. If you want to test multi-valued field stuff, you really need to use a field that is multi-valued. multi_s is not as far as I can see. 2. You search for multi_s:value1 and multi_s:value2, but where do you ever add them? It seems valid that they are not found. 3. Your test (if/when written correctly) will pass whether the field is multivalued or not - ie it won't test if the params were really added as a multi-valued field. Solr cell does add multiple literals as multi-values when the the field is actually multi-valued, but when its not, it just concatenates the values - so those searches would still pass. > ExtractingRequestHandler does not propagate multiple values to a multi-valued > field > --- > > Key: SOLR-1803 > URL: https://issues.apache.org/jira/browse/SOLR-1803 > Project: Solr > Issue Type: Bug > Components: contrib - Solr Cell (Tika extraction) >Reporter: Lance Norskog >Priority: Minor > Attachments: display-extracting-bug.patch > > > When multiple values for one field are extracted from a document, only the > last value is stored in the document. If one or more values are given as > parameters, those values are all stored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1807) UpdateHandler plugin is not fully supported
[
https://issues.apache.org/jira/browse/SOLR-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843357#action_12843357
]
Mark Miller commented on SOLR-1807:
---
bq. I guess the only way is to change the UpdateHandler interface.
I almost think thats the lessor of two evils. While it breaks impls, those
impls cannot fully work with Solr anyway.
> UpdateHandler plugin is not fully supported
> ---
>
> Key: SOLR-1807
> URL: https://issues.apache.org/jira/browse/SOLR-1807
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 1.4
>Reporter: John Wang
>
> UpdateHandler is published as a supported Plugin, but code such as the
> following:
> if (core.getUpdateHandler() instanceof DirectUpdateHandler2) {
> ((DirectUpdateHandler2)
> core.getUpdateHandler()).forceOpenWriter();
> } else {
> LOG.warn("The update handler being used is not an instance or
> sub-class of DirectUpdateHandler2. " +
> "Replicate on Startup cannot work.");
> }
> suggest that it is really not fully supported.
> Must all implementations of UpdateHandler be subclasses of
> DirectUpdateHandler2 for it to work with replication?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1743) error reporting is rendering "404 missing core name in path" for all type of errors
[ https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843355#action_12843355 ] Mark Miller commented on SOLR-1743: --- So from what I can see - the immediate problem here is that places that would like to register an error do not have access to the core name - eg schema, solrconfig > error reporting is rendering "404 missing core name in path" for all type of > errors > --- > > Key: SOLR-1743 > URL: https://issues.apache.org/jira/browse/SOLR-1743 > Project: Solr > Issue Type: Bug > Components: Build > Environment: all > Reporter: Marcin >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch, > SOLR-1743.patch, SOLR-1743.patch > > > despite the error in schema syntax or any other type of error you will always > get: > "404 missing core name in path" communicate. > cheers, > /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1743) error reporting is rendering "404 missing core name in path" for all type of errors
[ https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843227#action_12843227 ] Mark Miller commented on SOLR-1743: --- Okay, I sat down and thought about what we should do before really reading through your suggestion - and I came up with practically the exact same thing - so I think this is what we should attempt. > error reporting is rendering "404 missing core name in path" for all type of > errors > --- > > Key: SOLR-1743 > URL: https://issues.apache.org/jira/browse/SOLR-1743 > Project: Solr > Issue Type: Bug > Components: Build > Environment: all > Reporter: Marcin >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch, > SOLR-1743.patch, SOLR-1743.patch > > > despite the error in schema syntax or any other type of error you will always > get: > "404 missing core name in path" communicate. > cheers, > /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1812) StreamingUpdateSolrServer creates an OutputStreamWriter that it never closes
[ https://issues.apache.org/jira/browse/SOLR-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842728#action_12842728 ] Mark Miller commented on SOLR-1812: --- I do not agree that this is a correct use of the API. OutputStreamWriter.close does not simply close the outputstream, nor does it simply flush and then close the outputstream. What it does it actually impl dependent, but its more than that in either case. This API misuse is just asking for trouble. > StreamingUpdateSolrServer creates an OutputStreamWriter that it never closes > > > Key: SOLR-1812 > URL: https://issues.apache.org/jira/browse/SOLR-1812 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.4 >Reporter: Mark Miller >Priority: Minor > Fix For: 1.5 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1812) StreamingUpdateSolrServer creates an OutputStreamWriter that it never closes
StreamingUpdateSolrServer creates an OutputStreamWriter that it never closes Key: SOLR-1812 URL: https://issues.apache.org/jira/browse/SOLR-1812 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.4 Reporter: Mark Miller Priority: Minor Fix For: 1.5 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1722) Allowing changing the "special" default core name, and as a default default core name, switch to using collection1 rather than DEFAULT_CORE
[ https://issues.apache.org/jira/browse/SOLR-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-1722. --- Resolution: Fixed > Allowing changing the "special" default core name, and as a default default > core name, switch to using collection1 rather than DEFAULT_CORE > --- > > Key: SOLR-1722 > URL: https://issues.apache.org/jira/browse/SOLR-1722 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1722.patch, SOLR-1722.patch > > > see > http://search.lucidimagination.com/search/document/f5f2af7c5041a79e/default_core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1808) When IndexReader.reopen is called, old reader is not properly closed
[
https://issues.apache.org/jira/browse/SOLR-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841844#action_12841844
]
Mark Miller commented on SOLR-1808:
---
Right - thats how its supposed to work - we don't close the old instance
because it can still be serving requests on a previous SolrIndexSearcher - it
will be closed when that Searcher is closed.
> When IndexReader.reopen is called, old reader is not properly closed
>
>
> Key: SOLR-1808
> URL: https://issues.apache.org/jira/browse/SOLR-1808
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 1.4
>Reporter: John Wang
>
> According to Lucene documentation:
> "If the index has not changed since this instance was (re)opened, then this
> call is a NOOP and returns this instance. Otherwise, a new instance is
> returned. The old instance is not closed and remains usable."
> In SolrCore.java:
> if (newestSearcher != null && solrConfig.reopenReaders
> && indexDirFile.equals(newIndexDirFile)) {
> IndexReader currentReader = newestSearcher.get().getReader();
> IndexReader newReader = currentReader.reopen();
> if (newReader == currentReader) {
> currentReader.incRef();
> }
> tmp = new SolrIndexSearcher(this, schema, "main", newReader, true,
> true);
> }
> When currentReader!=newReader, currentReader seems to be leaking.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Vote on merging dev of Lucene and Solr
For those committers that don't follow the general mailing list, or follow it that closely, we are currently having a vote for committers: http://search.lucidimagination.com/search/document/4722d3144c2e3a8b/vote_merge_lucene_solr_development -- - Mark http://www.lucidimagination.com
[jira] Updated: (SOLR-1722) Allowing changing the "special" default core name, and as a default default core name, switch to using collection1 rather than DEFAULT_CORE
[ https://issues.apache.org/jira/browse/SOLR-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1722: -- Attachment: SOLR-1722.patch I'm going to commit this fix a little later today. > Allowing changing the "special" default core name, and as a default default > core name, switch to using collection1 rather than DEFAULT_CORE > --- > > Key: SOLR-1722 > URL: https://issues.apache.org/jira/browse/SOLR-1722 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1722.patch, SOLR-1722.patch > > > see > http://search.lucidimagination.com/search/document/f5f2af7c5041a79e/default_core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1722) Allowing changing the "special" default core name, and as a default default core name, switch to using collection1 rather than DEFAULT_CORE
[ https://issues.apache.org/jira/browse/SOLR-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840748#action_12840748 ] Mark Miller edited comment on SOLR-1722 at 3/3/10 5:39 PM: --- small bug - defaultCoreName is looked for at /solr, but should be /solr/cores - also, defaultCoreName should really not default to DEFAULT_DEFAULT_CORENAME was (Author: markrmil...@gmail.com): small bug - defaultCoreName is looked for at /solr, but should be /solr/cores - also, defaultCoreName should really default to DEFAULT_DEFAULT_CORENAME > Allowing changing the "special" default core name, and as a default default > core name, switch to using collection1 rather than DEFAULT_CORE > --- > > Key: SOLR-1722 > URL: https://issues.apache.org/jira/browse/SOLR-1722 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1722.patch > > > see > http://search.lucidimagination.com/search/document/f5f2af7c5041a79e/default_core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SOLR-1722) Allowing changing the "special" default core name, and as a default default core name, switch to using collection1 rather than DEFAULT_CORE
[ https://issues.apache.org/jira/browse/SOLR-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reopened SOLR-1722: --- small bug - defaultCoreName is looked for at /solr, but should be /solr/cores - also, defaultCoreName should really default to DEFAULT_DEFAULT_CORENAME > Allowing changing the "special" default core name, and as a default default > core name, switch to using collection1 rather than DEFAULT_CORE > --- > > Key: SOLR-1722 > URL: https://issues.apache.org/jira/browse/SOLR-1722 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1722.patch > > > see > http://search.lucidimagination.com/search/document/f5f2af7c5041a79e/default_core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1743) error reporting is rendering "404 missing core name in path" for all type of errors
[ https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840177#action_12840177 ] Mark Miller commented on SOLR-1743: --- Hoss - I've got to digest and respond to this more fully later, but: Yes, I def agree the best solution is something entirely different. I agree that the current, historical based stuff is just not right for multicore. What I've tried to do is just hack things back closer to what they were, but a real solution would be to start from scratch and handle things better - Sounds like you have an idea for that, and I'll dig into your explanation when I get a chance and perhaps off some feedback. > error reporting is rendering "404 missing core name in path" for all type of > errors > --- > > Key: SOLR-1743 > URL: https://issues.apache.org/jira/browse/SOLR-1743 > Project: Solr > Issue Type: Bug > Components: Build > Environment: all > Reporter: Marcin >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch, > SOLR-1743.patch, SOLR-1743.patch > > > despite the error in schema syntax or any other type of error you will always > get: > "404 missing core name in path" communicate. > cheers, > /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1743) error reporting is rendering "404 missing core name in path" for all type of errors
[ https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1743: -- Attachment: SOLR-1743.patch Here is a quick attempt at solving most of the rest of this. The idea is: reporting that the mutlicore core name is missing on the http://localhost:8983/solr/admin/ page is now not always correct when SolrCore is not put into the request. Sometimes this means an error in one of the cores - though with the previous part of this patch you only run into this issue when abortOnConfigError is false. But anyway, what this does is: if there is no default core specified, the old error is shown - you are missing the corename. If there is a default core specified (and there is by default these days - collection1), and that core couldn't load, all of the errors found while loading cores are printed to the page: HTTP ERROR: 404 Severe errors in solr configuration. Check your log files for more detailed information on what may be wrong. The following are the errors registered by the cores you tried to load: Could prob be a better message even. Still, if you try and go to the full url of a core that couldn't load, you will get page not found - because the core will have never loaded. Would be nice to see the error there too, but this is as far as I go at the moment. This patch also removes a System.out in the last patch and fixes a bug in reading the defaultCoreName from solr.xml - it was looking for it at /solr when it should have been looking at /solr/cores. > error reporting is rendering "404 missing core name in path" for all type of > errors > --- > > Key: SOLR-1743 > URL: https://issues.apache.org/jira/browse/SOLR-1743 > Project: Solr > Issue Type: Bug > Components: Build > Environment: all > Reporter: Marcin >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1743.patch, SOLR-1743.patch, SOLR-1743.patch > > > despite the error in schema syntax or any other type of error you will always > get: > "404 missing core name in path" communicate. > cheers, > /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1743) error reporting is rendering "404 missing core name in path" for all type of errors
[ https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1743: -- Attachment: SOLR-1743.patch Well its no surprise that I'm confusing... But I swear I tested that stupid patch - and yet .. I must not have ... Here is a patch updated to trunk and with the correct fix. Was still looking at the abortOnConfig setting in the wrong place - if the schema couldn't load, an exception *still* caused the setting check to be skipped - so setting check has to go in the createCore call, right after the config object is created. Swear I'm looking at the darn exception at http://localhost:8983/solr/admin/ right now. Like I said, this is not a full fix to the issue, but it least puts us back where we were with single core, and solves half the multi core problem. > error reporting is rendering "404 missing core name in path" for all type of > errors > --- > > Key: SOLR-1743 > URL: https://issues.apache.org/jira/browse/SOLR-1743 > Project: Solr > Issue Type: Bug > Components: Build > Environment: all > Reporter: Marcin >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1743.patch, SOLR-1743.patch > > > despite the error in schema syntax or any other type of error you will always > get: > "404 missing core name in path" communicate. > cheers, > /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Upgrading Lucene jars to 2.9.2 artifacts
On 02/27/2010 05:53 AM, Shalin Shekhar Mangar wrote: Any objections? Didn't rc2 (that we are on) end up being the final release? -- - Mark http://www.lucidimagination.com
Some odd wiki stuff on the SolrRequestHandler page
The SolrRequestHandler page is generating some odd wiki links: Under List of Request Handlers Available we use: <-title:CategorySolrRequestHandler)>> But thats bring up a non relevant german and what looks like japanese page: 1. CategoryCategory 2. DataImportHandler 3. DisMaxRequestHandler 4. HilfeZuMakros 5. LukeRequestHandler 6. MoreLikeThisHandler 7. SearchHandler 8. SpellCheckerRequestHandler 9. The content of each page is not correct for this set of links. Just noting in case someone more familiar with this wants to take care of it. Offhand I'm not sure if something needs to be changed about those pages, or if we need to change how we are listing them. -- - Mark http://www.lucidimagination.com
Re: admin page errors if UniqueKey not defined in schema
Have you removed the QueryElevationComponent from the solrconfig? It requires a unique field in schema, and that its a String type. -- - Mark http://www.lucidimagination.com Erick Erickson wrote: > This may be related to SOLR-1742 and/or SOLR-1743. > > I have a minimal schema file, 4 fields and one copyfield. If UniqueKey > isn't specified in the schema file, going to the admin page produces a > "missing core name in path" error. I can't seem to add documents via Posting > either. > > This is with a SOLR downloaded and compiled this morning (Sunday, 14-Feb). > Does anyone have a clue about this or am I seeing things? > > Same thing happens with the 1.4 release. > > The *only* difference between success and failure is removing (or not) > . Yet we state that the unique key isn't required at > http://wiki.apache.org/solr/SchemaXml#The_Unique_Key_Field. And specifying > required="false" doesn't seem to change things. > > To try to get this to a minimal set of things to look at, I deleted my index > directory completely and saw the above, before indexing anything. If I leave > UniqueKey in, the admin page shows up fine. > > Even with required="false" (both for field and UniqueKey), indexing a > document via post fails with "...Status 400 - Document is missing uniqueKey > field idtype Status > reportmessage" > > Running under Tomcat on a Mac if it matters, Java 1.6 > > Erick > > Here's the (I believe) relevant portion of my schema file... > > > > required="true" /> > required="true" /> > required="true" /> > stored="true" required="true" /> > required="false"/> > > > > id > > > body > > > > > > >
[jira] Commented: (SOLR-1774) IndexReaderFactory should have a close() method for cleanup
[ https://issues.apache.org/jira/browse/SOLR-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12834052#action_12834052 ] Mark Miller commented on SOLR-1774: --- We could just add it to the classes that are allowed to be core aware. > IndexReaderFactory should have a close() method for cleanup > --- > > Key: SOLR-1774 > URL: https://issues.apache.org/jira/browse/SOLR-1774 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 >Reporter: John Wang > > The custom IndexReaderFactory may choose to pool some resources that needs to > be cleaned up. > IndexReaderFactory should contract a new method, e.g. close() such that when > called, the implementation can choose to do some cleanup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1770) move default example core config/data into a collection1 folder
[ https://issues.apache.org/jira/browse/SOLR-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1770: -- Attachment: SOLR-1770.patch initial patch (won't do it form a patch to handle the moves though) > move default example core config/data into a collection1 folder > --- > > Key: SOLR-1770 > URL: https://issues.apache.org/jira/browse/SOLR-1770 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 > Reporter: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1770.patch > > > This is a better starting point for adding more cores - perhaps we can also > get rid of multi-core example -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1770) move default example core config/data into a collection1 folder
move default example core config/data into a collection1 folder --- Key: SOLR-1770 URL: https://issues.apache.org/jira/browse/SOLR-1770 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Mark Miller Fix For: 1.5 This is a better starting point for adding more cores - perhaps we can also get rid of multi-core example -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1722) Allowing changing the "special" default core name, and as a default default core name, switch to using collection1 rather than DEFAULT_CORE
[ https://issues.apache.org/jira/browse/SOLR-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-1722. --- Resolution: Fixed > Allowing changing the "special" default core name, and as a default default > core name, switch to using collection1 rather than DEFAULT_CORE > --- > > Key: SOLR-1722 > URL: https://issues.apache.org/jira/browse/SOLR-1722 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1722.patch > > > see > http://search.lucidimagination.com/search/document/f5f2af7c5041a79e/default_core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1722) Allowing changing the "special" default core name, and as a default default core name, switch to using collection1 rather than DEFAULT_CORE
[ https://issues.apache.org/jira/browse/SOLR-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830943#action_12830943 ] Mark Miller commented on SOLR-1722: --- If no one objects, I'd like to commit this soon. I think its a clear improvement on what is there now, so I'd like to get it in. I think we can talk about how the normalization occurs in another issue. Doing things differently has its own back compat issues, and it would be nice if this configurability wasn't caught up in it. Another option we have is to leave the normalization as it is, but just change getName so that it returns the default name rather than "". > Allowing changing the "special" default core name, and as a default default > core name, switch to using collection1 rather than DEFAULT_CORE > --- > > Key: SOLR-1722 > URL: https://issues.apache.org/jira/browse/SOLR-1722 > Project: Solr > Issue Type: Improvement > Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1722.patch > > > see > http://search.lucidimagination.com/search/document/f5f2af7c5041a79e/default_core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1743) error reporting is rendering "404 missing core name in path" for all type of errors
[ https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1743: -- Attachment: SOLR-1743.patch Fixes the "at least one core has abortOnConfigError = true" case. > error reporting is rendering "404 missing core name in path" for all type of > errors > --- > > Key: SOLR-1743 > URL: https://issues.apache.org/jira/browse/SOLR-1743 > Project: Solr > Issue Type: Bug > Components: Build > Environment: all > Reporter: Marcin >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1743.patch > > > despite the error in schema syntax or any other type of error you will always > get: > "404 missing core name in path" communicate. > cheers, > /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1743) error reporting is rendering "404 missing core name in path" for all type of errors
[ https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12830271#action_12830271 ] Mark Miller commented on SOLR-1743: --- Not quite as bad as I thought - I guess this is setup to work right with multicore. Wasn't seeing the full picture. The reason we don't see the error is because the core doesn't load, and abortOnConfigurationError never gets set to true. We don't handle that setting correctly with MultiCore - we check it by iterating through all of the cores that loaded - but a core with a config erorr wouldn't have loaded ... so abortOnConfigError gets read as false when it should be true. So we can fix that, but if you *don't* want to abortOnConfiguration error, your still going to see this confusing message, so we should prob improve on that as well. > error reporting is rendering "404 missing core name in path" for all type of > errors > --- > > Key: SOLR-1743 > URL: https://issues.apache.org/jira/browse/SOLR-1743 > Project: Solr > Issue Type: Bug > Components: Build > Environment: all >Reporter: Marcin >Assignee: Mark Miller > Fix For: 1.5 > > > despite the error in schema syntax or any other type of error you will always > get: > "404 missing core name in path" communicate. > cheers, > /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1743) error reporting is rendering "404 missing core name in path" for all type of errors
[ https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829828#action_12829828 ] Mark Miller commented on SOLR-1743: --- bq. ... I'll take a whack at a fix. Heh - perhaps I will. Annoyingly, its going to take some thought. The old machinery counts on an exception while building the core bubbling up to the dispatchfilter init method - but the corecontainer swallows such exceptions, as we try and run other cores even if one is whacked. Anyway, this error reporting will have to be done in a completely different way to properly work with multicore. > error reporting is rendering "404 missing core name in path" for all type of > errors > --- > > Key: SOLR-1743 > URL: https://issues.apache.org/jira/browse/SOLR-1743 > Project: Solr > Issue Type: Bug > Components: Build > Environment: all > Reporter: Marcin >Assignee: Mark Miller > Fix For: 1.5 > > > despite the error in schema syntax or any other type of error you will always > get: > "404 missing core name in path" communicate. > cheers, > /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1743) error reporting is rendering "404 missing core name in path" for all type of errors
[ https://issues.apache.org/jira/browse/SOLR-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-1743: - Assignee: Mark Miller I think this was always a bug with MultiCore and single core worked. Now that we always run in "multicore mode", its just more prominent. I think. Anyway, I see whats going wrong and I'll take a whack at a fix. > error reporting is rendering "404 missing core name in path" for all type of > errors > --- > > Key: SOLR-1743 > URL: https://issues.apache.org/jira/browse/SOLR-1743 > Project: Solr > Issue Type: Bug > Components: Build > Environment: all > Reporter: Marcin >Assignee: Mark Miller > Fix For: 1.5 > > > despite the error in schema syntax or any other type of error you will always > get: > "404 missing core name in path" communicate. > cheers, > /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1756) the date.format setting does not work
[ https://issues.apache.org/jira/browse/SOLR-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-1756. --- Resolution: Fixed Thanks a lot Christoph! > the date.format setting does not work > - > > Key: SOLR-1756 > URL: https://issues.apache.org/jira/browse/SOLR-1756 > Project: Solr > Issue Type: Bug > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 1.4 > Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1756.patch > > > There is a bad cast (casts to String when its a Map.Entry), and an iterator > is used by constantly creating a new iterator rather than using the same one > - so it never actually iterates, and calling hasNext on a new iterator every > time creates an infinite loop. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
