[jira] Commented: (SOLR-561) Solr replication by Solr (for windows also)
[ https://issues.apache.org/jira/browse/SOLR-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601891#action_12601891 ] Noble Paul commented on SOLR-561: - Should we plan this feature for Solr 1.3 release ?. If yes, what all are the items pending to be completed? Solr replication by Solr (for windows also) --- Key: SOLR-561 URL: https://issues.apache.org/jira/browse/SOLR-561 Project: Solr Issue Type: New Feature Components: replication Affects Versions: 1.3 Environment: All Reporter: Noble Paul Attachments: SOLR-561.patch, SOLR-561.patch The current replication strategy in solr involves shell scripts . The following are the drawbacks with the approach * It does not work with windows * Replication works as a separate piece not integrated with solr. * Cannot control replication from solr admin/JMX * Each operation requires manual telnet to the host Doing the replication in java has the following advantages * Platform independence * Manual steps can be completely eliminated. Everything can be driven from solrconfig.xml . ** Adding the url of the master in the slaves should be good enough to enable replication. Other things like frequency of snapshoot/snappull can also be configured . All other information can be automatically obtained. * Start/stop can be triggered from solr/admin or JMX * Can get the status/progress while replication is going on. It can also abort an ongoing replication * No need to have a login into the machine This issue can track the implementation of solr replication in java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-589) DisMaxRequestHandler crashes on badly formed query strings ( combinations of - and + )
DisMaxRequestHandler crashes on badly formed query strings ( combinations of - and + ) -- Key: SOLR-589 URL: https://issues.apache.org/jira/browse/SOLR-589 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.2 Environment: all platforms Reporter: bram de jong Priority: Minor The DisMaxRequestHandler parser crashes on strings which contain double dashes or various combinations of - and + like: chocolate cookie - chocolate -+cookie chocolate --cookie chocolate - - cookie Originally found by me: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200806.mbox/browser And verified by Sean Tim: http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200806.mbox/browser -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-561) Solr replication by Solr (for windows also)
[ https://issues.apache.org/jira/browse/SOLR-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601951#action_12601951 ] Andrew Savory commented on SOLR-561: I'd certainly like to see this in 1.3, it would make my life easier! I'm trying out the code now and hope to feedback in depth soon. Meanwhile some initial comments: there's inconsistency between 4 space and 2 space tabs in the code, and a few System.out.println that you probably want to remove or replace with proper logging. Solr replication by Solr (for windows also) --- Key: SOLR-561 URL: https://issues.apache.org/jira/browse/SOLR-561 Project: Solr Issue Type: New Feature Components: replication Affects Versions: 1.3 Environment: All Reporter: Noble Paul Attachments: SOLR-561.patch, SOLR-561.patch The current replication strategy in solr involves shell scripts . The following are the drawbacks with the approach * It does not work with windows * Replication works as a separate piece not integrated with solr. * Cannot control replication from solr admin/JMX * Each operation requires manual telnet to the host Doing the replication in java has the following advantages * Platform independence * Manual steps can be completely eliminated. Everything can be driven from solrconfig.xml . ** Adding the url of the master in the slaves should be good enough to enable replication. Other things like frequency of snapshoot/snappull can also be configured . All other information can be automatically obtained. * Start/stop can be triggered from solr/admin or JMX * Can get the status/progress while replication is going on. It can also abort an ongoing replication * No need to have a login into the machine This issue can track the implementation of solr replication in java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-161) Dangling dash causes stack trace
[
https://issues.apache.org/jira/browse/SOLR-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602038#action_12602038
]
Mike Klaas commented on SOLR-161:
-
It is really a Lucene query parser bug, but it wouldn't hurt to do s/(.*)-//
as a workaround. Assuming my ed(1) syntax is still fresh. Regardless, no
query string should ever give a stack trace
This might be hard to guarantee. Already there are four issues details
specific ways that dismax that barf on input. A lot of the suggestions above
are of the form of detecting a specific failure mode and correcting it, which
does not guarantee that you will catch them all.
A robust way to do it is parse the query into an AST using a grammar in a way
that matches the query as well as possible (dropping the stuff that doesn't
fit). Unfortunately, this is duplicative of the lucene parsing logic, and it
would be nicer add a relaxed mode to lucene rather than pre-parsing the query.
(The reparse+reassemble method is what we use, btw. It is written in python
but it might be possible to translate to java.)
Dangling dash causes stack trace
Key: SOLR-161
URL: https://issues.apache.org/jira/browse/SOLR-161
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 1.1.0
Environment: Java 1.5, Tomcat 5.5.17, Fedora Core 4, Intel
Reporter: Walter Underwood
I'm running tests from our search logs, and we have a query that ends in a
dash. That caused a stack trace.
org.apache.lucene.queryParser.ParseException: Cannot parse 'digging for the
truth -': Encountered EOF at line 1, column 23.
Was expecting one of:
( ...
QUOTED ...
TERM ...
PREFIXTERM ...
WILDTERM ...
[ ...
{ ...
NUMBER ...
at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:127)
at
org.apache.solr.request.DisMaxRequestHandler.handleRequest(DisMaxRequestHandler.java:272)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:595)
at org.apache.solr.servlet.SolrServlet.doGet(SolrServlet.java:92)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-572) Spell Checker as a Search Component
The current patch has been broken for some days now and implementing a correct query parsing logic may take time to get right. Let's not aim for everything to get into the 1.3 release. I would like to cut down the scope of this issue to a implementation that indexes files and Lucene indices (both Solr and arbitary) and gives suggestions while using the correct analyzer for multi-word queries. Let's get a spell checker working and commit it. We can deal with more enhancements like abstractions for custom spellcheckers and query parsing etc. in another issue which can be dealt with separately (in 1.3 or after). Thoughts? If there is a general consensus, I can give a new patch which can be good enough to go in. On Sat, May 31, 2008 at 2:44 AM, Oleg Gnatovskiy (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601256#action_12601256] Oleg Gnatovskiy commented on SOLR-572: -- I installed the latest patch. Still getting a NPE. Here is my config: searchComponent name=spellcheck class=org.apache.solr.handler.component.SpellCheckComponent lst name=defaults !-- omp = Only More Popular -- str name=spellcheck.onlyMorePopularfalse/str !-- exr = Extended Results -- str name=spellcheck.extendedResultsfalse/str !-- The number of suggestions to return -- str name=spellcheck.count1/str /lst lst name=spellchecker str name=classnameorg.apache.solr.spelling.FileBasedSpellChecker/str str name=nameexternal/str str name=sourceLocationspellings.txt/str str name=characterEncodingUTF-8/str str name=fieldTypetext_ws/str str name=indexDir/usr/local/apache/lucene/solr2home/solr/data/spellIndex/str /lst /searchComponent Here is the URL I am hitting: http://localhost:8983/solr/select/?q=pizzaspellcheck=truespellcheck.dictionary=externalspellcheck.build=true Here is the error: HTTP Status 500 - null java.lang.NullPointerException at org.apache.lucene.index.Term.init(Term.java:39) at org.apache.lucene.index.Term.init(Term.java:36) at org.apache.lucene.search.spell.SpellChecker.suggestSimilar(SpellChecker.java:228) at org.apache.solr.spelling.AbstractLuceneSpellChecker.getSuggestions(AbstractLuceneSpellChecker.java:71) at org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:177) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:153) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:125) at org.apache.solr.core.SolrCore.execute(SolrCore.java:965) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:339) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:274) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) spelling.txt is in my solr/home/conf. Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch Expose the Lucene contrib SpellChecker as a Search Component. Provide the following features: * Allow creating a spell index on a given field and make it possible to have multiple spell indices -- one for each field * Give suggestions on a per-field basis * Given a multi-word query, give only one
Re: [jira] Commented: (SOLR-572) Spell Checker as a Search Component
I'm +1 on getting the basic stuff done and committed for 1.3. If Grant is hot on getting the abstractions in for 1.3, he will do so, but I think it's OK to get this done in 2 parts: 1) core working and committed for 1.3 2) abstractions working and committed after 1.3 if Grant doesn't finish them before 1.3 Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Shalin Shekhar Mangar [EMAIL PROTECTED] To: solr-dev@lucene.apache.org Sent: Tuesday, June 3, 2008 3:53:10 PM Subject: Re: [jira] Commented: (SOLR-572) Spell Checker as a Search Component The current patch has been broken for some days now and implementing a correct query parsing logic may take time to get right. Let's not aim for everything to get into the 1.3 release. I would like to cut down the scope of this issue to a implementation that indexes files and Lucene indices (both Solr and arbitary) and gives suggestions while using the correct analyzer for multi-word queries. Let's get a spell checker working and commit it. We can deal with more enhancements like abstractions for custom spellcheckers and query parsing etc. in another issue which can be dealt with separately (in 1.3 or after). Thoughts? If there is a general consensus, I can give a new patch which can be good enough to go in. On Sat, May 31, 2008 at 2:44 AM, Oleg Gnatovskiy (JIRA) wrote: [ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601256#action_12601256] Oleg Gnatovskiy commented on SOLR-572: -- I installed the latest patch. Still getting a NPE. Here is my config: class=org.apache.solr.handler.component.SpellCheckComponent false false 1 name=classnameorg.apache.solr.spelling.FileBasedSpellChecker external spellings.txt UTF-8 text_ws name=indexDir/usr/local/apache/lucene/solr2home/solr/data/spellIndex Here is the URL I am hitting: http://localhost:8983/solr/select/?q=pizzaspellcheck=truespellcheck.dictionary=externalspellcheck.build=true Here is the error: HTTP Status 500 - null java.lang.NullPointerException at org.apache.lucene.index.Term.(Term.java:39) at org.apache.lucene.index.Term.(Term.java:36) at org.apache.lucene.search.spell.SpellChecker.suggestSimilar(SpellChecker.java:228) at org.apache.solr.spelling.AbstractLuceneSpellChecker.getSuggestions(AbstractLuceneSpellChecker.java:71) at org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:177) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:153) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:125) at org.apache.solr.core.SolrCore.execute(SolrCore.java:965) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:339) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:274) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) spelling.txt is in my solr/home/conf. Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch
Re: [jira] Commented: (SOLR-572) Spell Checker as a Search Component
I will be back on it tomorrow and will see this through before 1.3 with the abstractions. In other words, -1 on cutting this off prematurely. :-) Since I don't think this is the only thing holding up 1.3, let's just play it out and get it right so all of us are happy. -Grant On Jun 3, 2008, at 3:53 PM, Shalin Shekhar Mangar wrote: The current patch has been broken for some days now and implementing a correct query parsing logic may take time to get right. Let's not aim for everything to get into the 1.3 release. I would like to cut down the scope of this issue to a implementation that indexes files and Lucene indices (both Solr and arbitary) and gives suggestions while using the correct analyzer for multi-word queries. Let's get a spell checker working and commit it. We can deal with more enhancements like abstractions for custom spellcheckers and query parsing etc. in another issue which can be dealt with separately (in 1.3 or after). Thoughts? If there is a general consensus, I can give a new patch which can be good enough to go in. On Sat, May 31, 2008 at 2:44 AM, Oleg Gnatovskiy (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601256 #action_12601256] Oleg Gnatovskiy commented on SOLR-572: -- I installed the latest patch. Still getting a NPE. Here is my config: searchComponent name=spellcheck class=org.apache.solr.handler.component.SpellCheckComponent lst name=defaults !-- omp = Only More Popular -- str name=spellcheck.onlyMorePopularfalse/str !-- exr = Extended Results -- str name=spellcheck.extendedResultsfalse/str !-- The number of suggestions to return -- str name=spellcheck.count1/str /lst lst name=spellchecker str name=classnameorg.apache.solr.spelling.FileBasedSpellChecker/str str name=nameexternal/str str name=sourceLocationspellings.txt/str str name=characterEncodingUTF-8/str str name=fieldTypetext_ws/str str name=indexDir/usr/local/apache/lucene/solr2home/solr/data/ spellIndex/str /lst /searchComponent Here is the URL I am hitting: http://localhost:8983/solr/select/?q=pizzaspellcheck=truespellcheck.dictionary=externalspellcheck.build=true Here is the error: HTTP Status 500 - null java.lang.NullPointerException at org.apache.lucene.index.Term.init(Term.java:39) at org.apache.lucene.index.Term.init(Term.java:36) at org .apache .lucene.search.spell.SpellChecker.suggestSimilar(SpellChecker.java: 228) at org .apache .solr .spelling .AbstractLuceneSpellChecker .getSuggestions(AbstractLuceneSpellChecker.java:71) at org .apache .solr .handler .component.SpellCheckComponent.process(SpellCheckComponent.java:177) at org .apache .solr .handler .component.SearchHandler.handleRequestBody(SearchHandler.java:153) at org .apache .solr .handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java: 125) at org.apache.solr.core.SolrCore.execute(SolrCore.java:965) at org .apache .solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:339) at org .apache .solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java: 274) at org .apache .catalina .core .ApplicationFilterChain .internalDoFilter(ApplicationFilterChain.java:235) at org .apache .catalina .core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java: 206) at org .apache .catalina .core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org .apache .catalina .core.StandardContextValve.invoke(StandardContextValve.java:175) at org .apache .catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org .apache .catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org .apache .catalina.core.StandardEngineValve.invoke(StandardEngineValve.java: 109) at org .apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java: 286) at org .apache.coyote.http11.Http11Processor.process(Http11Processor.java: 844) at org.apache.coyote.http11.Http11Protocol $Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint $Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) spelling.txt is in my solr/home/conf. Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3 Reporter: Shalin Shekhar Mangar Assignee: Grant Ingersoll Priority: Minor Fix For: 1.3 Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch,
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602068#action_12602068 ] Otis Gospodnetic commented on SOLR-502: --- Just in case it helps: * I used solrconfig.xml from example/solr/conf * I set all cache sizes to 0 Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602068#action_12602068 ] otis edited comment on SOLR-502 at 6/3/08 1:47 PM: --- Just in case it helps: * I used solrconfig.xml from example/solr/conf * I set all cache sizes to 0 Also, after adding some lovely print statements to the patch, right in the QueryComponent's process method, it looks like my query requests are not even executing QueryComponent's process method. Is there something I need to enable to get QueryComponent included? Standard request handler should be using it already, no? was (Author: otis): Just in case it helps: * I used solrconfig.xml from example/solr/conf * I set all cache sizes to 0 Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Issue Comment Edited: (SOLR-502) Add search time out support
Otis-- I didn't get a chance to look at it today. I plan to take a look at it tomorrow. -Sean Otis Gospodnetic (JIRA) wrote: [ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602068#action_12602068 ] otis edited comment on SOLR-502 at 6/3/08 1:47 PM: --- Just in case it helps: * I used solrconfig.xml from example/solr/conf * I set all cache sizes to 0 Also, after adding some lovely print statements to the patch, right in the QueryComponent's process method, it looks like my query requests are not even executing QueryComponent's process method. Is there something I need to enable to get QueryComponent included? Standard request handler should be using it already, no? was (Author: otis): Just in case it helps: * I used solrconfig.xml from example/solr/conf * I set all cache sizes to 0 Add search time out support --- Key: SOLR-502 URL: https://issues.apache.org/jira/browse/SOLR-502 Project: Solr Issue Type: New Feature Components: search Reporter: Sean Timm Assignee: Otis Gospodnetic Priority: Minor Fix For: 1.3 Attachments: SOLR-502.patch, SOLR-502.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch Uses LUCENE-997 to add time out support to Solr.
[jira] Updated: (SOLR-590) Limitation in pgrep on Linux platform breaks script-utils fixUser
[ https://issues.apache.org/jira/browse/SOLR-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hannes Schmidt updated SOLR-590: Priority: Minor (was: Major) Changing priority to minor. Limitation in pgrep on Linux platform breaks script-utils fixUser -- Key: SOLR-590 URL: https://issues.apache.org/jira/browse/SOLR-590 Project: Solr Issue Type: Bug Affects Versions: 1.2 Environment: Linux 2.6.18-53.1.14.el5 #1 SMP Wed Mar 5 11:37:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux procps-3.2.7-8.1.el5 Reporter: Hannes Schmidt Priority: Minor The fixUser function in script-utils uses two methods to determine the username of the parent process (oldwhoami). If the first method fails for certain reasons it will fallback to the second method. For most people the first method will succeed but I know that in my particular installation the first method fails so I need the second method to succeed. Unfortunately, that fallback method doesn't work because it uses pgrep to lookup the current script's name and on my Linux 2.6.18 platform pgrep is limited to 15 characters. The names of many scripts in the SOLR distribution are longer than that, causing pgrep to return nothing and the subsequent ps invocation to fail with an error: ERROR: List of process IDs must follow -p. You can easily reproduce that behaviour with /app/solr/solr/bin/snappuller-enable /dev/null The redirection of stdin from /dev/null causes fixUser to fallback to the second method but there are other, more realistic scenarios in which the fallback happens, like ssh [EMAIL PROTECTED] /app/solr/solr/bin/snappuller-enable The fix is to use the -f option which causes pgrep to compare the full path of the executable. Interestingly, that method is not subject to the 15 character length limit. The limit is not actually enforced by jetty but rather by the procfs file system of the linux kernel. If you look at /proc/*/stat you will notice that the second column is limited to 15 characters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-590) Limitation in pgrep on Linux platform breaks script-utils fixUser
Limitation in pgrep on Linux platform breaks script-utils fixUser -- Key: SOLR-590 URL: https://issues.apache.org/jira/browse/SOLR-590 Project: Solr Issue Type: Bug Affects Versions: 1.2 Environment: Linux 2.6.18-53.1.14.el5 #1 SMP Wed Mar 5 11:37:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux procps-3.2.7-8.1.el5 Reporter: Hannes Schmidt The fixUser function in script-utils uses two methods to determine the username of the parent process (oldwhoami). If the first method fails for certain reasons it will fallback to the second method. For most people the first method will succeed but I know that in my particular installation the first method fails so I need the second method to succeed. Unfortunately, that fallback method doesn't work because it uses pgrep to lookup the current script's name and on my Linux 2.6.18 platform pgrep is limited to 15 characters. The names of many scripts in the SOLR distribution are longer than that, causing pgrep to return nothing and the subsequent ps invocation to fail with an error: ERROR: List of process IDs must follow -p. You can easily reproduce that behaviour with /app/solr/solr/bin/snappuller-enable /dev/null The redirection of stdin from /dev/null causes fixUser to fallback to the second method but there are other, more realistic scenarios in which the fallback happens, like ssh [EMAIL PROTECTED] /app/solr/solr/bin/snappuller-enable The fix is to use the -f option which causes pgrep to compare the full path of the executable. Interestingly, that method is not subject to the 15 character length limit. The limit is not actually enforced by jetty but rather by the procfs file system of the linux kernel. If you look at /proc/*/stat you will notice that the second column is limited to 15 characters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-590) Limitation in pgrep on Linux platform breaks script-utils fixUser
[ https://issues.apache.org/jira/browse/SOLR-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hannes Schmidt updated SOLR-590: Attachment: fixUser.patch Attaching patch. Limitation in pgrep on Linux platform breaks script-utils fixUser -- Key: SOLR-590 URL: https://issues.apache.org/jira/browse/SOLR-590 Project: Solr Issue Type: Bug Affects Versions: 1.2 Environment: Linux 2.6.18-53.1.14.el5 #1 SMP Wed Mar 5 11:37:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux procps-3.2.7-8.1.el5 Reporter: Hannes Schmidt Priority: Minor Attachments: fixUser.patch The fixUser function in script-utils uses two methods to determine the username of the parent process (oldwhoami). If the first method fails for certain reasons it will fallback to the second method. For most people the first method will succeed but I know that in my particular installation the first method fails so I need the second method to succeed. Unfortunately, that fallback method doesn't work because it uses pgrep to lookup the current script's name and on my Linux 2.6.18 platform pgrep is limited to 15 characters. The names of many scripts in the SOLR distribution are longer than that, causing pgrep to return nothing and the subsequent ps invocation to fail with an error: ERROR: List of process IDs must follow -p. You can easily reproduce that behaviour with /app/solr/solr/bin/snappuller-enable /dev/null The redirection of stdin from /dev/null causes fixUser to fallback to the second method but there are other, more realistic scenarios in which the fallback happens, like ssh [EMAIL PROTECTED] /app/solr/solr/bin/snappuller-enable The fix is to use the -f option which causes pgrep to compare the full path of the executable. Interestingly, that method is not subject to the 15 character length limit. The limit is not actually enforced by jetty but rather by the procfs file system of the linux kernel. If you look at /proc/*/stat you will notice that the second column is limited to 15 characters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-469) Data Import RequestHandler
[
https://issues.apache.org/jira/browse/SOLR-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602089#action_12602089
]
Olivier Poitrey commented on SOLR-469:
--
Paul,
The current version of the code seems not to allow the construction
pk=forum.forumId you're talking about. I did a small patch to make it
possible, I don't know if it's the correct way to do it but it works well for
me. Here is the patch:
{noformat}
---
a/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/SqlEntityProcessor.java
+++
b/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/SqlEntityProcessor.java
@@ -124,7 +124,9 @@ public class SqlEntityProcessor extends EntityProcessorBase
{
sb.append( and );
first = false;
}
- Object val = resolver.resolve(primaryKeys[i]);
+ // Only send the field part of the pk when pk includes the table ref
+ String[] pkParts = primaryKeys[i].split(\\.);
+ Object val = resolver.resolve(pkParts[pkParts.length - 1]);
sb.append(primaryKeys[i]).append( = );
if (val instanceof Number) {
sb.append(val.toString());
{noformat}
Hope that helps.
Data Import RequestHandler
--
Key: SOLR-469
URL: https://issues.apache.org/jira/browse/SOLR-469
Project: Solr
Issue Type: New Feature
Components: update
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Grant Ingersoll
Fix For: 1.3
Attachments: SOLR-469-contrib.patch, SOLR-469.patch, SOLR-469.patch,
SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch,
SOLR-469.patch, SOLR-469.patch
We need a RequestHandler Which can import data from a DB or other dataSources
into the Solr index .Think of it as an advanced form of SqlUpload Plugin
(SOLR-103).
The way it works is as follows.
* Provide a configuration file (xml) to the Handler which takes in the
necessary SQL queries and mappings to a solr schema
- It also takes in a properties file for the data source
configuraution
* Given the configuration it can also generate the solr schema.xml
* It is registered as a RequestHandler which can take two commands
do-full-import, do-delta-import
- do-full-import - dumps all the data from the Database into the
index (based on the SQL query in configuration)
- do-delta-import - dumps all the data that has changed since last
import. (We assume a modified-timestamp column in tables)
* It provides a admin page
- where we can schedule it to be run automatically at regular
intervals
- It shows the status of the Handler (idle, full-import,
delta-import)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-469) Data Import RequestHandler
[
https://issues.apache.org/jira/browse/SOLR-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602089#action_12602089
]
rs edited comment on SOLR-469 at 6/3/08 2:59 PM:
--
Paul,
The current version of the code seems not to allow the construction
pk=forum.forumId you're talking about. I did a small patch to make it
possible. I don't know if it's the correct way to do it but it worked well for
me.
Here is the patch:
{noformat}
---
a/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/SqlEntityProcessor.java
+++
b/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/SqlEntityProcessor.java
@@ -124,7 +124,9 @@ public class SqlEntityProcessor extends EntityProcessorBase
{
sb.append( and );
first = false;
}
- Object val = resolver.resolve(primaryKeys[i]);
+ // Only send the field part of the pk when pk includes the table ref
+ String[] pkParts = primaryKeys[i].split(\\.);
+ Object val = resolver.resolve(pkParts[pkParts.length - 1]);
sb.append(primaryKeys[i]).append( = );
if (val instanceof Number) {
sb.append(val.toString());
{noformat}
Hope that helps.
was (Author: rs):
Paul,
The current version of the code seems not to allow the construction
pk=forum.forumId you're talking about. I did a small patch to make it
possible, I don't know if it's the correct way to do it but it works well for
me. Here is the patch:
{noformat}
---
a/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/SqlEntityProcessor.java
+++
b/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/SqlEntityProcessor.java
@@ -124,7 +124,9 @@ public class SqlEntityProcessor extends EntityProcessorBase
{
sb.append( and );
first = false;
}
- Object val = resolver.resolve(primaryKeys[i]);
+ // Only send the field part of the pk when pk includes the table ref
+ String[] pkParts = primaryKeys[i].split(\\.);
+ Object val = resolver.resolve(pkParts[pkParts.length - 1]);
sb.append(primaryKeys[i]).append( = );
if (val instanceof Number) {
sb.append(val.toString());
{noformat}
Hope that helps.
Data Import RequestHandler
--
Key: SOLR-469
URL: https://issues.apache.org/jira/browse/SOLR-469
Project: Solr
Issue Type: New Feature
Components: update
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Grant Ingersoll
Fix For: 1.3
Attachments: SOLR-469-contrib.patch, SOLR-469.patch, SOLR-469.patch,
SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch,
SOLR-469.patch, SOLR-469.patch
We need a RequestHandler Which can import data from a DB or other dataSources
into the Solr index .Think of it as an advanced form of SqlUpload Plugin
(SOLR-103).
The way it works is as follows.
* Provide a configuration file (xml) to the Handler which takes in the
necessary SQL queries and mappings to a solr schema
- It also takes in a properties file for the data source
configuraution
* Given the configuration it can also generate the solr schema.xml
* It is registered as a RequestHandler which can take two commands
do-full-import, do-delta-import
- do-full-import - dumps all the data from the Database into the
index (based on the SQL query in configuration)
- do-delta-import - dumps all the data that has changed since last
import. (We assume a modified-timestamp column in tables)
* It provides a admin page
- where we can schedule it to be run automatically at regular
intervals
- It shows the status of the Handler (idle, full-import,
delta-import)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-469) Data Import RequestHandler
hi Olivier,
I guess this is the same problem reported by Moser. Your fix is more
or less fine. We have made a fix that is similar to what you have
done. The next patch will have these fixes also.if you wish we will
post the java file separately.
We are just waiting for the first patch to get committed so that these
can be bug fixes on that.
--Noble
On Wed, Jun 4, 2008 at 3:28 AM, Olivier Poitrey (JIRA) [EMAIL PROTECTED]
wrote:
[
https://issues.apache.org/jira/browse/SOLR-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602089#action_12602089
]
Olivier Poitrey commented on SOLR-469:
--
Paul,
The current version of the code seems not to allow the construction
pk=forum.forumId you're talking about. I did a small patch to make it
possible, I don't know if it's the correct way to do it but it works well for
me. Here is the patch:
{noformat}
---
a/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/SqlEntityProcessor.java
+++
b/contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/SqlEntityProcessor.java
@@ -124,7 +124,9 @@ public class SqlEntityProcessor extends
EntityProcessorBase {
sb.append( and );
first = false;
}
- Object val = resolver.resolve(primaryKeys[i]);
+ // Only send the field part of the pk when pk includes the table ref
+ String[] pkParts = primaryKeys[i].split(\\.);
+ Object val = resolver.resolve(pkParts[pkParts.length - 1]);
sb.append(primaryKeys[i]).append( = );
if (val instanceof Number) {
sb.append(val.toString());
{noformat}
Hope that helps.
Data Import RequestHandler
--
Key: SOLR-469
URL: https://issues.apache.org/jira/browse/SOLR-469
Project: Solr
Issue Type: New Feature
Components: update
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Grant Ingersoll
Fix For: 1.3
Attachments: SOLR-469-contrib.patch, SOLR-469.patch, SOLR-469.patch,
SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch,
SOLR-469.patch, SOLR-469.patch
We need a RequestHandler Which can import data from a DB or other
dataSources into the Solr index .Think of it as an advanced form of
SqlUpload Plugin (SOLR-103).
The way it works is as follows.
* Provide a configuration file (xml) to the Handler which takes in the
necessary SQL queries and mappings to a solr schema
- It also takes in a properties file for the data source
configuraution
* Given the configuration it can also generate the solr schema.xml
* It is registered as a RequestHandler which can take two commands
do-full-import, do-delta-import
- do-full-import - dumps all the data from the Database into the
index (based on the SQL query in configuration)
- do-delta-import - dumps all the data that has changed since last
import. (We assume a modified-timestamp column in tables)
* It provides a admin page
- where we can schedule it to be run automatically at regular
intervals
- It shows the status of the Handler (idle, full-import,
delta-import)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
--
--Noble Paul
Re: [jira] Commented: (SOLR-572) Spell Checker as a Search Component
On Wed, Jun 4, 2008 at 2:15 AM, Grant Ingersoll [EMAIL PROTECTED] wrote: I will be back on it tomorrow and will see this through before 1.3 with the abstractions. In other words, -1 on cutting this off prematurely. :-) Since I don't think this is the only thing holding up 1.3, let's just play it out and get it right so all of us are happy. This feature may not be holding back 1.3 release. The potential users of this issue are very much interested in a basic working version. They may be able to live without these advanced features. May be we can have another jira issue for enhancements which may/may not go into 1.3 (depending on when it happens). -Grant On Jun 3, 2008, at 3:53 PM, Shalin Shekhar Mangar wrote: The current patch has been broken for some days now and implementing a correct query parsing logic may take time to get right. Let's not aim for everything to get into the 1.3 release. I would like to cut down the scope of this issue to a implementation that indexes files and Lucene indices (both Solr and arbitary) and gives suggestions while using the correct analyzer for multi-word queries. Let's get a spell checker working and commit it. We can deal with more enhancements like abstractions for custom spellcheckers and query parsing etc. in another issue which can be dealt with separately (in 1.3 or after). Thoughts? If there is a general consensus, I can give a new patch which can be good enough to go in. On Sat, May 31, 2008 at 2:44 AM, Oleg Gnatovskiy (JIRA) [EMAIL PROTECTED] wrote: [ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601256#action_12601256] Oleg Gnatovskiy commented on SOLR-572: -- I installed the latest patch. Still getting a NPE. Here is my config: searchComponent name=spellcheck class=org.apache.solr.handler.component.SpellCheckComponent lst name=defaults !-- omp = Only More Popular -- str name=spellcheck.onlyMorePopularfalse/str !-- exr = Extended Results -- str name=spellcheck.extendedResultsfalse/str !-- The number of suggestions to return -- str name=spellcheck.count1/str /lst lst name=spellchecker str name=classnameorg.apache.solr.spelling.FileBasedSpellChecker/str str name=nameexternal/str str name=sourceLocationspellings.txt/str str name=characterEncodingUTF-8/str str name=fieldTypetext_ws/str str name=indexDir/usr/local/apache/lucene/solr2home/solr/data/spellIndex/str /lst /searchComponent Here is the URL I am hitting: http://localhost:8983/solr/select/?q=pizzaspellcheck=truespellcheck.dictionary=externalspellcheck.build=true Here is the error: HTTP Status 500 - null java.lang.NullPointerException at org.apache.lucene.index.Term.init(Term.java:39) at org.apache.lucene.index.Term.init(Term.java:36) at org.apache.lucene.search.spell.SpellChecker.suggestSimilar(SpellChecker.java:228) at org.apache.solr.spelling.AbstractLuceneSpellChecker.getSuggestions(AbstractLuceneSpellChecker.java:71) at org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:177) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:153) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:125) at org.apache.solr.core.SolrCore.execute(SolrCore.java:965) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:339) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:274) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) spelling.txt is in my solr/home/conf. Spell Checker as a Search Component --- Key: SOLR-572 URL: https://issues.apache.org/jira/browse/SOLR-572 Project: Solr Issue Type: New Feature Components: spellchecker Affects Versions: 1.3
