Solr nightly build failure
init-forrest-entities: [mkdir] Created dir: /tmp/apache-solr-nightly/build [mkdir] Created dir: /tmp/apache-solr-nightly/build/web compile-solrj: [mkdir] Created dir: /tmp/apache-solr-nightly/build/solrj [javac] Compiling 83 source files to /tmp/apache-solr-nightly/build/solrj [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile: [mkdir] Created dir: /tmp/apache-solr-nightly/build/solr [javac] Compiling 375 source files to /tmp/apache-solr-nightly/build/solr [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compileTests: [mkdir] Created dir: /tmp/apache-solr-nightly/build/tests [javac] Compiling 162 source files to /tmp/apache-solr-nightly/build/tests [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. junit: [mkdir] Created dir: /tmp/apache-solr-nightly/build/test-results [junit] Running org.apache.solr.BasicFunctionalityTest [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 20.536 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 8.971 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 5.536 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 3.936 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 2.777 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.118 sec [junit] Running org.apache.solr.SolrInfoMBeanTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.975 sec [junit] Running org.apache.solr.TestDistributedSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 31.274 sec [junit] Running org.apache.solr.TestTrie [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 10.031 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.433 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.402 sec [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.09 sec [junit] Running org.apache.solr.analysis.HTMLStripReaderTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.603 sec [junit] Running org.apache.solr.analysis.LengthFilterTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.482 sec [junit] Running org.apache.solr.analysis.SnowballPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.514 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.123 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.971 sec [junit] Running org.apache.solr.analysis.TestCharFilter [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.714 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.202 sec [junit] Running org.apache.solr.analysis.TestKeepFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.634 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.203 sec [junit] Running org.apache.solr.analysis.TestMappingCharFilter [junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 0.565 sec [junit] Running org.apache.solr.analysis.TestMappingCharFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.442 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.218 sec [junit] Running org.apache.solr.analysis.TestPatternTokenizerFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.52 sec [junit] Running org.apache.solr.analysis.TestPhoneticFilter
[jira] Created: (SOLR-1226) XPathEntityProcessor should resolve xsl references within Solr's configuration
XPathEntityProcessor should resolve xsl references within Solr's configuration -- Key: SOLR-1226 URL: https://issues.apache.org/jira/browse/SOLR-1226 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 1.4 Reporter: David Smiley Priority: Minor The XPathEntityProcessor forces me to use a URL to specify where my XSL file is. if it is not a URL, what it should do is attempt to resolve it from Solr's configuration via SolrCore.getREsourceLoader(). I have attached a patch which does this. Note: it is not clear in the DIH what the concurrency model is and thus I was not certain that XPathEntityProcessor needs to be thread-safe or not. So just in case I cached the XSLT Transformer in a thread-safe manner using a ThreadLocal. If DIH committers know that it doesn't have to be thread-safe then some of this code can be simplified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1226) XPathEntityProcessor should resolve xsl references within Solr's configuration
[ https://issues.apache.org/jira/browse/SOLR-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-1226: --- Attachment: SOLR-1226.patch > XPathEntityProcessor should resolve xsl references within Solr's configuration > -- > > Key: SOLR-1226 > URL: https://issues.apache.org/jira/browse/SOLR-1226 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: David Smiley >Priority: Minor > Attachments: SOLR-1226.patch > > > The XPathEntityProcessor forces me to use a URL to specify where my XSL file > is. if it is not a URL, what it should do is attempt to resolve it from > Solr's configuration via SolrCore.getREsourceLoader(). I have attached a > patch which does this. > Note: it is not clear in the DIH what the concurrency model is and thus I was > not certain that XPathEntityProcessor needs to be thread-safe or not. So > just in case I cached the XSLT Transformer in a thread-safe manner using a > ThreadLocal. If DIH committers know that it doesn't have to be thread-safe > then some of this code can be simplified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Missing SLF4J lib?
Hi everybody, With Solr 1.4, when I try to *run* an app that uses SolrJ, it fails with this exception: Exception in thread "Thread-4" java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:77) I searched around a bit, and have found people telling me I need to include the SLF4J jars in my classpath. The most helpful of these comments read: > I think you need slf4j-api-1.5.5.jar and slf4j-jdk14-1.5.5.jar. Both > can be found in solr's nightly downloads in the lib directory. Unfortunately that's not true, the "slf4j-jdk" JAR is not present in the nightly's lib directory. In order to get my program to run I had to download it from here and put it in my runtime classpath in order to get my program to work: http://www.slf4j.org/download.html Should I log a bug to have this library included in the nightly builds? Also, on a related note, we may want to warn users of SolrJ in the documentation that they'll need these jars during runtime. Otherwise their programs will fail and they'll wonder what's going on. - Daryl.
Re: Missing SLF4J lib?
True, its not in apache-solr-nightly/dist/solrj-lib, but it is in apache-solr-nightly/lib, so no reason to have to download it. I couldn't comment on whether or not it also belongs in solrj-lib. -- - Mark http://www.lucidimagination.com Development Team wrote: Hi everybody, With Solr 1.4, when I try to *run* an app that uses SolrJ, it fails with this exception: Exception in thread "Thread-4" java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:77) I searched around a bit, and have found people telling me I need to include the SLF4J jars in my classpath. The most helpful of these comments read: I think you need slf4j-api-1.5.5.jar and slf4j-jdk14-1.5.5.jar. Both can be found in solr's nightly downloads in the lib directory. Unfortunately that's not true, the "slf4j-jdk" JAR is not present in the nightly's lib directory. In order to get my program to run I had to download it from here and put it in my runtime classpath in order to get my program to work: http://www.slf4j.org/download.html Should I log a bug to have this library included in the nightly builds? Also, on a related note, we may want to warn users of SolrJ in the documentation that they'll need these jars during runtime. Otherwise their programs will fail and they'll wonder what's going on. - Daryl.
[jira] Commented: (SOLR-1223) Query Filter fq with OR operator
[ https://issues.apache.org/jira/browse/SOLR-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720710#action_12720710 ] Brian Pearson commented on SOLR-1223: - Just putting my thoughts out .. obviously don't have the same understanding as Yonik :) Feels like specifying which filter's are cached doesn't need to be part of this issue. This issue could just be about specifying the boolean logic that gets applied to the Doc Maps that are created by the filters. So today you have a number of filters .. F1, F2, ... FN and the boolean logic is F1 & F2 & .. &FN What I'm hoping for is something simple where you have 2 groups, the AND group and the OR group. AND group: A1, A2 OR group: O1, O2 So the filter you end up with is (A1 & A2) & (O1 | O2). The caching logic doesn't need to change then, there are still 4 filter queries. Real example: Current method fq=popularity:[10 TO *] OR section:0 fq=type:2 New method (assuming we added ofq for the OR'd filter query group, probably there is a better way to make the API ) ofq=popularity:[10 TO *] ofq=section:0 fq=type:2 I realize I'm probably missing some important implementation details that Yonik alludes to, just wanted to get my thoughts down. I wish I was in a position to actually work on this .. if someone takes this on, I can help with beta testing and documentation. If anyone cares, the reason I want this is because my apps have extremely complicated authorization logic. I can do what I need using fq's, but the filters get large and are very specific to the user that did the search. If I had OR logic, then I could break the filters down into smaller pieces, which would be much more reusable from the cache, and performance would be much better Thanks for listening :) > Query Filter fq with OR operator > > > Key: SOLR-1223 > URL: https://issues.apache.org/jira/browse/SOLR-1223 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Brian Pearson >Priority: Minor > > See this > [issue|http://www.nabble.com/Query-Filter-fq-with-OR-operator-td23895837.html] > for some background.Today, all of the Query filters specified with the > fq parameter are AND'd together. > This issue is about allowing a set of filters to be OR'd together (in > addition to having another set of filters that are AND'd).The OR'd > filters would of course be applied before any scoring is done. > The advantage of this feature is that you will be able to break up complex > filters into simple, more cacheable filters, which should improve performance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Missing SLF4J lib?
Ahhh... yeah it is there, thanks. Seems to me that it should be in dist's solrj-lib (since it's required at runtime), but then again I'm not really in a position to comment on that either. Question: Are all the jars in solrj-lib required to run SolrJ? - Daryl. On Wed, Jun 17, 2009 at 11:13 AM, Mark Miller wrote: > True, its not in apache-solr-nightly/dist/solrj-lib, but it is in > apache-solr-nightly/lib, so no reason to have to download it. > > I couldn't comment on whether or not it also belongs in solrj-lib. > > -- > - Mark > > http://www.lucidimagination.com > > > > > Development Team wrote: > >> Hi everybody, >> With Solr 1.4, when I try to *run* an app that uses SolrJ, it fails >> with this exception: >> >> Exception in thread "Thread-4" java.lang.NoClassDefFoundError: >> org/slf4j/LoggerFactory >> at >> >> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.(CommonsHttpSolrServer.java:77) >> >> I searched around a bit, and have found people telling me I need to >> include the SLF4J jars in my classpath. The most helpful of these comments >> read: >> >> >> >>> I think you need slf4j-api-1.5.5.jar and slf4j-jdk14-1.5.5.jar. Both >>> can be found in solr's nightly downloads in the lib directory. >>> >>> >> >> Unfortunately that's not true, the "slf4j-jdk" JAR is not present in >> the nightly's lib directory. In order to get my program to run I had to >> download it from here and put it in my runtime classpath in order to get >> my >> program to work: http://www.slf4j.org/download.html >> Should I log a bug to have this library included in the nightly >> builds? >> >> Also, on a related note, we may want to warn users of SolrJ in the >> documentation that they'll need these jars during runtime. Otherwise their >> programs will fail and they'll wonder what's going on. >> >> - Daryl. >> >> >> > > > >
Re: Problem getting Solr statistics
So for all those wondering what the problem was:
It turns out I can't just initialize my own CoreContainer; that just gives
me a *new* set of cores, and since those are not the cores being used by the
SolrDispatchFilter, they're never accessed and thus the stats remain the
same (such as having "2" queries performed on the core) throughout the life
of the server.
What I had to do was extend the SolrDispatchFilter to gain access to its
protected CoreContainer and use that one.
(Should Solr expose the core to those who are servicing requests that are
not HTTP-based? The SolrDispatchFilter puts the "core" into the request, but
not all things that need access to the core are servlets or filters. For
example, I'm using an MBean whose actions are called through SNMP.)
- Daryl.
On Tue, Jun 16, 2009 at 2:42 PM, Development Team wrote:
> Hi all,
> I am stumped trying to get statistics from the Solr server. It seems
> that every time I get the correct SolrInfoMBean, when I look up the proper
> value (by name) in the NamedList, I get the exact same number back each
> time. For example, upon start-up the server reports that "2" queries have
> been performed, and any time I pull the value out of the MBean after that it
> says "2" even though the stats.jsp reports an increasing number of queries
> over time. What am I doing wrong?
> Here is my sample code:
>
> public class SolrUtil {
>
> protected static final CoreContainer coreContainer;
> protected static final String DEFAULT_CORE_NAME = "";
>
> static {
> CoreContainer.Initializer initializer = new
> CoreContainer.Initializer();
> try {
> coreContainer = initializer.initialize();
> }
> catch (Exception e) {
> throw new ExceptionInInitializerError("Can't initialize core
> container: " + e.getMessage());
> }
> initialize();
> }
>
> private static SolrCore getCore() {
> return getCore(DEFAULT_CORE_NAME);
> }
>
> private static SolrCore getCore(String name) {
> try {
> return coreContainer.getCore(name);
> }
> catch (Exception e) {
> e.printStackTrace();
> }
> return null;
> }
>
> public static String getSolrInfoMBeanValue(SolrInfoMBean.Category
> category, String entryName, String statName) {
> Map registry = getCore().getInfoRegistry();
> for (Map.Entry entry : registry.entrySet()) {
> String key = entry.getKey();
> SolrInfoMBean solrInfoMBean = entry.getValue();
> if ((solrInfoMBean.getCategory() != category) ||
> (!entryName.equals(key.trim( {
> continue;
> }
> NamedList nl = solrInfoMBean.getStatistics();
> if ((nl != null) && (nl.size() > 0)) {
> for (int i = 0; i < nl.size(); i++) {
> if (nl.getName(i).equals(statName)) {
> return nl.getVal(i).toString();
> }
> }
> }
> }
> return null;
> }
>
> [...I have other methods, that also get the value as a long, etc]
>
> }
>
>
>
> This code is modeled after the SolrDispatchFilter.java, _info.jsp and
> stats.jsp.
> I'd appreciate any help. (And yes, my core is named "".)
>
> Sincerely,
>
> Daryl.
>
[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=12720861#action_12720861 ] Shekhar commented on SOLR-773: -- Can someone please let me know where can I download latest spatial solr code from. > 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 > Attachments: lucene.tar.gz, 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.patch, > SOLR-773.patch, 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.
[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=12720866#action_12720866 ] patrick o'leary commented on SOLR-773: -- It's in lucene trunk under contrib/spatial > 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 > Attachments: lucene.tar.gz, 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.patch, > SOLR-773.patch, 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.
[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=12720899#action_12720899 ] Shekhar commented on SOLR-773: -- I checkedout code from https://svn.apache.org/repos/asf/lucene/java/trunk/contrib/. It generates lucene-spatial-2.9-dev.jar. But I am looking for solr-spatial (org.apache.solr.spatial.tier package). > 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 > Attachments: lucene.tar.gz, 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.patch, > SOLR-773.patch, 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.
[jira] Commented: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720908#action_12720908 ] Shekhar commented on SOLR-236: -- Thanks a lot Martijn for you help.. Could you please point me to the example you are referring to. I could not find any example which is using DistanceCalculatingComponent. > Field collapsing > > > Key: SOLR-236 > URL: https://issues.apache.org/jira/browse/SOLR-236 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Emmanuel Keller > Fix For: 1.5 > > Attachments: collapsing-patch-to-1.3.0-dieter.patch, > collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, > collapsing-patch-to-1.3.0-ivan_3.patch, field-collapse-solr-236-2.patch, > field-collapse-solr-236.patch, field-collapsing-extended-592129.patch, > field_collapsing_1.1.0.patch, field_collapsing_1.3.patch, > field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, > field_collapsing_dsteigerwald.diff, SOLR-236-FieldCollapsing.patch, > SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, > solr-236.patch, SOLR-236_collapsing.patch, SOLR-236_collapsing.patch > > > This patch include a new feature called "Field collapsing". > "Used in order to collapse a group of results with similar value for a given > field to a single entry in the result set. Site collapsing is a special case > of this, where all results for a given web site is collapsed into one or two > entries in the result set, typically with an associated "more documents from > this site" link. See also Duplicate detection." > http://www.fastsearch.com/glossary.aspx?m=48&amid=299 > The implementation add 3 new query parameters (SolrParams): > "collapse.field" to choose the field used to group results > "collapse.type" normal (default value) or adjacent > "collapse.max" to select how many continuous results are allowed before > collapsing > TODO (in progress): > - More documentation (on source code) > - Test cases > Two patches: > - "field_collapsing.patch" for current development version > - "field_collapsing_1.1.0.patch" for Solr-1.1.0 > P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1227) schema.jsp will be cached in browser
schema.jsp will be cached in browser Key: SOLR-1227 URL: https://issues.apache.org/jira/browse/SOLR-1227 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 1.4 Environment: Solr 1.4 embedded jetty Reporter: Edward Capriolo Fix For: 1.4 The solr.xml schema file gets cached by the browser http://localhost:port/solr/admin/schema.jsp . This leads people to thing the schema has not been changed after editing it. The web interface should instantly expire this page and possibly some others. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
aaah, using trunk is fun! -- Illegal sort type: 2
Just started getting this error with a recent update: Caused by: java.lang.IllegalStateException: Illegal sort type: 2 at org.apache.lucene.search.SortField.getComparator(SortField.java:492) at org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.(FieldValueHitQueue.java:80) at org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:190) at org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:851) at org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1082) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:880) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:341) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:176) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1290) at org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:139) This only happens when I combine a custom filter with a text search (same custom filter as the last time). Before digging deeply into what solr/lucene rev changed the behavior, I just want to check if this rings a bell with anyone thanks! ryan
Re: aaah, using trunk is fun! -- Illegal sort type: 2
Type 2 is auto and its been deprecated in Lucene. Not sure why you are seeing this issue though. Could be the recent changes to Solr for LUCENE-1483 - auto now has to be resolved before using the collector, ie using int autotype = SortField.detectFieldType(reader, fieldname); I remember this changing but not the exact details. Probably Solr is not doing this though. - Mark Ryan McKinley wrote: Just started getting this error with a recent update: Caused by: java.lang.IllegalStateException: Illegal sort type: 2 at org.apache.lucene.search.SortField.getComparator(SortField.java:492) at org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.(FieldValueHitQueue.java:80) at org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:190) at org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:851) at org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1082) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:880) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:341) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:176) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1290) at org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:139) This only happens when I combine a custom filter with a text search (same custom filter as the last time). Before digging deeply into what solr/lucene rev changed the behavior, I just want to check if this rings a bell with anyone thanks! ryan -- - Mark http://www.lucidimagination.com
Re: aaah, using trunk is fun! -- Illegal sort type: 2
Digging in a little more... this is triggered by a custom search
component that takes some parameters and adds a custom filter to the
mix.
In the component prepare() function, it checks if the there is a sort
defined, if not it defaults to something:
SortSpec sortSpec = builder.getSortSpec();
if( sortSpec.getSort() == null ) {
sortSpec.setSort( new Sort( new SortField[] {
new SortField( "afield", true )
}));
}
If I comment this out, I do not get the error (not surprising)
However, if I add the sort field to the original query it works without problem.
Perhaps there has been some changen that now requires me to do something else?
Any ideas?
thanks
ryan
On Wed, Jun 17, 2009 at 7:28 PM, Mark Miller wrote:
> Type 2 is auto and its been deprecated in Lucene.
>
> Not sure why you are seeing this issue though. Could be the recent changes
> to Solr for LUCENE-1483 - auto now has to be resolved before using the
> collector, ie using int autotype = SortField.detectFieldType(reader,
> fieldname);
>
> I remember this changing but not the exact details.
>
> Probably Solr is not doing this though.
>
> - Mark
>
> Ryan McKinley wrote:
>>
>> Just started getting this error with a recent update:
>>
>> Caused by: java.lang.IllegalStateException: Illegal sort type: 2
>> at
>> org.apache.lucene.search.SortField.getComparator(SortField.java:492)
>> at
>> org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.(FieldValueHitQueue.java:80)
>> at
>> org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:190)
>> at
>> org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:851)
>> at
>> org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1082)
>> at
>> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:880)
>> at
>> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:341)
>> at
>> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:176)
>> at
>> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195)
>> at
>> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
>> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1290)
>> at
>> org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:139)
>>
>>
>> This only happens when I combine a custom filter with a text search
>> (same custom filter as the last time).
>>
>> Before digging deeply into what solr/lucene rev changed the behavior,
>> I just want to check if this rings a bell with anyone
>>
>> thanks!
>> ryan
>>
>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
Re: aaah, using trunk is fun! -- Illegal sort type: 2
Oh, okay. Thats a deprecated constructor that will set the type to
auto:2. Should have occurred to me that Solr doesn't use auto anyway :)
Hard to switch my mind between these two projects.
I can't remember the discussion around this and back compat :) I'll
have to dig back.
You need to resolve that Sort field since the new sort collector won't
do it for you anymore. So either grab the field type from Solr and set
it rather than using AUTO, or resolve it with:
sortField = new SortField(field, SortField.detectFieldType(reader,field));
- Mark
Ryan McKinley wrote:
Digging in a little more... this is triggered by a custom search
component that takes some parameters and adds a custom filter to the
mix.
In the component prepare() function, it checks if the there is a sort
defined, if not it defaults to something:
SortSpec sortSpec = builder.getSortSpec();
if( sortSpec.getSort() == null ) {
sortSpec.setSort( new Sort( new SortField[] {
new SortField( "afield", true )
}));
}
If I comment this out, I do not get the error (not surprising)
However, if I add the sort field to the original query it works without problem.
Perhaps there has been some changen that now requires me to do something else?
Any ideas?
thanks
ryan
On Wed, Jun 17, 2009 at 7:28 PM, Mark Miller wrote:
Type 2 is auto and its been deprecated in Lucene.
Not sure why you are seeing this issue though. Could be the recent changes
to Solr for LUCENE-1483 - auto now has to be resolved before using the
collector, ie using int autotype = SortField.detectFieldType(reader,
fieldname);
I remember this changing but not the exact details.
Probably Solr is not doing this though.
- Mark
Ryan McKinley wrote:
Just started getting this error with a recent update:
Caused by: java.lang.IllegalStateException: Illegal sort type: 2
at
org.apache.lucene.search.SortField.getComparator(SortField.java:492)
at
org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.(FieldValueHitQueue.java:80)
at
org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:190)
at
org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:851)
at
org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1082)
at
org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:880)
at
org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:341)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:176)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1290)
at
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.request(EmbeddedSolrServer.java:139)
This only happens when I combine a custom filter with a text search
(same custom filter as the last time).
Before digging deeply into what solr/lucene rev changed the behavior,
I just want to check if this rings a bell with anyone
thanks!
ryan
--
- Mark
http://www.lucidimagination.com
--
- Mark
http://www.lucidimagination.com
Re: aaah, using trunk is fun! -- Illegal sort type: 2
... grab the field type from Solr and set it rather than using AUTO, ... This constructor public SortField (String field, int type, boolean reverse)
[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=12720995#action_12720995 ] patrick o'leary commented on SOLR-773: -- That comes from this patch- This was an older port of localsolr to solr that's fallen behind and hasn't been maintained. I'll take a look at it and see see about getting it working > 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 > Attachments: lucene.tar.gz, 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.patch, > SOLR-773.patch, 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: aaah, using trunk is fun! -- Illegal sort type: 2
thanks!
I replaced my code with this and it works fine now:
SortSpec sortSpec = builder.getSortSpec();
if( sortSpec.getSort() == null ) {
SchemaField sf = builder.req.getCore().getSchema()
.getField( "somefield" );
sortSpec.setSort( new Sort( new SortField[] {
sf.getSortField( true )
}));
}
thanks mark!
On Wed, Jun 17, 2009 at 8:07 PM, Mark Miller wrote:
>
>> ... grab the field type from Solr and set it rather than using AUTO, ...
>
> This constructor public SortField (String field, int type, boolean reverse)
>
>
[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=12721016#action_12721016 ] Shekhar commented on SOLR-773: -- Patrick, I finally got it compiled. Had to do some minor changes. But it is giving 0 results. I am trying to run localsolr and collapse together. But so far no luck. Following is my solrconfig : explicit spatial_tier doctype:provider lat lng geo_distance tier collapse geodistance === Response : int name="QTime">6 − 40.755677 500 on LCD geo -74.418689 2.2 > 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 > Attachments: lucene.tar.gz, 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.patch, > SOLR-773.patch, 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.
[jira] Issue Comment Edited: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721016#action_12721016 ] Shekhar edited comment on SOLR-773 at 6/17/09 5:42 PM: --- Patrick, I finally got it compiled. Had to do some minor changes. But it is giving 0 results. I am trying to run localsolr and collapse together. But so far no luck. Request : http://localhost:9080/solr/select?indent=on&version=2.2&q=LCD&qt=geo&long=-74.418689&radius=500&lat=40.755677 Following is my solrconfig : explicit spatial_tier doctype:provider lat lng geo_distance tier collapse geodistance === Response : int name="QTime">6 − 40.755677 500 on LCD geo -74.418689 2.2 was (Author: csnirkhe): Patrick, I finally got it compiled. Had to do some minor changes. But it is giving 0 results. I am trying to run localsolr and collapse together. But so far no luck. Following is my solrconfig : explicit spatial_tier doctype:provider lat lng geo_distance tier collapse geodistance === Response : int name="QTime">6 − 40.755677 500 on LCD geo -74.418689 2.2 > 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 > Attachments: lucene.tar.gz, 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.patch, > SOLR-773.patch, 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.
