[jira] Commented: (SOLR-1781) Replication index directories not always cleaned up
[ https://issues.apache.org/jira/browse/SOLR-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836519#action_12836519 ] Noble Paul commented on SOLR-1781: -- The problem is that while you are trying to delete the original index, there may be requests in pipleline which uses the old index. If the index files are deleted those requests may fail. > Replication index directories not always cleaned up > --- > > Key: SOLR-1781 > URL: https://issues.apache.org/jira/browse/SOLR-1781 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 1.4 > Environment: Windows Server 2003 R2, Java 6b18 >Reporter: Terje Sten Bjerkseth >Assignee: Noble Paul > Fix For: 1.5 > > Attachments: > 0001-Replication-does-not-always-clean-up-old-directories.patch > > > We had the same problem as someone described in > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201001.mbox/%3c222a518d-ddf5-4fc8-a02a-74d4f232b...@snooth.com%3e. > A partial copy of that message: > We're using the new replication and it's working pretty well. There's > one detail I'd like to get some more information about. > As the replication works, it creates versions of the index in the data > directory. Originally we had index/, but now there are dated versions > such as index.20100127044500/, which are the replicated versions. > Each copy is sized in the vicinity of 65G. With our current hard drive > it's fine to have two around, but 3 gets a little dicey. Sometimes > we're finding that the replication doesn't always clean up after > itself. I would like to understand this better, or to not have this > happen. It could be a configuration issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1781) Replication index directories not always cleaned up
[ https://issues.apache.org/jira/browse/SOLR-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1781: Assignee: Noble Paul > Replication index directories not always cleaned up > --- > > Key: SOLR-1781 > URL: https://issues.apache.org/jira/browse/SOLR-1781 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 1.4 > Environment: Windows Server 2003 R2, Java 6b18 >Reporter: Terje Sten Bjerkseth >Assignee: Noble Paul > Fix For: 1.5 > > Attachments: > 0001-Replication-does-not-always-clean-up-old-directories.patch > > > We had the same problem as someone described in > http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201001.mbox/%3c222a518d-ddf5-4fc8-a02a-74d4f232b...@snooth.com%3e. > A partial copy of that message: > We're using the new replication and it's working pretty well. There's > one detail I'd like to get some more information about. > As the replication works, it creates versions of the index in the data > directory. Originally we had index/, but now there are dated versions > such as index.20100127044500/, which are the replicated versions. > Each copy is sized in the vicinity of 65G. With our current hard drive > it's fine to have two around, but 3 gets a little dicey. Sometimes > we're finding that the replication doesn't always clean up after > itself. I would like to understand this better, or to not have this > happen. It could be a configuration issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solrj @Field getter annotation
On Sun, Feb 21, 2010 at 11:04 PM, Norman Wiechmann wrote: > Hi, > > I'm wondering if there is a reason why the @Field annotation is restricted > to setters? The preferred way is to apply the annotation to fields. it is provided on setters also if you prefer the set/get xxx() route. > > In my case I would like to index beans from java using the solrj client > implementation. Transforming documents to beans is not required because I > use queries to Solr from JavaScript only. > > To avoid the creation of setter methods just to use the @Field annotation I > extended SolrServer to overwrite getBinder() and added an > DocumentObjectBinder implementation that supports @Field annotations at bean > property getter methods. > > For me it feels very unusual to add annotations to setters. It does not > match with the experience I have from other libraries like JPA or JAXB. > > Best, Norman > -- - Noble Paul | Systems Architect| AOL | http://aol.com
[jira] Issue Comment Edited: (SOLR-1785) Handle +/-Inf, NaN when scoring
[ https://issues.apache.org/jira/browse/SOLR-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836387#action_12836387 ] Yonik Seeley edited comment on SOLR-1785 at 2/21/10 6:57 PM: - In Solr 1.3 and before, +-Inf were handled normally, and scores of NaN caused the relative ordering of other documents to be mixed up. The new lucene collectors used in 1.4 can't all handle -Inf and NaN (they can return Integer.MAX_VAL to be returned as a docid), leading to exceptions as seen in SOLR-1778. Because of this Solr's function queries normalized their output to exclude -Inf and NaN. Unfortunately, this is not sufficient, because non-infinite scores can combine with a boolean query into an infinite score. And once you have an infinite score, a simple multiplication by zero will yield a NaN. example: http://localhost:8983/solr/select?fl=id,score&q=_val_:"-3e38"+_val_:"-3e38"; Properly handing -Inf is an easy fix. The bigger question is how to handle NaN. We could: 1) punt and realize that any NaNs will mess up the ordering of all other documents for that request 2) Move the FunctionQuery normalization that changes -Inf and NaN into -Float.MAX_VALUE to right before collection (probably with a wrapper collector). This would preserve the ordering of all the other documents, at the cost of a little performance, and information loss (the fact that there was a NaN or -Inf). 3) Fix -Inf handling, and normalize NaN to -Inf 4) Completely order NaNs (probably after -Inf)... This keeps the most information, but would require implementing a custom comparator for score sorting (for anything other than a simple score desc). was (Author: ysee...@gmail.com): In Solr 1.3 and before, +-Inf were handled normally, and scores of NaN caused the relative ordering of other documents to be mixed up. The new lucene collectors used in 1.4 can't all handle -Inf and NaN (they can return Integer.MAX_VAL to be returned as a docid), leading to exceptions as seen in SOLR-1778. Because of this Solr's function queries normalized their output to exclude -Inf and NaN. Unfortunately, this is not sufficient, because non-infinite scores can combine with a boolean query into an infinite score. And once you have an infinite score, a simple multiplication by zero will yield a NaN. example: http://localhost:8983/solr/select?fl=id,score&q=_val_:"-3e38"+_val_:"-3e38"; Properly handing -Inf is an easy fix. The bigger question is how to handle NaN. We could: 1) punt and realize that any NaNs will mess up the ordering of all other documents for that request 2) Move the FunctionQuery normalization that changes -Inf and NaN into -Float.MAX_VALUE to right before collection (probably with a wrapper collector). This would preserve the ordering of all the other documents, at the cost of a little performance, and information loss (the fact that there was a NaN or -Inf). 3) Completely order NaNs (probably after -Inf)... This keeps the most information, but would require implementing a custom comparator for score sorting (for anything other than a simple score desc). > Handle +/-Inf, NaN when scoring > > > Key: SOLR-1785 > URL: https://issues.apache.org/jira/browse/SOLR-1785 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Yonik Seeley > Fix For: 1.5 > > > Scores of -Inf or NaN being collected can cause exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Solrj @Field getter annotation
Hi, I'm wondering if there is a reason why the @Field annotation is restricted to setters? In my case I would like to index beans from java using the solrj client implementation. Transforming documents to beans is not required because I use queries to Solr from JavaScript only. To avoid the creation of setter methods just to use the @Field annotation I extended SolrServer to overwrite getBinder() and added an DocumentObjectBinder implementation that supports @Field annotations at bean property getter methods. For me it feels very unusual to add annotations to setters. It does not match with the experience I have from other libraries like JPA or JAXB. Best, Norman
[jira] Commented: (SOLR-1297) Enable sorting by Function Query
[ https://issues.apache.org/jira/browse/SOLR-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836398#action_12836398 ] Yonik Seeley commented on SOLR-1297: Function queries can contain normal queries, which need weighting to produce correct scores and work properly. This may not be straightforward to get right, hence I've just left this issue open for now. > Enable sorting by Function Query > > > Key: SOLR-1297 > URL: https://issues.apache.org/jira/browse/SOLR-1297 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1297.patch > > > It would be nice if one could sort by FunctionQuery. See also SOLR-773, > where this was first mentioned by Yonik as part of the generic solution to > geo-search -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1297) Enable sorting by Function Query
[ https://issues.apache.org/jira/browse/SOLR-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836394#action_12836394 ] Grant Ingersoll commented on SOLR-1297: --- Not following. What do I need to fix? > Enable sorting by Function Query > > > Key: SOLR-1297 > URL: https://issues.apache.org/jira/browse/SOLR-1297 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1297.patch > > > It would be nice if one could sort by FunctionQuery. See also SOLR-773, > where this was first mentioned by Yonik as part of the generic solution to > geo-search -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1785) Handle +/-Inf, NaN when scoring
[ https://issues.apache.org/jira/browse/SOLR-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836387#action_12836387 ] Yonik Seeley commented on SOLR-1785: In Solr 1.3 and before, +-Inf were handled normally, and scores of NaN caused the relative ordering of other documents to be mixed up. The new lucene collectors used in 1.4 can't all handle -Inf and NaN (they can return Integer.MAX_VAL to be returned as a docid), leading to exceptions as seen in SOLR-1778. Because of this Solr's function queries normalized their output to exclude -Inf and NaN. Unfortunately, this is not sufficient, because non-infinite scores can combine with a boolean query into an infinite score. And once you have an infinite score, a simple multiplication by zero will yield a NaN. example: http://localhost:8983/solr/select?fl=id,score&q=_val_:"-3e38"+_val_:"-3e38"; Properly handing -Inf is an easy fix. The bigger question is how to handle NaN. We could: 1) punt and realize that any NaNs will mess up the ordering of all other documents for that request 2) Move the FunctionQuery normalization that changes -Inf and NaN into -Float.MAX_VALUE to right before collection (probably with a wrapper collector). This would preserve the ordering of all the other documents, at the cost of a little performance, and information loss (the fact that there was a NaN or -Inf). 3) Completely order NaNs (probably after -Inf)... This keeps the most information, but would require implementing a custom comparator for score sorting (for anything other than a simple score desc). > Handle +/-Inf, NaN when scoring > > > Key: SOLR-1785 > URL: https://issues.apache.org/jira/browse/SOLR-1785 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Yonik Seeley > Fix For: 1.5 > > > Scores of -Inf or NaN being collected can cause exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1785) Handle +/-Inf, NaN when scoring
Handle +/-Inf, NaN when scoring Key: SOLR-1785 URL: https://issues.apache.org/jira/browse/SOLR-1785 Project: Solr Issue Type: Bug Affects Versions: 1.4 Reporter: Yonik Seeley Fix For: 1.5 Scores of -Inf or NaN being collected can cause exceptions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
