Re: Efficient Query Evaluation using a Two-Level Retrieval Process

[Shalin Shekhar Mangar]

Hey Joaquin,

The mailing list strips off attachments. Can you please upload it somewhere
and give us the link?

On Mon, Nov 16, 2009 at 12:35 PM, J. Delgado wrote:

> Please find attached the paper on "Efficient Query Evaluation using a
> Two-Level Retrieval Process". I believe that such approach may improve the
> way Lucene/Solr evaluates queries today.
>
> Cheers,
>
> -- Joaquin
>



-- 
Regards,
Shalin Shekhar Mangar.

Efficient Query Evaluation using a Two-Level Retrieval Process

[J. Delgado]

Please find attached the paper on "Efficient Query Evaluation using a
Two-Level Retrieval Process". I believe that such approach may improve the
way Lucene/Solr evaluates queries today.

Cheers,

-- Joaquin

Re: Functions as Filters

[Grant Ingersoll]

On Nov 15, 2009, at 5:07 PM, Yonik Seeley wrote:

> On Sat, Nov 14, 2009 at 2:30 PM, Grant Ingersoll  wrote:
>> Is it at all meaningful to think about a function query acting as a Filter?  
>> The basic idea being that if the score was above/below some value 
>> (presumably 0 by default), then that particular document would be on/off.
> 
> frange?
> 
> http://www.lucidimagination.com/blog/tag/frange/

This might have legs...  In combination with the new Distance functions I 
committed yesterday:

http://localhost:8983/solr/select/?q=*:*&fq={!frange%20l=0%20u=5}dist%282,%2032,%20-80,%20lat,%20lon%29

As I see it, I can now filter, boost and sort (using the ^0 workaround) by 
distance using Function queries.  I've only tested on a small index so far (68K 
geo-locations), but will try to use something bigger once I get it indexed.  

-Grant

Re: [Solr Wiki] Update of "FunctionQuery" by GrantIngersoll

[Yonik Seeley]

Let's all try to summarize changes to the wiki as we would changes to
the code - without that it's tough to tell what the changes are.

In this particular case, I'm not sure if all of the formatting changes
were deliberate or accidental.  If accidental, I wonder if the cause
was a bug in GUI mode, or a bug in your browser?

-Yonik
http://www.lucidimagination.com



