[jira] Created: (SOLR-1838) TermVectors and Multicore configuration
TermVectors and Multicore configuration
Key: SOLR-1838
URL: https://issues.apache.org/jira/browse/SOLR-1838
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 1.4
Environment: Linux Debian
Reporter: Christian Fontana
Hello.
My new to solr and I'm trying to setup solr with a multicore configuration.
All cores shares the same schema.xml and I'm using index sharding.
I need term vectors data to generate tag clouds but when I try to run a search
across all cores to retrieve term vectors data the engine
raises me the exception below.
Now I created two request handlers, one for the user search and one for the
engine in charge to create the tag cloud. The problem of this
solution is that I've to run n queries if n cores are cofigured and than merge
results
thanks in advance
christian f.
Mar 19, 2010 4:34:15 PM org.apache.solr.core.SolrCore execute
INFO: [it] webapp=/solr path=/select
params={tv.docIds=167&isShard=true&wt=javabin&version=1&tv=true} status=500
QTime=10
Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
SEVERE: java.lang.NullPointerException
at java.io.StringReader.(StringReader.java:33)
at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:197)
at
org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78)
at org.apache.solr.search.QParser.getQuery(QParser.java:131)
at
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:89)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
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.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
SEVERE: java.lang.NullPointerException
at java.io.StringReader.(StringReader.java:33)
at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:197)
at
org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78)
at org.apache.solr.search.QParser.getQuery(QParser.java:131)
at
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:89)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
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)
Mailing List merge
Shall we merge the dev mailing lists? This should reduce the cross-posting and can be completely automated (other than you may have to update your client-side filters) and was part of the plan to merge dev efforts. I'd propose it be called lucene-solr-...@l.a.o. I can put in an issue for infra@ to do it. -Grant
[jira] Commented: (SOLR-1838) TermVectors and Multicore configuration
[
https://issues.apache.org/jira/browse/SOLR-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848175#action_12848175
]
Grant Ingersoll commented on SOLR-1838:
---
What's your input URL? It looks to me like you are not sending the request to
the correct Request Handler, but am not 100% certain.
> TermVectors and Multicore configuration
>
>
> Key: SOLR-1838
> URL: https://issues.apache.org/jira/browse/SOLR-1838
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 1.4
> Environment: Linux Debian
>Reporter: Christian Fontana
>
> Hello.
> My new to solr and I'm trying to setup solr with a multicore configuration.
> All cores shares the same schema.xml and I'm using index sharding.
> I need term vectors data to generate tag clouds but when I try to run a
> search across all cores to retrieve term vectors data the engine
> raises me the exception below.
> Now I created two request handlers, one for the user search and one for the
> engine in charge to create the tag cloud. The problem of this
> solution is that I've to run n queries if n cores are cofigured and than
> merge results
> thanks in advance
> christian f.
> Mar 19, 2010 4:34:15 PM org.apache.solr.core.SolrCore execute
> INFO: [it] webapp=/solr path=/select
> params={tv.docIds=167&isShard=true&wt=javabin&version=1&tv=true} status=500
> QTime=10
> Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:33)
> at
> org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:197)
> at
> org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78)
> at org.apache.solr.search.QParser.getQuery(QParser.java:131)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:89)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
> 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.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:33)
> at
> org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:197)
> at
> org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78)
> at org.apache.solr.search.QParser.getQuery(QParser.java:131)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:89)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
> at
> org.apache.solr.servlet.SolrDispatchFilt
Re: Mailing List merge
why not just "d...@lucene.apache.org"? On Mon, Mar 22, 2010 at 11:44 AM, Grant Ingersoll wrote: > Shall we merge the dev mailing lists? This should reduce the cross-posting > and can be completely automated (other than you may have to update your > client-side filters) and was part of the plan to merge dev efforts. > > I'd propose it be called lucene-solr-...@l.a.o. I can put in an issue for > infra@ to do it. > > -Grant > - > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
Re: Mailing List merge
Logistically, how would this work? would d...@lucene.apache.org be an alias for java-dev and solr-dev? or a whole new list? Would people need to subscribe to it, or would you already be on the list if you were on java/solr dev? If we are on both lists, do we get two copies of every message? On Mon, Mar 22, 2010 at 11:44 AM, Grant Ingersoll wrote: > Shall we merge the dev mailing lists? This should reduce the cross-posting > and can be completely automated (other than you may have to update your > client-side filters) and was part of the plan to merge dev efforts. > > I'd propose it be called lucene-solr-...@l.a.o. I can put in an issue for > infra@ to do it. > > -Grant > - > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
Re: Mailing List merge
On Mar 22, 2010, at 12:43 PM, Ryan McKinley wrote: > Logistically, how would this work? > > would d...@lucene.apache.org be an alias for java-dev and solr-dev? or > a whole new list? I thought of d...@l.a.o, but we still have other dev lists under the PMC, so didn't want to imply it was the only one > > Would people need to subscribe to it, or would you already be on the > list if you were on java/solr dev? Infra would migrate all existing subscribers. > If we are on both lists, do we get > two copies of every message? No. There would only be one list.
solr delete core index files
Hi, to delete a solr core index, I do (1) curl "host/solr/admin/cores?action=UNLOAD&core=FOO" (2) rm -rf /abs_path_to_foo/FOO Is there a way to avoid step 2 and tell the solr server directly to delete the index files upon UNLOAD ? Thanks, Johannes
Branding Solr+Lucene
Now that Solr and Lucene live in the same space, there has been an on-going debate about what to call the merged entity. The names being mulled at this point include (variously sized) snippets of both Lucene's and Solr's names, and include LuSolr, Solcene, etc. (my current personal favorites along these lines: Sorlusr :) ). My guess is that Lucene partisans would like to see Solr just become a product (along with the Lucene java library) of the Lucene project. Judging from suggestions coming from Solr partisans, though, I don't think this will fly. So I think an entirely new name is needed for the merged project. Lucene and Solr would remain the product names of this newly named merged project. Along these lines, search.apache.org has been brought up a couple of times recently on the #lucene IRC channel. However (with all due respect to what-happens-on-#lucene-stays-on-#lucene (TM) ), Grant wrote in response to one of these suggestions this morning: prob. is "Search" is not a brand ASF likes names So in the spirit of a real name (i.e., an abstract symbol), I propose "Srrrch" (riffing off of "Riot Grrrls" and Solr's penchant for vowel droppings) Okay, not really. I do have one idea, though: thinking about the icons for Lucene (looks to me like the font used on 50's automobile brand logos) and Solr (a sun): car+sun => convertible => "Ragtop". Fun, short, abstract, apolitical. Solr's and Lucene's icons could be easily embedded in a Ragtop logo. Steve
Re: Branding Solr+Lucene
What are the implications of this this new branding effort with the brands for the existing Lucene and Solr? Will the names "Lucene" and "Solr" cease in the mainstream in favor of a merged name? Cheers, Chris On 3/22/10 11:02 AM, "Steven A Rowe" wrote: > Now that Solr and Lucene live in the same space, there has been an on-going > debate about what to call the merged entity. > > The names being mulled at this point include (variously sized) snippets of > both Lucene's and Solr's names, and include LuSolr, Solcene, etc. (my current > personal favorites along these lines: Sorlusr :) ). > > My guess is that Lucene partisans would like to see Solr just become a product > (along with the Lucene java library) of the Lucene project. Judging from > suggestions coming from Solr partisans, though, I don't think this will fly. > > So I think an entirely new name is needed for the merged project. Lucene and > Solr would remain the product names of this newly named merged project. > > Along these lines, search.apache.org has been brought up a couple of times > recently on the #lucene IRC channel. However (with all due respect to > what-happens-on-#lucene-stays-on-#lucene (TM) ), Grant wrote in response to > one of these suggestions this morning: > >prob. is "Search" is not a brand >ASF likes names > > So in the spirit of a real name (i.e., an abstract symbol), I propose "Srrrch" > (riffing off of "Riot Grrrls" and Solr's penchant for vowel droppings) > Okay, not really. > > I do have one idea, though: thinking about the icons for Lucene (looks to me > like the font used on 50's automobile brand logos) and Solr (a sun): car+sun > => convertible => "Ragtop". Fun, short, abstract, apolitical. Solr's and > Lucene's icons could be easily embedded in a Ragtop logo. > > Steve > > ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
Re: Branding Solr+Lucene
I'm confused... what is the need for a new name? The only place where there is a conflict is in the top level svn tree... What about something general like: https://svn.apache.org/repos/asf/lucene/dev or https://svn.apache.org/repos/asf/lucene/project ryan On Mon, Mar 22, 2010 at 2:02 PM, Steven A Rowe wrote: > Now that Solr and Lucene live in the same space, there has been an on-going > debate about what to call the merged entity. > > The names being mulled at this point include (variously sized) snippets of > both Lucene's and Solr's names, and include LuSolr, Solcene, etc. (my current > personal favorites along these lines: Sorlusr :) ). > > My guess is that Lucene partisans would like to see Solr just become a > product (along with the Lucene java library) of the Lucene project. Judging > from suggestions coming from Solr partisans, though, I don't think this will > fly. > > So I think an entirely new name is needed for the merged project. Lucene and > Solr would remain the product names of this newly named merged project. > > Along these lines, search.apache.org has been brought up a couple of times > recently on the #lucene IRC channel. However (with all due respect to > what-happens-on-#lucene-stays-on-#lucene (TM) ), Grant wrote in response to > one of these suggestions this morning: > > prob. is "Search" is not a brand > ASF likes names > > So in the spirit of a real name (i.e., an abstract symbol), I propose > "Srrrch" (riffing off of "Riot Grrrls" and Solr's penchant for vowel > droppings) Okay, not really. > > I do have one idea, though: thinking about the icons for Lucene (looks to me > like the font used on 50's automobile brand logos) and Solr (a sun): car+sun > => convertible => "Ragtop". Fun, short, abstract, apolitical. Solr's and > Lucene's icons could be easily embedded in a Ragtop logo. > > Steve > > > - > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
Re: Branding Solr+Lucene
On Mon, Mar 22, 2010 at 2:20 PM, Ryan McKinley wrote: > I'm confused... what is the need for a new name? The only place where > there is a conflict is in the top level svn tree... Agree, no need to re-brand. > What about something general like: > https://svn.apache.org/repos/asf/lucene/dev > or > https://svn.apache.org/repos/asf/lucene/project Hmmm, that one isn't bad. -Yonik
[jira] Commented: (SOLR-1826) highlighting breaks when using WordDelimiterFilter and setting termOffsets=true
[
https://issues.apache.org/jira/browse/SOLR-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848271#action_12848271
]
Sanjoy Ghosh commented on SOLR-1826:
Hi,
I investigated this some more. The problem seems to be in:
org.apache.lucene.search.highlight.TokenSource.java
public static TokenStream getTokenStream(TermPositionVector tpv, boolean
tokenPositionsGuaranteedContiguous) {
has at the end the following code to sort the tokens into original document
order.
Arrays.sort(tokensInOriginalOrder, new Comparator(){
public int compare(Object o1, Object o2)
{
Token t1=(Token) o1;
Token t2=(Token) o2;
if(t1.startOffset()>t2.endOffset())
return 1;
if(t1.startOffset() highlighting breaks when using WordDelimiterFilter and setting
> termOffsets=true
> ---
>
> Key: SOLR-1826
> URL: https://issues.apache.org/jira/browse/SOLR-1826
> Project: Solr
> Issue Type: Bug
> Components: highlighter
>Affects Versions: 1.4
>Reporter: Stefan Oestreicher
> Attachments: SOLR-1826.txt, SOLR-1826.txt, SOLR-1826.txt
>
>
> When using the WordDelimiterFilter and setting termOffsets to true the
> highlighting breaks in certain cases. This did not happen in the 1.3 release.
> For example, if I index the term "PowerShot.com" and search for {{pow*}} the
> highlighting snippet contains {{PowerPowerShot.com}}.
> I will attach a patch which adds tests to the highlighter unittest to
> demonstrate the issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Branding Solr+Lucene
On Mon, Mar 22, 2010 at 11:30 AM, Yonik Seeley wrote: > On Mon, Mar 22, 2010 at 2:20 PM, Ryan McKinley wrote: > > I'm confused... what is the need for a new name? The only place where > > there is a conflict is in the top level svn tree... > > Agree, no need to re-brand. I don't see any need to rebrand. The artifacts will still be called Lucene and Solr, regardless. In SVN, the natural thing to do is go with the momentum that puts solr under lucene. Insofar as the TLP, I would think that it would still be Lucene with two delivered artifacts.
RE: Branding Solr+Lucene
On 03/22/2010 at 2:30 PM, Yonik Seeley wrote: > On Mon, Mar 22, 2010 at 2:20 PM, Ryan McKinley > wrote: > > I'm confused... what is the need for a new name? The only place where > > there is a conflict is in the top level svn tree... > > Agree, no need to re-brand. Hmm, I've apparently misunderestimated the name-mooting that's been echoing around lately. Since "name" can refer to a bunch of partially overlapping things (Apache TLP name; svn directory name; development project name; product name; etc.): - Lucene will remain the name of the Apache TLP hosting both the Lucene-Java product and the Solr product. - Solr, while ceasing to refer to a stand-alone development sub-project, will continue to be a product, with no change in its user-facing *product* communications; Solr's downloadable artifacts, the wiki, the website, and the solr-user mailing list will remain as-is. (The website javadocs will need re-jiggering, though, I'd guess.) Any disagreement? Steve
[jira] Updated: (SOLR-1835) speed up and improve tests
[ https://issues.apache.org/jira/browse/SOLR-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-1835: -- Attachment: SOLR-1835_parallel.patch attached is a patch to parallelize the tests... improvements can be done, and contrib too (e.g. DIH) but this drops my test time to 4:42 on the first try. > speed up and improve tests > -- > > Key: SOLR-1835 > URL: https://issues.apache.org/jira/browse/SOLR-1835 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley > Fix For: 3.1 > > Attachments: SOLR-1835.patch, SOLR-1835_parallel.patch > > > General test improvements. > We should use @BeforeClass where possible to avoid per test method overhead, > and reuse lucene test utils where possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1835) speed up and improve tests
[ https://issues.apache.org/jira/browse/SOLR-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-1835: -- Attachment: SOLR-1835_parallel.patch updated patch: * doesnt do parallel for the -Dtestcase= case, but does for all, -Dtestpackage, -Dtestpackageroot, etc * you can make the condition for whether to do parallel or not more complex, e.g. nightlies could go sequentially. > speed up and improve tests > -- > > Key: SOLR-1835 > URL: https://issues.apache.org/jira/browse/SOLR-1835 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley > Fix For: 3.1 > > Attachments: SOLR-1835.patch, SOLR-1835_parallel.patch, > SOLR-1835_parallel.patch > > > General test improvements. > We should use @BeforeClass where possible to avoid per test method overhead, > and reuse lucene test utils where possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-632) Upgrade bundled Jetty with latest from vendor
[ https://issues.apache.org/jira/browse/SOLR-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848332#action_12848332 ] Mark Miller commented on SOLR-632: -- I'm trying out this upgrade (to 6.1.22) on newtrunk - seems like a nice time to get this done > Upgrade bundled Jetty with latest from vendor > - > > Key: SOLR-632 > URL: https://issues.apache.org/jira/browse/SOLR-632 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Norberto Meijome >Assignee: Erik Hatcher >Priority: Minor > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > The Jetty that is bundled for the example application is version 6.1.3, which > is over a year old. > We should upgrade Jetty to the latest, 6.1.11. > I am not sure how to attach a patch to remove files, so these are the steps : > Using as base the root of 'apache-solr-nightly': > DELETE: > example/lib/jetty-6.1.3.jar > example/lib/jetty-util-6.1.3.jar > example/lib/servlet-api-2.5-6.1.3.jar > ADD > example/lib/jetty-6.1.11.jar > example/lib/jetty-util-6.1.11.jar > example/lib/servlet-api-2.5-6.1.11.jar > --- > The files to be added can be found in Jetty's binary distribution file : > http://dist.codehaus.org/jetty/jetty-6.1.11/jetty-6.1.11.zip > I couldn't find any noticeable changes in jetty.xml that should be carried > over. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1838) TermVectors and Multicore configuration
[
https://issues.apache.org/jira/browse/SOLR-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848338#action_12848338
]
Christian Fontana commented on SOLR-1838:
-
To be more complete on my configuration I've attached solr.xml / schema.xml and
solrconfig.xml
Nodes config files differ only for few details.
The url I tried for the request is:
http://localhost:8983/solr/it/select/?q=*%3A*&version=2.2&start=0&rows=10&indent=on&qt=tv&shards=localhost:8983/solr/it,localhost:8983/solr/en
Thanks
> TermVectors and Multicore configuration
>
>
> Key: SOLR-1838
> URL: https://issues.apache.org/jira/browse/SOLR-1838
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 1.4
> Environment: Linux Debian
>Reporter: Christian Fontana
>
> Hello.
> My new to solr and I'm trying to setup solr with a multicore configuration.
> All cores shares the same schema.xml and I'm using index sharding.
> I need term vectors data to generate tag clouds but when I try to run a
> search across all cores to retrieve term vectors data the engine
> raises me the exception below.
> Now I created two request handlers, one for the user search and one for the
> engine in charge to create the tag cloud. The problem of this
> solution is that I've to run n queries if n cores are cofigured and than
> merge results
> thanks in advance
> christian f.
> Mar 19, 2010 4:34:15 PM org.apache.solr.core.SolrCore execute
> INFO: [it] webapp=/solr path=/select
> params={tv.docIds=167&isShard=true&wt=javabin&version=1&tv=true} status=500
> QTime=10
> Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:33)
> at
> org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:197)
> at
> org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78)
> at org.apache.solr.search.QParser.getQuery(QParser.java:131)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:89)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
> 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.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:33)
> at
> org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:197)
> at
> org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78)
> at org.apache.solr.search.QParser.getQuery(QParser.java:131)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:89)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
> at org.ap
[jira] Updated: (SOLR-1838) TermVectors and Multicore configuration
[
https://issues.apache.org/jira/browse/SOLR-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Fontana updated SOLR-1838:
Attachment: solrconfig.xml
schema.xml
solr.xml
My config files
> TermVectors and Multicore configuration
>
>
> Key: SOLR-1838
> URL: https://issues.apache.org/jira/browse/SOLR-1838
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 1.4
> Environment: Linux Debian
>Reporter: Christian Fontana
> Attachments: schema.xml, solr.xml, solrconfig.xml
>
>
> Hello.
> My new to solr and I'm trying to setup solr with a multicore configuration.
> All cores shares the same schema.xml and I'm using index sharding.
> I need term vectors data to generate tag clouds but when I try to run a
> search across all cores to retrieve term vectors data the engine
> raises me the exception below.
> Now I created two request handlers, one for the user search and one for the
> engine in charge to create the tag cloud. The problem of this
> solution is that I've to run n queries if n cores are cofigured and than
> merge results
> thanks in advance
> christian f.
> Mar 19, 2010 4:34:15 PM org.apache.solr.core.SolrCore execute
> INFO: [it] webapp=/solr path=/select
> params={tv.docIds=167&isShard=true&wt=javabin&version=1&tv=true} status=500
> QTime=10
> Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:33)
> at
> org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:197)
> at
> org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78)
> at org.apache.solr.search.QParser.getQuery(QParser.java:131)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:89)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
> 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.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:33)
> at
> org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:197)
> at
> org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78)
> at org.apache.solr.search.QParser.getQuery(QParser.java:131)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:89)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatch
[jira] Updated: (SOLR-1838) TermVectors and Multicore configuration
[
https://issues.apache.org/jira/browse/SOLR-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Fontana updated SOLR-1838:
Comment: was deleted
(was: My config files)
> TermVectors and Multicore configuration
>
>
> Key: SOLR-1838
> URL: https://issues.apache.org/jira/browse/SOLR-1838
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 1.4
> Environment: Linux Debian
>Reporter: Christian Fontana
> Attachments: schema.xml, solr.xml, solrconfig.xml
>
>
> Hello.
> My new to solr and I'm trying to setup solr with a multicore configuration.
> All cores shares the same schema.xml and I'm using index sharding.
> I need term vectors data to generate tag clouds but when I try to run a
> search across all cores to retrieve term vectors data the engine
> raises me the exception below.
> Now I created two request handlers, one for the user search and one for the
> engine in charge to create the tag cloud. The problem of this
> solution is that I've to run n queries if n cores are cofigured and than
> merge results
> thanks in advance
> christian f.
> Mar 19, 2010 4:34:15 PM org.apache.solr.core.SolrCore execute
> INFO: [it] webapp=/solr path=/select
> params={tv.docIds=167&isShard=true&wt=javabin&version=1&tv=true} status=500
> QTime=10
> Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:33)
> at
> org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:197)
> at
> org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78)
> at org.apache.solr.search.QParser.getQuery(QParser.java:131)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:89)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
> 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.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:33)
> at
> org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:197)
> at
> org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78)
> at org.apache.solr.search.QParser.getQuery(QParser.java:131)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:89)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
> at
> org.mortbay.jetty.
Re: [jira] Commented: (SOLR-1838) TermVectors and Multicore configuration
The mailing lists don't do attachments. Please include the files in-line.
I'm beginning to think a google form & docs would help this process.
On Mon, Mar 22, 2010 at 2:11 PM, Christian Fontana (JIRA)
wrote:
>
> [
> https://issues.apache.org/jira/browse/SOLR-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848338#action_12848338
> ]
>
> Christian Fontana commented on SOLR-1838:
> -
>
> To be more complete on my configuration I've attached solr.xml / schema.xml
> and solrconfig.xml
>
> Nodes config files differ only for few details.
>
> The url I tried for the request is:
>
> http://localhost:8983/solr/it/select/?q=*%3A*&version=2.2&start=0&rows=10&indent=on&qt=tv&shards=localhost:8983/solr/it,localhost:8983/solr/en
>
> Thanks
>
>> TermVectors and Multicore configuration
>>
>>
>> Key: SOLR-1838
>> URL: https://issues.apache.org/jira/browse/SOLR-1838
>> Project: Solr
>> Issue Type: Bug
>> Components: multicore
>> Affects Versions: 1.4
>> Environment: Linux Debian
>> Reporter: Christian Fontana
>>
>> Hello.
>> My new to solr and I'm trying to setup solr with a multicore configuration.
>> All cores shares the same schema.xml and I'm using index sharding.
>> I need term vectors data to generate tag clouds but when I try to run a
>> search across all cores to retrieve term vectors data the engine
>> raises me the exception below.
>> Now I created two request handlers, one for the user search and one for the
>> engine in charge to create the tag cloud. The problem of this
>> solution is that I've to run n queries if n cores are cofigured and than
>> merge results
>> thanks in advance
>> christian f.
>> Mar 19, 2010 4:34:15 PM org.apache.solr.core.SolrCore execute
>> INFO: [it] webapp=/solr path=/select
>> params={tv.docIds=167&isShard=true&wt=javabin&version=1&tv=true} status=500
>> QTime=10
>> Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
>> SEVERE: java.lang.NullPointerException
>> at java.io.StringReader.(StringReader.java:33)
>> at
>> org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:197)
>> at
>> org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78)
>> at org.apache.solr.search.QParser.getQuery(QParser.java:131)
>> at
>> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:89)
>> at
>> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174)
>> at
>> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
>> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
>> at
>> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
>> at
>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
>> 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.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
>> at
>> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
>> Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
>> SEVERE: java.lang.NullPointerException
>> at java.io.StringReader.(StringReader.java:33)
>> at
>> org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:197)
>> at
>> org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78)
>> at org.apache.solr.search.QParser.getQuery(QParser.java:131)
>>
Re: [jira] Commented: (SOLR-1838) TermVectors and Multicore configuration
Oops, didn't notice this was solr-dev in a JIRA.
Please do questions like this on solr-user. Thanks!
On Mon, Mar 22, 2010 at 2:19 PM, Lance Norskog wrote:
> The mailing lists don't do attachments. Please include the files in-line.
>
> I'm beginning to think a google form & docs would help this process.
>
> On Mon, Mar 22, 2010 at 2:11 PM, Christian Fontana (JIRA)
> wrote:
>>
>> [
>> https://issues.apache.org/jira/browse/SOLR-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848338#action_12848338
>> ]
>>
>> Christian Fontana commented on SOLR-1838:
>> -
>>
>> To be more complete on my configuration I've attached solr.xml / schema.xml
>> and solrconfig.xml
>>
>> Nodes config files differ only for few details.
>>
>> The url I tried for the request is:
>>
>> http://localhost:8983/solr/it/select/?q=*%3A*&version=2.2&start=0&rows=10&indent=on&qt=tv&shards=localhost:8983/solr/it,localhost:8983/solr/en
>>
>> Thanks
>>
>>> TermVectors and Multicore configuration
>>>
>>>
>>> Key: SOLR-1838
>>> URL: https://issues.apache.org/jira/browse/SOLR-1838
>>> Project: Solr
>>> Issue Type: Bug
>>> Components: multicore
>>> Affects Versions: 1.4
>>> Environment: Linux Debian
>>> Reporter: Christian Fontana
>>>
>>> Hello.
>>> My new to solr and I'm trying to setup solr with a multicore configuration.
>>> All cores shares the same schema.xml and I'm using index sharding.
>>> I need term vectors data to generate tag clouds but when I try to run a
>>> search across all cores to retrieve term vectors data the engine
>>> raises me the exception below.
>>> Now I created two request handlers, one for the user search and one for the
>>> engine in charge to create the tag cloud. The problem of this
>>> solution is that I've to run n queries if n cores are cofigured and than
>>> merge results
>>> thanks in advance
>>> christian f.
>>> Mar 19, 2010 4:34:15 PM org.apache.solr.core.SolrCore execute
>>> INFO: [it] webapp=/solr path=/select
>>> params={tv.docIds=167&isShard=true&wt=javabin&version=1&tv=true} status=500
>>> QTime=10
>>> Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
>>> SEVERE: java.lang.NullPointerException
>>> at java.io.StringReader.(StringReader.java:33)
>>> at
>>> org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:197)
>>> at
>>> org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78)
>>> at org.apache.solr.search.QParser.getQuery(QParser.java:131)
>>> at
>>> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:89)
>>> at
>>> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174)
>>> at
>>> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
>>> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
>>> at
>>> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
>>> at
>>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
>>> 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.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
>>> at
>>> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
>>> Mar 19, 2010 4:34:15 PM org.apache.solr.common.SolrException log
>>> SEVERE: java.lang.NullPointerException
>>> at java.io.StringReader.(StringR
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[
https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848347#action_12848347
]
Dan Bentson commented on SOLR-773:
--
Update to my above comment. I was able to get both types of searches working.
Using the Spatial Filter QParser I'm getting the results I want (example query:
q=pizza{!sfilt fl=location}&pt=49.32,-79.0&dist=20). I have a couple questions
though:
First of all what is the distance unit of measurement? Miles? Meters?
Also, using Patrick's plug-in it returned the distance as a result field. Is
there any way to do that in SOLR 1.5?
Any help with this would be greatly appreciated!!!
Thanks
> Incorporate Local Lucene/Solr
> -
>
> Key: SOLR-773
> URL: https://issues.apache.org/jira/browse/SOLR-773
> Project: Solr
> Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar,
> lucene.tar.gz, screenshot-1.jpg, SOLR-773-local-lucene.patch,
> SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch,
> SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch,
> SOLR-773-spatial_solr.patch, SOLR-773.patch, SOLR-773.patch,
> solrGeoQuery.tar, spatial-solr.tar.gz
>
>
> Local Lucene has been donated to the Lucene project. It has some Solr
> components, but we should evaluate how best to incorporate it into Solr.
> See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: solr delete core index files
Two things: 1> you can create a delete query matching all your documents like the query "*:*" 2> This kind of question is better suited to the solr user list, this list is devoted to internal SOLR development... Best Erick On Mon, Mar 22, 2010 at 1:36 PM, Johannes Goll wrote: > Hi, > > to delete a solr core index, I do > (1) curl "host/solr/admin/cores?action=UNLOAD&core=FOO" > (2) rm -rf /abs_path_to_foo/FOO > > Is there a way to avoid step 2 and tell the solr server directly to > delete the index files > upon UNLOAD ? > > Thanks, > Johannes >
[jira] Updated: (SOLR-1835) speed up and improve tests
[ https://issues.apache.org/jira/browse/SOLR-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-1835: -- Attachment: SOLR-1835_parallel.patch attached is a new patch: * the output from multiple threads is no longer interleaved * you need to put ant.jar and ant-junit.jar in example/lib for this patch to work. these need to be ant 1.7.1 (lucene needs this version anyway i think) > speed up and improve tests > -- > > Key: SOLR-1835 > URL: https://issues.apache.org/jira/browse/SOLR-1835 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley > Fix For: 3.1 > > Attachments: SOLR-1835.patch, SOLR-1835_parallel.patch, > SOLR-1835_parallel.patch, SOLR-1835_parallel.patch > > > General test improvements. > We should use @BeforeClass where possible to avoid per test method overhead, > and reuse lucene test utils where possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1835) speed up and improve tests
[ https://issues.apache.org/jira/browse/SOLR-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-1835: -- Attachment: SOLR-1835_parallel.patch there was a stray slash in the previous version. this caused some people to mistakenly believe they have a faster computer than me. > speed up and improve tests > -- > > Key: SOLR-1835 > URL: https://issues.apache.org/jira/browse/SOLR-1835 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley > Fix For: 3.1 > > Attachments: SOLR-1835.patch, SOLR-1835_parallel.patch, > SOLR-1835_parallel.patch, SOLR-1835_parallel.patch, SOLR-1835_parallel.patch > > > General test improvements. > We should use @BeforeClass where possible to avoid per test method overhead, > and reuse lucene test utils where possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-42) Highlighting problems with HTMLStripWhitespaceTokenizerFactory
[ https://issues.apache.org/jira/browse/SOLR-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12848542#action_12848542 ] David Smiley commented on SOLR-42: -- I was just reading this whole thread and SOLR-1394. It seems this issue can be closed as a duplicate of SOLR-1394. No? > Highlighting problems with HTMLStripWhitespaceTokenizerFactory > -- > > Key: SOLR-42 > URL: https://issues.apache.org/jira/browse/SOLR-42 > Project: Solr > Issue Type: Bug > Components: highlighter >Reporter: Andrew May >Assignee: Grant Ingersoll >Priority: Minor > Attachments: htmlStripReaderTest.html, HTMLStripReaderTest.java, > HtmlStripReaderTestXmlProcessing.patch, > HtmlStripReaderTestXmlProcessing.patch, SOLR-42.patch, SOLR-42.patch, > SOLR-42.patch, SOLR-42.patch, TokenPrinter.java > > > Indexing content that contains HTML markup, causes problems with highlighting > if the HTMLStripWhitespaceTokenizerFactory is used (to prevent the tag names > from being searchable). > Example title field: > 40Ar/39Ar laserprobe dating of mylonitic fabrics in a > polyorogenic terrane of NW Iberia > Searching for title:fabrics with highlighting on, the highlighted version has > the tags in the wrong place - 22 characters to the left of where they > should be (i.e. the sum of the lengths of the tags). > Response from Yonik on the solr-user mailing-list: > HTMLStripWhitespaceTokenizerFactory works in two phases... > HTMLStripReader removes the HTML and passes the result to > WhitespaceTokenizer... at that point, Tokens are generated, but the > offsets will correspond to the text after HTML removal, not before. > I did it this way so that HTMLStripReader could go before any > tokenizer (like StandardTokenizer). > Can you open a JIRA bug for this? The fix would be a special version > of HTMLStripReader integrated with a WhitespaceTokenizer to keep > offsets correct. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
