[jira] Resolved: (SOLR-953) Small simplification for LuceneGapFragmenter.isNewFragment
[
https://issues.apache.org/jira/browse/SOLR-953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otis Gospodnetic resolved SOLR-953.
---
Resolution: Fixed
Assignee: Otis Gospodnetic
Thanks Chris.
Sendingsrc/java/org/apache/solr/highlight/GapFragmenter.java
Transmitting file data .
Committed revision 734336.
> Small simplification for LuceneGapFragmenter.isNewFragment
> --
>
> Key: SOLR-953
> URL: https://issues.apache.org/jira/browse/SOLR-953
> Project: Solr
> Issue Type: Improvement
> Components: highlighter
>Affects Versions: 1.4
>Reporter: Chris Harris
>Assignee: Otis Gospodnetic
>Priority: Minor
> Attachments: SOLR-953.patch
>
>
> This little patch makes the code for LuceneGapFragmenter.isNewFragment(Token)
> slightly more intuitive.
> The method currently features the line
> {code}
> fragOffsetAccum += token.endOffset() - fragOffsetAccum;
> {code}
> This can be simplified, though, to just
> {code}
> fragOffsetAccum = token.endOffset();
> {code}
> Maybe it's just me, but I find the latter expression's intent to be
> sufficiently clearer than the former to warrant committing such a change.
> This patch makes this simplification. Also, if you do make this
> simplification, then it doesn't really make sense to think of fragOffsetAccum
> as an accumulator anymore, so in the patch we rename the variable to just
> fragOffset.
> Tests from HighlighterTest.java pass with the patch applied.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-954) SolrQuery - better cross-referential documentation / fix inconsistent cross-reference links .
[ https://issues.apache.org/jira/browse/SOLR-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic resolved SOLR-954. --- Resolution: Fixed Assignee: Otis Gospodnetic Thanks Kay. Sendingsrc/solrj/org/apache/solr/client/solrj/SolrQuery.java Transmitting file data . Committed revision 734332. > SolrQuery - better cross-referential documentation / fix inconsistent > cross-reference links . > - > > Key: SOLR-954 > URL: https://issues.apache.org/jira/browse/SOLR-954 > Project: Solr > Issue Type: Improvement > Components: documentation >Affects Versions: 1.3 > Environment: Tomcat 6, Java 6 >Reporter: Kay Kay >Assignee: Otis Gospodnetic >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-954.patch, SOLR-954.patch > > Original Estimate: 3h > Remaining Estimate: 3h > > SolrQuery methods need quite a bit of documentation as the javadoc appears to > be blank at the moment and comments for some deprecated methods point to > non-existent methods. Patch relevant to documentation available herewith. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-956) SolrParams#getFieldInt(String, String) - inconsistent documentation
[ https://issues.apache.org/jira/browse/SOLR-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic resolved SOLR-956. --- Resolution: Fixed Assignee: Otis Gospodnetic Thanks Kay. Sendingsrc/common/org/apache/solr/common/params/SolrParams.java Transmitting file data . Committed revision 734330. > SolrParams#getFieldInt(String, String) - inconsistent documentation > - > > Key: SOLR-956 > URL: https://issues.apache.org/jira/browse/SOLR-956 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Kay Kay >Assignee: Otis Gospodnetic > Fix For: 1.4 > > Attachments: SOLR-956.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > SolrParams#getFieldInt(String, String) documentation says it returns def. if > the value does not exist. > There is no def. passed on to the method - so seems to be inconsistent with > what the method does. It returns null if the field,param does not exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-957) CommonParams#VERSION : Inconsistent doc
[ https://issues.apache.org/jira/browse/SOLR-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic resolved SOLR-957. --- Resolution: Fixed Thanks Kay. Sendingsrc/common/org/apache/solr/common/params/CommonParams.java Transmitting file data . Committed revision 734329. > CommonParams#VERSION : Inconsistent doc > > > Key: SOLR-957 > URL: https://issues.apache.org/jira/browse/SOLR-957 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Kay Kay >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-957.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > The doc for VERSION (in CommonParams) seems to be copied from the previous > field. (totally unrelated ). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-958) CommonsHttpSolrServer - documentation ..
[ https://issues.apache.org/jira/browse/SOLR-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic resolved SOLR-958. --- Resolution: Fixed Assignee: Otis Gospodnetic Thanks! Sending src/solrj/org/apache/solr/client/solrj/impl/CommonsHttpSolrServer.java Transmitting file data . Committed revision 734326. > CommonsHttpSolrServer - documentation .. > - > > Key: SOLR-958 > URL: https://issues.apache.org/jira/browse/SOLR-958 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Kay Kay >Assignee: Otis Gospodnetic >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-958.patch > > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > clarification about ResponseParser member , useMultiPartPost -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-959) Remove hardcoded port numbers from TestReplicationHandler
[ https://issues.apache.org/jira/browse/SOLR-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-959: -- Attachment: replicationtest-port-refactor.patch first pass at a refactoring to clean up the hardcoded ports -- takes advantage of the copyFile function that was already in the test to replace a marker token in the config with the real port number. at first glance this refactoring *should* work, but testIndexAndConfigAliasReplication errors with this patch --i believe the problem is because it expects the slave to pull files from a master after the master server has been stoped and then restarted -- which fails because the new master won't have the same port number. we could try explicitly creating the new master with the same port as the old master, but there's no guarantee the os won't have already allocated that port to a new process at that point. A better solution is to eliminate the need to stop/start the master by using core reload or something similar instead. The most alarming thing at this point is that several other test methods do similar stop/start of the master, and yet they work fine (even though the slave has no knowledge of the new master port) which suggests to me that the tests may be false positives making flawed assumptions. unfortunately i don't have any more time to look into this at the moment ... attaching patch as a checkpoint in case someone else wants to look into it (or i get hit by a bus) > Remove hardcoded port numbers from TestReplicationHandler > - > > Key: SOLR-959 > URL: https://issues.apache.org/jira/browse/SOLR-959 > Project: Solr > Issue Type: Test > Components: replication (java) >Reporter: Hoss Man >Priority: Minor > Attachments: replicationtest-port-refactor.patch > > > TestReplicationHandler has a hardcoded port of in it for the "master". > hardcoding port numbers in unit tests is very brittle and error prone and can > cause problems. Ideally tests that aren't explicitly testing network related > functionality should avoid dealing with the network at all, but when > neccessary it's much better to let the OS pick any available port (as most > other solr tests do) then to hardcoded it. > in TestReplicationHandler things are a little more complicated because the > master port number needs to be refered to in the slave config files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-959) Remove hardcoded port numbers from TestReplicationHandler
Remove hardcoded port numbers from TestReplicationHandler - Key: SOLR-959 URL: https://issues.apache.org/jira/browse/SOLR-959 Project: Solr Issue Type: Test Components: replication (java) Reporter: Hoss Man Priority: Minor TestReplicationHandler has a hardcoded port of in it for the "master". hardcoding port numbers in unit tests is very brittle and error prone and can cause problems. Ideally tests that aren't explicitly testing network related functionality should avoid dealing with the network at all, but when neccessary it's much better to let the OS pick any available port (as most other solr tests do) then to hardcoded it. in TestReplicationHandler things are a little more complicated because the master port number needs to be refered to in the slave config files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-820) replicate After startup for new replication
[
https://issues.apache.org/jira/browse/SOLR-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663533#action_12663533
]
mhenson edited comment on SOLR-820 at 1/13/09 3:41 PM:
--
I have not been able to get this to work in my configuration. The slave
instance, starting with an empty target directory, creates segments files for
itself on startup. It then has an "index version" that is a higher number than
the master's index version. The replication never starts, unless I do a commit
on the master.
My replication config is very straightforward. My configuration assumes that
the slave machine is starting off completely empty of all data (aside from the
essentials necessary to get Solr to start), and will pull everything from the
master instance.
NOTE: I tested this with nightly build solr-2009-01-12.zip
was (Author: mhenson):
I have not been able to get this to work in my configuration. The slave
instance, starting with an empty target directory, creates segments files for
itself on startup. It then has an "index version" that is a higher number than
the master's index version. The replication never starts, unless I do a commit
on the master.
My replication config is very straightforward. My configuration assumes that
the slave machine is starting off completely empty of all data (aside from the
essentials necessary to get Solr to start), and will pull everything from the
master instance.
> replicate After startup for new replication
> ---
>
> Key: SOLR-820
> URL: https://issues.apache.org/jira/browse/SOLR-820
> Project: Solr
> Issue Type: Improvement
> Components: replication (scripts)
>Reporter: Noble Paul
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-820.patch
>
>
> add another option of
> {code}
> startup
> {code}
> so that replication can be triggered w/o a commit
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-914) Presence of finalize() in the codebase
[
https://issues.apache.org/jira/browse/SOLR-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663540#action_12663540
]
Kay Kay commented on SOLR-914:
--
SolrIndexWriter#finalize() seems to delegate the same to IndexWriter.close()
which is quite expensive.
ConcurrentLRUCache#finalize() seems to close a thread (by means of notify() ) .
I am not sure if those methods are good enough candidates to be present in
finalize() since they seem to do more than logging at this point.
> Presence of finalize() in the codebase
> ---
>
> Key: SOLR-914
> URL: https://issues.apache.org/jira/browse/SOLR-914
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 1.3
> Environment: Tomcat 6, JRE 6
>Reporter: Kay Kay
>Priority: Minor
> Fix For: 1.4
>
> Original Estimate: 480h
> Remaining Estimate: 480h
>
> There seems to be a number of classes - that implement finalize() method.
> Given that it is perfectly ok for a Java VM to not to call it - may be -
> there has to some other way { try .. finally - when they are created to
> destroy them } to destroy them and the presence of finalize() method , (
> depending on implementation ) might not serve what we want and in some cases
> can end up delaying the gc process, depending on the algorithms.
> $ find . -name *.java | xargs grep finalize
> ./contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/JdbcDataSource.java:
> protected void finalize() {
> ./src/java/org/apache/solr/update/SolrIndexWriter.java: protected void
> finalize() {
> ./src/java/org/apache/solr/core/CoreContainer.java: protected void
> finalize() {
> ./src/java/org/apache/solr/core/SolrCore.java: protected void finalize() {
> ./src/common/org/apache/solr/common/util/ConcurrentLRUCache.java: protected
> void finalize() throws Throwable {
> May be we need to revisit these occurences from a design perspective to see
> if they are necessary / if there is an alternate way of managing guaranteed
> destruction of resources.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-958) CommonsHttpSolrServer - documentation ..
[ https://issues.apache.org/jira/browse/SOLR-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated SOLR-958: - Attachment: SOLR-958.patch > CommonsHttpSolrServer - documentation .. > - > > Key: SOLR-958 > URL: https://issues.apache.org/jira/browse/SOLR-958 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Kay Kay > Fix For: 1.4 > > Attachments: SOLR-958.patch > > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > clarification about ResponseParser member , useMultiPartPost -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-958) CommonsHttpSolrServer - documentation ..
[ https://issues.apache.org/jira/browse/SOLR-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated SOLR-958: - Component/s: documentation Fix Version/s: 1.4 Priority: Minor (was: Major) > CommonsHttpSolrServer - documentation .. > - > > Key: SOLR-958 > URL: https://issues.apache.org/jira/browse/SOLR-958 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Kay Kay >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-958.patch > > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > clarification about ResponseParser member , useMultiPartPost -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-958) CommonsHttpSolrServer - documentation ..
CommonsHttpSolrServer - documentation .. - Key: SOLR-958 URL: https://issues.apache.org/jira/browse/SOLR-958 Project: Solr Issue Type: Bug Reporter: Kay Kay clarification about ResponseParser member , useMultiPartPost -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-820) replicate After startup for new replication
[
https://issues.apache.org/jira/browse/SOLR-820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12663533#action_12663533
]
Michael Henson commented on SOLR-820:
-
I have not been able to get this to work in my configuration. The slave
instance, starting with an empty target directory, creates segments files for
itself on startup. It then has an "index version" that is a higher number than
the master's index version. The replication never starts, unless I do a commit
on the master.
My replication config is very straightforward. My configuration assumes that
the slave machine is starting off completely empty of all data (aside from the
essentials necessary to get Solr to start), and will pull everything from the
master instance.
> replicate After startup for new replication
> ---
>
> Key: SOLR-820
> URL: https://issues.apache.org/jira/browse/SOLR-820
> Project: Solr
> Issue Type: Improvement
> Components: replication (scripts)
>Reporter: Noble Paul
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-820.patch
>
>
> add another option of
> {code}
> startup
> {code}
> so that replication can be triggered w/o a commit
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-957) CommonParams#VERSION : Inconsistent doc
[ https://issues.apache.org/jira/browse/SOLR-957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated SOLR-957: - Attachment: SOLR-957.patch > CommonParams#VERSION : Inconsistent doc > > > Key: SOLR-957 > URL: https://issues.apache.org/jira/browse/SOLR-957 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Kay Kay >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-957.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > The doc for VERSION (in CommonParams) seems to be copied from the previous > field. (totally unrelated ). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-957) CommonParams#VERSION : Inconsistent doc
CommonParams#VERSION : Inconsistent doc Key: SOLR-957 URL: https://issues.apache.org/jira/browse/SOLR-957 Project: Solr Issue Type: Bug Components: documentation Reporter: Kay Kay Priority: Minor Fix For: 1.4 Attachments: SOLR-957.patch The doc for VERSION (in CommonParams) seems to be copied from the previous field. (totally unrelated ). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-849) Add bwlimit support to snappuller
[ https://issues.apache.org/jira/browse/SOLR-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic updated SOLR-849: -- Assignee: Otis Gospodnetic > Add bwlimit support to snappuller > - > > Key: SOLR-849 > URL: https://issues.apache.org/jira/browse/SOLR-849 > Project: Solr > Issue Type: Improvement > Components: replication (scripts) >Reporter: Otis Gospodnetic >Assignee: Otis Gospodnetic >Priority: Minor > Attachments: SOLR-849.patch > > > From http://markmail.org/message/njnbh5gbb2mvfe24 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-849) Add bwlimit support to snappuller
[ https://issues.apache.org/jira/browse/SOLR-849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic resolved SOLR-849. --- Resolution: Won't Fix No need for this since we are moving away from shell script-based replication, most likely. > Add bwlimit support to snappuller > - > > Key: SOLR-849 > URL: https://issues.apache.org/jira/browse/SOLR-849 > Project: Solr > Issue Type: Improvement > Components: replication (scripts) >Reporter: Otis Gospodnetic >Priority: Minor > Attachments: SOLR-849.patch > > > From http://markmail.org/message/njnbh5gbb2mvfe24 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-956) SolrParams#getFieldInt(String, String) - inconsistent documentation
[ https://issues.apache.org/jira/browse/SOLR-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated SOLR-956: - Attachment: SOLR-956.patch > SolrParams#getFieldInt(String, String) - inconsistent documentation > - > > Key: SOLR-956 > URL: https://issues.apache.org/jira/browse/SOLR-956 > Project: Solr > Issue Type: Improvement > Components: documentation >Reporter: Kay Kay > Fix For: 1.4 > > Attachments: SOLR-956.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > SolrParams#getFieldInt(String, String) documentation says it returns def. if > the value does not exist. > There is no def. passed on to the method - so seems to be inconsistent with > what the method does. It returns null if the field,param does not exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-956) SolrParams#getFieldInt(String, String) - inconsistent documentation
SolrParams#getFieldInt(String, String) - inconsistent documentation - Key: SOLR-956 URL: https://issues.apache.org/jira/browse/SOLR-956 Project: Solr Issue Type: Improvement Components: documentation Reporter: Kay Kay Fix For: 1.4 Attachments: SOLR-956.patch SolrParams#getFieldInt(String, String) documentation says it returns def. if the value does not exist. There is no def. passed on to the method - so seems to be inconsistent with what the method does. It returns null if the field,param does not exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-954) SolrQuery - better cross-referential documentation / fix inconsistent cross-reference links .
[ https://issues.apache.org/jira/browse/SOLR-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated SOLR-954: - Attachment: SOLR-954.patch * More documentation added about QueryType. and some methods. > SolrQuery - better cross-referential documentation / fix inconsistent > cross-reference links . > - > > Key: SOLR-954 > URL: https://issues.apache.org/jira/browse/SOLR-954 > Project: Solr > Issue Type: Improvement > Components: documentation >Affects Versions: 1.3 > Environment: Tomcat 6, Java 6 >Reporter: Kay Kay >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-954.patch, SOLR-954.patch > > Original Estimate: 3h > Remaining Estimate: 3h > > SolrQuery methods need quite a bit of documentation as the javadoc appears to > be blank at the moment and comments for some deprecated methods point to > non-existent methods. Patch relevant to documentation available herewith. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-955) JdbcDataSource : getARow() : Do not hardcode default type ..
[ https://issues.apache.org/jira/browse/SOLR-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated SOLR-955: - Component/s: contrib - DataImportHandler Fix Version/s: 1.4 Priority: Minor (was: Major) Affects Version/s: 1.3 > JdbcDataSource : getARow() : Do not hardcode default type .. > > > Key: SOLR-955 > URL: https://issues.apache.org/jira/browse/SOLR-955 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.3 > Environment: Java 6 , Tomcat 6 >Reporter: Kay Kay >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-955.patch > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > Patch to replace the hard-coded default type in getARow() method (instead of > 12, it should have been Types.VARCHAR ) - without affecting the semantics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-955) JdbcDataSource : getARow() : Do not hardcode default type ..
JdbcDataSource : getARow() : Do not hardcode default type .. Key: SOLR-955 URL: https://issues.apache.org/jira/browse/SOLR-955 Project: Solr Issue Type: Improvement Environment: Java 6 , Tomcat 6 Reporter: Kay Kay Attachments: SOLR-955.patch Patch to replace the hard-coded default type in getARow() method (instead of 12, it should have been Types.VARCHAR ) - without affecting the semantics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-955) JdbcDataSource : getARow() : Do not hardcode default type ..
[ https://issues.apache.org/jira/browse/SOLR-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated SOLR-955: - Attachment: SOLR-955.patch > JdbcDataSource : getARow() : Do not hardcode default type .. > > > Key: SOLR-955 > URL: https://issues.apache.org/jira/browse/SOLR-955 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.3 > Environment: Java 6 , Tomcat 6 >Reporter: Kay Kay >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-955.patch > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > Patch to replace the hard-coded default type in getARow() method (instead of > 12, it should have been Types.VARCHAR ) - without affecting the semantics. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-954) SolrQuery - better cross-referential documentation / fix inconsistent cross-reference links .
SolrQuery - better cross-referential documentation / fix inconsistent cross-reference links . - Key: SOLR-954 URL: https://issues.apache.org/jira/browse/SOLR-954 Project: Solr Issue Type: Improvement Components: documentation Affects Versions: 1.3 Environment: Tomcat 6, Java 6 Reporter: Kay Kay Priority: Minor Fix For: 1.4 Attachments: SOLR-954.patch SolrQuery methods need quite a bit of documentation as the javadoc appears to be blank at the moment and comments for some deprecated methods point to non-existent methods. Patch relevant to documentation available herewith. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-954) SolrQuery - better cross-referential documentation / fix inconsistent cross-reference links .
[ https://issues.apache.org/jira/browse/SOLR-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated SOLR-954: - Attachment: SOLR-954.patch > SolrQuery - better cross-referential documentation / fix inconsistent > cross-reference links . > - > > Key: SOLR-954 > URL: https://issues.apache.org/jira/browse/SOLR-954 > Project: Solr > Issue Type: Improvement > Components: documentation >Affects Versions: 1.3 > Environment: Tomcat 6, Java 6 >Reporter: Kay Kay >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-954.patch > > Original Estimate: 3h > Remaining Estimate: 3h > > SolrQuery methods need quite a bit of documentation as the javadoc appears to > be blank at the moment and comments for some deprecated methods point to > non-existent methods. Patch relevant to documentation available herewith. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-769) Support Document and Search Result clustering
[ https://issues.apache.org/jira/browse/SOLR-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-769: - Attachment: SOLR-769.patch Updated to trunk. See http://wiki.apache.org/solr/ClusteringComponent > Support Document and Search Result clustering > - > > Key: SOLR-769 > URL: https://issues.apache.org/jira/browse/SOLR-769 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: clustering-libs.tar, clustering-libs.tar, > SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, > SOLR-769.patch, SOLR-769.patch, SOLR-769.patch > > > Clustering is a useful tool for working with documents and search results, > similar to the notion of dynamic faceting. Carrot2 > (http://project.carrot2.org/) is a nice, BSD-licensed, library for doing > search results clustering. Mahout (http://lucene.apache.org/mahout) is well > suited for whole-corpus clustering. > The patch I lays out a contrib module that starts off w/ an integration of a > SearchComponent for doing clustering and an implementation using Carrot. In > search results mode, it will use the DocList as the input for the cluster. > While Carrot2 comes w/ a Solr input component, it is not the same as the > SearchComponent that I have in that the Carrot example actually submits a > query to Solr, whereas my SearchComponent is just chained into the Component > list and uses the ResponseBuilder to add in the cluster results. > While not fully fleshed out yet, the collection based mode will take in a > list of ids or just use the whole collection and will produce clusters. > Since this is a longer, typically offline task, there will need to be some > type of storage mechanism (and replication??) for the clusters. I _may_ > push this off to a separate JIRA issue, but I at least want to present the > use case as part of the design of this component/contrib. It may even make > sense that we split this out, such that the building piece is something like > an UpdateProcessor and then the SearchComponent just acts as a lookup > mechanism. -- 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 #682
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/682/changes Changes: [shalin] SOLR-951 -- Fixed bug in FacetComponent's refinement query generation for local params -- [...truncated 1942 lines...] [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.978 sec [junit] Running org.apache.solr.analysis.TestTrimFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.625 sec [junit] Running org.apache.solr.analysis.TestWordDelimiterFilter [junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 17.226 sec [junit] Running org.apache.solr.client.solrj.SolrExceptionTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.742 sec [junit] Running org.apache.solr.client.solrj.SolrQueryTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.585 sec [junit] Running org.apache.solr.client.solrj.beans.TestDocumentObjectBinder [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.93 sec [junit] Running org.apache.solr.client.solrj.embedded.JettyWebappTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 8.768 sec [junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeEmbeddedTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.552 sec [junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.215 sec [junit] Running org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.327 sec [junit] Running org.apache.solr.client.solrj.embedded.MultiCoreExampleJettyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.387 sec [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 8.505 sec [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleJettyTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 15.676 sec [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 19.272 sec [junit] Running org.apache.solr.client.solrj.embedded.TestSolrProperties [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.885 sec [junit] Running org.apache.solr.client.solrj.response.QueryResponseTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.596 sec [junit] Running org.apache.solr.client.solrj.response.TestSpellCheckResponse [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 6.897 sec [junit] Running org.apache.solr.client.solrj.util.ClientUtilsTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.4 sec [junit] Running org.apache.solr.common.SolrDocumentTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.44 sec [junit] Running org.apache.solr.common.params.SolrParamTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.389 sec [junit] Running org.apache.solr.common.util.ContentStreamTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.887 sec [junit] Running org.apache.solr.common.util.IteratorChainTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.412 sec [junit] Running org.apache.solr.common.util.NamedListTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.647 sec [junit] Running org.apache.solr.common.util.TestFastInputStream [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.762 sec [junit] Running org.apache.solr.common.util.TestNamedListCodec [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 1.729 sec [junit] Running org.apache.solr.common.util.TestXMLEscaping [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.553 sec [junit] Running org.apache.solr.core.AlternateDirectoryTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.091 sec [junit] Running org.apache.solr.core.RequestHandlersTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.896 sec [junit] Running org.apache.solr.core.ResourceLoaderTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.488 sec [junit] Running org.apache.solr.core.SOLR749Test [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.146 sec [junit] Running org.apache.solr.core.SolrCoreTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 11.025 sec [junit] Running org.apache.solr.core.TestArbitraryIndexDir [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.182 sec [junit] Running org.apache.solr.core.TestBadConfig [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.5 sec [junit] Running org.apache.solr.core.TestConfig [junit] Tests run: 3, Failures: 0,
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 70 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 350 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 136 source files to /tmp/apache-solr-nightly/build/tests [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. junit: [mkdir] Created dir: /tmp/apache-solr-nightly/build/test-results [junit] Running org.apache.solr.BasicFunctionalityTest [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 37.75 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 11.107 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 9.443 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 5.591 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 4.972 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 4.423 sec [junit] Running org.apache.solr.SolrInfoMBeanTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.312 sec [junit] Running org.apache.solr.TestDistributedSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 45.156 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.864 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.597 sec [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.604 sec [junit] Running org.apache.solr.analysis.HTMLStripReaderTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.824 sec [junit] Running org.apache.solr.analysis.LengthFilterTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.987 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.182 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.056 sec [junit] Running org.apache.solr.analysis.TestCharFilter [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.364 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.449 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.602 sec [junit] Running org.apache.solr.analysis.TestMappingCharFilter [junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 0.633 sec [junit] Running org.apache.solr.analysis.TestMappingCharFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.475 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.076 sec [junit] Running org.apache.solr.analysis.TestPatternTokenizerFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.67 sec [junit] Running org.apache.solr.analysis.TestPhoneticFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.74 sec [junit] Running org.apache.solr.analysis.TestRemoveDuplicatesTokenFilter [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.905 sec [junit] Running org.apache.solr.analysis.TestSynonymFilter [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 2.137 sec [junit] Running org.apache.solr.analysis.TestSyn
