[jira] Commented: (SOLR-1131) Allow a single field to index multiple fields
[ https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703545#action_12703545 ] Erik Hatcher commented on SOLR-1131: Perhaps this is a case where the TeeTokenFilter and friends can come into play in Solr finally? Allow a single field to index multiple fields - Key: SOLR-1131 URL: https://issues.apache.org/jira/browse/SOLR-1131 Project: Solr Issue Type: New Feature Components: Analysis Reporter: Ryan McKinley Attachments: SOLR-1131-IndexMultipleFields.patch In a few special cases, it makes sense for a single field (the concept) to be indexed as a set of Fields (lucene Field). Consider SOLR-773. The concept point may be best indexed in a variety of ways: * geohash (sincle lucene field) * lat field, lon field (two double fields) * cartesian tiers (a series of fields with tokens to say if it exists within that region) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1094) spellcheck component, correctlySpelled is bogus!
[
https://issues.apache.org/jira/browse/SOLR-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-1094.
-
Resolution: Fixed
Assignee: Shalin Shekhar Mangar
Committed revision 769310.
Thanks David and Mark!
spellcheck component, correctlySpelled is bogus!
Key: SOLR-1094
URL: https://issues.apache.org/jira/browse/SOLR-1094
Project: Solr
Issue Type: Bug
Affects Versions: 1.3
Reporter: David Smiley
Assignee: Shalin Shekhar Mangar
Fix For: 1.4
Attachments: SOLR-1094.patch
I've found that {{correctlySpelled}} is sometimes hidden and it is sometimes
shown, and when it is shown it may indicate true when it should clearly be
false. As such I've discounted it altogether. I should be fixed or removed.
Here's a search query I ran against my index and I swear I don't have a
termh zzzwwwzz :-)
{code}
lst name=responseHeader
int name=status0/int
int name=QTime58/int
lst name=params
str name=spellchecktrue/str
str name=rows0/str
str name=indenton/str
str name=echoParamsexplicit/str
str name=spellcheck.collatetrue/str
str name=spellcheck.extendedResultstrue/str
str name=qzzzwwwzz/str
str name=spellcheck.count3/str
str name=version2.2/str
/lst
/lst
result name=response numFound=0 start=0/
lst name=spellcheck
lst name=suggestions
bool name=correctlySpelledtrue/bool
/lst
/lst
/response
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: OutofMemory on Highlightling
Is it possible to read only maxAnalyzedChars from the stored field
instead of reading the complete field in the memory? For instance, in my
case, is it possible to read only first 50K characters instead of
complete 1 MB stored text? That will help minimizing the memory usage
(Though, it will still take 50K * 500 * 2 = 50 MB for 500 results).
I would really appreciate some feedback on this issue...
Thanks,
Siddharth
-Original Message-
From: Gargate, Siddharth [mailto:sgarg...@ptc.com]
Sent: Friday, April 24, 2009 10:46 AM
To: solr-u...@lucene.apache.org
Subject: RE: OutofMemory on Highlightling
I am not sure whether lazy loading should help solve this problem. I
have set enableLazyFieldLoading to true but it is not helping.
I went through the code and observed that
DefaultSolrHighlighter.doHighlighting is reading all the documents and
the fields for highlighting (In my case, 1 MB stored field is read for
all documents).
Also I am confused over the following code in SolrIndexSearcher.doc()
method
if(!enableLazyFieldLoading || fields == null) {
d = searcher.getIndexReader().document(i);
} else {
d = searcher.getIndexReader().document(i,
new SetNonLazyFieldSelector(fields));
}
Are we setting the fields as NonLazy even if lazy loading is enabled?
Thanks,
Siddharth
-Original Message-
From: Gargate, Siddharth [mailto:sgarg...@ptc.com]
Sent: Wednesday, April 22, 2009 11:12 AM
To: solr-u...@lucene.apache.org
Subject: RE: OutofMemory on Highlightling
Here is the stack trace
SEVERE: java.lang.OutOfMemoryError: Java heap space
at
java.lang.StringCoding$StringDecoder.decode(StringCoding.java:133)
at java.lang.StringCoding.decode(StringCoding.java:173)
at java.lang.String.init(String.java:444)
at
org.apache.lucene.store.IndexInput.readString(IndexInput.java:125)
at
org.apache.lucene.index.FieldsReader.addField(FieldsReader.java:390)
at
org.apache.lucene.index.FieldsReader.doc(FieldsReader.java:230)
at
org.apache.lucene.index.SegmentReader.document(SegmentReader.java:892)
at
org.apache.lucene.index.MultiSegmentReader.document(MultiSegmentReader.j
ava:277)
at
org.apache.solr.search.SolrIndexReader.document(SolrIndexReader.java:176
)
at
org.apache.solr.search.SolrIndexSearcher.doc(SolrIndexSearcher.java:457)
at
org.apache.solr.search.SolrIndexSearcher.readDocs(SolrIndexSearcher.java
:482)
at
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultS
olrHighlighter.java:253)
at
org.apache.solr.handler.component.HighlightComponent.process(HighlightCo
mponent.java:84)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(Search
Handler.java:195)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerB
ase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1333)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.ja
va:303)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.j
ava:232)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.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:2
86)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:84
5)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
-Original Message-
From: Gargate, Siddharth [mailto:sgarg...@ptc.com]
Sent: Wednesday, April 22, 2009 9:29 AM
To: solr-u...@lucene.apache.org
Subject: RE: OutofMemory on Highlightling
I tried disabling the documentCache but still the same issue.
documentCache
class=solr.LRUCache
size=0
initialSize=0
autowarmCount=0/
-Original Message-
From: Koji Sekiguchi [mailto:k...@r.email.ne.jp]
Sent: Monday, April 20, 2009 4:38 PM
To: solr-u...@lucene.apache.org
Subject: Re: OutofMemory on Highlightling
Gargate, Siddharth wrote:
Anybody facing the same issue? Following is my configuration
...
field name=content type=text indexed=true stored=false
multiValued=true/
field name=teaser type=text indexed=false stored=true/
[jira] Commented: (SOLR-1133) solr-common 1.4-SNAPSHOT is not in maven2 repository
[ https://issues.apache.org/jira/browse/SOLR-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703593#action_12703593 ] Uri Boness commented on SOLR-1133: -- Actually, the same issue is with solr-lucen-contrib library (the pom's are there, but not the jar) solr-common 1.4-SNAPSHOT is not in maven2 repository Key: SOLR-1133 URL: https://issues.apache.org/jira/browse/SOLR-1133 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Uri Boness Fix For: 1.3.1 Looking at the apache maven2 repository ([http://people.apache.org/repo/m2-snapshot-repository/]) solr-common-1.4-SNAPSHOT is missing -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1094) spellcheck component, correctlySpelled is bogus!
[
https://issues.apache.org/jira/browse/SOLR-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-1094:
--
Attachment: SOLR-1094.patch
another test and another fix - a single correctly spelled word will come back
with correctlySpelled = true
spellcheck component, correctlySpelled is bogus!
Key: SOLR-1094
URL: https://issues.apache.org/jira/browse/SOLR-1094
Project: Solr
Issue Type: Bug
Affects Versions: 1.3
Reporter: David Smiley
Assignee: Shalin Shekhar Mangar
Fix For: 1.4
Attachments: SOLR-1094.patch, SOLR-1094.patch
I've found that {{correctlySpelled}} is sometimes hidden and it is sometimes
shown, and when it is shown it may indicate true when it should clearly be
false. As such I've discounted it altogether. I should be fixed or removed.
Here's a search query I ran against my index and I swear I don't have a
termh zzzwwwzz :-)
{code}
lst name=responseHeader
int name=status0/int
int name=QTime58/int
lst name=params
str name=spellchecktrue/str
str name=rows0/str
str name=indenton/str
str name=echoParamsexplicit/str
str name=spellcheck.collatetrue/str
str name=spellcheck.extendedResultstrue/str
str name=qzzzwwwzz/str
str name=spellcheck.count3/str
str name=version2.2/str
/lst
/lst
result name=response numFound=0 start=0/
lst name=spellcheck
lst name=suggestions
bool name=correctlySpelledtrue/bool
/lst
/lst
/response
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1094) spellcheck component, correctlySpelled is bogus!
[
https://issues.apache.org/jira/browse/SOLR-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703618#action_12703618
]
Shalin Shekhar Mangar commented on SOLR-1094:
-
Committed revision 769357.
Thanks Mark!
spellcheck component, correctlySpelled is bogus!
Key: SOLR-1094
URL: https://issues.apache.org/jira/browse/SOLR-1094
Project: Solr
Issue Type: Bug
Affects Versions: 1.3
Reporter: David Smiley
Assignee: Shalin Shekhar Mangar
Fix For: 1.4
Attachments: SOLR-1094.patch, SOLR-1094.patch
I've found that {{correctlySpelled}} is sometimes hidden and it is sometimes
shown, and when it is shown it may indicate true when it should clearly be
false. As such I've discounted it altogether. I should be fixed or removed.
Here's a search query I ran against my index and I swear I don't have a
termh zzzwwwzz :-)
{code}
lst name=responseHeader
int name=status0/int
int name=QTime58/int
lst name=params
str name=spellchecktrue/str
str name=rows0/str
str name=indenton/str
str name=echoParamsexplicit/str
str name=spellcheck.collatetrue/str
str name=spellcheck.extendedResultstrue/str
str name=qzzzwwwzz/str
str name=spellcheck.count3/str
str name=version2.2/str
/lst
/lst
result name=response numFound=0 start=0/
lst name=spellcheck
lst name=suggestions
bool name=correctlySpelledtrue/bool
/lst
/lst
/response
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-916) CoreContainer :: register(String, SolrCore, boolean) documentation clarification about returnPrev argument
[ https://issues.apache.org/jira/browse/SOLR-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703631#action_12703631 ] Mark Miller commented on SOLR-916: -- I could go either way. The name change certainly makes some sense, but even as is, a core that is returned closed is not very useful. Null could just as well be returned. But when you ask to returnPrev, a working open core is guaranteed to be returned if a previous one existed. I wouldnt feel so bad leaving it as it is - your change almost seems to strengthen the contract - you have to return the closed core as well. Neither side is a very strong argument to me and I could go either way. CoreContainer :: register(String, SolrCore, boolean) documentation clarification about returnPrev argument --- Key: SOLR-916 URL: https://issues.apache.org/jira/browse/SOLR-916 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Environment: Tomcat 6, JRE 6 Reporter: Kay Kay Priority: Minor Fix For: 1.4 Attachments: SOLR-916.patch Original Estimate: 2h Remaining Estimate: 2h In CoreContainer.java :: register(name, core, returnPrev) - the documentation says it would return a previous core having the same name if it existed *and returnPrev = true*. * @return a previous core having the same name if it existed and returnPrev==true */ public SolrCore register(String name, SolrCore core, boolean returnPrev) .. But as per the code towards the end - the previous core is returned anyway, irrespective of the value of returnPrev. The difference, though, seems to be that when returnPrev is false, the previous core (of the same name, if exists) is closed. Which one of them is correct . If the code were correct , would the variable be better renamed as closePrevious , as opposed to returnPrevious. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-465) Add configurable DirectoryProvider so that alternate Directory implementations can be specified via solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-465: - Attachment: SOLR-465.patch changes made Add configurable DirectoryProvider so that alternate Directory implementations can be specified via solrconfig.xml -- Key: SOLR-465 URL: https://issues.apache.org/jira/browse/SOLR-465 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: TJ Laurenzo Assignee: Yonik Seeley Fix For: 1.4 Attachments: SOLR-465-fixes.patch, SOLR-465.patch, SOLR-465.patch, SOLR-465.patch, SOLR-465.patch, solr-directory-provider.patch Original Estimate: 0.25h Remaining Estimate: 0.25h Solr is presently hard-coded to use the FSDirectory implementation in Lucene. Other Directory implementations are possible. This patch creates a new DirectoryProvider interface and extends SolrCore to load an implementation of it from solrconfig.xml (if specified). If not specified, then it will fallback to the FSDirectory. A DirectoryProvider plugin can be configured in solrconfig.xml with the following XML: directoryProvider class=class.name !-- Parameters as required by the implementation -- /directoryProvider This patch was created against solr trunk checked out on 11/20/2007. Most of it is new code and should apply cleanly or with minor relocation. If it does not, let me know and I will update. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-243) Create a hook to allow custom code to create custom IndexReaders
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-243:
-
Attachment: SOLR-243.patch
to trunk
Create a hook to allow custom code to create custom IndexReaders
Key: SOLR-243
URL: https://issues.apache.org/jira/browse/SOLR-243
Project: Solr
Issue Type: Improvement
Components: search
Environment: Solr core
Reporter: John Wang
Assignee: Hoss Man
Fix For: 1.5
Attachments: indexReaderFactory.patch, indexReaderFactory.patch,
indexReaderFactory.patch, indexReaderFactory.patch, indexReaderFactory.patch,
indexReaderFactory.patch, indexReaderFactory.patch, SOLR-243.patch,
SOLR-243.patch, SOLR-243.patch, SOLR-243.patch, SOLR-243.patch, SOLR-243.patch
I have a customized IndexReader and I want to write a Solr plugin to use my
derived IndexReader implementation. Currently IndexReader instantiation is
hard coded to be:
IndexReader.open(path)
It would be really useful if this is done thru a plugable factory that can be
configured, e.g. IndexReaderFactory
interface IndexReaderFactory{
IndexReader newReader(String name,String path);
}
the default implementation would just return: IndexReader.open(path)
And in the newSearcher and getSearcher methods in SolrCore class can call the
current factory implementation to get the IndexReader instance and then build
the SolrIndexSearcher by passing in the reader.
It would be really nice to add this improvement soon (This seems to be a
trivial addition) as our project really depends on this.
Thanks
-John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1131) Allow a single field to index multiple fields
[ https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703661#action_12703661 ] Ryan McKinley commented on SOLR-1131: - [TeeTokenFilter|http://lucene.apache.org/java/2_4_1/api/org/apache/lucene/analysis/TeeTokenFilter.html] look interesting. How do you imagine it could help with letting a solr Field index multiple fields? Using the TeeTokenFilter seems like a matter of plumbing. Perhaps we could add some properties to FieldType that create a SinkTokenizer and then use copyField (or something similar) to use the existing SinkTokenizer. I'm not familiar enought with the Sink/Tee stuff to know what we would need -- but we should make sure any SchemaField/FieldType changes open the door to this. Allow a single field to index multiple fields - Key: SOLR-1131 URL: https://issues.apache.org/jira/browse/SOLR-1131 Project: Solr Issue Type: New Feature Components: Analysis Reporter: Ryan McKinley Attachments: SOLR-1131-IndexMultipleFields.patch In a few special cases, it makes sense for a single field (the concept) to be indexed as a set of Fields (lucene Field). Consider SOLR-773. The concept point may be best indexed in a variety of ways: * geohash (sincle lucene field) * lat field, lon field (two double fields) * cartesian tiers (a series of fields with tokens to say if it exists within that region) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-916) CoreContainer :: register(String, SolrCore, boolean) documentation clarification about returnPrev argument
[ https://issues.apache.org/jira/browse/SOLR-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703669#action_12703669 ] Kay Kay commented on SOLR-916: -- | I could go either way. The name change certainly makes some sense, but even as is, a core that is returned closed is not very useful. Null could just as well be returned. But when you ask to returnPrev, a working open core is guaranteed to be returned if a previous one existed. I wouldnt feel so bad leaving it as it is - your change almost seems to strengthen the contract - you have to return the closed core as well. Neither side is a very strong argument to me and I could go either way. I do not have an issue with the logic ( closing an existing core if returnPrev is false ) as it is currently but am more concerned with the name of the variable and the documentation about the same - just to make sure that it is in sync with the actual logic as of today. CoreContainer :: register(String, SolrCore, boolean) documentation clarification about returnPrev argument --- Key: SOLR-916 URL: https://issues.apache.org/jira/browse/SOLR-916 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Environment: Tomcat 6, JRE 6 Reporter: Kay Kay Priority: Minor Fix For: 1.4 Attachments: SOLR-916.patch Original Estimate: 2h Remaining Estimate: 2h In CoreContainer.java :: register(name, core, returnPrev) - the documentation says it would return a previous core having the same name if it existed *and returnPrev = true*. * @return a previous core having the same name if it existed and returnPrev==true */ public SolrCore register(String name, SolrCore core, boolean returnPrev) .. But as per the code towards the end - the previous core is returned anyway, irrespective of the value of returnPrev. The difference, though, seems to be that when returnPrev is false, the previous core (of the same name, if exists) is closed. Which one of them is correct . If the code were correct , would the variable be better renamed as closePrevious , as opposed to returnPrevious. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: opening a searcher lazily
: is it required to open the searcher in the constructor of SolrCore?. : We have a usecase where we just open a SolrCore to write a document : and close it. Opening the searcher is proving to be quite expensive : for us. Hmmm... i suspect it was setup that way initially because add required a searcher to check for an existing doc to delete first. conceptually we should be able to change the SolrCore so a searcher is only opened once needed -- but practically this may be a challenge ... i believe there are more then a few places where an assumtion is made about there being at least one open searcher. -Hoss
[jira] Updated: (SOLR-465) Add configurable DirectoryProvider so that alternate Directory implementations can be specified via solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-465: - Attachment: SOLR-465.patch Sorry, missed UpdateHandler in that last patch - new patch to fix. Eclipse is both a blessing and a curse :) Add configurable DirectoryProvider so that alternate Directory implementations can be specified via solrconfig.xml -- Key: SOLR-465 URL: https://issues.apache.org/jira/browse/SOLR-465 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: TJ Laurenzo Assignee: Yonik Seeley Fix For: 1.4 Attachments: SOLR-465-fixes.patch, SOLR-465.patch, SOLR-465.patch, SOLR-465.patch, SOLR-465.patch, SOLR-465.patch, solr-directory-provider.patch Original Estimate: 0.25h Remaining Estimate: 0.25h Solr is presently hard-coded to use the FSDirectory implementation in Lucene. Other Directory implementations are possible. This patch creates a new DirectoryProvider interface and extends SolrCore to load an implementation of it from solrconfig.xml (if specified). If not specified, then it will fallback to the FSDirectory. A DirectoryProvider plugin can be configured in solrconfig.xml with the following XML: directoryProvider class=class.name !-- Parameters as required by the implementation -- /directoryProvider This patch was created against solr trunk checked out on 11/20/2007. Most of it is new code and should apply cleanly or with minor relocation. If it does not, let me know and I will update. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Make ant example faster
: Wouldn't one solution to this bundling and aggregating/separating of examples : and plugins be made a lot less painful if SolrResourceLoader could load from a : list of directories rather than only a single directory? What are the I'm not understanding how that would help the example situation. what are you envisioning that the instanceDir would look like? how would SolrResourceLoader know which directories to use? right now SolrResourceLoader assumes (instanceDir + lib/) will contain a bunch of jars ... i can imagine that we could let that directory contain other directories and walk it recursively looking for jars, and then people could put symlinks in it to other lib directories -- but how would that help us with the example? would we create the symlinks via ant? can tgz/zip files store symlinks efficiently? Or are you thinking that we would add a new way to specify additional lib dir paths in the solrconfig.xml? ... i suppose that would be posible, but i think it would require some funky changes to SolrConfig and Config to parse out the lib dirs before parsing anything else (that would need to kow about the SolrResourceLoader) -Hoss
Re: Make ant example faster
: assuming we have more use-case specific examples, wouldn't that just be : something that copies one of them to a target directory? : : I guess what I really want is a way to be able to say: Give me a Solr home : that has these X features (DIH, Solr Cell, spell checking, highlighting, plus : whatever libs are needed) with some basic configuration + my choice of a : schema ranging from one that is barebones (maybe just an id field defined) : to a full fledged one (the current example) and I want to be able to do it : as simple as possible (i.e. as few commands as possible). Ah i'm understanding now. you don't just want a lot of good micro-examples of each feature, you want an easy way to generate default configs that work for an arbitrary set of features specified by the user. That seems like a hard problem to get right in a generic way. The simplest method i can think of for achiving that would be to start with a kitchen-sink type example that includes *everything* (because then it's easy to test that all of the pieces work well together and don't collide -- duplicate fieldnames or hanler names etc...) and then use xml comments or some other templating to be able to split that kitchen sink file up into snippets -- which could then be combined again in lots of combinations. (Or ... I suppose the snippets could be maintained by hand and then the build system could generate the kitchen sink and run tests to ensure that none of them collide ... but maintaining the kitchen-sink by hand seems easier in a weird way) -Hoss
[jira] Commented: (SOLR-1014) SolrExampleStreamingTest failures
[ https://issues.apache.org/jira/browse/SOLR-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703843#action_12703843 ] Yonik Seeley commented on SOLR-1014: The failure seems to be SolrExampleStreamingTest .testCommitWithin() This fails consistently on my fast linux workstation (ubuntu 9.04, quad-core phenom II, ext4, java6_12), but not on windows. SolrExampleStreamingTest failures -- Key: SOLR-1014 URL: https://issues.apache.org/jira/browse/SOLR-1014 Project: Solr Issue Type: Bug Reporter: Yonik Seeley Fix For: 1.4 SolrExampleStreamingTest intermittently fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-965) Better exception logging when no ping query configured
[ https://issues.apache.org/jira/browse/SOLR-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-965. --- Resolution: Fixed Assignee: Hoss Man thanks mark ... i added a little warning logging on init if hte deprecated feature was used, and tweaked your error message so it directed people to use PingRequestHandler instead of the old admin/pingQuery if they ever encountered that error. Committed revision 769574. Better exception logging when no ping query configured -- Key: SOLR-965 URL: https://issues.apache.org/jira/browse/SOLR-965 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Reporter: Hoss Man Assignee: Hoss Man Fix For: 1.4 Attachments: SOLR-965.patch user noted that with the example multicore configs, http://localhost:8983/solr/core1/admin/ping results in a 500 error and logs quite a bit of crap starting with a NullPointerException. The failing ping is the correct behavior, because the example multicore configs don't define a pingQuery -- but the code path of the failure and the exceptions logged are less then ideal. ping.jsp (which is still used if the PingRequestHandler doesn't get registered) and SolrConfig.getPingQueryRequest should me modified to log an (on topic) error and fail fast when there is no pingQuery declaration. A quick skim of PingRequestHandlers suggests we may also want to add some better logging (specifically: warnings about configuring it with good defaults) if it gets called without any params. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1073) StrField should allow locale sensitive sorting
[
https://issues.apache.org/jira/browse/SOLR-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703884#action_12703884
]
Hoss Man commented on SOLR-1073:
The patch seems ok to me, ideally it should validate the Locale during init and
fail if it doesn't exist, but that doesn't seem like a show stopper. I'm
personally not comfortable committing it without a basic test (Locale stuff is
tricky, it would be good to know we aren't tickling some weird Lucene-Java bug
in an odd way).
The only other big catch in my mind is that this new class doesn't respect the
sortMissingLast sortMissingTrue options that StrField does. We should at
least document this in the javadocs, but ideally we should make them work as
well. I *think* it would be possible if we changed
MissingStringLastComparatorSource so that it could wrap another
SortComparatorSource (do the null checks first, then delegate). if we managed
to get that working, then there wouldn't be any reason for a new
LocaleStrField, it could just be a new option on StrField.
StrField should allow locale sensitive sorting
--
Key: SOLR-1073
URL: https://issues.apache.org/jira/browse/SOLR-1073
Project: Solr
Issue Type: Improvement
Environment: All
Reporter: Sachin
Attachments: LocaleStrField.java
Currently, StrField does not take a parameter which it can pass to ctor of
SortField making the StrField's sorting rely on the locale of the JVM.
Ideally, StrField should allow setting the locale in the schema.xml and use
it to create a new instance of the SortField in getSortField() method,
something like:
snip:
public SortField getSortField(SchemaField field,boolean reverse)
{
...
Locale locale = new Locale(lang,country);
return new SortField(field.getName(), locale, reverse);
}
More details about this issue here:
http://www.nabble.com/CJKAnalyzer-and-Chinese-Text-sort-td22374195.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1073) StrField should allow locale sensitive sorting
[
https://issues.apache.org/jira/browse/SOLR-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703893#action_12703893
]
Walter Underwood commented on SOLR-1073:
Using the locale of the JVM is very, very bad for a multilingual server. Solr
should always use the same, simple locale. It is OK to set a Locale in
configuration for single-language installations, but using the JVM locale is a
recipe for disaster. You move Solr to a different server and everything breaks.
Very, very bad.
In a multi-lingual config, locales must be set per-request.
Ideally, requests should send an ISO language code as context for the query.
StrField should allow locale sensitive sorting
--
Key: SOLR-1073
URL: https://issues.apache.org/jira/browse/SOLR-1073
Project: Solr
Issue Type: Improvement
Environment: All
Reporter: Sachin
Attachments: LocaleStrField.java
Currently, StrField does not take a parameter which it can pass to ctor of
SortField making the StrField's sorting rely on the locale of the JVM.
Ideally, StrField should allow setting the locale in the schema.xml and use
it to create a new instance of the SortField in getSortField() method,
something like:
snip:
public SortField getSortField(SchemaField field,boolean reverse)
{
...
Locale locale = new Locale(lang,country);
return new SortField(field.getName(), locale, reverse);
}
More details about this issue here:
http://www.nabble.com/CJKAnalyzer-and-Chinese-Text-sort-td22374195.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-465) Add configurable DirectoryProvider so that alternate Directory implementations can be specified via solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-465: - Attachment: SOLR-465.patch I should have also changed the SolrCore use of SolrIndexWriter to create an index to use a non deprecated SolrIndexWriter constructor. Add configurable DirectoryProvider so that alternate Directory implementations can be specified via solrconfig.xml -- Key: SOLR-465 URL: https://issues.apache.org/jira/browse/SOLR-465 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: TJ Laurenzo Assignee: Yonik Seeley Fix For: 1.4 Attachments: SOLR-465-fixes.patch, SOLR-465.patch, SOLR-465.patch, SOLR-465.patch, SOLR-465.patch, SOLR-465.patch, SOLR-465.patch, solr-directory-provider.patch Original Estimate: 0.25h Remaining Estimate: 0.25h Solr is presently hard-coded to use the FSDirectory implementation in Lucene. Other Directory implementations are possible. This patch creates a new DirectoryProvider interface and extends SolrCore to load an implementation of it from solrconfig.xml (if specified). If not specified, then it will fallback to the FSDirectory. A DirectoryProvider plugin can be configured in solrconfig.xml with the following XML: directoryProvider class=class.name !-- Parameters as required by the implementation -- /directoryProvider This patch was created against solr trunk checked out on 11/20/2007. Most of it is new code and should apply cleanly or with minor relocation. If it does not, let me know and I will update. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1014) SolrExampleStreamingTest failures
[ https://issues.apache.org/jira/browse/SOLR-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12703902#action_12703902 ] Mark Miller commented on SOLR-1014: --- Thats odd - I have not seen it fail yet with many, many runs. ubuntu 9.04, duo-core, ext3, openjdk 6 and sun java 1.5 (both 64-bit). Havn't tried with sun 1.6 yet. SolrExampleStreamingTest failures -- Key: SOLR-1014 URL: https://issues.apache.org/jira/browse/SOLR-1014 Project: Solr Issue Type: Bug Reporter: Yonik Seeley Fix For: 1.4 SolrExampleStreamingTest intermittently fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