On Sat, Nov 14, 2009 at 9:05 AM, Apache Wiki  wrote:
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Solr Wiki" for change 
> notification.
>
> The "FunctionQuery" page has been changed by GrantIngersoll.
> http://wiki.apache.org/solr/FunctionQuery?action=diff&rev1=29&rev2=30
>
> --
>
> - FunctionQuery allows one to use the actual value of a numeric field and 
> functions of those fields in a relevancy score.
> + FunctionQuery allows one to use the actual value of a numeric field and 
> functions of those fields in a relevancy score.
>
>  <>
>
>  = Using FunctionQuery =
>  There are a few ways to use FunctionQuery from Solr's HTTP interface:
> +
>   1. Embed a FunctionQuery in a regular query expressed in SolrQuerySyntax 
> via the _val_ hook
>   1. Use the FunctionQParserPlugin, ie: {{{q={!func}log(foo)}}}
>   1. Use a parameter that has an explicit type of FunctionQuery, such as 
> DisMaxRequestHandler's '''bf''' (boost function) parameter.
> -     * NOTE: the '''bf''' parameter actually takes a list of function 
> queries separated by whitespace and each with an optional boost.  Make sure 
> to eliminate any internal whitespace in single function queries when using 
> '''bf'''.
> +   * NOTE: the '''bf''' parameter actually takes a list of function queries 
> separated by whitespace and each with an optional boost.  Make sure to 
> eliminate any internal whitespace in single function queries when using 
> '''bf'''.
> -     * Example: {{{q=foo&bf="ord(popularity)^0.5 
> recip(rord(price),1,1000,1000)^0.3"}}}
> +   * Example: {{{q=foo&bf="ord(popularity)^0.5 
> recip(rord(price),1,1000,1000)^0.3"}}}
>
>  See SolrPlugins#ValueSourceParser for information on how to hook in your own 
> FunctionQuery.
>
> @@ -20, +21 @@
>
>  There is currently no infix parser - functions must be expressed as function 
> calls (e.g. sum(a,b) instead of a+b)
>
>  = Available Functions =
> -
>  == constant ==
> -  [[Solr1.3]]
> - Floating point constants.
> +  [[Solr1.3]] Floating point constants.
> +
> -     Example Syntax: '''1.5'''
> +  . Example Syntax: '''1.5'''
> -
> -     SolrQuerySyntax Example: '''_val_:1.5'''
> +  SolrQuerySyntax Example: '''_val_:1.5'''
>
>  == fieldvalue ==
>  This function returns the numeric field value of an indexed field with a 
> maximum of one value per document (not multiValued).  The syntax is simply 
> the field name by itself.  0 is returned for documents without a value in the 
> field.
> +
> -     Example Syntax: '''myFloatField'''
> +  . Example Syntax: '''myFloatField'''
> -
> -     SolrQuerySyntax Example: '''_val_:myFloatField'''
> +  SolrQuerySyntax Example: '''_val_:myFloatField'''
>
>  == ord ==
>  ord(myfield) returns the ordinal of the indexed field value within the 
> indexed list of terms for that field in lucene index order (lexicographically 
> ordered by unicode value), starting at 1. In other words, for a given field, 
> all values are ordered lexicographically; this function then returns the 
> offset of a particular value in that ordering. The field must have a maximum 
> of one value per document (not multiValued).  0 is returned for documents 
> without a value in the field.
> +
> -    Example: If there were only three values for a particular field: 
> "apple","banana","pear", then ord("apple")=1, ord("banana")=2, ord("pear")=3
> +  . Example: If there were only three values for a particular field: 
> "apple","banana","pear", then ord("apple")=1, ord("banana")=2, ord("pear")=3
> -
> -    Example Syntax: '''ord(myIndexedField)'''
> +  Example Syntax: '''ord(myIndexedField)'''
> -
> -    Example SolrQuerySyntax: '''_val_:"ord(myIndexedField)"'''
> +  Example SolrQuerySyntax: '''_val_:"ord(myIndexedField)"'''
>
> + WARNING: as of Solr 1.4, ord() and rord() can cause excess memory use since 
> they must use a FieldCache entry at the top level reader, while sorting and 
> function queries now use entries at the segment level.  Hence sorting or 
> using a different function query, in addition to ord()/rord() will double 
> memory use.
> - WARNING: as of Solr 1.4, ord() and rord() can cause excess memory use since 
> they must use a FieldCache entry
> - at the top level reader, while sorting and function queries now use entries 
> at the segment level.  Hence sorting
> - or using a different function query, in addition to ord()/rord() will 
> double memory use.
> -
>
>  WARNING: ord() depends on the position in an index and can thus change when 
> other documents are inserted or deleted, or if a !MultiSearcher is used.
>
>  == rord ==
>  Th

Re: Functions as Filters

[Yonik Seeley]

On Sat, Nov 14, 2009 at 2:30 PM, Grant Ingersoll  wrote:
> Is it at all meaningful to think about a function query acting as a Filter?  
> The basic idea being that if the score was above/below some value (presumably 
> 0 by default), then that particular document would be on/off.

frange?

http://www.lucidimagination.com/blog/tag/frange/

-Yonik
http://www.lucidimagination.com

[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr

[Bill Bell (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778182#action_12778182
 ] 

Bill Bell commented on SOLR-773:


Patrick,

Now that 1.4 is out, what are we looking at to get your LOCALSOLR to work with 
it?

Thanks in advance.



> Incorporate Local Lucene/Solr
> -
>
> Key: SOLR-773
> URL: https://issues.apache.org/jira/browse/SOLR-773
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, 
> lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
> SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
> SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, 
> SOLR-773.patch, solrGeoQuery.tar, spatial-solr.tar.gz
>
>
> Local Lucene has been donated to the Lucene project.  It has some Solr 
> components, but we should evaluate how best to incorporate it into Solr.
> See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-236) Field collapsing

[Martijn van Groningen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martijn van Groningen updated SOLR-236:
---

Attachment: field-collapse-5.patch

I have attached a new patch, that incorporates Micheal's quasi distributed 
patch so you don't have to patch twice. In addition to that the new patch also 
merges the collapse_count data from each individual shard response. When using 
this patch you will still need to make sure that all documents of one collapse 
group stay on one shard, otherwise your collapse result will be incorrect. The 
documents of a different collapse group can stay on a different shard.  

> 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-5.patch, field-collapse-5.patch, 
> field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, 
> field-collapse-5.patch, field-collapse-5.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, quasidistributed.additional.patch, 
> 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-1316) Create autosuggest component

[Ankul Garg (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778167#action_12778167
 ] 

Ankul Garg commented on SOLR-1316:
--

Nice work Andrzej!!! There's a little problem with insertion of tokens in build 
function of TSTLookup class. Strings in HighFrequencyDictionary must be in 
sorted order and simply iterating over the dict and adding strings in sorted 
order in TST will make the tree highly unbalanced. An ordered insertion of 
strings in the same way as one does a binary search over a sorted list will 
make the tree balanced. The function balancedTree of TSTAutocomplete class 
takes care of that.

> 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
>
> Attachments: suggest.patch, suggest.patch, TST.zip
>
>   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-236) Field collapsing

[Martijn van Groningen (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778147#action_12778147
 ] 

Martijn van Groningen commented on SOLR-236:


What kind of exception is occurring if you use dismax (with and without field 
collapsing)? If I do a collapse search with dismax in the example setup 
(http://localhost:8983/solr/select/?q=power&collapse.field=inStock&qt=dismax) 
field collapsing appears to be working. 

> 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-5.patch, field-collapse-5.patch, 
> field-collapse-5.patch, field-collapse-5.patch, field-collapse-5.patch, 
> field-collapse-5.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, 
> quasidistributed.additional.patch, 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-1485) PayloadTermQuery support

[david (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778095#action_12778095
 ] 

david commented on SOLR-1485:
-

Hi,
What if I want to do a boolean query?
like: payoladField:steve OR NonPayloadField:George ?

Won't the payload plugin be used for all the query parts?

> PayloadTermQuery support
> 
>
> Key: SOLR-1485
> URL: https://issues.apache.org/jira/browse/SOLR-1485
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Erik Hatcher
> Attachments: PayloadTermQueryPlugin.java
>
>
> Solr currently has no support for Lucene's PayloadTermQuery, yet it has 
> support for indexing payloads. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1564) payload plugin does not load on standard solr 1.4.0 distribution

[david (JIRA)]

payload plugin does not load on standard solr 1.4.0 distribution 
-

 Key: SOLR-1564
 URL: https://issues.apache.org/jira/browse/SOLR-1564
 Project: Solr
  Issue Type: Bug
  Components: Analysis
Affects Versions: 1.4
 Environment: windows 2008 server jdk 1.6 update 14, tomcat 6 64 bit + 
4 gigs ram machine
Reporter: david


Hi,
I have succeeded running and querying with PayloadTermQueryPlugin, 
When I ran my test against an embedded solrj server it ran fine, Im using maven 
solr 1.4 artifacts.
When I deployed it into my servlet container the plugin didn't load, the war in 
the servlet container came from a standard Solr 1.4 downloaded tar.gz
When I changed the jar in the WEB-INF/lib folder to the jars from the maven 
repository, the plugin loaded.
Just need to synch the distibution with the maven repositories

-- 
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 #985

[Apache Hudson Server]

See 

Changes:

[gsingers] SOLR-1302: Implemented Haversine, plus Euclidean, Manhattan 
distances (p-norms) plus deg, rad functions

--
[...truncated 2219 lines...]
[junit] Running org.apache.solr.client.solrj.SolrQueryTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.398 sec
[junit] Running org.apache.solr.client.solrj.TestBatchUpdate
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 20.603 sec
[junit] Running org.apache.solr.client.solrj.TestLBHttpSolrServer
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 16.866 sec
[junit] Running org.apache.solr.client.solrj.beans.TestDocumentObjectBinder
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.783 sec
[junit] Running org.apache.solr.client.solrj.embedded.JettyWebappTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 10.828 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 14.439 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.LargeVolumeEmbeddedTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.629 sec
[junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 17.603 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.MergeIndexesEmbeddedTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 8.899 sec
[junit] Running org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.641 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.MultiCoreExampleJettyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.798 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 33.08 sec
[junit] Running org.apache.solr.client.solrj.embedded.SolrExampleJettyTest
[junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 42.025 sec
[junit] Running 
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 49.915 sec
[junit] Running org.apache.solr.client.solrj.embedded.TestSolrProperties
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 8.669 sec
[junit] Running org.apache.solr.client.solrj.request.TestUpdateRequestCodec
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.427 sec
[junit] Running 
org.apache.solr.client.solrj.response.AnlysisResponseBaseTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.566 sec
[junit] Running 
org.apache.solr.client.solrj.response.DocumentAnalysisResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.471 sec
[junit] Running 
org.apache.solr.client.solrj.response.FieldAnalysisResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.431 sec
[junit] Running org.apache.solr.client.solrj.response.QueryResponseTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.537 sec
[junit] Running org.apache.solr.client.solrj.response.TestSpellCheckResponse
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 19.547 sec
[junit] Running org.apache.solr.client.solrj.util.ClientUtilsTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.45 sec
[junit] Running org.apache.solr.common.SolrDocumentTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.486 sec
[junit] Running org.apache.solr.common.params.ModifiableSolrParamsTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.379 sec
[junit] Running org.apache.solr.common.params.SolrParamTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.425 sec
[junit] Running org.apache.solr.common.util.ContentStreamTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.602 sec
[junit] Running org.apache.solr.common.util.DOMUtilTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.457 sec
[junit] Running org.apache.solr.common.util.FileUtilsTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.395 sec
[junit] Running org.apache.solr.common.util.IteratorChainTest
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.37 sec
[junit] Running org.apache.solr.common.util.NamedListTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.37 sec
[junit] Running org.apache.solr.common.util.TestFastInputStream
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.464 sec
[junit] Running org.apache.solr.common.util.TestHash
[junit] Tests run: 2, Failures: 0, Errors: 0, Tim