[jira] Commented: (SOLR-1425) Better exception messages for classloader mishaps
[ https://issues.apache.org/jira/browse/SOLR-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754483#action_12754483 ] Hoss Man commented on SOLR-1425: (FWIW: this is an offshoot of SOLR-1419) Benson: can you post the *FULL* stacktrace of what you see in your VM when you encounter a problem like this? The stack trace you posted in SOLR-1419 is only partial (note that it starts with "Caused by" ... there should have been more before that) SolrResourceLoader already catches ClassNotFound and logs appropriate info -- so that stack trace you posted should have started with something more useful. > Better exception messages for classloader mishaps > - > > Key: SOLR-1425 > URL: https://issues.apache.org/jira/browse/SOLR-1425 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Benson Margulies > > If an idiot such as myself tries to specify a filter or such that lives in a > parent classloader, such as the system classloader of a servlet container, > Solr will fail to load it. The JVM is prone to create an exception that > mentions some Solr interface as being missing instead of the filter itself. > It would be less confusing for the miscreant if Solr were to try/catch > ClassNotFound and NoClassDefError and throw its own exception with the name > of the thing specified in the schema included in the message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1316) Create autosuggest component
[ https://issues.apache.org/jira/browse/SOLR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754482#action_12754482 ] Shalin Shekhar Mangar commented on SOLR-1316: - This is a duplicate of SOLR-706. Since we comments on both, which one should I close? :) > Create autosuggest component > > > Key: SOLR-1316 > URL: https://issues.apache.org/jira/browse/SOLR-1316 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Priority: Minor > Fix For: 1.5 > > Original Estimate: 96h > Remaining Estimate: 96h > > Autosuggest is a common search function that can be integrated > into Solr as a SearchComponent. Our first implementation will > use the TernaryTree found in Lucene contrib. > * Enable creation of the dictionary from the index or via Solr's > RPC mechanism > * What types of parameters and settings are desirable? > * Hopefully in the future we can include user click through > rates to boost those terms/phrases higher -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1336) Add support for lucene's SmartChineseAnalyzer
[ https://issues.apache.org/jira/browse/SOLR-1336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754481#action_12754481 ] Hoss Man commented on SOLR-1336: bq. The downside is a 3MB jar in solr/lib and in the solr.war contrib? Chinese isn't something everybody needs, and 3MB would almost double the size of the solr.war. > Add support for lucene's SmartChineseAnalyzer > - > > Key: SOLR-1336 > URL: https://issues.apache.org/jira/browse/SOLR-1336 > Project: Solr > Issue Type: New Feature > Components: Analysis >Reporter: Robert Muir > Attachments: SOLR-1336.patch, SOLR-1336.patch, SOLR-1336.patch > > > SmartChineseAnalyzer was contributed to lucene, it indexes simplified chinese > text as words. > if the factories for the tokenizer and word token filter are added to solr it > can be used, although there should be a sample config or wiki entry showing > how to apply the built-in stopwords list. > this is because it doesn't contain actual stopwords, but must be used to > prevent indexing punctuation... > note: we did some refactoring/cleanup on this analyzer recently, so it would > be much easier to do this after the next lucene update. > it has also been moved out of -analyzers.jar due to size, and now builds in > its own smartcn jar file, so that would need to be added if this feature is > desired. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-788) MoreLikeThis should support distributed search
[ https://issues.apache.org/jira/browse/SOLR-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-788: --- Component/s: MoreLikeThis Fix Version/s: 1.5 > MoreLikeThis should support distributed search > -- > > Key: SOLR-788 > URL: https://issues.apache.org/jira/browse/SOLR-788 > Project: Solr > Issue Type: Improvement > Components: MoreLikeThis >Reporter: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: AlternateDistributedMLT.patch, > MoreLikeThisComponentTest.patch, SolrMoreLikeThisPatch.txt > > > The MoreLikeThis component should support distributed processing. > See SOLR-303. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1424) ant generate-maven-artifacts fails on windows
[
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-1424.
-
Resolution: Fixed
Fix Version/s: 1.4
> ant generate-maven-artifacts fails on windows
> -
>
> Key: SOLR-1424
> URL: https://issues.apache.org/jira/browse/SOLR-1424
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: SOLR-1424.patch
>
>
> From solr-user...
> {noformat}
> generate-maven-artifacts:
> [mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
> [mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
> [copy] Copying 1 file to
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
> olr_trunk\src\maven
> BUILD FAILED
> c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
> execut
> ing this line:
> c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
> c:\Downloads\solr_t
> runk\src\maven\solr-parent-pom.xml.template to
> c:\Downloads\solr_trunk\build\mav
> en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
> java.io
> .FileNotFoundException
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
> nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
> volu
> me label syntax is incorrect)
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1424) ant generate-maven-artifacts fails on windows
[
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1424:
Attachment: SOLR-1424.patch
> ant generate-maven-artifacts fails on windows
> -
>
> Key: SOLR-1424
> URL: https://issues.apache.org/jira/browse/SOLR-1424
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Ryan McKinley
> Fix For: 1.4
>
> Attachments: SOLR-1424.patch
>
>
> From solr-user...
> {noformat}
> generate-maven-artifacts:
> [mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
> [mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
> [copy] Copying 1 file to
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
> olr_trunk\src\maven
> BUILD FAILED
> c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
> execut
> ing this line:
> c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
> c:\Downloads\solr_t
> runk\src\maven\solr-parent-pom.xml.template to
> c:\Downloads\solr_trunk\build\mav
> en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
> java.io
> .FileNotFoundException
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
> nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
> volu
> me label syntax is incorrect)
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1424) ant generate-maven-artifacts fails on windows
[
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley reassigned SOLR-1424:
---
Assignee: Ryan McKinley
yup, that does it... I will commit shortly
> ant generate-maven-artifacts fails on windows
> -
>
> Key: SOLR-1424
> URL: https://issues.apache.org/jira/browse/SOLR-1424
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Ryan McKinley
>
> From solr-user...
> {noformat}
> generate-maven-artifacts:
> [mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
> [mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
> [copy] Copying 1 file to
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
> olr_trunk\src\maven
> BUILD FAILED
> c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
> execut
> ing this line:
> c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
> c:\Downloads\solr_t
> runk\src\maven\solr-parent-pom.xml.template to
> c:\Downloads\solr_trunk\build\mav
> en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
> java.io
> .FileNotFoundException
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
> nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
> volu
> me label syntax is incorrect)
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Spec Version vs Implementation Version
: What are the differences between specification version and implementation : version those are concepts from the Java specification for jars and wars (more info then you could ever possibly want in the URLs below) : I downloaded the nightly build for September 05 2009 and it has a spec : version of 1.3 and the implementation version states 1.4-dev I think you are abreviating. the spec version should be something like "1.3.0.2009.09.05.12.07.49" and the implementation version should be something like "1.4-dev 812759 - hudson - 2009-09-05 12:07:49" In a nutshell: the spec version identifies the specification, in our case the Java APIs. the Implementation version itentifies the implementation (in our case: the internals of those methods). a spec version must be purely numeric, and has rules about how to interpret when one version is newer then another. For a relase, the spec version looks like "1.3.0" or "1.3.1" or "1.4.0" but for the nightlys we include the date to denote that the API is "newer" then it was in 1.3.0. An implementation version can be any string. for releases it starts out the same as the spec version, but then includes other details about that particular build (the svn revision, who built it, and when it was build) ... for dev versions it says all the same things, but the initial verion info tells you what development branch you're looking at - so 1.4-dev means it's working towards 1.4 (as opposed to a hypothetical 1.3.1-dev that might exist if someone created a maintence branch on 1.3 in anticipation of a 1.3.1 release) http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#JAR%20Manifest http://java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/versioning2.html http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Package.html http://java.sun.com/j2se/1.5.0/docs/api/java/util/jar/package-summary.html http://java.sun.com/developer/Books/javaprogramming/JAR/basics/manifest.html : : : -- : "Good Enough" is not good enough. : To give anything less than your best is to sacrifice the gift. : Quality First. Measure Twice. Cut Once. : -Hoss
[jira] Commented: (SOLR-1424) ant generate-maven-artifacts fails on windows
[
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754450#action_12754450
]
Hoss Man commented on SOLR-1424:
Hmmm i think the way the macro uses the pom.xml argument is the problem ...
in some cases it can be an absolute path (ie: when you're on windows) so
concating with ${maven.build.dir} in the copy task is a bad idea.
we could change the copy task to use a target dir instead of a target file ...
except the artifact:pom task also needs the final filename.
Try changing the call something like this...
{noformat}
Index: build.xml
===
--- build.xml (revision 813985)
+++ build.xml (working copy)
@@ -747,7 +747,7 @@
-
+
{noformat}
...and if that works, just document the hell out of the m2-deploy macro that
the pom.xml arg must be a relative path.
> ant generate-maven-artifacts fails on windows
> -
>
> Key: SOLR-1424
> URL: https://issues.apache.org/jira/browse/SOLR-1424
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>
> From solr-user...
> {noformat}
> generate-maven-artifacts:
> [mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
> [mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
> [copy] Copying 1 file to
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
> olr_trunk\src\maven
> BUILD FAILED
> c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
> execut
> ing this line:
> c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
> c:\Downloads\solr_t
> runk\src\maven\solr-parent-pom.xml.template to
> c:\Downloads\solr_trunk\build\mav
> en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
> java.io
> .FileNotFoundException
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
> nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
> volu
> me label syntax is incorrect)
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r808988 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/request/PHPSerializedResponseWriter.java
: > if the container can't correctly output : > some characters, i see no reason to hide the bug : : Another problem is that it won't reliably break. The bug breaks our : encapsulation (before the patch) and thus the client reads the wrong : number of chars for the string, and who knows what happens after that. : The majority of the time will result in an exception, but it really : depends. This is the type of stuff (buffer underflows / overflows) : that could be used to mess with security too... a carefully crafted : request could inject / change fields in the response and have it look : valid. Isn't that an argument in favor of having an explicit option to control how we do the counting? otherwise we're still at risk of the scenerio i discribed (ie: jetty fixes the byte conversion code, but we're still counting the bytes "wrong" for them) with an explicit option we put control in the hands of the solr admin to decide what's right for them (we can even give them a little shell script to test it with) -Hoss
[jira] Commented: (SOLR-1316) Create autosuggest component
[ https://issues.apache.org/jira/browse/SOLR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754443#action_12754443 ] Jason Rutherglen commented on SOLR-1316: Basically we need an algorithm that does suffix compression as well? > Create autosuggest component > > > Key: SOLR-1316 > URL: https://issues.apache.org/jira/browse/SOLR-1316 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Priority: Minor > Fix For: 1.5 > > Original Estimate: 96h > Remaining Estimate: 96h > > Autosuggest is a common search function that can be integrated > into Solr as a SearchComponent. Our first implementation will > use the TernaryTree found in Lucene contrib. > * Enable creation of the dictionary from the index or via Solr's > RPC mechanism > * What types of parameters and settings are desirable? > * Hopefully in the future we can include user click through > rates to boost those terms/phrases higher -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1316) Create autosuggest component
[ https://issues.apache.org/jira/browse/SOLR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754440#action_12754440 ] Jason Rutherglen commented on SOLR-1316: Andrzej, There's the ternary tree which is supposed to be better? There are other algorithms for compressed dictionaries that could be used (off hand I can't think of them). > Create autosuggest component > > > Key: SOLR-1316 > URL: https://issues.apache.org/jira/browse/SOLR-1316 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Priority: Minor > Fix For: 1.5 > > Original Estimate: 96h > Remaining Estimate: 96h > > Autosuggest is a common search function that can be integrated > into Solr as a SearchComponent. Our first implementation will > use the TernaryTree found in Lucene contrib. > * Enable creation of the dictionary from the index or via Solr's > RPC mechanism > * What types of parameters and settings are desirable? > * Hopefully in the future we can include user click through > rates to boost those terms/phrases higher -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1316) Create autosuggest component
[ https://issues.apache.org/jira/browse/SOLR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754404#action_12754404 ] Andrzej Bialecki commented on SOLR-1316: - Jason, did you make any progress on this? I'm interested in this functionality.. I'm not sure tries are the best choice, unless heavily pruned they occupy a lot of RAM space. I had some moderate success using ngram based method (I reused the spellchecker, with slight modifications) - the method is fast and reuses the existing spellchecker index, but precision of lookups is not ideal. > Create autosuggest component > > > Key: SOLR-1316 > URL: https://issues.apache.org/jira/browse/SOLR-1316 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Priority: Minor > Fix For: 1.5 > > Original Estimate: 96h > Remaining Estimate: 96h > > Autosuggest is a common search function that can be integrated > into Solr as a SearchComponent. Our first implementation will > use the TernaryTree found in Lucene contrib. > * Enable creation of the dictionary from the index or via Solr's > RPC mechanism > * What types of parameters and settings are desirable? > * Hopefully in the future we can include user click through > rates to boost those terms/phrases higher -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r808988 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/request/PHPSerializedResponseWriter.java
you are correct, it was my misunderstanding of the problem - now that I've read more than I ever wanted to know about UCS-2, UTF-16 and modified UTF-8, I'm more upto speed. Thanks for the patience. On Sep 11, 2009, at 6:32 PM, Yonik Seeley wrote: On Fri, Sep 11, 2009 at 6:21 PM, Donovan Jimenez wrote: Is it possible (and would it even help) to normalize all strings with regards to surrogate pairs at indexing time instead? Already done, in a way... there's only one way to represent a character outside the BMP in UTF-16 (which is the in-memory encoding used by Java String). Unless I misunderstood what you meant by normalization. -Yonik http://www.lucidimagination.com
Re: svn commit: r808988 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/request/PHPSerializedResponseWriter.java
On Tue, Sep 8, 2009 at 7:46 PM, Chris Hostetter wrote: > if the container can't correctly output > some characters, i see no reason to hide the bug Another problem is that it won't reliably break. The bug breaks our encapsulation (before the patch) and thus the client reads the wrong number of chars for the string, and who knows what happens after that. The majority of the time will result in an exception, but it really depends. This is the type of stuff (buffer underflows / overflows) that could be used to mess with security too... a carefully crafted request could inject / change fields in the response and have it look valid. -Yonik http://www.lucidimagination.com
Re: svn commit: r808988 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/request/PHPSerializedResponseWriter.java
On Fri, Sep 11, 2009 at 6:21 PM, Donovan Jimenez wrote: > Is it possible (and would it even help) to normalize all strings with > regards to surrogate pairs at indexing time instead? Already done, in a way... there's only one way to represent a character outside the BMP in UTF-16 (which is the in-memory encoding used by Java String). Unless I misunderstood what you meant by normalization. -Yonik http://www.lucidimagination.com
[jira] Commented: (SOLR-1424) ant generate-maven-artifacts fails on windows
[
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754386#action_12754386
]
Ryan McKinley commented on SOLR-1424:
-
no dice. with:
{code}
$ svn diff
Index: common-build.xml
===
--- common-build.xml(revision 814053)
+++ common-build.xml(working copy)
@@ -104,13 +104,12 @@
-
-
+
+
+
-
-
{code}
I still get:
{code}
generate-maven-artifacts:
[copy] Copying 1 file to
c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src\maven
BUILD FAILED
c:\workspace\apache\solr\build.xml:750: The following error occurred while
executing this line:
c:\workspace\apache\solr\common-build.xml:260: Failed to copy
c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template to
c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src\maven
\solr-parent-pom.xml.template due to java.io.FileNotFoundException
c:\workspace\apache\solr\build\maven\c:\workspace\apache\solr\src\maven\solr-parent-pom.xml.template
(The filename, directory name, o
r volume label syntax is incorrect)
Total time: 4 minutes 7 seconds
{code}
looking around at some other options, but don't see anything obvious
> ant generate-maven-artifacts fails on windows
> -
>
> Key: SOLR-1424
> URL: https://issues.apache.org/jira/browse/SOLR-1424
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>
> From solr-user...
> {noformat}
> generate-maven-artifacts:
> [mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
> [mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
> [copy] Copying 1 file to
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
> olr_trunk\src\maven
> BUILD FAILED
> c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
> execut
> ing this line:
> c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
> c:\Downloads\solr_t
> runk\src\maven\solr-parent-pom.xml.template to
> c:\Downloads\solr_trunk\build\mav
> en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
> java.io
> .FileNotFoundException
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
> nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
> volu
> me label syntax is incorrect)
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r808988 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/request/PHPSerializedResponseWriter.java
Is it possible (and would it even help) to normalize all strings with regards to surrogate pairs at indexing time instead? or will container still possibly differ in byte for byte output? - Donovan On Sep 11, 2009, at 5:34 PM, Chris Hostetter wrote: : > why don't we just output the raw bytes ourselves? : : That would require writing TextResponseWriter and friends as binary : writers, right? Or did you have a different way in mind for injecting : bytes into the output stream? Grr you're right. i got so turned arround thinking about counting the bytes and encapsulating it all in the PHPS markup i forgot that we still want/need the *raw* bytes output as part of the character stream ... not some sort of string representation of the bytes ... wow that sounds even more comfusing when i look at it on paper. character data sucks. I still repeat my earlier vote: let's yank this patch and just document that byte counts for strings included in the PHPS format are only accurate for characters outside the BMP if the servlet container being used writes them correctly -- that seems like a totally fair requirement to having in place, and points the figner squarly where in belongs (without putting us at risk for having broken code if/when jetty fixes this problem. Alternately: have an option and/or system property to force/disable this behavior even if jetty.home isn't/is set. Even if we change nothing else: there needs to be a big fat freaking disclaimer in the javadocs for the writer that it's looking at the jetty.home variable, and explaining why. -Hoss
[jira] Created: (SOLR-1428) make ValueSourceParser and QParserPlugin implement SolrInfoMBean so people can use registry.jsp to see which ones are loaded
make ValueSourceParser and QParserPlugin implement SolrInfoMBean so people can use registry.jsp to see which ones are loaded Key: SOLR-1428 URL: https://issues.apache.org/jira/browse/SOLR-1428 Project: Solr Issue Type: Improvement Reporter: Hoss Man there are a lot of default QParserPlugins and ValueSourceParsers loaded by default in solr -- but there is no clear way to see which ones are loaded. if we made the abstract base classes implement SolrInfoMBean (with sane defaults for all the methods, or at the very least have them return strings like "INFO NOT AVAILABLE") then people could use the infoRegistry to see what's available -- both by default, and when they load their own. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1427) SearchComponents aren't listed on registry.jsp
SearchComponents aren't listed on registry.jsp -- Key: SOLR-1427 URL: https://issues.apache.org/jira/browse/SOLR-1427 Project: Solr Issue Type: Bug Reporter: Hoss Man Fix For: 1.4 SearchComponent implements SolrInfoMBean using getCategory() of "OTHER" but they aren't listed on the registry.jsp display of loaded plugins. This may be a one-of-glitch because of the way SearchComponents get loaded, or it may indicate some other problem with the infoRegistry. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1380) Extend StatsComponent to MultiValued Fields
[ https://issues.apache.org/jira/browse/SOLR-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-1380. --- Resolution: Fixed Committed revision 814042. > Extend StatsComponent to MultiValued Fields > --- > > Key: SOLR-1380 > URL: https://issues.apache.org/jira/browse/SOLR-1380 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 >Reporter: Harish Agarwal >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1380.patch, SOLR-1380.patch, SOLR-1380.patch, > SOLR-1380.patch, SOLR-1380.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > The StatsComponent does not work on multivalued fields. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1426) Allow delta-import to run continously until aborted
[ https://issues.apache.org/jira/browse/SOLR-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abdul Chaudhry updated SOLR-1426: - Description: Modify the delta-import so that it takes a perpetual flag that makes it run continuously until its aborted. http://localhost:8985/solr/tickets/select/?command=delta-import&clean=false&qt=/dataimport&commit=true&perpetual=true perpetual means the delta import will keep running and pause for a few seconds when running queries. The only way to stop delta import will be to explicitly issue an abort like so:- http://localhost:8985/solr/tickets/select/?command=abort was: Modify the delta-import so that it takes a perpetual flag that makes it run continuously until its aborted. http://search-master.fansnap.com:8985/solr/tickets/select/?command=delta-import&clean=false&qt=/dataimport&commit=true&perpetual=true perpetual means the delta import will keep running and pause for a few seconds when running queries. The only way to stop delta import will be to explicitly issue an abort like so:- http://search-master.fansnap.com:8985/solr/tickets/select/?command=abort > Allow delta-import to run continously until aborted > --- > > Key: SOLR-1426 > URL: https://issues.apache.org/jira/browse/SOLR-1426 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Abdul Chaudhry > Fix For: 1.4 > > Attachments: delta-import-perpetual.patch > > > Modify the delta-import so that it takes a perpetual flag that makes it run > continuously until its aborted. > http://localhost:8985/solr/tickets/select/?command=delta-import&clean=false&qt=/dataimport&commit=true&perpetual=true > perpetual means the delta import will keep running and pause for a few > seconds when running queries. > The only way to stop delta import will be to explicitly issue an abort like > so:- > http://localhost:8985/solr/tickets/select/?command=abort -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1426) Allow delta-import to run continously until aborted
[ https://issues.apache.org/jira/browse/SOLR-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abdul Chaudhry updated SOLR-1426: - Description: Modify the delta-import so that it takes a perpetual flag that makes it run continuously until its aborted. http://localhost:8985/solr/select/?command=delta-import&clean=false&qt=/dataimport&commit=true&perpetual=true perpetual means the delta import will keep running and pause for a few seconds when running queries. The only way to stop delta import will be to explicitly issue an abort like so:- http://localhost:8985/solr/tickets/select/?command=abort was: Modify the delta-import so that it takes a perpetual flag that makes it run continuously until its aborted. http://localhost:8985/solr/tickets/select/?command=delta-import&clean=false&qt=/dataimport&commit=true&perpetual=true perpetual means the delta import will keep running and pause for a few seconds when running queries. The only way to stop delta import will be to explicitly issue an abort like so:- http://localhost:8985/solr/tickets/select/?command=abort > Allow delta-import to run continously until aborted > --- > > Key: SOLR-1426 > URL: https://issues.apache.org/jira/browse/SOLR-1426 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Abdul Chaudhry > Fix For: 1.4 > > Attachments: delta-import-perpetual.patch > > > Modify the delta-import so that it takes a perpetual flag that makes it run > continuously until its aborted. > http://localhost:8985/solr/select/?command=delta-import&clean=false&qt=/dataimport&commit=true&perpetual=true > perpetual means the delta import will keep running and pause for a few > seconds when running queries. > The only way to stop delta import will be to explicitly issue an abort like > so:- > http://localhost:8985/solr/tickets/select/?command=abort -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1426) Allow delta-import to run continously until aborted
[ https://issues.apache.org/jira/browse/SOLR-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abdul Chaudhry updated SOLR-1426: - Attachment: delta-import-perpetual.patch Uploaded a patch that implements this feature. Ran all unit tests on my tree and they pass. The only thing I have hard-coded is the sleep interval which is :- Thread.sleep(3000) This should probably be configurable. > Allow delta-import to run continously until aborted > --- > > Key: SOLR-1426 > URL: https://issues.apache.org/jira/browse/SOLR-1426 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Abdul Chaudhry > Fix For: 1.4 > > Attachments: delta-import-perpetual.patch > > > Modify the delta-import so that it takes a perpetual flag that makes it run > continuously until its aborted. > http://search-master.fansnap.com:8985/solr/tickets/select/?command=delta-import&clean=false&qt=/dataimport&commit=true&perpetual=true > perpetual means the delta import will keep running and pause for a few > seconds when running queries. > The only way to stop delta import will be to explicitly issue an abort like > so:- > http://search-master.fansnap.com:8985/solr/tickets/select/?command=abort -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1426) Allow delta-import to run continously until aborted
Allow delta-import to run continously until aborted --- Key: SOLR-1426 URL: https://issues.apache.org/jira/browse/SOLR-1426 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 1.4 Reporter: Abdul Chaudhry Fix For: 1.4 Modify the delta-import so that it takes a perpetual flag that makes it run continuously until its aborted. http://search-master.fansnap.com:8985/solr/tickets/select/?command=delta-import&clean=false&qt=/dataimport&commit=true&perpetual=true perpetual means the delta import will keep running and pause for a few seconds when running queries. The only way to stop delta import will be to explicitly issue an abort like so:- http://search-master.fansnap.com:8985/solr/tickets/select/?command=abort -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r808988 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/request/PHPSerializedResponseWriter.java
: > why don't we just output the raw bytes ourselves? : : That would require writing TextResponseWriter and friends as binary : writers, right? Or did you have a different way in mind for injecting : bytes into the output stream? Grr you're right. i got so turned arround thinking about counting the bytes and encapsulating it all in the PHPS markup i forgot that we still want/need the *raw* bytes output as part of the character stream ... not some sort of string representation of the bytes ... wow that sounds even more comfusing when i look at it on paper. character data sucks. I still repeat my earlier vote: let's yank this patch and just document that byte counts for strings included in the PHPS format are only accurate for characters outside the BMP if the servlet container being used writes them correctly -- that seems like a totally fair requirement to having in place, and points the figner squarly where in belongs (without putting us at risk for having broken code if/when jetty fixes this problem. Alternately: have an option and/or system property to force/disable this behavior even if jetty.home isn't/is set. Even if we change nothing else: there needs to be a big fat freaking disclaimer in the javadocs for the writer that it's looking at the jetty.home variable, and explaining why. -Hoss
Re: svn commit: r808988 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/request/PHPSerializedResponseWriter.java
On Fri, Sep 11, 2009 at 5:06 PM, Chris Hostetter wrote: > why don't we just output the raw bytes ourselves? That would require writing TextResponseWriter and friends as binary writers, right? Or did you have a different way in mind for injecting bytes into the output stream? -Yonik http://www.lucidimagination.com
Re: svn commit: r808988 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/request/PHPSerializedResponseWriter.java
On Fri, Sep 11, 2009 at 5:06 PM, Chris Hostetter wrote: > I must be missunderstanding something still ... based on your description, > it sounds like it shouldn't matter if the encoder knows that it's one > logical character or not, either way it should wind up outputing the same > number of bytes yes, the # of bytes is different: 6 bytes versus 4 bytes in UTF-8 -- Robert Muir rcm...@gmail.com
Re: svn commit: r808988 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/request/PHPSerializedResponseWriter.java
: A code point (unicode character) outside of the BMP (basic : multilingual plane, fits in 16 bits) is represented as two java chars : - a surrogate pair. It's a single logical character - see : String.codePointAt(). In correct UTF-8 it should be encoded as a : single code point... but Jetty is ignoring the fact that it's a : surrogate pair and encoding each Java char as it's own code point... : this is often called modified-UTF8 or CESU-8. : : So... say you have this incorrect CESU-8 that is masquerading as : UTF-8: all is not lost. ... I must be missunderstanding something still ... based on your description, it sounds like it shouldn't matter if the encoder knows that it's one logical character or not, either way it should wind up outputing the same number of bytes Except that if that were the case, why would we have had this bug in the first place? clearly i'm still missunderstanding something. : Bottom line - if we correctly encapsulate whatever the servlet : container is writing, it's certainly possible for clients to use the : output correctly. I still come back to not liking that this is a hardcoded hack just for jetty ... it seems like it would be easy for a future version of jetty to change this behavior in some way that makes solr start breaking -- jetty could fix this bug and break solr's byte counting ... that doesn't seem cool why don't we just output the raw bytes ourselves? the code to generate the byte[] was/is allready there, we're just ignoring it and only using the length. -Hoss
[jira] Commented: (SOLR-756) Make DisjunctionMaxQueryParser generally useful by supporting all query types.
[
https://issues.apache.org/jira/browse/SOLR-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754337#action_12754337
]
Hoss Man commented on SOLR-756:
---
at this stage in the process for 1.4, i think most committers are focusing on
bug fixes and avoiding adding new features ... especially new features that
have been added to existing functionality, so they could trigger new bugs in
*existing* use cases.
FWIW:
* the patch doesn't seem to have any test cases demonstrating the new
functionality, which makes me leary of committing
* i'm not certain just from skimming the patch, but it seems like this should
break behavior for any existing users of DisjunctionMaxQueryParser who are
expecting the field aliases to only affect getFieldQuery ... i could be wrong
about that though.
> Make DisjunctionMaxQueryParser generally useful by supporting all query types.
> --
>
> Key: SOLR-756
> URL: https://issues.apache.org/jira/browse/SOLR-756
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: David Smiley
> Fix For: 1.5
>
> Attachments: SolrPluginUtilsDisMax.patch
>
>
> This is an enhancement to the DisjunctionMaxQueryParser to work on all the
> query variants such as wildcard, prefix, and fuzzy queries, and to support
> working in "AND" scenarios that are not processed by the min-should-match
> DisMax QParser. This was not in Solr already because DisMax was only used for
> a very limited syntax that didn't use those features. In my opinion, this
> makes a more suitable base parser for general use because unlike the
> Lucene/Solr parser, this one supports multiple default fields whereas other
> ones (say Yonik's {!prefix} one for example, can't do dismax). The notion of
> a single default field is antiquated and a technical under-the-hood detail of
> Lucene that I think Solr should shield the user from by on-the-fly using a
> DisMax when multiple fields are used.
> (patch to be attached soon)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1425) Better exception messages for classloader mishaps
Better exception messages for classloader mishaps - Key: SOLR-1425 URL: https://issues.apache.org/jira/browse/SOLR-1425 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Benson Margulies If an idiot such as myself tries to specify a filter or such that lives in a parent classloader, such as the system classloader of a servlet container, Solr will fail to load it. The JVM is prone to create an exception that mentions some Solr interface as being missing instead of the filter itself. It would be less confusing for the miscreant if Solr were to try/catch ClassNotFound and NoClassDefError and throw its own exception with the name of the thing specified in the schema included in the message. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1419) Solr won't load filters from parent class loader, and the resulting error stacktrace is very confusing
[ https://issues.apache.org/jira/browse/SOLR-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754324#action_12754324 ] Benson Margulies commented on SOLR-1419: I'll comment here and then open a feature request. Solr knows that it just called into the class loader to locate a class by name. So it could certainly include the name of what it was looking for in its exception, even if the VM chooses to describe as the source of the problem. > Solr won't load filters from parent class loader, and the resulting error > stacktrace is very confusing > -- > > Key: SOLR-1419 > URL: https://issues.apache.org/jira/browse/SOLR-1419 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 >Reporter: Benson Margulies > > I specified a token filter class in my schema, and provided that class in a > jar file in the system classpath of my jetty instance instead of in > WEB-INF/lib of my solr webapp. > This did not work. > To make matters odder, the logged error did not mention my filter, but rather > an internal solr interface: > Caused by: java.lang.ClassNotFoundException: > org.apache.solr.util.plugin.ResourceLoaderAware > at java.net.URLClassLoader$1.run(URLClassLoader.java:200) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:319) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330) > at java.lang.ClassLoader.loadClass(ClassLoader.java:254) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:399) > I note in passing that the token filter in turn uses other classes which > stayed happily behind in the outer classloader after moved the immediate > filter class into the webapp. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1419) Solr won't load filters from parent class loader, and the resulting error stacktrace is very confusing
[ https://issues.apache.org/jira/browse/SOLR-1419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754294#action_12754294 ] Hoss Man commented on SOLR-1419: bq. The error message issue struck me as JIRA-worthy even if the underlying behavior is by design. the behavior is by design -- of the VM. Solr doesn't have anything to do with it, so Solr can't really improve the message produced either. there *MAY* be some tricks Solr can do to recognize when a class load error was caused by another class load error for a class Solr already know about -- and then solr could generate an additional err message explaining the problem -- but that would certainly be a new feature, not a bug. > Solr won't load filters from parent class loader, and the resulting error > stacktrace is very confusing > -- > > Key: SOLR-1419 > URL: https://issues.apache.org/jira/browse/SOLR-1419 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 >Reporter: Benson Margulies > > I specified a token filter class in my schema, and provided that class in a > jar file in the system classpath of my jetty instance instead of in > WEB-INF/lib of my solr webapp. > This did not work. > To make matters odder, the logged error did not mention my filter, but rather > an internal solr interface: > Caused by: java.lang.ClassNotFoundException: > org.apache.solr.util.plugin.ResourceLoaderAware > at java.net.URLClassLoader$1.run(URLClassLoader.java:200) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:319) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:330) > at java.lang.ClassLoader.loadClass(ClassLoader.java:254) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:399) > I note in passing that the token filter in turn uses other classes which > stayed happily behind in the outer classloader after moved the immediate > filter class into the webapp. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1424) ant generate-maven-artifacts fails on windows
[
https://issues.apache.org/jira/browse/SOLR-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754287#action_12754287
]
Hoss Man commented on SOLR-1424:
I believe the error is just because maven directory properties are defined like
this...
{code}
{code}
...but i'm pretty sure they're suppose to be defined like this...
{code}
{code}
...so that ANt recognizes that they're paths.
but i don't have a windows box, so i can't test that that fixes the problem
> ant generate-maven-artifacts fails on windows
> -
>
> Key: SOLR-1424
> URL: https://issues.apache.org/jira/browse/SOLR-1424
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>
> From solr-user...
> {noformat}
> generate-maven-artifacts:
> [mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
> [mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
> [copy] Copying 1 file to
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
> olr_trunk\src\maven
> BUILD FAILED
> c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
> execut
> ing this line:
> c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
> c:\Downloads\solr_t
> runk\src\maven\solr-parent-pom.xml.template to
> c:\Downloads\solr_trunk\build\mav
> en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
> java.io
> .FileNotFoundException
> c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
> nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
> volu
> me label syntax is incorrect)
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1380) Extend StatsComponent to MultiValued Fields
[ https://issues.apache.org/jira/browse/SOLR-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harish Agarwal updated SOLR-1380: - Attachment: SOLR-1380.patch Fix to distributed search, null stats. > Extend StatsComponent to MultiValued Fields > --- > > Key: SOLR-1380 > URL: https://issues.apache.org/jira/browse/SOLR-1380 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 >Reporter: Harish Agarwal >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1380.patch, SOLR-1380.patch, SOLR-1380.patch, > SOLR-1380.patch, SOLR-1380.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > The StatsComponent does not work on multivalued fields. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SOLR-1380) Extend StatsComponent to MultiValued Fields
[ https://issues.apache.org/jira/browse/SOLR-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harish Agarwal reopened SOLR-1380: -- Noticed that distributed search was crashing for me in the StatsComponent. I believe this is related to the fuzziness around when the returned stats values should be null for a field. I'm submitting a small patch which fixes the bug, and always returns null for stats values for which the count is equal to zero in both distributed and non-distributed search. My rationale behind this is that when the count is equal to zero, the min/max/mean values reported are garbage and should not be relied on as valid statistics for the field. Hopefully this can still be incorporated into the trunk before the 1.4 release. > Extend StatsComponent to MultiValued Fields > --- > > Key: SOLR-1380 > URL: https://issues.apache.org/jira/browse/SOLR-1380 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 >Reporter: Harish Agarwal >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1380.patch, SOLR-1380.patch, SOLR-1380.patch, > SOLR-1380.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > The StatsComponent does not work on multivalued fields. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1424) ant generate-maven-artifacts fails on windows
ant generate-maven-artifacts fails on windows
-
Key: SOLR-1424
URL: https://issues.apache.org/jira/browse/SOLR-1424
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
>From solr-user...
{noformat}
generate-maven-artifacts:
[mkdir] Created dir: c:\Downloads\solr_trunk\build\maven
[mkdir] Created dir: c:\Downloads\solr_trunk\dist\maven
[copy] Copying 1 file to
c:\Downloads\solr_trunk\build\maven\c:\Downloads\s
olr_trunk\src\maven
BUILD FAILED
c:\Downloads\solr_trunk\build.xml:741: The following error occurred while
execut
ing this line:
c:\Downloads\solr_trunk\common-build.xml:261: Failed to copy
c:\Downloads\solr_t
runk\src\maven\solr-parent-pom.xml.template to
c:\Downloads\solr_trunk\build\mav
en\c:\Downloads\solr_trunk\src\maven\solr-parent-pom.xml.template due to
java.io
.FileNotFoundException
c:\Downloads\solr_trunk\build\maven\c:\Downloads\solr_tru
nk\src\maven\solr-parent-pom.xml.template (The filename, directory name, or
volu
me label syntax is incorrect)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1301) Solr + Hadoop
[ https://issues.apache.org/jira/browse/SOLR-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754276#action_12754276 ] jv ning commented on SOLR-1301: --- I have an updated version that uses a sequence number, to ensure uniqueness in the multiple output format case. Same concept, shorter path. > Solr + Hadoop > - > > Key: SOLR-1301 > URL: https://issues.apache.org/jira/browse/SOLR-1301 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Andrzej Bialecki > Attachments: hadoop-0.19.1-core.jar, hadoop.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, solr.zip > > > This patch contains a contrib module that provides distributed indexing > (using Hadoop) to Solr EmbeddedSolrServer. The idea behind this module is > twofold: > * provide an API that is familiar to Hadoop developers, i.e. that of > OutputFormat > * avoid unnecessary export and (de)serialization of data maintained on HDFS. > SolrOutputFormat consumes data produced by reduce tasks directly, without > storing it in intermediate files. Furthermore, by using an > EmbeddedSolrServer, the indexing task is split into as many parts as there > are reducers, and the data to be indexed is not sent over the network. > Design > -- > Key/value pairs produced by reduce tasks are passed to SolrOutputFormat, > which in turn uses SolrRecordWriter to write this data. SolrRecordWriter > instantiates an EmbeddedSolrServer, and it also instantiates an > implementation of SolrDocumentConverter, which is responsible for turning > Hadoop (key, value) into a SolrInputDocument. This data is then added to a > batch, which is periodically submitted to EmbeddedSolrServer. When reduce > task completes, and the OutputFormat is closed, SolrRecordWriter calls > commit() and optimize() on the EmbeddedSolrServer. > The API provides facilities to specify an arbitrary existing solr.home > directory, from which the conf/ and lib/ files will be taken. > This process results in the creation of as many partial Solr home directories > as there were reduce tasks. The output shards are placed in the output > directory on the default filesystem (e.g. HDFS). Such part-N directories > can be used to run N shard servers. Additionally, users can specify the > number of reduce tasks, in particular 1 reduce task, in which case the output > will consist of a single shard. > An example application is provided that processes large CSV files and uses > this API. It uses a custom CSV processing to avoid (de)serialization overhead. > This patch relies on hadoop-core-0.19.1.jar - I attached the jar to this > issue, you should put it in contrib/hadoop/lib. > Note: the development of this patch was sponsored by an anonymous contributor > and approved for release under Apache License. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1301) Solr + Hadoop
[ https://issues.apache.org/jira/browse/SOLR-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kris Jirapinyo updated SOLR-1301: - Attachment: SOLR-1301.patch Because we are using MultipleOutputFormat, we can't have the data directory be the task_id, as when the indexes were building, the directories were conflicting. This patch uses a random UUID instead as the data directory so that if there are more than one shards being created under a reducer, the directories will not conflict. > Solr + Hadoop > - > > Key: SOLR-1301 > URL: https://issues.apache.org/jira/browse/SOLR-1301 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Andrzej Bialecki > Attachments: hadoop-0.19.1-core.jar, hadoop.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, solr.zip > > > This patch contains a contrib module that provides distributed indexing > (using Hadoop) to Solr EmbeddedSolrServer. The idea behind this module is > twofold: > * provide an API that is familiar to Hadoop developers, i.e. that of > OutputFormat > * avoid unnecessary export and (de)serialization of data maintained on HDFS. > SolrOutputFormat consumes data produced by reduce tasks directly, without > storing it in intermediate files. Furthermore, by using an > EmbeddedSolrServer, the indexing task is split into as many parts as there > are reducers, and the data to be indexed is not sent over the network. > Design > -- > Key/value pairs produced by reduce tasks are passed to SolrOutputFormat, > which in turn uses SolrRecordWriter to write this data. SolrRecordWriter > instantiates an EmbeddedSolrServer, and it also instantiates an > implementation of SolrDocumentConverter, which is responsible for turning > Hadoop (key, value) into a SolrInputDocument. This data is then added to a > batch, which is periodically submitted to EmbeddedSolrServer. When reduce > task completes, and the OutputFormat is closed, SolrRecordWriter calls > commit() and optimize() on the EmbeddedSolrServer. > The API provides facilities to specify an arbitrary existing solr.home > directory, from which the conf/ and lib/ files will be taken. > This process results in the creation of as many partial Solr home directories > as there were reduce tasks. The output shards are placed in the output > directory on the default filesystem (e.g. HDFS). Such part-N directories > can be used to run N shard servers. Additionally, users can specify the > number of reduce tasks, in particular 1 reduce task, in which case the output > will consist of a single shard. > An example application is provided that processes large CSV files and uses > this API. It uses a custom CSV processing to avoid (de)serialization overhead. > This patch relies on hadoop-core-0.19.1.jar - I attached the jar to this > issue, you should put it in contrib/hadoop/lib. > Note: the development of this patch was sponsored by an anonymous contributor > and approved for release under Apache License. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1395) Integrate Katta
[ https://issues.apache.org/jira/browse/SOLR-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Rutherglen updated SOLR-1395: --- Attachment: hadoop-core-0.19.0.jar log4j-1.2.13.jar zookeeper-3.2.1.jar These are the external libraries necessary to run the test > Integrate Katta > --- > > Key: SOLR-1395 > URL: https://issues.apache.org/jira/browse/SOLR-1395 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Priority: Minor > Fix For: 1.5 > > Attachments: hadoop-core-0.19.0.jar, KATTA-SOLR.patch, > log4j-1.2.13.jar, SOLR-1395.patch, zookeeper-3.2.1.jar > > Original Estimate: 336h > Remaining Estimate: 336h > > We'll integrate Katta into Solr so that: > * Distributed search uses Hadoop RPC > * Shard/SolrCore distribution and management > * Zookeeper based failover > * Indexes may be built using Hadoop -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Spec Version vs Implementation Version
What are the differences between specification version and implementation version I downloaded the nightly build for September 05 2009 and it has a spec version of 1.3 and the implementation version states 1.4-dev What does that mean? -- "Good Enough" is not good enough. To give anything less than your best is to sacrifice the gift. Quality First. Measure Twice. Cut Once.
[jira] Commented: (SOLR-1395) Integrate Katta
[ https://issues.apache.org/jira/browse/SOLR-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754241#action_12754241 ] Jason Rutherglen commented on SOLR-1395: I added a wiki page at: http://wiki.apache.org/solr/KattaIntegration > Integrate Katta > --- > > Key: SOLR-1395 > URL: https://issues.apache.org/jira/browse/SOLR-1395 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Priority: Minor > Fix For: 1.5 > > Attachments: KATTA-SOLR.patch, SOLR-1395.patch > > Original Estimate: 336h > Remaining Estimate: 336h > > We'll integrate Katta into Solr so that: > * Distributed search uses Hadoop RPC > * Shard/SolrCore distribution and management > * Zookeeper based failover > * Indexes may be built using Hadoop -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1394) HTML stripper is splitting tokens
[ https://issues.apache.org/jira/browse/SOLR-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754215#action_12754215 ] Jason Rutherglen commented on SOLR-1394: bq. In which situation do you get this exception? We need to log the HTML. I'll post it when we implement the logging. > HTML stripper is splitting tokens > - > > Key: SOLR-1394 > URL: https://issues.apache.org/jira/browse/SOLR-1394 > Project: Solr > Issue Type: Bug > Components: Analysis >Affects Versions: 1.4 >Reporter: Anders Melchiorsen > Attachments: SOLR-1394.patch > > > I am having problems with the Solr HTML stripper. > After some investigation, I have found the cause to be that the > stripper is replacing the removed HTML with spaces. This obviously > breaks when the HTML is in the middle of a word, like "Günther". > So, without knowing what I was doing, I hacked together a fix that > uses offset correction instead. > That seemed to work, except that closing tags and attributes still > broke the positioning. With even less of a clue, I replaced read() > with next() in the two methods handling those. > Finally, invalid HTML also gave wrong offsets, and I fixed that by > restoring numRead when rolling back the input stream. > At this point I stopped trying to break it, so there may still be more > problems. Or I might have introduced some problem on my own. Anyway, I > have put the three patches at the bottom of this mail, in case > somebody wants to move along with this issue. -- 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=12754212#action_12754212 ] Oleg Gnatovskiy commented on SOLR-236: -- Hey Martijn, Have you made any progress on making field collapsing distributed? Oleg > 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-3.patch, > field-collapse-4-with-solrj.patch, field-collapse-5.patch, > field-collapse-5.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] Commented: (SOLR-1292) show lucene fieldcache entries and sizes
[ https://issues.apache.org/jira/browse/SOLR-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754188#action_12754188 ] Grant Ingersoll commented on SOLR-1292: --- Looks like a reasonable first pass, Hoss. I think we should commit and then we can iterate in 1.5. > show lucene fieldcache entries and sizes > > > Key: SOLR-1292 > URL: https://issues.apache.org/jira/browse/SOLR-1292 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley >Assignee: Mark Miller >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1292.patch > > > See LUCENE-1749, FieldCache introspection API -- 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=12754182#action_12754182
]
Paul Nelson commented on SOLR-236:
--
Thanks Martijn!
Also, while I was doing testing on collapse, I've noticed some threading issues
as well. I think they are primarily centered around the collapseRequest field.
Specifically, when I run two collapse queries at the same time, I get the
following exception:
{code}
java.lang.IllegalStateException: Invoke the collapse method before invoking
getCollapseInfo method
at
org.apache.solr.search.AbstractDocumentCollapser.getCollapseInfo(AbstractDocumentCollapser.java:183)
at
org.apache.solr.handler.component.CollapseComponent.doProcess(CollapseComponent.java:115)
at
org.apache.solr.handler.component.CollapseComponent.process(CollapseComponent.java:67)
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:1299)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:619)
{code}
And when I run a second (non-collapsing) query at the same time I run the
collapse query I get this exception:
{code}
java.lang.NullPointerException
at
org.apache.solr.handler.component.CollapseComponent.doProcess(CollapseComponent.java:109)
at
org.apache.solr.handler.component.CollapseComponent.process(CollapseComponent.java:67)
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:1299)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:619)
{code}
These errors occurred with the 2009-08-24 patch, but (upon brief inspection) it
looks like the same situation would occur with the latest patch.
If I get the chance, I'll try and debug further.
> 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,
> c
[jira] Resolved: (SOLR-1380) Extend StatsComponent to MultiValued Fields
[ https://issues.apache.org/jira/browse/SOLR-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-1380. --- Resolution: Fixed Committed revision 813874. Thanks Harish! > Extend StatsComponent to MultiValued Fields > --- > > Key: SOLR-1380 > URL: https://issues.apache.org/jira/browse/SOLR-1380 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 >Reporter: Harish Agarwal >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1380.patch, SOLR-1380.patch, SOLR-1380.patch, > SOLR-1380.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > The StatsComponent does not work on multivalued fields. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: solr 1.4 release schedule
https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230&versionId=12313351&showOpenIssuesOnly=true We are down to 14 open. On Sep 8, 2009, at 1:41 PM, Grant Ingersoll wrote: I can be RM unless someone else is dying to do it. On Sep 8, 2009, at 11:06 AM, Yonik Seeley wrote: My day-job colleagues and I are all traveling this week (company get-together) so that may slow things down a bit for some of us, and perhaps cause the goal of releasing Solr 1 week after Lucene to slip a little. Still, if there are any issues that are assigned to you, and that you can't get to this week (including the weekend) please un-assign yourself as a signal that someone else should try and take it up. [moving release discussion to solr-dev] OK... how about going into code freeze by the end of the week? Again, if you have an issue that you won't get to, please un-assign yourself. -Yonik http://www.lucidimagination.com
[jira] Commented: (SOLR-1404) Random failures with highlighting
[ https://issues.apache.org/jira/browse/SOLR-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754162#action_12754162 ] Uwe Schindler commented on SOLR-1404: - bq. Will LUCENE-1906 fix it (in an alternate way)? It should fix it. Lucene Tokenizer now do not have separate methods for CharStream anymore. They are simply handled as Readers. The trap of overwriting the wrong method should be fixed now. The offset correction is now done conditionally if the Reader is a CharStream subclass. > Random failures with highlighting > - > > Key: SOLR-1404 > URL: https://issues.apache.org/jira/browse/SOLR-1404 > Project: Solr > Issue Type: Bug > Components: Analysis, highlighter >Affects Versions: 1.4 >Reporter: Anders Melchiorsen > Fix For: 1.4 > > Attachments: SOLR-1404.patch > > > With a recent Solr nightly, we started getting errors when highlighting. > I have not been able to reduce our real setup to a minimal one that is > failing, but the same error seems to pop up with the configuration below. > Note that the QUERY will mostly fail, but it will work sometimes. Notably, > after running "java -jar start.jar", the QUERY will work the first time, but > then start failing for a while. Seems that something is not being reset > properly. > The example uses the deprecated HTMLStripWhitespaceTokenizerFactory but the > problem apparently also exists with other tokenizers; I was just unable to > create a minimal example with other configurations. > SCHEMA > > > > > > > > > > > > > > > id > > INDEX > URL=http://localhost:8983/solr/update > curl $URL --data-binary '1 name="test">test' -H 'Content-type:text/xml; > charset=utf-8' > curl $URL --data-binary '' -H 'Content-type:text/xml; charset=utf-8' > QUERY > curl 'http://localhost:8983/solr/select/?hl.fl=test&hl=true&q=id:1' > ERROR > org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token test > exceeds length of provided text sized 4 > org.apache.solr.common.SolrException: > org.apache.lucene.search.highlight.InvalidTokenOffsetsException: Token test > exceeds length of provided text sized 4 > at > org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:328) > at > org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:89) > 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:1299) > 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.headerComplete(HttpConnection.java:821) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > 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) > Caused by: org.apache.lucene.search.highlight.InvalidTokenOffsetsException: > Token test exceeds length of provided text sized 4 > at > org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:254) > at > org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:321) > ... 23 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the i
[jira] Resolved: (SOLR-1411) SolrJ ContentStream Update Request
[ https://issues.apache.org/jira/browse/SOLR-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-1411. --- Resolution: Fixed Committed revision 813860. > SolrJ ContentStream Update Request > -- > > Key: SOLR-1411 > URL: https://issues.apache.org/jira/browse/SOLR-1411 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1411-build.xml, SOLR-1411.patch, SOLR-1411.patch, > SOLR-1411.patch > > > Create a SolrRequest for SolrJ that can add content streams to Solr for > indexing. > Patch shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr nightly build failure
thanks, this patch fixes the build issue On Fri, Sep 11, 2009 at 10:14 AM, Grant Ingersoll wrote: > Please try https://issues.apache.org/jira/browse/SOLR-1411 > SOLR-1411-build.patch -- Robert Muir rcm...@gmail.com
[jira] Updated: (SOLR-1423) Lucene 2.9 RC4 may need some changes in Solr Analyzers using CharStream & others
[ https://issues.apache.org/jira/browse/SOLR-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-1423: - Affects Version/s: 1.4 Fix Version/s: 1.4 Assignee: Koji Sekiguchi I'd like to check it before 1.4 release. I'll look into it once RC4 is checked in Solr. > Lucene 2.9 RC4 may need some changes in Solr Analyzers using CharStream & > others > > > Key: SOLR-1423 > URL: https://issues.apache.org/jira/browse/SOLR-1423 > Project: Solr > Issue Type: Task > Components: Analysis >Affects Versions: 1.4 >Reporter: Uwe Schindler >Assignee: Koji Sekiguchi > Fix For: 1.4 > > > Because of some backwards compatibility problems (LUCENE-1906) we changed the > CharStream/CharFilter API a little bit. Tokenizer now only has a input field > of type java.io.Reader (as before the CharStream code). To correct offsets, > it is now needed to call the Tokenizer.correctOffset(int) method, which > delegates to the CharStream (if input is subclass of CharStream), else > returns an uncorrected offset. Normally it is enough to change all occurences > of input.correctOffset() to this.correctOffset() in Tokenizers. It should > also be checked, if custom Tokenizers in Solr do correct their offsets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1203) We should add an example of setting the update.processor for a given RequestHandler
[ https://issues.apache.org/jira/browse/SOLR-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-1203. --- Resolution: Fixed thanks for the review - committed r813854 > We should add an example of setting the update.processor for a given > RequestHandler > --- > > Key: SOLR-1203 > URL: https://issues.apache.org/jira/browse/SOLR-1203 > Project: Solr > Issue Type: Improvement >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1203.patch > > > a commented out example that points to the commented out example update chain > or just as good: a comment above the current update chain example explaining > how to attach it to a handler. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr nightly build failure
Please try https://issues.apache.org/jira/browse/SOLR-1411 SOLR-1411- build.patch On Sep 11, 2009, at 9:34 AM, Grant Ingersoll wrote: On Sep 11, 2009, at 9:23 AM, Grant Ingersoll wrote: I bet it is due to ant example not being run first. I confirm that's the issue. Argh. Don't really want to make people run example first (because it is slow) but if the example is going to include /update/extract, then we need to make sure the libs are there. I suppose we could run just the Solr Cell example target.
[jira] Reopened: (SOLR-1411) SolrJ ContentStream Update Request
[ https://issues.apache.org/jira/browse/SOLR-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll reopened SOLR-1411: --- > SolrJ ContentStream Update Request > -- > > Key: SOLR-1411 > URL: https://issues.apache.org/jira/browse/SOLR-1411 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1411-build.xml, SOLR-1411.patch, SOLR-1411.patch, > SOLR-1411.patch > > > Create a SolrRequest for SolrJ that can add content streams to Solr for > indexing. > Patch shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1411) SolrJ ContentStream Update Request
[ https://issues.apache.org/jira/browse/SOLR-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-1411: -- Attachment: SOLR-1411-build.xml Fixes the build issue > SolrJ ContentStream Update Request > -- > > Key: SOLR-1411 > URL: https://issues.apache.org/jira/browse/SOLR-1411 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1411-build.xml, SOLR-1411.patch, SOLR-1411.patch, > SOLR-1411.patch > > > Create a SolrRequest for SolrJ that can add content streams to Solr for > indexing. > Patch shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1321) Support for efficient leading wildcards search
[ https://issues.apache.org/jira/browse/SOLR-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-1321. --- Resolution: Fixed Committed revision 813830. > Support for efficient leading wildcards search > -- > > Key: SOLR-1321 > URL: https://issues.apache.org/jira/browse/SOLR-1321 > Project: Solr > Issue Type: Improvement > Components: Analysis >Affects Versions: 1.4 >Reporter: Andrzej Bialecki >Assignee: Grant Ingersoll > Fix For: 1.4 > > Attachments: SOLR-1321.patch, SOLR-1321.patch, SOLR-1321.patch, > wildcards-2.patch, wildcards-3.patch, wildcards.patch > > > This patch is an implementation of the "reversed tokens" strategy for > efficient leading wildcards queries. > ReversedWildcardsTokenFilter reverses tokens and returns both the original > token (optional) and the reversed token (with positionIncrement == 0). > Reversed tokens are prepended with a marker character to avoid collisions > between legitimate tokens and the reversed tokens - e.g. "DNA" would become > "and", thus colliding with the regular term "and", but with the marker > character it becomes "\u0001and". > This TokenFilter can be added to the analyzer chain that it used during > indexing. > SolrQueryParser has been modified to detect the presence of such fields in > the current schema, and treat them in a special way. First, SolrQueryParser > examines the schema and collects a map of fields where these reversed tokens > are indexed. If there is at least one such field, it also sets > QueryParser.setAllowLeadingWildcards(true). When building a wildcard query > (in getWildcardQuery) the term text may be optionally reversed to put > wildcards further along the term text. This happens when the field uses the > reversing filter during indexing (as detected above), AND if the wildcard > characters are either at 0-th or 1-st position in the term. Otherwise the > term text is processed as before, i.e. turned into a regular wildcard query. > Unit tests are provided to test the TokenFilter and the query parsing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1321) Support for efficient leading wildcards search
[ https://issues.apache.org/jira/browse/SOLR-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754124#action_12754124 ] Grant Ingersoll commented on SOLR-1321: --- Only annoying thing about this solution is now that * check gets done twice, once in the SolrQueryParser method and once in the QueryParser method. Also, why not just && the two clauses (I realize it is a cut and paste from the parent). I'll fix and commit. > Support for efficient leading wildcards search > -- > > Key: SOLR-1321 > URL: https://issues.apache.org/jira/browse/SOLR-1321 > Project: Solr > Issue Type: Improvement > Components: Analysis >Affects Versions: 1.4 >Reporter: Andrzej Bialecki >Assignee: Grant Ingersoll > Fix For: 1.4 > > Attachments: SOLR-1321.patch, SOLR-1321.patch, SOLR-1321.patch, > wildcards-2.patch, wildcards-3.patch, wildcards.patch > > > This patch is an implementation of the "reversed tokens" strategy for > efficient leading wildcards queries. > ReversedWildcardsTokenFilter reverses tokens and returns both the original > token (optional) and the reversed token (with positionIncrement == 0). > Reversed tokens are prepended with a marker character to avoid collisions > between legitimate tokens and the reversed tokens - e.g. "DNA" would become > "and", thus colliding with the regular term "and", but with the marker > character it becomes "\u0001and". > This TokenFilter can be added to the analyzer chain that it used during > indexing. > SolrQueryParser has been modified to detect the presence of such fields in > the current schema, and treat them in a special way. First, SolrQueryParser > examines the schema and collects a map of fields where these reversed tokens > are indexed. If there is at least one such field, it also sets > QueryParser.setAllowLeadingWildcards(true). When building a wildcard query > (in getWildcardQuery) the term text may be optionally reversed to put > wildcards further along the term text. This happens when the field uses the > reversing filter during indexing (as detected above), AND if the wildcard > characters are either at 0-th or 1-st position in the term. Otherwise the > term text is processed as before, i.e. turned into a regular wildcard query. > Unit tests are provided to test the TokenFilter and the query parsing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr nightly build failure
On Sep 11, 2009, at 9:23 AM, Grant Ingersoll wrote: I bet it is due to ant example not being run first. I confirm that's the issue. Argh. Don't really want to make people run example first (because it is slow) but if the example is going to include /update/extract, then we need to make sure the libs are there. I suppose we could run just the Solr Cell example target.
Re: Solr nightly build failure
I bet it is due to ant example not being run first. On Sep 11, 2009, at 9:02 AM, Robert Muir wrote: i see this with a clean checkout and ant test On Fri, Sep 11, 2009 at 8:37 AM, Grant Ingersoll wrote: Hmm, ant clean test passes for me. On Sep 11, 2009, at 8:25 AM, Grant Ingersoll wrote: Hmm, this looks like my commit. I'll check into it. Anyone else seeing failures? On Sep 11, 2009, at 4:38 AM, solr-dev@lucene.apache.org wrote: 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 86 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 374 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 168 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: 20, Failures: 0, Errors: 0, Time elapsed: 43.509 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 24.636 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 21.207 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 6.797 sec [junit] Running org.apache.solr.MinimalSchemaTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 10.042 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 7.022 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.666 sec [junit] Running org.apache.solr.SolrInfoMBeanTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.302 sec [junit] Running org.apache.solr.TestDistributedSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 97.45 sec [junit] Running org.apache.solr.TestPluginEnable [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.54 sec [junit] Running org.apache.solr.TestSolrCoreProperties [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.094 sec [junit] Running org.apache.solr.TestTrie [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 14.825 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.829 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 1.181 sec [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.589 sec [junit] Running org.apache.solr.analysis.HTMLStripCharFilterTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.68 sec [junit] Running org.apache.solr.analysis.LengthFilterTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.704 sec [junit] Running org.apache.solr.analysis.SnowballPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.717 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 6.264 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.031 sec [junit] Running org.apache.solr.analysis.TestDelimitedPayloadTokenFilterFactory [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 11.213 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.398 sec [junit] Running org.apache.solr.analysis.TestKeepFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.732 sec [junit] Running org.apache.solr.analysis.T
[jira] Commented: (SOLR-1143) Return partial results when a connection to a shard is refused
[ https://issues.apache.org/jira/browse/SOLR-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754118#action_12754118 ] Martijn van Groningen commented on SOLR-1143: - Sure, that is a good idea. I think that also other types of exceptions should result in a partial result (currently just a connection timeout will result in a partial result). I think that this behaviour should be enabled with a parameter in the request. Something like _shards.requestTimeout=1500_ (time is in ms). > Return partial results when a connection to a shard is refused > -- > > Key: SOLR-1143 > URL: https://issues.apache.org/jira/browse/SOLR-1143 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Nicolas Dessaigne >Assignee: Grant Ingersoll > Fix For: 1.5 > > Attachments: SOLR-1143-2.patch, SOLR-1143-3.patch, SOLR-1143.patch > > > If any shard is down in a distributed search, a ConnectException it thrown. > Here's a little patch that change this behaviour: if we can't connect to a > shard (ConnectException), we get partial results from the active shards. As > for TimeOut parameter (https://issues.apache.org/jira/browse/SOLR-502), we > set the parameter "partialResults" at true. > This patch also adresses a problem expressed in the mailing list about a year > ago > (http://www.nabble.com/partialResults,-distributed-search---SOLR-502-td19002610.html) > We have a use case that needs this behaviour and we would like to know your > thougths about such a behaviour? Should it be the default behaviour for > distributed search? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr nightly build failure
i see this with a clean checkout and ant test On Fri, Sep 11, 2009 at 8:37 AM, Grant Ingersoll wrote: > Hmm, ant clean test passes for me. > > > On Sep 11, 2009, at 8:25 AM, Grant Ingersoll wrote: > >> Hmm, this looks like my commit. I'll check into it. Anyone else seeing >> failures? >> >> On Sep 11, 2009, at 4:38 AM, solr-dev@lucene.apache.org wrote: >> >>> >>> 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 86 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 374 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 168 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: 20, Failures: 0, Errors: 0, Time elapsed: 43.509 sec >>> [junit] Running org.apache.solr.ConvertedLegacyTest >>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 24.636 sec >>> [junit] Running org.apache.solr.DisMaxRequestHandlerTest >>> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 21.207 sec >>> [junit] Running org.apache.solr.EchoParamsTest >>> [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 6.797 sec >>> [junit] Running org.apache.solr.MinimalSchemaTest >>> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 10.042 sec >>> [junit] Running org.apache.solr.OutputWriterTest >>> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 7.022 sec >>> [junit] Running org.apache.solr.SampleTest >>> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.666 sec >>> [junit] Running org.apache.solr.SolrInfoMBeanTest >>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.302 sec >>> [junit] Running org.apache.solr.TestDistributedSearch >>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 97.45 sec >>> [junit] Running org.apache.solr.TestPluginEnable >>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.54 sec >>> [junit] Running org.apache.solr.TestSolrCoreProperties >>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.094 sec >>> [junit] Running org.apache.solr.TestTrie >>> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 14.825 sec >>> [junit] Running >>> org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest >>> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.829 sec >>> [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest >>> [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 1.181 sec >>> [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest >>> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.589 sec >>> [junit] Running org.apache.solr.analysis.HTMLStripCharFilterTest >>> [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.68 sec >>> [junit] Running org.apache.solr.analysis.LengthFilterTest >>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.704 sec >>> [junit] Running org.apache.solr.analysis.SnowballPorterFilterFactoryTest >>> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.717 sec >>> [junit] Running org.apache.solr.analysis.TestBufferedTokenStream >>> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 6.264 sec >>> [junit] Running org.apache.solr.analysis.TestCapitalizationFilter >>> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.031 sec >>> [junit] Running >>> org.apache.solr.analysis.TestDelimitedPayloadTokenFilterFactory >>> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 11.213 sec >>> [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter >>> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.398 sec >>> [junit] Running org.
Re: Solr nightly build failure
Hmm, ant clean test passes for me. On Sep 11, 2009, at 8:25 AM, Grant Ingersoll wrote: Hmm, this looks like my commit. I'll check into it. Anyone else seeing failures? On Sep 11, 2009, at 4:38 AM, solr-dev@lucene.apache.org wrote: 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 86 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 374 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 168 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: 20, Failures: 0, Errors: 0, Time elapsed: 43.509 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 24.636 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 21.207 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 6.797 sec [junit] Running org.apache.solr.MinimalSchemaTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 10.042 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 7.022 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.666 sec [junit] Running org.apache.solr.SolrInfoMBeanTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.302 sec [junit] Running org.apache.solr.TestDistributedSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 97.45 sec [junit] Running org.apache.solr.TestPluginEnable [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.54 sec [junit] Running org.apache.solr.TestSolrCoreProperties [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.094 sec [junit] Running org.apache.solr.TestTrie [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 14.825 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.829 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 1.181 sec [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.589 sec [junit] Running org.apache.solr.analysis.HTMLStripCharFilterTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.68 sec [junit] Running org.apache.solr.analysis.LengthFilterTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.704 sec [junit] Running org.apache.solr.analysis.SnowballPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.717 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 6.264 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.031 sec [junit] Running org.apache.solr.analysis.TestDelimitedPayloadTokenFilterFactory [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 11.213 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.398 sec [junit] Running org.apache.solr.analysis.TestKeepFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.732 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 8.458 sec [junit] Running org.apache.solr.ana
Re: Solr nightly build failure
i'm seeing this one too On Fri, Sep 11, 2009 at 8:25 AM, Grant Ingersoll wrote: > Hmm, this looks like my commit. I'll check into it. Anyone else seeing > failures? > > On Sep 11, 2009, at 4:38 AM, solr-dev@lucene.apache.org wrote: > >> >> 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 86 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 374 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 168 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: 20, Failures: 0, Errors: 0, Time elapsed: 43.509 sec >> [junit] Running org.apache.solr.ConvertedLegacyTest >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 24.636 sec >> [junit] Running org.apache.solr.DisMaxRequestHandlerTest >> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 21.207 sec >> [junit] Running org.apache.solr.EchoParamsTest >> [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 6.797 sec >> [junit] Running org.apache.solr.MinimalSchemaTest >> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 10.042 sec >> [junit] Running org.apache.solr.OutputWriterTest >> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 7.022 sec >> [junit] Running org.apache.solr.SampleTest >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.666 sec >> [junit] Running org.apache.solr.SolrInfoMBeanTest >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.302 sec >> [junit] Running org.apache.solr.TestDistributedSearch >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 97.45 sec >> [junit] Running org.apache.solr.TestPluginEnable >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.54 sec >> [junit] Running org.apache.solr.TestSolrCoreProperties >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.094 sec >> [junit] Running org.apache.solr.TestTrie >> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 14.825 sec >> [junit] Running >> org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.829 sec >> [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest >> [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 1.181 sec >> [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.589 sec >> [junit] Running org.apache.solr.analysis.HTMLStripCharFilterTest >> [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.68 sec >> [junit] Running org.apache.solr.analysis.LengthFilterTest >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.704 sec >> [junit] Running org.apache.solr.analysis.SnowballPorterFilterFactoryTest >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.717 sec >> [junit] Running org.apache.solr.analysis.TestBufferedTokenStream >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 6.264 sec >> [junit] Running org.apache.solr.analysis.TestCapitalizationFilter >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.031 sec >> [junit] Running >> org.apache.solr.analysis.TestDelimitedPayloadTokenFilterFactory >> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 11.213 sec >> [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.398 sec >> [junit] Running org.apache.solr.analysis.TestKeepFilterFactory >> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.732 sec >> [junit] Running
Re: Solr nightly build failure
Hmm, this looks like my commit. I'll check into it. Anyone else seeing failures? On Sep 11, 2009, at 4:38 AM, solr-dev@lucene.apache.org wrote: 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 86 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 374 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 168 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: 20, Failures: 0, Errors: 0, Time elapsed: 43.509 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 24.636 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 21.207 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 6.797 sec [junit] Running org.apache.solr.MinimalSchemaTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 10.042 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 7.022 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.666 sec [junit] Running org.apache.solr.SolrInfoMBeanTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.302 sec [junit] Running org.apache.solr.TestDistributedSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 97.45 sec [junit] Running org.apache.solr.TestPluginEnable [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.54 sec [junit] Running org.apache.solr.TestSolrCoreProperties [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.094 sec [junit] Running org.apache.solr.TestTrie [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 14.825 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.829 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 1.181 sec [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.589 sec [junit] Running org.apache.solr.analysis.HTMLStripCharFilterTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.68 sec [junit] Running org.apache.solr.analysis.LengthFilterTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.704 sec [junit] Running org.apache.solr.analysis.SnowballPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.717 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 6.264 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.031 sec [junit] Running org.apache.solr.analysis.TestDelimitedPayloadTokenFilterFactory [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 11.213 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.398 sec [junit] Running org.apache.solr.analysis.TestKeepFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.732 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 8.458 sec [junit] Running org.apache.solr.analysis.TestMappingChar
[jira] Created: (SOLR-1423) Lucene 2.9 RC4 may need some changes in Solr Analyzers using CharStream & others
Lucene 2.9 RC4 may need some changes in Solr Analyzers using CharStream & others Key: SOLR-1423 URL: https://issues.apache.org/jira/browse/SOLR-1423 Project: Solr Issue Type: Task Components: Analysis Reporter: Uwe Schindler Because of some backwards compatibility problems (LUCENE-1906) we changed the CharStream/CharFilter API a little bit. Tokenizer now only has a input field of type java.io.Reader (as before the CharStream code). To correct offsets, it is now needed to call the Tokenizer.correctOffset(int) method, which delegates to the CharStream (if input is subclass of CharStream), else returns an uncorrected offset. Normally it is enough to change all occurences of input.correctOffset() to this.correctOffset() in Tokenizers. It should also be checked, if custom Tokenizers in Solr do correct their offsets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1422) Add one QParser to Query Chinese Sentences
Add one QParser to Query Chinese Sentences
--
Key: SOLR-1422
URL: https://issues.apache.org/jira/browse/SOLR-1422
Project: Solr
Issue Type: Improvement
Components: search
Environment: windows xp/ jdk1.6 / tomcat6
Reporter: tom liu
DisMaxQParser do not correctly analysis chinese sentence. So, i implement one
QParser derived from DisMax.
Limis:
in schema.xml, set defaultSearchField to chineseFieldType-Field
Result:
if you input C1C2C3C4, then:
in DisMaxQParser, we will find that qstr is "C1C2 C3C4"
1. SentenceDisMaxQParser Class::
package org.apache.solr.search;
import org.apache.lucene.queryParser.ParseException;
import org.apache.lucene.search.BooleanClause;
import org.apache.lucene.search.BooleanQuery;
import org.apache.lucene.search.Query;
import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.analysis.TokenStream;
import org.apache.lucene.analysis.Token;
import java.io.StringReader;
import org.apache.solr.common.SolrException;
import org.apache.solr.common.params.DefaultSolrParams;
import org.apache.solr.common.params.DisMaxParams;
import org.apache.solr.common.params.SolrParams;
import org.apache.solr.common.util.NamedList;
import org.apache.solr.request.SolrQueryRequest;
import org.apache.solr.util.SolrPluginUtils;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class SentenceDisMaxQParser extends DisMaxQParser {
private static Logger log =
LoggerFactory.getLogger(SentenceDisMaxQParser.class);
public SentenceDisMaxQParser(String qstr, SolrParams localParams, SolrParams
params, SolrQueryRequest req) {
super(qstr, localParams, params, req);
Analyzer analyzer = req.getSchema().getQueryAnalyzer();
if(null == analyzer)
return;
StringBuilder norm = new StringBuilder();
log.info("before analyzer, qstr="+this.qstr);
try{
TokenStream tokens = analyzer.reusableTokenStream(
req.getSchema().getDefaultSearchFieldName(), new StringReader( this.qstr ) );
tokens.reset();
Token token = tokens.next();
while( token != null ) {
norm.append( new String(token.termBuffer(), 0,
token.termLength()) ).append(" ");
token = tokens.next();
}
} catch(Exception ex){
log.info("Ex="+ex);
}
if(norm.length() > 0)
this.qstr = norm.toString();
log.info("after analyzer, qstr="+this.qstr);
}
}
2. SentenceDisMaxQParserPlugin Class::
package org.apache.solr.search;
import org.apache.solr.common.params.SolrParams;
import org.apache.solr.common.util.NamedList;
import org.apache.solr.request.SolrQueryRequest;
public class SentenceDisMaxQParserPlugin extends QParserPlugin {
public static String NAME = "sdismax";
public void init(NamedList args) {
}
public QParser createParser(String qstr, SolrParams localParams, SolrParams
params, SolrQueryRequest req) {
return new SentenceDisMaxQParser(qstr, localParams, params, req);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Build failed in Hudson: Solr-trunk #921
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/921/changes Changes: [noble] SOLR-1421 FieldreaderDataSource uses a stale Variableresolver [gsingers] SOLR-1381: Handle when term vecs are present, but not offsets [gsingers] SOLR-868: removed sample.sgm [gsingers] SOLR-1411: Add support for uploading ContentStreams via SolrJ [noble] SOLR-1420 FieldreaderDataSource should throw an Exception if field has no data -- [...truncated 2245 lines...] [junit] Running org.apache.solr.analysis.TestSynonymMap [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 3.169 sec [junit] Running org.apache.solr.analysis.TestTrimFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.672 sec [junit] Running org.apache.solr.analysis.TestWordDelimiterFilter [junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 37.098 sec [junit] Running org.apache.solr.client.solrj.SolrExceptionTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.274 sec [junit] Running org.apache.solr.client.solrj.SolrQueryTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.532 sec [junit] Running org.apache.solr.client.solrj.TestBatchUpdate [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 21.634 sec [junit] Running org.apache.solr.client.solrj.TestLBHttpSolrServer [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 18.754 sec [junit] Running org.apache.solr.client.solrj.beans.TestDocumentObjectBinder [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.935 sec [junit] Running org.apache.solr.client.solrj.embedded.JettyWebappTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 14.625 sec [junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 13.22 sec [junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeEmbeddedTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.33 sec [junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 11.635 sec [junit] Running org.apache.solr.client.solrj.embedded.MergeIndexesEmbeddedTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.514 sec [junit] Running org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.35 sec [junit] Running org.apache.solr.client.solrj.embedded.MultiCoreExampleJettyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.54 sec [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest [junit] Tests run: 9, Failures: 0, Errors: 1, Time elapsed: 21.947 sec [junit] Test org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest FAILED [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleJettyTest [junit] [junit] lazy_loading_error__orgapachesolrcommonSolrException_lazy_loading_error__at_orgapachesolrcoreRequestHandlers$LazyRequestHandlerWrappergetWrappedHandlerRequestHandlersjava243__at_orgapachesolrcoreRequestHandlers$LazyRequestHandlerWrapperhandleRequestRequestHandlersjava225__at_orgapachesolrcoreSolrCoreexecuteSolrCorejava1301__at_orgapachesolrservletSolrDispatchFilterexecuteSolrDispatchFilterjava338__at_orgapachesolrservletSolrDispatchFilterdoFilterSolrDispatchFilterjava241__at_orgmortbayjettyservletServletHandler$CachedChaindoFilterServletHandlerjava1089__at_orgmortbayjettyservletServletHandlerhandleServletHandlerjava365__at_orgmortbayjettyservletSessionHandlerhandleSessionHandlerjava181__at_orgmortbayjettyhandlerContextHandlerhandleContextHandlerjava712__at_orgmortbayjettyhandlerHandlerWrapperhandleHandlerWrapperjava139__at_orgmortbayjettyServerhandleServerjava285__at_orgmortbayjettyHttpConnectionhandleRequestHttpConnectionjava502__at_orgmortbayjettyHttpConnection$RequestHandlercontentHttpConnectionjava835__at_orgmortbayjettyHttpParserparseNextHttpParserjava641__at_orgmortbayjettyHttpParserparseAvailableHttpParserjava202__at_orgmortbayjettyHttpConnectionhandleHttpConnectionjava378__at_orgmortbayjettybioSocketConnector$ConnectionrunSocketConnectorjava226__at_orgmortbaythreadBoundedThreadPool$PoolThreadrunBoundedThreadPooljava442_Caused_by_orgapachesolrcommonSolrException_Error_loading_class_orgapachesolrhandlerextractionExtractingRequestHandler__at_orgapachesolrcoreSolrResourceLoaderfindClassSolrResourceLoaderjava310__at_orgapachesolrcoreSolrCorecreateInstanceSolrCorejava411__at_orgapachesolrcoreSolrCorecreateRequestHandlerSolrCorejava436__at_orgapachesolrcoreRequestHandlers$LazyRequestHandlerWrappergetWrappedHandlerRequestHandlersjava234___17_more_Caused_by_javalangClassNotFoundException_orgapachesol [junit] [junit] request: http://localhost:38026/example/update/extract?literal.id=mailing
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 86 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 374 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 168 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: 20, Failures: 0, Errors: 0, Time elapsed: 43.509 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 24.636 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 21.207 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 6.797 sec [junit] Running org.apache.solr.MinimalSchemaTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 10.042 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 7.022 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.666 sec [junit] Running org.apache.solr.SolrInfoMBeanTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.302 sec [junit] Running org.apache.solr.TestDistributedSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 97.45 sec [junit] Running org.apache.solr.TestPluginEnable [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.54 sec [junit] Running org.apache.solr.TestSolrCoreProperties [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.094 sec [junit] Running org.apache.solr.TestTrie [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 14.825 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.829 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 1.181 sec [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.589 sec [junit] Running org.apache.solr.analysis.HTMLStripCharFilterTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.68 sec [junit] Running org.apache.solr.analysis.LengthFilterTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.704 sec [junit] Running org.apache.solr.analysis.SnowballPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 5.717 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 6.264 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 3.031 sec [junit] Running org.apache.solr.analysis.TestDelimitedPayloadTokenFilterFactory [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 11.213 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.398 sec [junit] Running org.apache.solr.analysis.TestKeepFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.732 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 8.458 sec [junit] Running org.apache.solr.analysis.TestMappingCharFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.764 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [juni
[jira] Commented: (SOLR-1394) HTML stripper is splitting tokens
[ https://issues.apache.org/jira/browse/SOLR-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754032#action_12754032 ] Anders Melchiorsen commented on SOLR-1394: -- In which situation do you get this exception? > HTML stripper is splitting tokens > - > > Key: SOLR-1394 > URL: https://issues.apache.org/jira/browse/SOLR-1394 > Project: Solr > Issue Type: Bug > Components: Analysis >Affects Versions: 1.4 >Reporter: Anders Melchiorsen > Attachments: SOLR-1394.patch > > > I am having problems with the Solr HTML stripper. > After some investigation, I have found the cause to be that the > stripper is replacing the removed HTML with spaces. This obviously > breaks when the HTML is in the middle of a word, like "Günther". > So, without knowing what I was doing, I hacked together a fix that > uses offset correction instead. > That seemed to work, except that closing tags and attributes still > broke the positioning. With even less of a clue, I replaced read() > with next() in the two methods handling those. > Finally, invalid HTML also gave wrong offsets, and I fixed that by > restoring numRead when rolling back the input stream. > At this point I stopped trying to break it, so there may still be more > problems. Or I might have introduced some problem on my own. Anyway, I > have put the three patches at the bottom of this mail, in case > somebody wants to move along with this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
