[jira] Updated: (SOLR-560) Convert JDK logging to SLF4J
[ https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-560: -- Attachment: SOLR-560-slf4j.patch patch updated for the latest trunk. i also tested that it works with slf4j redirecting to log4j. > Convert JDK logging to SLF4J > > > Key: SOLR-560 > URL: https://issues.apache.org/jira/browse/SOLR-560 > Project: Solr > Issue Type: Wish >Reporter: Ryan McKinley > Fix For: 1.3 > > Attachments: slf4j-api-1.5.0.jar, slf4j-jdk14-1.5.0.jar, > SOLR-560-slf4j.patch, SOLR-560-slf4j.patch, SOLR-560-slf4j.patch > > > After lots of discussion, we should consider using SLF4j to enable more > flexibility in logging configuration. > See: > http://www.nabble.com/Solr-Logging-td16836646.html > http://www.nabble.com/logging-through-log4j-td13747253.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-342) Add support for Lucene's new Indexing and merge features (excluding Document/Field/Token reuse)
[ https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570319#action_12570319 ] Will Johnson commented on SOLR-342: --- the new solr with the new lucene did the trick. i was made the mistake of using the 2.3 tag instead of the branch before which was why i still saw the problem. > Add support for Lucene's new Indexing and merge features (excluding > Document/Field/Token reuse) > --- > > Key: SOLR-342 > URL: https://issues.apache.org/jira/browse/SOLR-342 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: copyLucene.sh, SOLR-342.patch, SOLR-342.patch, > SOLR-342.patch, SOLR-342.tar.gz > > > LUCENE-843 adds support for new indexing capabilities using the > setRAMBufferSizeMB() method that should significantly speed up indexing for > many applications. To fix this, we will need trunk version of Lucene (or > wait for the next official release of Lucene) > Side effect of this is that Lucene's new, faster StandardTokenizer will also > be incorporated. > Also need to think about how we want to incorporate the new merge scheduling > functionality (new default in Lucene is to do merges in a background thread) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-342) Add support for Lucene's new Indexing and merge features (excluding Document/Field/Token reuse)
[ https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12569408#action_12569408 ] Will Johnson commented on SOLR-342: --- i switched to the lucene 2.3 branch, updated (and confirmed that yonik's 1 line change was in place), reran the tests and still saw the same problem. if i missed something please let me know. > Add support for Lucene's new Indexing and merge features (excluding > Document/Field/Token reuse) > --- > > Key: SOLR-342 > URL: https://issues.apache.org/jira/browse/SOLR-342 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: copyLucene.sh, SOLR-342.patch, SOLR-342.patch, > SOLR-342.patch, SOLR-342.tar.gz > > > LUCENE-843 adds support for new indexing capabilities using the > setRAMBufferSizeMB() method that should significantly speed up indexing for > many applications. To fix this, we will need trunk version of Lucene (or > wait for the next official release of Lucene) > Side effect of this is that Lucene's new, faster StandardTokenizer will also > be incorporated. > Also need to think about how we want to incorporate the new merge scheduling > functionality (new default in Lucene is to do merges in a background thread) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-342) Add support for Lucene's new Indexing and merge features (excluding Document/Field/Token reuse)
[ https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567508#action_12567508 ] Will Johnson commented on SOLR-342: --- we are doing multi-threaded indexing and searching while indexing however the 'bad' results come back after the indexing run is finished and the index itself is static. > Add support for Lucene's new Indexing and merge features (excluding > Document/Field/Token reuse) > --- > > Key: SOLR-342 > URL: https://issues.apache.org/jira/browse/SOLR-342 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: copyLucene.sh, SOLR-342.patch, SOLR-342.patch, > SOLR-342.patch, SOLR-342.tar.gz > > > LUCENE-843 adds support for new indexing capabilities using the > setRAMBufferSizeMB() method that should significantly speed up indexing for > many applications. To fix this, we will need trunk version of Lucene (or > wait for the next official release of Lucene) > Side effect of this is that Lucene's new, faster StandardTokenizer will also > be incorporated. > Also need to think about how we want to incorporate the new merge scheduling > functionality (new default in Lucene is to do merges in a background thread) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-342) Add support for Lucene's new Indexing and merge features (excluding Document/Field/Token reuse)
[
https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567235#action_12567235
]
Will Johnson commented on SOLR-342:
---
we're using SolrCore in terms of:
core = new SolrCore("foo", dataDir, solrConfig, solrSchema);
UpdateHandler handler = core.getUpdateHandler();
updateHandler.addDoc(command);
which is a bit more low level than normal however when we flipped back to solr
trunk + lucene 2.3 everything was fine so it leads me to belive that we are ok
in that respect.
i was going to try and reproduce with lucene directly also but that too is a
bit outside the scope of what i have time for at the moment.
and we're not getting any exceptions, just bad search results.
> Add support for Lucene's new Indexing and merge features (excluding
> Document/Field/Token reuse)
> ---
>
> Key: SOLR-342
> URL: https://issues.apache.org/jira/browse/SOLR-342
> Project: Solr
> Issue Type: Improvement
> Components: update
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Attachments: copyLucene.sh, SOLR-342.patch, SOLR-342.patch,
> SOLR-342.patch, SOLR-342.tar.gz
>
>
> LUCENE-843 adds support for new indexing capabilities using the
> setRAMBufferSizeMB() method that should significantly speed up indexing for
> many applications. To fix this, we will need trunk version of Lucene (or
> wait for the next official release of Lucene)
> Side effect of this is that Lucene's new, faster StandardTokenizer will also
> be incorporated.
> Also need to think about how we want to incorporate the new merge scheduling
> functionality (new default in Lucene is to do merges in a background thread)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-342) Add support for Lucene's new Indexing and merge features (excluding Document/Field/Token reuse)
[ https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567218#action_12567218 ] Will Johnson commented on SOLR-342: --- we're not using parallel reader but we are using direct core access instead of going over http. as for doc size, we're indexing wikipedia but creating anumber of extra fields. they are only large in comparison to any of the 'large volume' tests i've seen in most of the solr and lucene tests. - will > Add support for Lucene's new Indexing and merge features (excluding > Document/Field/Token reuse) > --- > > Key: SOLR-342 > URL: https://issues.apache.org/jira/browse/SOLR-342 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: copyLucene.sh, SOLR-342.patch, SOLR-342.patch, > SOLR-342.patch, SOLR-342.tar.gz > > > LUCENE-843 adds support for new indexing capabilities using the > setRAMBufferSizeMB() method that should significantly speed up indexing for > many applications. To fix this, we will need trunk version of Lucene (or > wait for the next official release of Lucene) > Side effect of this is that Lucene's new, faster StandardTokenizer will also > be incorporated. > Also need to think about how we want to incorporate the new merge scheduling > functionality (new default in Lucene is to do merges in a background thread) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-342) Add support for Lucene's new Indexing and merge features (excluding Document/Field/Token reuse)
[ https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567198#action_12567198 ] Will Johnson commented on SOLR-342: --- we have: 10 64 2147483647 and i'm working on a unit test but just adding a few terms per doc doesnt seem to trigger it, at least not 'quickly.' > Add support for Lucene's new Indexing and merge features (excluding > Document/Field/Token reuse) > --- > > Key: SOLR-342 > URL: https://issues.apache.org/jira/browse/SOLR-342 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: copyLucene.sh, SOLR-342.patch, SOLR-342.patch, > SOLR-342.patch, SOLR-342.tar.gz > > > LUCENE-843 adds support for new indexing capabilities using the > setRAMBufferSizeMB() method that should significantly speed up indexing for > many applications. To fix this, we will need trunk version of Lucene (or > wait for the next official release of Lucene) > Side effect of this is that Lucene's new, faster StandardTokenizer will also > be incorporated. > Also need to think about how we want to incorporate the new merge scheduling > functionality (new default in Lucene is to do merges in a background thread) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-342) Add support for Lucene's new Indexing and merge features (excluding Document/Field/Token reuse)
[ https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567147#action_12567147 ] Will Johnson commented on SOLR-342: --- patched solr + lucene trunk is stil broken. if anyone has any pointers for ways to coax this problem to happen before we get 20-30k large docs in the system let me know and we can start working on a unit test, otherwise it's going to take a while to reproduce anything. > Add support for Lucene's new Indexing and merge features (excluding > Document/Field/Token reuse) > --- > > Key: SOLR-342 > URL: https://issues.apache.org/jira/browse/SOLR-342 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: copyLucene.sh, SOLR-342.patch, SOLR-342.patch, > SOLR-342.patch, SOLR-342.tar.gz > > > LUCENE-843 adds support for new indexing capabilities using the > setRAMBufferSizeMB() method that should significantly speed up indexing for > many applications. To fix this, we will need trunk version of Lucene (or > wait for the next official release of Lucene) > Side effect of this is that Lucene's new, faster StandardTokenizer will also > be incorporated. > Also need to think about how we want to incorporate the new merge scheduling > functionality (new default in Lucene is to do merges in a background thread) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-342) Add support for Lucene's new Indexing and merge features (excluding Document/Field/Token reuse)
[ https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567099#action_12567099 ] Will Johnson commented on SOLR-342: --- I think we're running into a very serious issue with trunk + this patch. either the document summaries are not matched or the overall matching is 'wrong'. i did find this in the lucene jira: LUCENE-994 "Note that these changes will break users of ParallelReader because the parallel indices will no longer have matching docIDs. Such users need to switch IndexWriter back to flushing by doc count, and switch the MergePolicy back to LogDocMergePolicy. It's likely also necessary to switch the MergeScheduler back to SerialMergeScheduler to ensure deterministic docID assignment." we're seeing rather consistent bad results but only after 20-30k documents and multiple commits and wondering if anyone else is seeing anything. i've verified that the results are bad even though luke which would seem to remove the search side of hte solr equation. the basic test case is to search for title:foo and get back documents that only have title:bar. we're going to start on a unit test but give the document counts and the corpus we're testing against it may be a while so i thought i'd ask to see if anyone had any hints. removing this patch seems to remove the issue so i doesn't appear to be a lucene problem > Add support for Lucene's new Indexing and merge features (excluding > Document/Field/Token reuse) > --- > > Key: SOLR-342 > URL: https://issues.apache.org/jira/browse/SOLR-342 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: copyLucene.sh, SOLR-342.patch, SOLR-342.patch, > SOLR-342.patch, SOLR-342.tar.gz > > > LUCENE-843 adds support for new indexing capabilities using the > setRAMBufferSizeMB() method that should significantly speed up indexing for > many applications. To fix this, we will need trunk version of Lucene (or > wait for the next official release of Lucene) > Side effect of this is that Lucene's new, faster StandardTokenizer will also > be incorporated. > Also need to think about how we want to incorporate the new merge scheduling > functionality (new default in Lucene is to do merges in a background thread) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-445) XmlUpdateRequestHandler bad documents mid batch aborts rest of batch
XmlUpdateRequestHandler bad documents mid batch aborts rest of batch Key: SOLR-445 URL: https://issues.apache.org/jira/browse/SOLR-445 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.3 Reporter: Will Johnson Has anyone run into the problem of handling bad documents / failures mid batch. Ie: 1 2 I_AM_A_BAD_DATE 3 Right now solr adds the first doc and then aborts. It would seem like it should either fail the entire batch or log a message/return a code and then continue on to add doc 3. Option 1 would seem to be much harder to accomplish and possibly require more memory while Option 2 would require more information to come back from the API. I'm about to dig into this but I thought I'd ask to see if anyone had any suggestions, thoughts or 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-342) Add support for Lucene's new Indexing and merge features (excluding Document/Field/Token reuse)
[ https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547925 ] Will Johnson commented on SOLR-342: --- is there any update on getting this patch committed? we needed to be able to set some of the buffer sizes so the script wouldn't help. have other people experienced tourbles with 2.3 and/or this patch that i should be wary of? > Add support for Lucene's new Indexing and merge features (excluding > Document/Field/Token reuse) > --- > > Key: SOLR-342 > URL: https://issues.apache.org/jira/browse/SOLR-342 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: copyLucene.sh, SOLR-342.patch, SOLR-342.tar.gz > > > LUCENE-843 adds support for new indexing capabilities using the > setRAMBufferSizeMB() method that should significantly speed up indexing for > many applications. To fix this, we will need trunk version of Lucene (or > wait for the next official release of Lucene) > Side effect of this is that Lucene's new, faster StandardTokenizer will also > be incorporated. > Also need to think about how we want to incorporate the new merge scheduling > functionality (new default in Lucene is to do merges in a background thread) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-342) Add support for Lucene's new Indexing and merge features (excluding Document/Field/Token reuse)
[ https://issues.apache.org/jira/browse/SOLR-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547854 ] Will Johnson commented on SOLR-342: --- just a comment to say that we added this patch and saw rather signifigant improvements, on the order of 10-25% for different index tests. > Add support for Lucene's new Indexing and merge features (excluding > Document/Field/Token reuse) > --- > > Key: SOLR-342 > URL: https://issues.apache.org/jira/browse/SOLR-342 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: SOLR-342.patch, SOLR-342.tar.gz > > > LUCENE-843 adds support for new indexing capabilities using the > setRAMBufferSizeMB() method that should significantly speed up indexing for > many applications. To fix this, we will need trunk version of Lucene (or > wait for the next official release of Lucene) > Side effect of this is that Lucene's new, faster StandardTokenizer will also > be incorporated. > Also need to think about how we want to incorporate the new merge scheduling > functionality (new default in Lucene is to do merges in a background thread) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-421) Make SolrParams serializable
[ https://issues.apache.org/jira/browse/SOLR-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547853 ] Will Johnson commented on SOLR-421: --- i also added 'implements java.io.Serializable' to: SolrRequest SolrInputField SolrInputDocument i'd generate a patch but my tree is so heavily patched for SOLR-342 (which rocks by the way) and i'm hesitatnt to try anything too ambitious this morning. > Make SolrParams serializable > > > Key: SOLR-421 > URL: https://issues.apache.org/jira/browse/SOLR-421 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Priority: Trivial > > Making SolrParams serializable will allow it to be sent over RMI or used in > other tools that require serialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-421) Make SolrParams serializable
[ https://issues.apache.org/jira/browse/SOLR-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546249 ] Will Johnson commented on SOLR-421: --- it would also be good to make the same changes to all of the solrj library classes as well. i know they are meant to be sent over http with solr specific marshaling, but we ended up needing to send some solrj request objects to another box via RMI and it was a bit of a pain. > Make SolrParams serializable > > > Key: SOLR-421 > URL: https://issues.apache.org/jira/browse/SOLR-421 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Priority: Trivial > > Making SolrParams serializable will allow it to be sent over RMI or used in > other tools that require serialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-360) Multithread update client causes exceptions and dropped documents
[ https://issues.apache.org/jira/browse/SOLR-360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-360: -- Attachment: TestJettyLargeVolume.java i'll work on the patch to make it cleaner and run with the build process but i wanted to get this up as soon as possible. if you drop it into /client/java/solrj/test/org/apache/solr/client/solrj/embedded it compiles/runs with eclipse. > Multithread update client causes exceptions and dropped documents > - > > Key: SOLR-360 > URL: https://issues.apache.org/jira/browse/SOLR-360 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 1.3 > Environment: test fails on both pc + mac, tomcat + jetty all java 1.6 >Reporter: Will Johnson > Attachments: TestJettyLargeVolume.java > > > we were doing some performance testing for the updating aspects of solr and > ran into what seems to be a large problem. we're creating small documents > with an id and one field of 1 term only submitting them in batches of 200 > with commits every 5000 docs. when we run the client with 1 thread > everything is fine. when we run it win >1 threads things go south (stack > trace is below). i've attached the junit test which shows the problem. this > happens on both a mac and a pc and when running solr in both jetty and > tomcat. i'll create a junit issue if necessary but i thought i'd see if > anyone else had run into this problem first. > also, the problem does not seem to surface under solr1.2 > (RyanM suggested it might be related to SOLR-215) > (output from junit test) > Started thread: 0 > Started thread: 1 > org.apache.solr.common.SolrException: > Current_state_is_not_among_the_states_START_ELEMENT__ATTRIBUTEvalid_for_getAttributeCount__javalangIllegalStateException_Current_state_is_not_among_the_states_START_ELEMENT__ATTRIBUTEvalid_for_getAttributeCount__at_comsunorgapachexercesinternalimplXMLStreamReaderImplgetAttributeCountXMLStreamReaderImpljava598__at_orgapachesolrhandlerXmlUpdateRequestHandlerreadDocXmlUpdateRequestHandlerjava335__at_orgapachesolrhandlerXmlUpdateRequestHandlerprocessUpdateXmlUpdateRequestHandlerjava181__at_orgapachesolrhandlerXmlUpdateRequestHandlerhandleRequestBodyXmlUpdateRequestHandlerjava109__at_orgapachesolrhandlerRequestHandlerBasehandleRequestRequestHandlerBasejava78__at_orgapachesolrcoreSolrCoreexecuteSolrCorejava804__at_orgapachesolrservletSolrDispatchFilterexecuteSolrDispatchFilterjava193__at_orgapachesolrservletSolrDispatchFilterdoFilterSolrDispatchFilterjava161__at_orgmortbayjettyservletServletHandler$CachedChaindoFilterServletHandlerjava1089__at_orgmortbayjettyservletServletHandlerhandleServletHandlerjava365__at_orgmortbayjettysecuritySecurityHandlerhandleSecurityHandlerjava216__at_orgmortbayjettyservletSessionHandlerhandleSessionHandlerjava181__at_orgmortbayjettyhandlerContextHandlerhandleContextHandlerjava712__at_orgmortbayjettywebappWebAppContexthandleWebAppContextjava405__at_orgmortbayjettyhandlerContextHandlerCollectionhandleContextHandlerCollectionjava211__at_orgmortbayjettyhandlerHandlerCollectionhandleHandlerCollectionjava114__at_orgmortbayjettyhandlerHandlerWrapperhandleHandlerWrapperjava139__at_orgmortbayjettyServerhandleServerjava285__at_orgmortbayjettyHttpConnectionhandleRequestHttpConnectionjava502__at_orgmortbayjettyHttpConnection$RequestHandlercontentHttpConnectionjava835__at_orgmortbayjettyHttpParserparseNextHttpParserjava641__at_orgmortbayjettyHttpParserparseAvailableHttpParserjava208__at_orgmortbayje > Current_state_is_not_among_the_states_START_ELEMENT__ATTRIBUTEvalid_for_getAttributeCount__javalangIllegalStateException_Current_state_is_not_among_the_states_START_ELEMENT__ATTRIBUTEvalid_for_getAttributeCount__at_comsunorgapachexercesinternalimplXMLStreamReaderImplgetAttributeCountXMLStreamReaderImpljava598__at_orgapachesolrhandlerXmlUpdateRequestHandlerreadDocXmlUpdateRequestHandlerjava335__at_orgapachesolrhandlerXmlUpdateRequestHandlerprocessUpdateXmlUpdateRequestHandlerjava181__at_orgapachesolrhandlerXmlUpdateRequestHandlerhandleRequestBodyXmlUpdateRequestHandlerjava109__at_orgapachesolrhandlerRequestHandlerBasehandleRequestRequestHandlerBasejava78__at_orgapachesolrcoreSolrCoreexecuteSolrCorejava804__at_orgapachesolrservletSolrDispatchFilterexecuteSolrDispatchFilterjava193__at_orgapachesolrservletSolrDispatchFilterdoFilterSolrDispatchFilterjava161__at_orgmortbayjettyservletServletHandler$CachedChaindoFilterServletHandlerjava1089__at_orgmortbayjettyservletServletHandlerhandleServletHandlerjava365__at_orgmortbayjettysecuritySecurityHandlerhandleSecurityHandlerjava216__at_orgmortbayjettyservletSessionHandlerhandleSessionHandlerjava181__at_orgmortbayjettyhandlerContextHandlerhandleContextHandlerjava712__at_orgmortbayjettywebappWebAppContexthandleWebAppCont
[jira] Created: (SOLR-360) Multithread update client causes exceptions and dropped documents
Multithread update client causes exceptions and dropped documents - Key: SOLR-360 URL: https://issues.apache.org/jira/browse/SOLR-360 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.3 Environment: test fails on both pc + mac, tomcat + jetty all java 1.6 Reporter: Will Johnson we were doing some performance testing for the updating aspects of solr and ran into what seems to be a large problem. we're creating small documents with an id and one field of 1 term only submitting them in batches of 200 with commits every 5000 docs. when we run the client with 1 thread everything is fine. when we run it win >1 threads things go south (stack trace is below). i've attached the junit test which shows the problem. this happens on both a mac and a pc and when running solr in both jetty and tomcat. i'll create a junit issue if necessary but i thought i'd see if anyone else had run into this problem first. also, the problem does not seem to surface under solr1.2 (RyanM suggested it might be related to SOLR-215) (output from junit test) Started thread: 0 Started thread: 1 org.apache.solr.common.SolrException: Current_state_is_not_among_the_states_START_ELEMENT__ATTRIBUTEvalid_for_getAttributeCount__javalangIllegalStateException_Current_state_is_not_among_the_states_START_ELEMENT__ATTRIBUTEvalid_for_getAttributeCount__at_comsunorgapachexercesinternalimplXMLStreamReaderImplgetAttributeCountXMLStreamReaderImpljava598__at_orgapachesolrhandlerXmlUpdateRequestHandlerreadDocXmlUpdateRequestHandlerjava335__at_orgapachesolrhandlerXmlUpdateRequestHandlerprocessUpdateXmlUpdateRequestHandlerjava181__at_orgapachesolrhandlerXmlUpdateRequestHandlerhandleRequestBodyXmlUpdateRequestHandlerjava109__at_orgapachesolrhandlerRequestHandlerBasehandleRequestRequestHandlerBasejava78__at_orgapachesolrcoreSolrCoreexecuteSolrCorejava804__at_orgapachesolrservletSolrDispatchFilterexecuteSolrDispatchFilterjava193__at_orgapachesolrservletSolrDispatchFilterdoFilterSolrDispatchFilterjava161__at_orgmortbayjettyservletServletHandler$CachedChaindoFilterServletHandlerjava1089__at_orgmortbayjettyservletServletHandlerhandleServletHandlerjava365__at_orgmortbayjettysecuritySecurityHandlerhandleSecurityHandlerjava216__at_orgmortbayjettyservletSessionHandlerhandleSessionHandlerjava181__at_orgmortbayjettyhandlerContextHandlerhandleContextHandlerjava712__at_orgmortbayjettywebappWebAppContexthandleWebAppContextjava405__at_orgmortbayjettyhandlerContextHandlerCollectionhandleContextHandlerCollectionjava211__at_orgmortbayjettyhandlerHandlerCollectionhandleHandlerCollectionjava114__at_orgmortbayjettyhandlerHandlerWrapperhandleHandlerWrapperjava139__at_orgmortbayjettyServerhandleServerjava285__at_orgmortbayjettyHttpConnectionhandleRequestHttpConnectionjava502__at_orgmortbayjettyHttpConnection$RequestHandlercontentHttpConnectionjava835__at_orgmortbayjettyHttpParserparseNextHttpParserjava641__at_orgmortbayjettyHttpParserparseAvailableHttpParserjava208__at_orgmortbayje Current_state_is_not_among_the_states_START_ELEMENT__ATTRIBUTEvalid_for_getAttributeCount__javalangIllegalStateException_Current_state_is_not_among_the_states_START_ELEMENT__ATTRIBUTEvalid_for_getAttributeCount__at_comsunorgapachexercesinternalimplXMLStreamReaderImplgetAttributeCountXMLStreamReaderImpljava598__at_orgapachesolrhandlerXmlUpdateRequestHandlerreadDocXmlUpdateRequestHandlerjava335__at_orgapachesolrhandlerXmlUpdateRequestHandlerprocessUpdateXmlUpdateRequestHandlerjava181__at_orgapachesolrhandlerXmlUpdateRequestHandlerhandleRequestBodyXmlUpdateRequestHandlerjava109__at_orgapachesolrhandlerRequestHandlerBasehandleRequestRequestHandlerBasejava78__at_orgapachesolrcoreSolrCoreexecuteSolrCorejava804__at_orgapachesolrservletSolrDispatchFilterexecuteSolrDispatchFilterjava193__at_orgapachesolrservletSolrDispatchFilterdoFilterSolrDispatchFilterjava161__at_orgmortbayjettyservletServletHandler$CachedChaindoFilterServletHandlerjava1089__at_orgmortbayjettyservletServletHandlerhandleServletHandlerjava365__at_orgmortbayjettysecuritySecurityHandlerhandleSecurityHandlerjava216__at_orgmortbayjettyservletSessionHandlerhandleSessionHandlerjava181__at_orgmortbayjettyhandlerContextHandlerhandleContextHandlerjava712__at_orgmortbayjettywebappWebAppContexthandleWebAppContextjava405__at_orgmortbayjettyhandlerContextHandlerCollectionhandleContextHandlerCollectionjava211__at_orgmortbayjettyhandlerHandlerCollectionhandleHandlerCollectionjava114__at_orgmortbayjettyhandlerHandlerWrapperhandleHandlerWrapperjava139__at_orgmortbayjettyServerhandleServerjava285__at_orgmortbayjettyHttpConnectionhandleRequestHttpConnectionjava502__at_orgmortbayjettyHttpConnection$RequestHandlercontentHttpConnectionjava835__at_orgmortbayjettyHttpParserparseNextHttpParserjava641__at_orgmortbayjettyHttpParserparseAvailableHttpParserjava208__at_orgmortbayje r
[jira] Updated: (SOLR-192) Move FunctionQuery to Lucene
[ https://issues.apache.org/jira/browse/SOLR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-192: -- Attachment: SOLR-192-functionQueries.patch patch attached that uses the functionality from lucene instead of solr. there were some changes in the api in the solr->lucene transition so there was one api change to a private static method in solr.search.QueryParsing. this patch also relies on LUCENE-989 (http://issues.apache.org/jira/browse/LUCENE-989) to get access to field names. a future patch could then get access to the statistics for exposing in results. - will > Move FunctionQuery to Lucene > > > Key: SOLR-192 > URL: https://issues.apache.org/jira/browse/SOLR-192 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Grant Ingersoll > Attachments: SOLR-192-functionQueries.patch > > > FunctionQuery is a useful concept to have in Lucene core. Deprecate the Solr > implementation and migrate it Lucene core. Have the deprecated Solr version > call the Lucene version. > See https://issues.apache.org/jira/browse/LUCENE-446 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-192) Move FunctionQuery to Lucene
[ https://issues.apache.org/jira/browse/SOLR-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523042 ] Will Johnson commented on SOLR-192: --- is anyone currently working on doing this migration? i submitted a patch to the lucene project tracker (https://issues.apache.org/jira/browse/LUCENE-989) and was going to post a patch for solr to use the new features but the implementations look to be reasonably different. > Move FunctionQuery to Lucene > > > Key: SOLR-192 > URL: https://issues.apache.org/jira/browse/SOLR-192 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Grant Ingersoll > > FunctionQuery is a useful concept to have in Lucene core. Deprecate the Solr > implementation and migrate it Lucene core. Have the deprecated Solr version > call the Lucene version. > See https://issues.apache.org/jira/browse/LUCENE-446 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-215) Multiple Solr Cores
[
https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513912
]
Will Johnson commented on SOLR-215:
---
did anything ever get baked into the patch for handling the core name as a cgi
param instead of as a url path element? the email thread we had going didn't
seem to come to any hard conclusions but i'd like to lobby for it as a part of
the spec. i read through the patch but i couldn't quite follow things enough
to tell.
> Multiple Solr Cores
> ---
>
> Key: SOLR-215
> URL: https://issues.apache.org/jira/browse/SOLR-215
> Project: Solr
> Issue Type: Improvement
>Reporter: Henri Biestro
>Priority: Minor
> Attachments: solr-215.patch, solr-215.patch, solr-215.patch,
> solr-215.patch.zip, solr-215.patch.zip, solr-215.patch.zip,
> solr-215.patch.zip, solr-215.patch.zip, solr-215.patch.zip,
> solr-trunk-533775.patch, solr-trunk-538091.patch, solr-trunk-542847-1.patch,
> solr-trunk-542847.patch, solr-trunk-src.patch
>
>
> WHAT:
> As of 1.2, Solr only instantiates one SolrCore which handles one Lucene index.
> This patch is intended to allow multiple cores in Solr which also brings
> multiple indexes capability.
> The patch file to grab is solr-215.patch.zip (see MISC session below).
> WHY:
> The current Solr practical wisdom is that one schema - thus one index - is
> most likely to accomodate your indexing needs, using a filter to segregate
> documents if needed. If you really need multiple indexes, deploy multiple web
> applications.
> There are a some use cases however where having multiple indexes or multiple
> cores through Solr itself may make sense.
> Multiple cores:
> Deployment issues within some organizations where IT will resist deploying
> multiple web applications.
> Seamless schema update where you can create a new core and switch to it
> without starting/stopping servers.
> Embedding Solr in your own application (instead of 'raw' Lucene) and
> functionally need to segregate schemas & collections.
> Multiple indexes:
> Multiple language collections where each document exists in different
> languages, analysis being language dependant.
> Having document types that have nothing (or very little) in common with
> respect to their schema, their lifetime/update frequencies or even collection
> sizes.
> HOW:
> The best analogy is to consider that instead of deploying multiple
> web-application, you can have one web-application that hosts more than one
> Solr core. The patch does not change any of the core logic (nor the core
> code); each core is configured & behaves exactly as the one core in 1.2; the
> various caches are per-core & so is the info-bean-registry.
> What the patch does is replace the SolrCore singleton by a collection of
> cores; all the code modifications are driven by the removal of the different
> singletons (the config, the schema & the core).
> Each core is 'named' and a static map (keyed by name) allows to easily manage
> them.
> You declare one servlet filter mapping per core you want to expose in the
> web.xml; this allows easy to access each core through a different url.
> USAGE (example web deployment, patch installed):
> Step0
> java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar solr.xml
> monitor.ml
> Will index the 2 documents in solr.xml & monitor.xml
> Step1:
> http://localhost:8983/solr/core0/admin/stats.jsp
> Will produce the statistics page from the admin servlet on core0 index; 2
> documents
> Step2:
> http://localhost:8983/solr/core1/admin/stats.jsp
> Will produce the statistics page from the admin servlet on core1 index; no
> documents
> Step3:
> java -Durl='http://localhost:8983/solr/core0/update' -jar post.jar ipod*.xml
> java -Durl='http://localhost:8983/solr/core1/update' -jar post.jar mon*.xml
> Adds the ipod*.xml to index of core0 and the mon*.xml to the index of core1;
> running queries from the admin interface, you can verify indexes have
> different content.
> USAGE (Java code):
> //create a configuration
> SolrConfig config = new SolrConfig("solrconfig.xml");
> //create a schema
> IndexSchema schema = new IndexSchema(config, "schema0.xml");
> //create a core from the 2 other.
> SolrCore core = new SolrCore("core0", "/path/to/index", config, schema);
> //Accessing a core:
> SolrCore core = SolrCore.getCore("core0");
> PATCH MODIFICATIONS DETAILS (per package):
> org.apache.solr.core:
> The heaviest modifications are in SolrCore & SolrConfig.
> SolrCore is the most obvious modification; instead of a singleton, there is a
> static map of cores keyed by names and assorted methods. To retain some
> compatibility, the 'null' named core replaces the singleton for the relevant
> methods, for instance SolrCore.getCore(). One small constraint on the core
> name is they can't contain '/' or '\' avoiding
[jira] Updated: (SOLR-312) create solrj javadoc in build.xml
[ https://issues.apache.org/jira/browse/SOLR-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-312: -- Attachment: create-solrj-javadoc.patch simple patch to add new task > create solrj javadoc in build.xml > - > > Key: SOLR-312 > URL: https://issues.apache.org/jira/browse/SOLR-312 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.3 > Environment: a new task in build.xml named javadoc-solrj that does > pretty much what you'd expect. creates a new fold build/docs/api-solrj. > heavily based on the example from the solr core javadoc target. >Reporter: Will Johnson >Priority: Minor > Fix For: 1.3 > > Attachments: create-solrj-javadoc.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-312) create solrj javadoc in build.xml
create solrj javadoc in build.xml - Key: SOLR-312 URL: https://issues.apache.org/jira/browse/SOLR-312 Project: Solr Issue Type: New Feature Components: clients - java Affects Versions: 1.3 Environment: a new task in build.xml named javadoc-solrj that does pretty much what you'd expect. creates a new fold build/docs/api-solrj. heavily based on the example from the solr core javadoc target. Reporter: Will Johnson Priority: Minor Fix For: 1.3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-267) log handler + query + hits
[ https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-267: -- Attachment: LogQueryHitCounts.patch new path produces the following output: Jul 11, 2007 1:35:19 PM org.apache.solr.core.SolrCore execute INFO: webapp=/solr path=/select/ params=indent=on&start=0&q=solr&version=2.2&rows=10 hits=0 status=0 QTime=79 and adds a NamedList toLog as yonik suggested. > log handler + query + hits > -- > > Key: SOLR-267 > URL: https://issues.apache.org/jira/browse/SOLR-267 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.3 > > Attachments: LogQueryHitCounts.patch, LogQueryHitCounts.patch, > LogQueryHitCounts.patch, LogQueryHitCounts.patch, LogQueryHitCounts.patch, > LogQueryHitCounts.patch, LogQueryHitCounts.patch > > > adds a logger to log handler, query string and hit counts for each query -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-280) slightly more efficient SolrDocument implementation
[ https://issues.apache.org/jira/browse/SOLR-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-280: -- Attachment: SOLR-280-SolrDocument2-API-Compatibility.patch >The API changes mostly affect solrj users. being one of those heavily affected users i created the attached patch to make us unaffected. (or at least i went from a few hundred compile errors to 0) the following methods were added back and are mostly 1-5 line wrappers to the existing methods or underlying datastructures. setField(String, Object) getFieldValue(String) getFieldValues(String) addField(String, Object) getFieldNames() - will > slightly more efficient SolrDocument implementation > --- > > Key: SOLR-280 > URL: https://issues.apache.org/jira/browse/SOLR-280 > Project: Solr > Issue Type: Improvement >Reporter: Ryan McKinley >Assignee: Ryan McKinley >Priority: Minor > Attachments: SOLR-280-SolrDocument2-API-Compatibility.patch, > SOLR-280-SolrDocument2.patch, SOLR-280-SolrDocument2.patch > > > Following discussion in SOLR-272 > This implementation stores fields as a Map rather then a > Map>. The API changes slightly in that: > getFieldValue( name ) returns a Collection if there are more then one fields > and a Object if there is only one. > getFirstValue( name ) returns a single value for the field. This is intended > to make things easier for client applications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-278) LukeRequest/Response for handling show=schema
[ https://issues.apache.org/jira/browse/SOLR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509160 ] Will Johnson commented on SOLR-278: --- I guess I was hoping for a super set of features in LukeResponse.FieldInfo which will be partially set by the schema and partially set by the luke-ish info. We could be even merge the two if it made sense. In the end I need to get a list of "fields that solr currently knows about" which seems to be a grouping of both the schema and the index via dynamic fields. The current patch does this but I think there is a better approach somewhere out there. - will > LukeRequest/Response for handling show=schema > - > > Key: SOLR-278 > URL: https://issues.apache.org/jira/browse/SOLR-278 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 1.3 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.3 > > Attachments: LukeSchemaHandling.patch > > > the soon to be attached patch adds a method to LukeRequest to set the option > for showing schema from SOLR-266. the patch also modifies LukeRepsonse to > handle the schema info in the same manner as the fields from the 'normal' > luke response. i think it's worth talking about unifying the response format > so that they aren't different but that's a larger discussion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-278) LukeRequest/Response for handling show=schema
[ https://issues.apache.org/jira/browse/SOLR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-278: -- Attachment: LukeSchemaHandling.patch > LukeRequest/Response for handling show=schema > - > > Key: SOLR-278 > URL: https://issues.apache.org/jira/browse/SOLR-278 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 1.3 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.3 > > Attachments: LukeSchemaHandling.patch > > > the soon to be attached patch adds a method to LukeRequest to set the option > for showing schema from SOLR-266. the patch also modifies LukeRepsonse to > handle the schema info in the same manner as the fields from the 'normal' > luke response. i think it's worth talking about unifying the response format > so that they aren't different but that's a larger discussion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-278) LukeRequest/Response for handling show=schema
LukeRequest/Response for handling show=schema - Key: SOLR-278 URL: https://issues.apache.org/jira/browse/SOLR-278 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 1.3 Reporter: Will Johnson Priority: Minor Fix For: 1.3 the soon to be attached patch adds a method to LukeRequest to set the option for showing schema from SOLR-266. the patch also modifies LukeRepsonse to handle the schema info in the same manner as the fields from the 'normal' luke response. i think it's worth talking about unifying the response format so that they aren't different but that's a larger discussion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-267) log handler + query + hits
[ https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-267: -- Attachment: LogQueryHitCounts.patch new patch that writes out request params as cgi instead of NL.toString() for pasting into a browser. i also figured out the HttpResponseHeader however i'm not sure how people feel about having that info duplicated in teh solr logs, the http headers/access logs and the actual solr response. in any case the following logic would go into SolrDispatchFilter: (but is not in this patch) > log handler + query + hits > -- > > Key: SOLR-267 > URL: https://issues.apache.org/jira/browse/SOLR-267 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.3 > > Attachments: LogQueryHitCounts.patch, LogQueryHitCounts.patch, > LogQueryHitCounts.patch, LogQueryHitCounts.patch, LogQueryHitCounts.patch, > LogQueryHitCounts.patch > > > adds a logger to log handler, query string and hit counts for each query -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-267) log handler + query + hits
[ https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508163 ] Will Johnson commented on SOLR-267: --- A few response rolled up: Yonik Seeley commented on SOLR-267: --- After having used this for a ~week now I kind of do too. I can work on a patch that switches that log component back unless someone else (who wants it more) beats me to it. "hits". Agreed, I'd love to have query pipelines and indexing pipelines for processing logic but that's a much bigger effort. At the moment it's only 1 line extra in each of the 'real' query handlers which doesn't seem too bad. Ian Holsman commented on SOLR-267: -- long? >you might need/want to put in some quotes are the query. It will look very long :) As long as there are no spaces which the url encoding should handle I think things are ok (this assumes we're going to switch back to cgi params) it >in) Not that I know how to do. Since the dispatch filter is a filter not a servlet it doesn't have access to an HttpServletResponse, only a ServletResponse which means it can't set HttpHeaders. This was my original idea for how to solve this problem and seems a bit more 'standard' anyways but I hit a dead end without getting more hackish than usual. - will > log handler + query + hits > -- > > Key: SOLR-267 > URL: https://issues.apache.org/jira/browse/SOLR-267 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.3 > > Attachments: LogQueryHitCounts.patch, LogQueryHitCounts.patch, > LogQueryHitCounts.patch, LogQueryHitCounts.patch, LogQueryHitCounts.patch > > > adds a logger to log handler, query string and hit counts for each query -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-267) log handler + query + hits
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-267:
--
Attachment: LogQueryHitCounts.patch
new patch to promote responseHeader from a defacto standard to an api standard
in SolrQueryResponse. this enables the SolrCore.execute() method to simply
print out it's contents containing any info people want logged. the format now
is:
Jun 22, 2007 10:37:25 AM org.apache.solr.core.SolrCore execute
INFO: webapp=/solr path=/select/ hits=0 status=0 QTime=0
params={indent=on,start=0,q=solr,version=2.2,rows=10}
which is fully labeled but i think mkaes things much easier to read/parse as
you can look for labels instead of positions which may or may not change.
> log handler + query + hits
> --
>
> Key: SOLR-267
> URL: https://issues.apache.org/jira/browse/SOLR-267
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
>Reporter: Will Johnson
>Priority: Minor
> Fix For: 1.3
>
> Attachments: LogQueryHitCounts.patch, LogQueryHitCounts.patch,
> LogQueryHitCounts.patch, LogQueryHitCounts.patch, LogQueryHitCounts.patch
>
>
> adds a logger to log handler, query string and hit counts for each query
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-267) log handler + query + hits
[
https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12507312
]
Will Johnson commented on SOLR-267:
---
One thing that comes to mind is making the response header a standard
part of the SolrQueryResponse object with get/set/add methods then the
log message can just print out what ever is in the response header. With
trunk, it already contains much of the same data (status, qtime,
params). The only issue is that in order to keep things 'clean' the
output would change to being fully labeled:
webapp=/solr path=/select/ status=0 QTime=63
params={indent=on,start=0,q=*:*,version=2.2,rows=10} myotherheader=foo
In general I think this makes things much cleaner and easier to read but
it does break backwards compatibility for log parsing purposes. Any
other ideas?
- will
> log handler + query + hits
> --
>
> Key: SOLR-267
> URL: https://issues.apache.org/jira/browse/SOLR-267
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
>Reporter: Will Johnson
>Priority: Minor
> Fix For: 1.3
>
> Attachments: LogQueryHitCounts.patch, LogQueryHitCounts.patch,
> LogQueryHitCounts.patch, LogQueryHitCounts.patch
>
>
> adds a logger to log handler, query string and hit counts for each query
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
[ https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506983 ] Will Johnson commented on SOLR-240: --- longer >>than without. No, after I applied the patch I have never seen a lockup. oldest Solr collections have been running in CNET for 2 years now, and I've never seen this happen). What I *have* seen is that exact exception when the server died, restarted, and then couldn't grab the write lock normally due to not a big enough heap causing excessive GC and leading resin's wrapper to restart the container. Another reason to use native locking. From the lucene native fs lock javadocs: "Furthermore, if the JVM crashes, the OS will free any held locks, whereas SimpleFSLockFactory will keep the locks held, requiring manual removal before re-running Lucene." My hunch (and that's all it is) is that people seeing/not seeing the issue may come down to usage patterns. My project is heavily focused on low indexing latency so we're doing huge numbers of add/deletes/commits/searches in very fast succession and from multiple clients. A more batch oriented update usage pattern may not see the issue. The patch because as is, it doesn't change any api or cause any change of existing functionality whatsoever unless you use the new option in solrconfig. I would argue that using native locking should be the default though. - will > java.io.IOException: Lock obtain timed out: SimpleFSLock > > > Key: SOLR-240 > URL: https://issues.apache.org/jira/browse/SOLR-240 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 1.2 > Environment: windows xp >Reporter: Will Johnson > Attachments: IndexWriter.patch, IndexWriter2.patch, stacktrace.txt, > ThrashIndex.java > > > when running the soon to be attached sample application against solr it will > eventually die. this same error has happened on both windows and rh4 linux. > the app is just submitting docs with an id in batches of 10, performing a > commit then repeating over and over again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-267) log handler + query + hits
[ https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-267: -- Attachment: LogQueryHitCounts.patch slight update to log the webapp name which is set in the SolrDispatchFilter. this lets you distinguish between multiple solr instances for tracking purposes. log output now looks like: Jun 21, 2007 10:31:05 AM org.apache.solr.core.SolrCore execute INFO: /solr /select/ indent=on&start=0&q=*:*&version=2.2&rows=10 hits=5 0 62 > log handler + query + hits > -- > > Key: SOLR-267 > URL: https://issues.apache.org/jira/browse/SOLR-267 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.3 > > Attachments: LogQueryHitCounts.patch, LogQueryHitCounts.patch, > LogQueryHitCounts.patch, LogQueryHitCounts.patch > > > adds a logger to log handler, query string and hit counts for each query -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-267) log handler + query + hits
[ https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-267: -- Attachment: LogQueryHitCounts.patch updated patch to work in SolrCore.execute() instead. i annotated the msg with hits=## as requested however i left time unlabeled for backwards compatibility and i had no idea what the static '0' was but i left it there just to be safe as well. i think i tmight be good to clean that up and i'm happy to but i don't know who or how those numbers are being used today. > log handler + query + hits > -- > > Key: SOLR-267 > URL: https://issues.apache.org/jira/browse/SOLR-267 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.3 > > Attachments: LogQueryHitCounts.patch, LogQueryHitCounts.patch > > > adds a logger to log handler, query string and hit counts for each query -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-267) log handler + query + hits
[ https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-267: -- Description: adds a logger to log handler, query string and hit counts for each query was: adds a logger Summary: log handler + query + hits (was: log handler + query + ) > log handler + query + hits > -- > > Key: SOLR-267 > URL: https://issues.apache.org/jira/browse/SOLR-267 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.3 > > Attachments: LogQueryHitCounts.patch > > > adds a logger to log handler, query string and hit counts for each query -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-267) log handler + query +
[ https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-267: -- Attachment: LogQueryHitCounts.patch hit a random key a little fast on the last post. the attached patch adds a logger to the Standard and DisMax request handlers to log the hander name, query string and hit count for each query. > log handler + query + > -- > > Key: SOLR-267 > URL: https://issues.apache.org/jira/browse/SOLR-267 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.3 > > Attachments: LogQueryHitCounts.patch > > > adds a logger -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-267) log handler + query +
log handler + query + -- Key: SOLR-267 URL: https://issues.apache.org/jira/browse/SOLR-267 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Will Johnson Priority: Minor Fix For: 1.3 adds a logger -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-176) Add detailed timing data to query response output
[ https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-176: -- Attachment: RequesthandlerBase.patch a slightly more ambitious patch that tracks: * total number of requests/errors * requests/errors in the current interval (interval defined in solrconfig) * requets/errors as of the start of the last interval * avg requet times for total / current interval > Add detailed timing data to query response output > - > > Key: SOLR-176 > URL: https://issues.apache.org/jira/browse/SOLR-176 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.2 >Reporter: Mike Klaas >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: dtiming.patch, dtiming.patch, dtiming.patch, > dtiming.patch, RequesthandlerBase.patch, RequesthandlerBase.patch > > > see > http://www.nabble.com/%27accumulate%27-copyField-for-faceting-tf3329986.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-265) Make IndexSchema updateable in live system
[ https://issues.apache.org/jira/browse/SOLR-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505938 ] Will Johnson commented on SOLR-265: --- After doing some more thinking about the issue after I submitted the patch I agree that there probably are some threading issues to work out. I was working on another approach that was much larger (only keep 1 copy in SolrCore accessible by getSchema() and add protection there) but that required a much larger code change than the one posted so I went with the shorter to at least promote discussion. If the single schema getter() makes sense, I'll be happy to provide such a patch. There do seem to be other alternatives though: First is a ModifySchema handler that could support adding fields etc which should be easier to defend against from a synchronization standpoint. At least there are fewer times when fields.clear() has been called but new values have not been added back. As this is all I care about at the moment I'd be happy, but I assume someone might want to do something else more complex. The second is to wrap up the clear/repopulate methods with some basic protection but actually allow different schemas inside a single request. This could be done by requiring all new schemas to be 'compatible' in some defined way. Since there doesn't seem to be any validation that goes on if I stop the app, change the schema and then restart it, compatible might just mean valid xml. If field 'new_x' suddenly appears during the middle of my post it shouldn't have any effect as my posted data won't contain 'new_x.' from a client's contractual perspective, if you want new fields processed correctly you have to wait for updateSchema to finish. In any case, it seems to me that restarting a webapp and suffering downtime is a heavy price to pay just to add a new field or even to just change an existing field property. - will > Make IndexSchema updateable in live system > -- > > Key: SOLR-265 > URL: https://issues.apache.org/jira/browse/SOLR-265 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.3 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.3 > > Attachments: IndexSchemaReload.patch > > > I've seen a few items on the mailing lists recently surrounding updating a > schema on the file system and not seeing the changes get propagated. while I > think that automatically detecting schema changes on disk may be unrealistic, > I do think it would be useful to be able to update the schema without having > to bounce the webapp. the forthcoming patch adds a method to SolrCore to do > just that as well as a request handler to be able to call said method. > The patch as it exists is a straw man for discussion. The one thing that > concerned me was making IndexScheam schema non-final in SolrCore. I'm not > quite sure why it needs to be final to begin with so perhaps someone can shed > some light on the situation. Also, I think it would be useful to be able to > upload a schema through the admin GUI, have it persisted to disk and then > call relaodSchema()but that seemed like a good bit of effort for a patch that > might not even be a good idea. > I'd also point out that this specific problem is one I've been trying to > address recently and while I think it could be solved with various dynamic > fields the combination of all the options for fields seemed to create too > many variables to make useful dynamic name patterns. > Thoughts? > - will -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-265) Make IndexSchema updateable in live system
[ https://issues.apache.org/jira/browse/SOLR-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-265: -- Attachment: IndexSchemaReload.patch updates to: * solconfig.xml to register handler * IndexSchema to add reload() method that clears() all internal data structures and calls readconfig() * a new o.a.s.handler.admin.IndexSchemaRequestHandler to trigger the updating > Make IndexSchema updateable in live system > -- > > Key: SOLR-265 > URL: https://issues.apache.org/jira/browse/SOLR-265 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.3 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.3 > > Attachments: IndexSchemaReload.patch > > > I've seen a few items on the mailing lists recently surrounding updating a > schema on the file system and not seeing the changes get propagated. while I > think that automatically detecting schema changes on disk may be unrealistic, > I do think it would be useful to be able to update the schema without having > to bounce the webapp. the forthcoming patch adds a method to SolrCore to do > just that as well as a request handler to be able to call said method. > The patch as it exists is a straw man for discussion. The one thing that > concerned me was making IndexScheam schema non-final in SolrCore. I'm not > quite sure why it needs to be final to begin with so perhaps someone can shed > some light on the situation. Also, I think it would be useful to be able to > upload a schema through the admin GUI, have it persisted to disk and then > call relaodSchema()but that seemed like a good bit of effort for a patch that > might not even be a good idea. > I'd also point out that this specific problem is one I've been trying to > address recently and while I think it could be solved with various dynamic > fields the combination of all the options for fields seemed to create too > many variables to make useful dynamic name patterns. > Thoughts? > - will -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-265) Make IndexSchema updateable in live system
Make IndexSchema updateable in live system -- Key: SOLR-265 URL: https://issues.apache.org/jira/browse/SOLR-265 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.3 Reporter: Will Johnson Priority: Minor Fix For: 1.3 I've seen a few items on the mailing lists recently surrounding updating a schema on the file system and not seeing the changes get propagated. while I think that automatically detecting schema changes on disk may be unrealistic, I do think it would be useful to be able to update the schema without having to bounce the webapp. the forthcoming patch adds a method to SolrCore to do just that as well as a request handler to be able to call said method. The patch as it exists is a straw man for discussion. The one thing that concerned me was making IndexScheam schema non-final in SolrCore. I'm not quite sure why it needs to be final to begin with so perhaps someone can shed some light on the situation. Also, I think it would be useful to be able to upload a schema through the admin GUI, have it persisted to disk and then call relaodSchema()but that seemed like a good bit of effort for a patch that might not even be a good idea. I'd also point out that this specific problem is one I've been trying to address recently and while I think it could be solved with various dynamic fields the combination of all the options for fields seemed to create too many variables to make useful dynamic name patterns. Thoughts? - will -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-239) Read IndexSchema from InputStream instead of Config file
[ https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505846 ] Will Johnson commented on SOLR-239: --- after looking at all the dependencies for IndexSchema and with the addition of the new solrj stuff in trunk i no longer think this approach is the correct way to go about things. the LukeRequest/LukeResponse seems to give most of the same info with ~0 overhead and it's already checked in. > Read IndexSchema from InputStream instead of Config file > > > Key: SOLR-239 > URL: https://issues.apache.org/jira/browse/SOLR-239 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.2 > Environment: all >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: IndexSchemaStream.patch, IndexSchemaStream2.patch, > IndexSchemaStream2.patch, IndexSchemaStream2.patch, IndexSchemaStream2.patch, > IndexSchemaStream2.patch > > > Soon to follow patch adds a constructor to IndexSchema to allow them to be > created directly from InputStreams. The overall logic for the Core's use of > the IndexSchema creation/use does not change however this allows java clients > like those in SOLR-20 to be able to parse an IndexSchema. Once a schema is > parsed, the client can inspect an index's capabilities which is useful for > building generic search UI's. ie provide a drop down list of fields to > search/sort by. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-259) More descriptive text on improperly set solr/home
[ https://issues.apache.org/jira/browse/SOLR-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-259: -- Attachment: betterSolrHomeError.patch +import java.util.logging.Level and a simple log.log(Level.SEVERE, "Could not start SOLR. Check solr/home property", t); > More descriptive text on improperly set solr/home > - > > Key: SOLR-259 > URL: https://issues.apache.org/jira/browse/SOLR-259 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: betterSolrHomeError.patch > > > when solr/home is set improperly, tomcat (and other containers) fail to log > any useful error messages because everything goes to SolrConfig.severeErrors > instead of some basic container level logs. the soon to be attached 1.5 line > patch adds a simple log message to the standard container logs to tell you to > check your settings and tell you what solr/home is currently set to. > Before the patch if solr/home is improperly set you get: > Jun 11, 2007 2:21:13 PM org.apache.solr.servlet.SolrDispatchFilter init > INFO: SolrDispatchFilter.init() > Jun 11, 2007 2:21:13 PM org.apache.solr.core.Config getInstanceDir > INFO: Using JNDI solr.home: > C:\data\workspace\gciTrunk\infrastructure\gciSolr\build\solr > Jun 11, 2007 2:21:13 PM org.apache.solr.core.Config setInstanceDir > INFO: Solr home set to > 'C:\data\workspace\gciTrunk\infrastructure\gciSolr\build\solr/' > Jun 11, 2007 2:21:13 PM org.apache.catalina.core.StandardContext start > SEVERE: Error filterStart > Jun 11, 2007 2:21:13 PM org.apache.catalina.core.StandardContext start > SEVERE: Context [/solr] startup failed due to previous errors > After the patch you get: > un 11, 2007 2:30:37 PM org.apache.solr.servlet.SolrDispatchFilter init > INFO: SolrDispatchFilter.init() > Jun 11, 2007 2:30:37 PM org.apache.solr.core.Config getInstanceDir > INFO: Using JNDI solr.home: > C:\data\workspace\gciTrunk\infrastructure\gciSolr\build\solr > Jun 11, 2007 2:30:37 PM org.apache.solr.core.Config setInstanceDir > INFO: Solr home set to > 'C:\data\workspace\gciTrunk\infrastructure\gciSolr\build\solr/' > Jun 11, 2007 2:30:37 PM org.apache.solr.servlet.SolrDispatchFilter init > SEVERE: Could not start SOLR. Check solr/home property > java.lang.ExceptionInInitializerError > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:66) > at > org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275) > at > org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397) > at > org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108) > at > org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3693) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4340) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) > at > org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626) > at > org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553) > at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488) > at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1206) > at > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:293) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) > at > org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337) > at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601) > at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) > at > org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590) > at java.lang.Thread.run(Thread.java:619) > Caused by: java.lang.RuntimeException: Error in solrconfig.xml > at org.apache.solr.core.SolrConfig.(SolrConfig.java:90) > ... 20 more > Caused by: java.lang.RuntimeException: Can't find resource 'solrconfig.xml' > in classpath or > 'C:\data\workspace\gciTrunk\infrastructure\gciSolr\build\solr/conf/', > cwd=C:\data\apps\tomcat6.0.13\bin > at org.apache.solr.core.Config.openResource(Config.java:357) > at org.apache.solr.core.SolrConfig.initConfig(SolrConfig.java:79) > at org.apache.solr.core.SolrConfig.(SolrConfig.java
[jira] Created: (SOLR-259) More descriptive text on improperly set solr/home
More descriptive text on improperly set solr/home - Key: SOLR-259 URL: https://issues.apache.org/jira/browse/SOLR-259 Project: Solr Issue Type: Improvement Affects Versions: 1.2 Reporter: Will Johnson Priority: Minor Fix For: 1.2 when solr/home is set improperly, tomcat (and other containers) fail to log any useful error messages because everything goes to SolrConfig.severeErrors instead of some basic container level logs. the soon to be attached 1.5 line patch adds a simple log message to the standard container logs to tell you to check your settings and tell you what solr/home is currently set to. Before the patch if solr/home is improperly set you get: Jun 11, 2007 2:21:13 PM org.apache.solr.servlet.SolrDispatchFilter init INFO: SolrDispatchFilter.init() Jun 11, 2007 2:21:13 PM org.apache.solr.core.Config getInstanceDir INFO: Using JNDI solr.home: C:\data\workspace\gciTrunk\infrastructure\gciSolr\build\solr Jun 11, 2007 2:21:13 PM org.apache.solr.core.Config setInstanceDir INFO: Solr home set to 'C:\data\workspace\gciTrunk\infrastructure\gciSolr\build\solr/' Jun 11, 2007 2:21:13 PM org.apache.catalina.core.StandardContext start SEVERE: Error filterStart Jun 11, 2007 2:21:13 PM org.apache.catalina.core.StandardContext start SEVERE: Context [/solr] startup failed due to previous errors After the patch you get: un 11, 2007 2:30:37 PM org.apache.solr.servlet.SolrDispatchFilter init INFO: SolrDispatchFilter.init() Jun 11, 2007 2:30:37 PM org.apache.solr.core.Config getInstanceDir INFO: Using JNDI solr.home: C:\data\workspace\gciTrunk\infrastructure\gciSolr\build\solr Jun 11, 2007 2:30:37 PM org.apache.solr.core.Config setInstanceDir INFO: Solr home set to 'C:\data\workspace\gciTrunk\infrastructure\gciSolr\build\solr/' Jun 11, 2007 2:30:37 PM org.apache.solr.servlet.SolrDispatchFilter init SEVERE: Could not start SOLR. Check solr/home property java.lang.ExceptionInInitializerError at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:66) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:275) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:397) at org.apache.catalina.core.ApplicationFilterConfig.(ApplicationFilterConfig.java:108) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3693) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4340) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:626) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:553) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:488) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1206) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:293) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.RuntimeException: Error in solrconfig.xml at org.apache.solr.core.SolrConfig.(SolrConfig.java:90) ... 20 more Caused by: java.lang.RuntimeException: Can't find resource 'solrconfig.xml' in classpath or 'C:\data\workspace\gciTrunk\infrastructure\gciSolr\build\solr/conf/', cwd=C:\data\apps\tomcat6.0.13\bin at org.apache.solr.core.Config.openResource(Config.java:357) at org.apache.solr.core.SolrConfig.initConfig(SolrConfig.java:79) at org.apache.solr.core.SolrConfig.(SolrConfig.java:87) ... 20 more Jun 11, 2007 2:30:37 PM org.apache.catalina.core.StandardContext start SEVERE: Error filterStart Jun 11, 2007 2:30:37 PM org.apache.catalina.core.StandardContext start SEVERE: Context [/solr] startup failed due to previous errors -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-239) Read IndexSchema from InputStream instead of Config file
[ https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-239: -- Attachment: IndexSchemaStream2.patch new patch that includes a GetFile servlet to possibly replace get-file.jsp due to the fact that it writes out invalid xml. > Read IndexSchema from InputStream instead of Config file > > > Key: SOLR-239 > URL: https://issues.apache.org/jira/browse/SOLR-239 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.2 > Environment: all >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: IndexSchemaStream.patch, IndexSchemaStream2.patch, > IndexSchemaStream2.patch, IndexSchemaStream2.patch, IndexSchemaStream2.patch, > IndexSchemaStream2.patch > > > Soon to follow patch adds a constructor to IndexSchema to allow them to be > created directly from InputStreams. The overall logic for the Core's use of > the IndexSchema creation/use does not change however this allows java clients > like those in SOLR-20 to be able to parse an IndexSchema. Once a schema is > parsed, the client can inspect an index's capabilities which is useful for > building generic search UI's. ie provide a drop down list of fields to > search/sort by. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-239) Read IndexSchema from InputStream instead of Config file
[ https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-239: -- Attachment: IndexSchemaStream2.patch New patch that address all 6 suggestions. The one thing that is interesting is that using http://localhost:8983/solr/admin/get-file.jsp?file=schema.xml does not work as it prints out a number of newlines before the XML declaration which causes it to be invalid. I'm not quite sure how to fix this without rewriting get-file.jsp as a servlet and making sure it only prints out the xml. In any case it does work against url's that only contain valid xml however I wasn't sure how we go about testing things that require the example to be running. (the test is therefore commented out) as for motivations, yes it does require a good bit of overhead and i think it would be good to have a 'lighter' IndexSchema implementation for client api's. i do think however that it's nice to know exactly what is running and to be able to inspect each fields capabilities so i'm not sure what the right thing to do is. - will > Read IndexSchema from InputStream instead of Config file > > > Key: SOLR-239 > URL: https://issues.apache.org/jira/browse/SOLR-239 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.2 > Environment: all >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: IndexSchemaStream.patch, IndexSchemaStream2.patch, > IndexSchemaStream2.patch, IndexSchemaStream2.patch, IndexSchemaStream2.patch > > > Soon to follow patch adds a constructor to IndexSchema to allow them to be > created directly from InputStreams. The overall logic for the Core's use of > the IndexSchema creation/use does not change however this allows java clients > like those in SOLR-20 to be able to parse an IndexSchema. Once a schema is > parsed, the client can inspect an index's capabilities which is useful for > building generic search UI's. ie provide a drop down list of fields to > search/sort by. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-239) Read IndexSchema from InputStream instead of Config file
[ https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500704 ] Will Johnson commented on SOLR-239: --- after seeing that i'd need to regenerate a patch for the new IndexSchema's SolrException handling i got to thinking about ways to preserve the getInputStream() functionality. tracing things down a bit it seems to all fall to Config.openResource(fileName). i was wondering if it might not be better to extend that code to handle URL's as well as file names by looking for http:// at the beginning of the resourceName. this might open up other avenues for centralized configuration of all of solr in the future but it does at least solve this problem and maintain more backwards compatibility with the existing api. thoughts? > Read IndexSchema from InputStream instead of Config file > > > Key: SOLR-239 > URL: https://issues.apache.org/jira/browse/SOLR-239 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.2 > Environment: all >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: IndexSchemaStream.patch, IndexSchemaStream2.patch, > IndexSchemaStream2.patch, IndexSchemaStream2.patch > > > Soon to follow patch adds a constructor to IndexSchema to allow them to be > created directly from InputStreams. The overall logic for the Core's use of > the IndexSchema creation/use does not change however this allows java clients > like those in SOLR-20 to be able to parse an IndexSchema. Once a schema is > parsed, the client can inspect an index's capabilities which is useful for > building generic search UI's. ie provide a drop down list of fields to > search/sort by. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
[ https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499843 ] Will Johnson commented on SOLR-240: --- i get the stacktrace below with the latest from head with useNativeLocks turned off (from my patch). this took about 2 minutes to reproduce on my windows laptop. one thing i thought of is that local antivirus scanning / backup software which we run here may be getting in the way. i know many other search engines / high performance databases out there have issues with antivirus software because it causes similar locking issues. i'm disabling as much of the IT 'malware' as possible and seeing better results even with default locking however i had everything running when i had good results with the native locking enabled so it still seems to be a good idea to use the patch (or something similar). - will SEVERE: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: [EMAIL PROTECTED] b822c61c394dd5f449aaf5e5717356-write.lock at org.apache.lucene.store.Lock.obtain(Lock.java:70) at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:579) at org.apache.lucene.index.IndexWriter.(IndexWriter.java:391) at org.apache.solr.update.SolrIndexWriter.(SolrIndexWriter.java:81) at org.apache.solr.update.UpdateHandler.createMainIndexWriter(UpdateHandler.java:120) at org.apache.solr.update.DirectUpdateHandler2.openWriter(DirectUpdateHandler2.java:181) at org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:259) at org.apache.solr.handler.XmlUpdateRequestHandler.update(XmlUpdateRequestHandler.java:166) at org.apache.solr.handler.XmlUpdateRequestHandler.handleRequestBody(XmlUpdateRequestHandler.java:84) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:79) at org.apache.solr.core.SolrCore.execute(SolrCore.java:658) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:198) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:166) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:285) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:835) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:641) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:368) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) > java.io.IOException: Lock obtain timed out: SimpleFSLock > > > Key: SOLR-240 > URL: https://issues.apache.org/jira/browse/SOLR-240 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 1.2 > Environment: windows xp >Reporter: Will Johnson > Attachments: IndexWriter.patch, IndexWriter2.patch, stacktrace.txt, > ThrashIndex.java > > > when running the soon to be attached sample application against solr it will > eventually die. this same error has happened on both windows and rh4 linux. > the app is just submitting docs with an id in batches of 10, performing a > commit then repeating over and over again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-239) Read IndexSchema from InputStream instead of Config file
[ https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-239: -- Attachment: IndexSchemaStream2.patch updated with fixed and test raw-schema.jsp and added back the IndexSchema testDynamicCopy() test. > Read IndexSchema from InputStream instead of Config file > > > Key: SOLR-239 > URL: https://issues.apache.org/jira/browse/SOLR-239 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.2 > Environment: all >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: IndexSchemaStream.patch, IndexSchemaStream2.patch, > IndexSchemaStream2.patch, IndexSchemaStream2.patch > > > Soon to follow patch adds a constructor to IndexSchema to allow them to be > created directly from InputStreams. The overall logic for the Core's use of > the IndexSchema creation/use does not change however this allows java clients > like those in SOLR-20 to be able to parse an IndexSchema. Once a schema is > parsed, the client can inspect an index's capabilities which is useful for > building generic search UI's. ie provide a drop down list of fields to > search/sort by. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-239) Read IndexSchema from InputStream instead of Config file
[ https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-239: -- Attachment: IndexSchemaStream2.patch the attached patch (IndexSchemaStream2.patch) includes a cleaned up test case as well as making the IndexSchema constructors throw a SolrException since they are reading InputStreams (which they were before). i think perhaps they should throw something a big 'stronger' but that seemed to have more wide-reaching implications. > Read IndexSchema from InputStream instead of Config file > > > Key: SOLR-239 > URL: https://issues.apache.org/jira/browse/SOLR-239 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.2 > Environment: all >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: IndexSchemaStream.patch, IndexSchemaStream2.patch, > IndexSchemaStream2.patch > > > Soon to follow patch adds a constructor to IndexSchema to allow them to be > created directly from InputStreams. The overall logic for the Core's use of > the IndexSchema creation/use does not change however this allows java clients > like those in SOLR-20 to be able to parse an IndexSchema. Once a schema is > parsed, the client can inspect an index's capabilities which is useful for > building generic search UI's. ie provide a drop down list of fields to > search/sort by. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-176) Add detailed timing data to query response output
[ https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-176: -- Attachment: RequesthandlerBase.patch added some average stats to RequestHandlerBase. all of the same info can be obtained by parsing the log files but having it show up on the admin screens and jmx is simple and nice to have. stats added: avgTimePerRequest and avgRequestsPerSecond. > Add detailed timing data to query response output > - > > Key: SOLR-176 > URL: https://issues.apache.org/jira/browse/SOLR-176 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.2 >Reporter: Mike Klaas > Assigned To: Mike Klaas >Priority: Minor > Fix For: 1.2 > > Attachments: dtiming.patch, dtiming.patch, RequesthandlerBase.patch > > > see > http://www.nabble.com/%27accumulate%27-copyField-for-faceting-tf3329986.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
[ https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-240: -- Attachment: IndexWriter2.patch the attached patch adds a param to SolrIndexConfig called useNativeLocks. the default is false which will keeps with the existing design using SimpleFSLockFactory. if people think we should allow fully pluggable locking mechanisms i'm game but i wasn't quite sure how to tackle that problem. as for testing, i wasn't quite sure how to run tests to ensure that the locks were working beyond some basic println's (which passed). if anyone has good ideas i'm all ears. - will > java.io.IOException: Lock obtain timed out: SimpleFSLock > > > Key: SOLR-240 > URL: https://issues.apache.org/jira/browse/SOLR-240 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 1.2 > Environment: windows xp >Reporter: Will Johnson > Attachments: IndexWriter.patch, IndexWriter2.patch, stacktrace.txt, > ThrashIndex.java > > > when running the soon to be attached sample application against solr it will > eventually die. this same error has happened on both windows and rh4 linux. > the app is just submitting docs with an id in batches of 10, performing a > commit then repeating over and over again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
[ https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-240: -- Attachment: IndexWriter.patch I found this: http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/javadoc/or g/apache/lucene/store/NativeFSLockFactory.html And so I made the attached patch which seems to run at least 100x longer than without. - will > java.io.IOException: Lock obtain timed out: SimpleFSLock > > > Key: SOLR-240 > URL: https://issues.apache.org/jira/browse/SOLR-240 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 1.2 > Environment: windows xp >Reporter: Will Johnson > Attachments: IndexWriter.patch, stacktrace.txt, ThrashIndex.java > > > when running the soon to be attached sample application against solr it will > eventually die. this same error has happened on both windows and rh4 linux. > the app is just submitting docs with an id in batches of 10, performing a > commit then repeating over and over again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
[ https://issues.apache.org/jira/browse/SOLR-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-240: -- Attachment: stacktrace.txt ThrashIndex.java > java.io.IOException: Lock obtain timed out: SimpleFSLock > > > Key: SOLR-240 > URL: https://issues.apache.org/jira/browse/SOLR-240 > Project: Solr > Issue Type: Bug > Components: update >Affects Versions: 1.2 > Environment: windows xp >Reporter: Will Johnson > Attachments: stacktrace.txt, ThrashIndex.java > > > when running the soon to be attached sample application against solr it will > eventually die. this same error has happened on both windows and rh4 linux. > the app is just submitting docs with an id in batches of 10, performing a > commit then repeating over and over again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-240) java.io.IOException: Lock obtain timed out: SimpleFSLock
java.io.IOException: Lock obtain timed out: SimpleFSLock Key: SOLR-240 URL: https://issues.apache.org/jira/browse/SOLR-240 Project: Solr Issue Type: Bug Components: update Affects Versions: 1.2 Environment: windows xp Reporter: Will Johnson when running the soon to be attached sample application against solr it will eventually die. this same error has happened on both windows and rh4 linux. the app is just submitting docs with an id in batches of 10, performing a commit then repeating over and over again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-239) Read IndexSchema from InputStream instead of Config file
[ https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-239: -- Attachment: IndexSchemaStream2.patch patch updated. now with the added benefit of compiling. > Read IndexSchema from InputStream instead of Config file > > > Key: SOLR-239 > URL: https://issues.apache.org/jira/browse/SOLR-239 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.2 > Environment: all >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: IndexSchemaStream.patch, IndexSchemaStream2.patch > > > Soon to follow patch adds a constructor to IndexSchema to allow them to be > created directly from InputStreams. The overall logic for the Core's use of > the IndexSchema creation/use does not change however this allows java clients > like those in SOLR-20 to be able to parse an IndexSchema. Once a schema is > parsed, the client can inspect an index's capabilities which is useful for > building generic search UI's. ie provide a drop down list of fields to > search/sort by. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-239) Read IndexSchema from InputStream instead of Config file
[ https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-239: -- Attachment: IndexSchemaStream.patch patch with test cases attached. i also had to change raw-schema.jsp to be a redirect to get-files.jsp however it wasn't clear that raw-schema.jsp was in use anymore. > Read IndexSchema from InputStream instead of Config file > > > Key: SOLR-239 > URL: https://issues.apache.org/jira/browse/SOLR-239 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.2 > Environment: all >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: IndexSchemaStream.patch > > > Soon to follow patch adds a constructor to IndexSchema to allow them to be > created directly from InputStreams. The overall logic for the Core's use of > the IndexSchema creation/use does not change however this allows java clients > like those in SOLR-20 to be able to parse an IndexSchema. Once a schema is > parsed, the client can inspect an index's capabilities which is useful for > building generic search UI's. ie provide a drop down list of fields to > search/sort by. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-239) Read IndexSchema from InputStream instead of Config file
Read IndexSchema from InputStream instead of Config file Key: SOLR-239 URL: https://issues.apache.org/jira/browse/SOLR-239 Project: Solr Issue Type: Improvement Affects Versions: 1.2 Environment: all Reporter: Will Johnson Priority: Minor Fix For: 1.2 Soon to follow patch adds a constructor to IndexSchema to allow them to be created directly from InputStreams. The overall logic for the Core's use of the IndexSchema creation/use does not change however this allows java clients like those in SOLR-20 to be able to parse an IndexSchema. Once a schema is parsed, the client can inspect an index's capabilities which is useful for building generic search UI's. ie provide a drop down list of fields to search/sort by. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-86) [PATCH] standalone updater cli based on httpClient
[ https://issues.apache.org/jira/browse/SOLR-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493784 ] Will Johnson commented on SOLR-86: -- has anyone brought up the idea of creating post.bat and post.sh scripts that use this java class instead of the curl example that currently ships in example/exampledocs? it would be one less thing for people to figure out and possibly screw up. > [PATCH] standalone updater cli based on httpClient > --- > > Key: SOLR-86 > URL: https://issues.apache.org/jira/browse/SOLR-86 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Thorsten Scherler > Assigned To: Erik Hatcher > Attachments: simple-post-tool-2007-02-15.patch, > simple-post-tool-2007-02-16.patch, > simple-post-using-urlconnection-approach.patch, solr-86.diff, solr-86.diff > > > We need a cross platform replacement for the post.sh. > The attached code is a direct replacement of the post.sh since it is actually > doing the same exact thing. > In the future one can extend the CLI with other feature like auto commit, > etc.. > Right now the code assumes that SOLR-85 is applied since we using the servlet > of this issue to actually do the update. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-20) A simple Java client for updating and searching
[ https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492902 ] Will Johnson commented on SOLR-20: -- the new api's work great, thanks! what's the plan for this going forward? id' like to start doing some work on this as it's rather critical to my current project and an are i've dealt with a lot in the past. assuming it's not getting dumped into org.apache.* land any time soon are you accepting patches to this code? if so i have some modifications to the api's that i think will make them easier to use (such as a method to set FacetParams on SolrQuery) and i'll even flush out the SolrServerTest for fun. also, i noticed that all the methods on SolrServer throw undeclared SolrExceptions which extends RuntimeException when things so south. should those throw some other sort of non-ignorable exception like a new SolrServerException? while it made coding/compiling easier to leave out all the usually required try's and catches it made running/debugging much less enjoyable. - will > A simple Java client for updating and searching > --- > > Key: SOLR-20 > URL: https://issues.apache.org/jira/browse/SOLR-20 > Project: Solr > Issue Type: New Feature > Components: clients - java > Environment: all >Reporter: Darren Erik Vengroff >Priority: Minor > Attachments: DocumentManagerClient.java, DocumentManagerClient.java, > solr-client-java-2.zip.zip, solr-client-java.zip, solr-client-sources.jar, > solr-client.zip, solr-client.zip, solr-client.zip, > solrclient_addqueryfacet.zip, SolrClientException.java, > SolrServerException.java > > > I wrote a simple little client class that can connect to a Solr server and > issue add, delete, commit and optimize commands using Java methods. I'm > posting here for review and comments as suggested by Yonik. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-20) A simple Java client for updating and searching
[ https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492700 ] Will Johnson commented on SOLR-20: -- the trunk version at http://solrstuff.org/svn/solrj/ seems to be missing a dependency and a copy of SolrParams. ant returns compile: [javac] Compiling 40 source files to C:\data\workspace\solrj\bin [javac] C:\data\workspace\solrj\src\org\apache\solr\client\solrj\impl\XMLResponseParser.java:10: package javax.xml.stream does not exist [javac] import javax.xml.stream.XMLInputFactory; [javac] C:\data\workspace\solrj\src\org\apache\solr\client\solrj\query\SolrQuery.java:10: cannot find symbol [javac] symbol : class SolrParams [javac] location: package org.apache.solr.util [javac] import org.apache.solr.util.SolrParams; > A simple Java client for updating and searching > --- > > Key: SOLR-20 > URL: https://issues.apache.org/jira/browse/SOLR-20 > Project: Solr > Issue Type: New Feature > Components: clients - java > Environment: all >Reporter: Darren Erik Vengroff >Priority: Minor > Attachments: DocumentManagerClient.java, DocumentManagerClient.java, > solr-client-java-2.zip.zip, solr-client-java.zip, solr-client-sources.jar, > solr-client.zip, solr-client.zip, solr-client.zip, > solrclient_addqueryfacet.zip, SolrClientException.java, > SolrServerException.java > > > I wrote a simple little client class that can connect to a Solr server and > issue add, delete, commit and optimize commands using Java methods. I'm > posting here for review and comments as suggested by Yonik. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-217) schema option to ignore unused fields
[ https://issues.apache.org/jira/browse/SOLR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-217: -- Attachment: ignoreUnnamedFields_v3.patch v3 patch included. this version of the patch also takes into account the suggested example/solr/conf/schema.xml changes. > schema option to ignore unused fields > - > > Key: SOLR-217 > URL: https://issues.apache.org/jira/browse/SOLR-217 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.2 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: ignoreNonIndexedNonStoredField.patch, > ignoreUnnamedFields.patch, ignoreUnnamedFields_v3.patch > > > One thing that causes problems for me (and i assume others) is that Solr is > schema-strict in that unknown fields cause solr to throw exceptions and there > is no way to relax this constraint. this can cause all sorts of serious > problems if you have automated feeding applications that do things like > SELECT * FROM table1 or where you want to add other fields to the document > for processing purposes before sending them to solr but don't want to deal > with 'cleanup' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-217) schema option to ignore unused fields
[ https://issues.apache.org/jira/browse/SOLR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492664 ] Will Johnson commented on SOLR-217: --- since we now have required fields (http://issues.apache.org/jira/browse/SOLR-181) any chance we can have ignored fields as well? let me know if something else needs to be done to the patch but as far as i can tell the code works and people seem to agree that it's the correct approach. - will > schema option to ignore unused fields > - > > Key: SOLR-217 > URL: https://issues.apache.org/jira/browse/SOLR-217 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.2 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: ignoreNonIndexedNonStoredField.patch, > ignoreUnnamedFields.patch > > > One thing that causes problems for me (and i assume others) is that Solr is > schema-strict in that unknown fields cause solr to throw exceptions and there > is no way to relax this constraint. this can cause all sorts of serious > problems if you have automated feeding applications that do things like > SELECT * FROM table1 or where you want to add other fields to the document > for processing purposes before sending them to solr but don't want to deal > with '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-217) schema option to ignore unused fields
[
https://issues.apache.org/jira/browse/SOLR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Johnson updated SOLR-217:
--
Attachment: ignoreNonIndexedNonStoredField.patch
I like that solution and I can definitely see the advantages of having
dumb_*=ignored and so on. How does this patch sound instead of the
previous:
public Field createField(SchemaField field, String externalVal, float
boost) {
String val;
try {
val = toInternal(externalVal);
} catch (NumberFormatException e) {
throw new SolrException(500, "Error while creating field '" +
field + "' from value '" + externalVal + "'", e, false);
}
if (val==null) return null;
if (!field.indexed() && !field.stored()) {
log.finest("Ignoring unindexed/unstored field: " + field);
return null;
}
... blah blah blah
- will
> schema option to ignore unused fields
> -
>
> Key: SOLR-217
> URL: https://issues.apache.org/jira/browse/SOLR-217
> Project: Solr
> Issue Type: Improvement
> Components: update
>Affects Versions: 1.2
>Reporter: Will Johnson
>Priority: Minor
> Fix For: 1.2
>
> Attachments: ignoreNonIndexedNonStoredField.patch,
> ignoreUnnamedFields.patch
>
>
> One thing that causes problems for me (and i assume others) is that Solr is
> schema-strict in that unknown fields cause solr to throw exceptions and there
> is no way to relax this constraint. this can cause all sorts of serious
> problems if you have automated feeding applications that do things like
> SELECT * FROM table1 or where you want to add other fields to the document
> for processing purposes before sending them to solr but don't want to deal
> with 'cleanup'
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-217) schema option to ignore unused fields
[ https://issues.apache.org/jira/browse/SOLR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492326 ] Will Johnson commented on SOLR-217: --- i was actually taking this requirement from the other enterprise search engines that i've worked with that do this by default. ie, solr is different in this case. your *->nothing method sounds good as well but it doesn't seem as obvious to someone reading the schema or trying to feed data. you might also run into problems later on when there are other properties for 'things to do' for fields other than indexing and searching. - will > schema option to ignore unused fields > - > > Key: SOLR-217 > URL: https://issues.apache.org/jira/browse/SOLR-217 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.2 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: ignoreUnnamedFields.patch > > > One thing that causes problems for me (and i assume others) is that Solr is > schema-strict in that unknown fields cause solr to throw exceptions and there > is no way to relax this constraint. this can cause all sorts of serious > problems if you have automated feeding applications that do things like > SELECT * FROM table1 or where you want to add other fields to the document > for processing purposes before sending them to solr but don't want to deal > with '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-217) schema option to ignore unused fields
[ https://issues.apache.org/jira/browse/SOLR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-217: -- Attachment: ignoreUnnamedFields.patch the attached patch solve this problme by adding a new option to schema.xml to allow unnamed fields including those that don't match dynamic fields to be ignored. the default is false if the attribute is missing which is consistent with existing SOLR functionality. if you want to enable this feature the schema.xml would look like: blah blah blah ... blah blah blah ... > schema option to ignore unused fields > - > > Key: SOLR-217 > URL: https://issues.apache.org/jira/browse/SOLR-217 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.2 >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: ignoreUnnamedFields.patch > > > One thing that causes problems for me (and i assume others) is that Solr is > schema-strict in that unknown fields cause solr to throw exceptions and there > is no way to relax this constraint. this can cause all sorts of serious > problems if you have automated feeding applications that do things like > SELECT * FROM table1 or where you want to add other fields to the document > for processing purposes before sending them to solr but don't want to deal > with 'cleanup' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-217) schema option to ignore unused fields
schema option to ignore unused fields - Key: SOLR-217 URL: https://issues.apache.org/jira/browse/SOLR-217 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.2 Reporter: Will Johnson Priority: Minor Fix For: 1.2 Attachments: ignoreUnnamedFields.patch One thing that causes problems for me (and i assume others) is that Solr is schema-strict in that unknown fields cause solr to throw exceptions and there is no way to relax this constraint. this can cause all sorts of serious problems if you have automated feeding applications that do things like SELECT * FROM table1 or where you want to add other fields to the document for processing purposes before sending them to solr but don't want to deal with 'cleanup' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-20) A simple Java client for updating and searching
[ https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490117 ] Will Johnson commented on SOLR-20: -- is there an updated package or anyone working on such a thing at the moment? the solr-client.zip at the top of the thread works like a charm but seems to be very outdated and the bits on the svn://solrstuff.org site have some rather serious bugs. i'm happy to do all the leg work of packaging things, fixing bugs, submitting a patch, etc but i wanted to make sure i'm not about to walk right behind someone else. also, if anyone has any ideas for the best starting point i'm happy to take suggestions. - will > A simple Java client for updating and searching > --- > > Key: SOLR-20 > URL: https://issues.apache.org/jira/browse/SOLR-20 > Project: Solr > Issue Type: New Feature > Components: clients - java > Environment: all >Reporter: Darren Erik Vengroff >Priority: Minor > Attachments: DocumentManagerClient.java, DocumentManagerClient.java, > solr-client-java-2.zip.zip, solr-client-java.zip, solr-client-sources.jar, > solr-client.zip, solr-client.zip, solr-client.zip, > solrclient_addqueryfacet.zip, SolrClientException.java, > SolrServerException.java > > > I wrote a simple little client class that can connect to a Solr server and > issue add, delete, commit and optimize commands using Java methods. I'm > posting here for review and comments as suggested by Yonik. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
