Hudson build is back to normal : Lucene-Solr-tests-only-trunk #12

[Apache Hudson Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Created: (LUCENE-2700) Expose DocValues via Fields

[Simon Willnauer (JIRA)]

Expose DocValues via Fields
---

 Key: LUCENE-2700
 URL: https://issues.apache.org/jira/browse/LUCENE-2700
 Project: Lucene - Java
  Issue Type: New Feature
  Components: Index
Reporter: Simon Willnauer
Assignee: Simon Willnauer
 Fix For: CSF branch


DocValues Reader are currently exposed / accessed directly via IndexReader. To 
integrate the new feature in a more "native" way we should expose the DocValues 
via Fields on a perSegment level and on MultiFields in the multi reader case. 
DocValues should be side by side with Fields.terms  enabling access to Source, 
SortedSource and ValuesEnum something like that:

{code}
public abstract class Fields {
...

  public DocValues values();

}

public abstract class DocValues {
  /** on disk enum based API */
  public abstract ValuesEnum getEnum() throws IOException;
  /** in memory Random Access API - with enum support - first call loads values 
in ram*/
  public abstract Source getSource() throws IOException;
  /** sorted in memory Random Access API - optional operation */
  public SortedSource getSortedSource(Comparator comparator) throws 
IOException, UnsupportedOperationException;
  /** unloads previously loaded source only but keeps the doc values open */
  public abstract unload();
  /** closes the doc values */
  public abstract close();
}
{code}



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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Hudson build is back to normal : Lucene-Solr-tests-only-3.x #9

[Apache Hudson Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Build failed in Hudson: Lucene-Solr-tests-only-trunk #11

[Apache Hudson Server]

See 

--
[...truncated 8912 lines...]
[junit] at 
org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:392)
[junit] at 
org.apache.solr.handler.dataimport.DataImportHandler.handleRequestBody(DataImportHandler.java:203)
[junit] at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
[junit] at org.apache.solr.core.SolrCore.execute(SolrCore.java:1324)
[junit] at 
org.apache.solr.util.TestHarness.queryAndResponse(TestHarness.java:334)
[junit] at org.apache.solr.util.TestHarness.query(TestHarness.java:321)
[junit] at 
org.apache.solr.handler.dataimport.AbstractDataImportHandlerTestCase.runFullImport(AbstractDataImportHandlerTestCase.java:108)
[junit] at 
org.apache.solr.handler.dataimport.TestDocBuilder2.testFileListEntityProcessor_lastIndexTime(TestDocBuilder2.java:245)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit] at java.lang.reflect.Method.invoke(Method.java:616)
[junit] at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
[junit] at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
[junit] at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
[junit] at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
[junit] at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
[junit] at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
[junit] at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
[junit] at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:795)
[junit] at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:768)
[junit] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
[junit] at 
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
[junit] at 
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
[junit] at 
org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
[junit] at 
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
[junit] at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
[junit] at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
[junit] at 
junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
[junit] Caused by: java.text.ParseException: Unparseable date: "1970-01-01 
01:00:00"
[junit] at java.text.DateFormat.parse(DateFormat.java:354)
[junit] at 
org.apache.solr.handler.dataimport.FileListEntityProcessor.getDate(FileListEntityProcessor.java:165)
[junit] ... 40 more
[junit] 13/10/2010 01:33:36 ? 
org.apache.solr.handler.dataimport.DataImporter doFullImport
[junit] SEVERE: Full Import failed
[junit] org.apache.solr.handler.dataimport.DataImportHandlerException: 
Invalid expression for date Processing Document # 1
[junit] at 
org.apache.solr.handler.dataimport.FileListEntityProcessor.getDate(FileListEntityProcessor.java:167)
[junit] at 
org.apache.solr.handler.dataimport.FileListEntityProcessor.nextRow(FileListEntityProcessor.java:204)
[junit] at 
org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:233)
[junit] at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:579)
[junit] at 
org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:260)
[junit] at 
org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:184)
[junit] at 
org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:334)
[junit] at 
org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:392)
[junit] at 
org.apache.solr.handler.dataimport.DataImportHandler.handleRequestB

Build failed in Hudson: Lucene-Solr-tests-only-3.x #8

[Apache Hudson Server]

See 

--
[...truncated 9769 lines...]
[junit] at 
org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:392)
[junit] at 
org.apache.solr.handler.dataimport.DataImportHandler.handleRequestBody(DataImportHandler.java:203)
[junit] at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
[junit] at org.apache.solr.core.SolrCore.execute(SolrCore.java:1322)
[junit] at 
org.apache.solr.util.TestHarness.queryAndResponse(TestHarness.java:334)
[junit] at org.apache.solr.util.TestHarness.query(TestHarness.java:321)
[junit] at 
org.apache.solr.handler.dataimport.AbstractDataImportHandlerTestCase.runFullImport(AbstractDataImportHandlerTestCase.java:108)
[junit] at 
org.apache.solr.handler.dataimport.TestDocBuilder2.testFileListEntityProcessor_lastIndexTime(TestDocBuilder2.java:245)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit] at java.lang.reflect.Method.invoke(Method.java:616)
[junit] at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
[junit] at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
[junit] at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
[junit] at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
[junit] at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48)
[junit] at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
[junit] at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
[junit] at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:693)
[junit] at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:666)
[junit] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
[junit] at 
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
[junit] at 
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
[junit] at 
org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
[junit] at 
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
[junit] at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
[junit] at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
[junit] at 
junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743)
[junit] Caused by: java.text.ParseException: Unparseable date: "1970-01-01 
01:00:00"
[junit] at java.text.DateFormat.parse(DateFormat.java:354)
[junit] at 
org.apache.solr.handler.dataimport.FileListEntityProcessor.getDate(FileListEntityProcessor.java:165)
[junit] ... 40 more
[junit] Oct 13, 2010 8:11:44 AM 
org.apache.solr.handler.dataimport.DataImporter doFullImport
[junit] SEVERE: Full Import failed
[junit] org.apache.solr.handler.dataimport.DataImportHandlerException: 
Invalid expression for date Processing Document # 1
[junit] at 
org.apache.solr.handler.dataimport.FileListEntityProcessor.getDate(FileListEntityProcessor.java:167)
[junit] at 
org.apache.solr.handler.dataimport.FileListEntityProcessor.nextRow(FileListEntityProcessor.java:204)
[junit] at 
org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:233)
[junit] at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:579)
[junit] at 
org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:260)
[junit] at 
org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:184)
[junit] at 
org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:334)
[junit] at 
org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:392)
[junit] at 
org.apache.solr.handler.dataimport.DataImportHandler.handleRequestBo

[jira] Updated: (LUCENE-2699) Update StandardTokenizer and UAX29Tokenizer to Unicode 6.0.0

[Steven Rowe (JIRA)]

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

Steven Rowe updated LUCENE-2699:


Attachment: LUCENE-2699.patch

Patch upgrading UAX#29-based tokenizers to Unicode 6.0.0.

> Update StandardTokenizer and UAX29Tokenizer to Unicode 6.0.0
> 
>
> Key: LUCENE-2699
> URL: https://issues.apache.org/jira/browse/LUCENE-2699
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: contrib/analyzers
>Affects Versions: 3.1, 4.0
>Reporter: Steven Rowe
>Assignee: Steven Rowe
>Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2699.patch
>
>
> Newly released Unicode 6.0.0 contains some character property changes from 
> the previous release (5.2.0) that affect word segmentation (UAX#29), and 
> JFlex 1.5.0-SNAPSHOT now supports Unicode 6.0.0, so Lucene's UAX#29-based 
> tokenizers should be updated accordingly.
> Note that the UAX#29 word break rules themselves did not change between 
> Unicode versions 5.2.0 and 6.0.0.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Created: (LUCENE-2699) Update StandardTokenizer and UAX29Tokenizer to Unicode 6.0.0

[Steven Rowe (JIRA)]

Update StandardTokenizer and UAX29Tokenizer to Unicode 6.0.0


 Key: LUCENE-2699
 URL: https://issues.apache.org/jira/browse/LUCENE-2699
 Project: Lucene - Java
  Issue Type: Improvement
  Components: contrib/analyzers
Affects Versions: 3.1, 4.0
Reporter: Steven Rowe
Assignee: Steven Rowe
Priority: Minor
 Fix For: 3.1, 4.0


Newly released Unicode 6.0.0 contains some character property changes from the 
previous release (5.2.0) that affect word segmentation (UAX#29), and JFlex 
1.5.0-SNAPSHOT now supports Unicode 6.0.0, so Lucene's UAX#29-based tokenizers 
should be updated accordingly.

Note that the UAX#29 word break rules themselves did not change between Unicode 
versions 5.2.0 and 6.0.0.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Commented: (SOLR-2155) Geospatial search using geohash prefixes

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-2155:


My next step is to measure performance, perhaps using Lucene's benchmark 
contrib module with some as yet unidentified source of lat-lons.  I then can 
due some tuning.  I've identified several areas for improvement I will tackle, 
most notably indexing geohashes at all character lengths thereby enabling an 
algorithm that can do faster queries that cover many points.  I've heard others 
call this "geospatial tiers" which is in effect what I'll be doing.  I'll also 
add a PolygonGeoShape.


> Geospatial search using geohash prefixes
> 
>
> Key: SOLR-2155
> URL: https://issues.apache.org/jira/browse/SOLR-2155
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
> Attachments: GeoHashPrefixFilter.patch
>
>
> There currently isn't a solution in Solr for doing geospatial filtering on 
> documents that have a variable number of points.  This scenario occurs when 
> there is location extraction (i.e. via a "gazateer") occurring on free text.  
> None, one, or many geospatial locations might be extracted from any given 
> document and users want to limit their search results to those occurring in a 
> user-specified area.
> I've implemented this by furthering the GeoHash based work in Lucene/Solr 
> with a geohash prefix based filter.  A geohash refers to a lat-lon box on the 
> earth.  Each successive character added further subdivides the box into a 4x8 
> (or 8x4 depending on the even/odd length of the geohash) grid.  The first 
> step in this scheme is figuring out which geohash grid squares cover the 
> user's search query.  I've added various extra methods to GeoHashUtils (and 
> added tests) to assist in this purpose.  The next step is an actual Lucene 
> Filter, GeoHashPrefixFilter, that uses these geohash prefixes in 
> TermsEnum.seek() to skip to relevant grid squares in the index.  Once a 
> matching geohash grid is found, the points therein are compared against the 
> user's query to see if it matches.  I created an abstraction GeoShape 
> extended by subclasses named PointDistance... and CartesianBox to support 
> different queried shapes so that the filter need not care about these details.
> This work was presented at LuceneRevolution in Boston on October 8th.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Updated: (SOLR-2155) Geospatial search using geohash prefixes

[David Smiley (JIRA)]

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

David Smiley updated SOLR-2155:
---

Attachment: GeoHashPrefixFilter.patch

This attached patch is tested, both at the GeoHashUtils level and via 
SpatialFilterTest.  I added tests to both of these.  I added ASF headers.

> Geospatial search using geohash prefixes
> 
>
> Key: SOLR-2155
> URL: https://issues.apache.org/jira/browse/SOLR-2155
> Project: Solr
>  Issue Type: Improvement
>Reporter: David Smiley
> Attachments: GeoHashPrefixFilter.patch
>
>
> There currently isn't a solution in Solr for doing geospatial filtering on 
> documents that have a variable number of points.  This scenario occurs when 
> there is location extraction (i.e. via a "gazateer") occurring on free text.  
> None, one, or many geospatial locations might be extracted from any given 
> document and users want to limit their search results to those occurring in a 
> user-specified area.
> I've implemented this by furthering the GeoHash based work in Lucene/Solr 
> with a geohash prefix based filter.  A geohash refers to a lat-lon box on the 
> earth.  Each successive character added further subdivides the box into a 4x8 
> (or 8x4 depending on the even/odd length of the geohash) grid.  The first 
> step in this scheme is figuring out which geohash grid squares cover the 
> user's search query.  I've added various extra methods to GeoHashUtils (and 
> added tests) to assist in this purpose.  The next step is an actual Lucene 
> Filter, GeoHashPrefixFilter, that uses these geohash prefixes in 
> TermsEnum.seek() to skip to relevant grid squares in the index.  Once a 
> matching geohash grid is found, the points therein are compared against the 
> user's query to see if it matches.  I created an abstraction GeoShape 
> extended by subclasses named PointDistance... and CartesianBox to support 
> different queried shapes so that the filter need not care about these details.
> This work was presented at LuceneRevolution in Boston on October 8th.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Created: (SOLR-2155) Geospatial search using geohash prefixes

[David Smiley (JIRA)]

Geospatial search using geohash prefixes


 Key: SOLR-2155
 URL: https://issues.apache.org/jira/browse/SOLR-2155
 Project: Solr
  Issue Type: Improvement
Reporter: David Smiley


There currently isn't a solution in Solr for doing geospatial filtering on 
documents that have a variable number of points.  This scenario occurs when 
there is location extraction (i.e. via a "gazateer") occurring on free text.  
None, one, or many geospatial locations might be extracted from any given 
document and users want to limit their search results to those occurring in a 
user-specified area.

I've implemented this by furthering the GeoHash based work in Lucene/Solr with 
a geohash prefix based filter.  A geohash refers to a lat-lon box on the earth. 
 Each successive character added further subdivides the box into a 4x8 (or 8x4 
depending on the even/odd length of the geohash) grid.  The first step in this 
scheme is figuring out which geohash grid squares cover the user's search 
query.  I've added various extra methods to GeoHashUtils (and added tests) to 
assist in this purpose.  The next step is an actual Lucene Filter, 
GeoHashPrefixFilter, that uses these geohash prefixes in TermsEnum.seek() to 
skip to relevant grid squares in the index.  Once a matching geohash grid is 
found, the points therein are compared against the user's query to see if it 
matches.  I created an abstraction GeoShape extended by subclasses named 
PointDistance... and CartesianBox to support different queried shapes so 
that the filter need not care about these details.

This work was presented at LuceneRevolution in Boston on October 8th.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Build failed in Hudson: Lucene-3.x #146

[Apache Hudson Server]

See 

Changes:

[rmuir] merge improvements to TestLBHttpSolrServer from trunk

[uschindler] enable parallel tests for hourly tests

[uschindler] add correct solr tests xml formatting

[uschindler] build also contrib with 1.5

[uschindler] again...

[uschindler] fix dirs :(

[uschindler] update some dir configs

[uschindler] add a general test-only target for Lucene+Solr that can be run all 
the time

--
[...truncated 20142 lines...]
[junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.732 sec
[junit] 
[junit] - Standard Output ---
[junit] 
[junit] Spans Dump --
[junit] payloads for span:2
[junit] doc:0 s:3 e:6 three:Noise:5
[junit] doc:0 s:3 e:6 one:Entity:3
[junit] 
[junit] Spans Dump --
[junit] payloads for span:3
[junit] doc:0 s:0 e:3 yy:Noise:2
[junit] doc:0 s:0 e:3 rr:Noise:1
[junit] doc:0 s:0 e:3 xx:Entity:0
[junit] 
[junit] Spans Dump --
[junit] payloads for span:3
[junit] doc:1 s:0 e:4 yy:Noise:1
[junit] doc:1 s:0 e:4 xx:Entity:0
[junit] doc:1 s:0 e:4 rr:Noise:3
[junit] 
[junit] Spans Dump --
[junit] payloads for span:3
[junit] doc:0 s:0 e:3 rr:Noise:1
[junit] doc:0 s:0 e:3 xx:Entity:0
[junit] doc:0 s:0 e:3 yy:Noise:2
[junit] 
[junit] Spans Dump --
[junit] payloads for span:3
[junit] doc:0 s:0 e:3 xx:Entity:0
[junit] doc:0 s:0 e:3 rr:Noise:1
[junit] doc:0 s:0 e:3 yy:Noise:2
[junit] 
[junit] Spans Dump --
[junit] payloads for span:3
[junit] doc:1 s:0 e:4 yy:Noise:1
[junit] doc:1 s:0 e:4 xx:Entity:0
[junit] doc:1 s:0 e:4 rr:Noise:3
[junit] 
[junit] Spans Dump --
[junit] payloads for span:3
[junit] doc:2 s:0 e:5 ss:Noise:2
[junit] doc:2 s:0 e:5 qq:Noise:1
[junit] doc:2 s:0 e:5 pp:Noise:3
[junit] 
[junit] Spans Dump --
[junit] payloads for span:8
[junit] doc:3 s:0 e:11 nine:Noise:8
[junit] doc:3 s:0 e:11 five:Noise:4
[junit] doc:3 s:0 e:11 one:Entity:0
[junit] doc:3 s:0 e:11 eleven:Noise:10
[junit] doc:3 s:0 e:11 three:Noise:2
[junit] doc:3 s:0 e:11 ten:Noise:9
[junit] doc:3 s:0 e:11 six:Noise:5
[junit] doc:3 s:0 e:11 two:Noise:1
[junit] 
[junit] Spans Dump --
[junit] payloads for span:8
[junit] doc:4 s:0 e:11 six:Noise:6
[junit] doc:4 s:0 e:11 eleven:Noise:9
[junit] doc:4 s:0 e:11 ten:Noise:10
[junit] doc:4 s:0 e:11 three:Noise:3
[junit] doc:4 s:0 e:11 one:Entity:1
[junit] doc:4 s:0 e:11 two:Noise:2
[junit] doc:4 s:0 e:11 nine:Noise:0
[junit] doc:4 s:0 e:11 five:Noise:5
[junit] match:k:Noise:11
[junit] match:a:Noise:10
[junit] Num payloads:1
[junit] rr:Noise:1
[junit] -  ---
[junit] Testsuite: org.apache.lucene.search.spans.TestSpanExplanations
[junit] Tests run: 31, Failures: 0, Errors: 0, Time elapsed: 0.693 sec
[junit] 
[junit] Testsuite: 
org.apache.lucene.search.spans.TestSpanExplanationsOfNonMatches
[junit] Tests run: 31, Failures: 0, Errors: 0, Time elapsed: 0.029 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.spans.TestSpans
[junit] Tests run: 25, Failures: 0, Errors: 0, Time elapsed: 0.256 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.spans.TestSpansAdvanced
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.02 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.spans.TestSpansAdvanced2
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.055 sec
[junit] 
[junit] Testsuite: org.apache.lucene.store.TestBufferedIndexInput
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 1.799 sec
[junit] 
[junit] Testsuite: org.apache.lucene.store.TestDirectory
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.014 sec
[junit] 
[junit] Testsuite: org.apache.lucene.store.TestFileSwitchDirectory
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.015 sec
[junit] 
[junit] Testsuite: org.apache.lucene.store.TestHugeRamFile
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 7.141 sec
[junit] 
[junit] Testsuite: org.apache.lucene.store.TestLock
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.013 sec
[junit] 
[junit] Testsuite: org.apache.lucene.store.TestLockFactory
[junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 3.163 sec
[junit] 
[junit] Testsuite: org.apache.lucene.store.TestRAMDirectory
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.27 sec
[junit] 
[junit] Testsuite: org.apache.lucene.store.TestWindowsMMap
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.051 sec
[junit] 
[junit] Testsuite: org.apache.lucene.util.ArrayUtilTest
[junit] Tests run: 1, Failures: 0, Err

[jira] Commented: (SOLR-2002) improve build/tests

[Robert Muir (JIRA)]

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

Robert Muir commented on SOLR-2002:
---

Committed to trunk (revision 1021969). Also set the connect-timeout to 1s in 
1021971.

Merged both to 3x in revision 1021972.

Sorry for the heavy committing, but this test was unreliable *and* took 15 
minutes on hudson!

> improve build/tests
> ---
>
> Key: SOLR-2002
> URL: https://issues.apache.org/jira/browse/SOLR-2002
> Project: Solr
>  Issue Type: Task
>  Components: Build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: SOLR-2002.patch, SOLR-2002_core_contrib.patch, 
> SOLR-2002_lbhttpsolrserver.patch, SOLR-2002_localization.patch, 
> SOLR-2002_lucenetestcase.patch, SOLR-2002_merged.patch, 
> SOLR-2002_merged.patch, SOLR-2002_merged.patch, SOLR-2002_merged.patch, 
> SOLR-2002_replication.patch, SOLR-2002_testiter.patch, 
> SOLR-2002_testmethod.patch, SOLR-2002_timeout.patch, 
> SOLR-2002setupteardown.patch
>
>
> we are working on improving some functionality in lucene's build/tests, it 
> would be good to improve the solr side to take advantage of it.
> currently its only sorta-kinda integrated and a bit messy.
> i'd like to do some incremental improvements piece-by-piece on this issue.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Hudson build is back to normal : Lucene-Solr-tests-only-3.x #2

[Apache Hudson Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Updated: (SOLR-2002) improve build/tests

[Robert Muir (JIRA)]

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

Robert Muir updated SOLR-2002:
--

Attachment: SOLR-2002_lbhttpsolrserver.patch

The TestLBHttpSolrServer is quite unreliable, especially with hudson builds.
this is because it shutsdown a jetty on port X then restarts it on the same 
port again...

attached is a patch that sets SO_REUSEADDR when running tests.

> improve build/tests
> ---
>
> Key: SOLR-2002
> URL: https://issues.apache.org/jira/browse/SOLR-2002
> Project: Solr
>  Issue Type: Task
>  Components: Build
>Reporter: Robert Muir
>Assignee: Robert Muir
>Priority: Minor
> Fix For: 3.1, 4.0
>
> Attachments: SOLR-2002.patch, SOLR-2002_core_contrib.patch, 
> SOLR-2002_lbhttpsolrserver.patch, SOLR-2002_localization.patch, 
> SOLR-2002_lucenetestcase.patch, SOLR-2002_merged.patch, 
> SOLR-2002_merged.patch, SOLR-2002_merged.patch, SOLR-2002_merged.patch, 
> SOLR-2002_replication.patch, SOLR-2002_testiter.patch, 
> SOLR-2002_testmethod.patch, SOLR-2002_timeout.patch, 
> SOLR-2002setupteardown.patch
>
>
> we are working on improving some functionality in lucene's build/tests, it 
> would be good to improve the solr side to take advantage of it.
> currently its only sorta-kinda integrated and a bit messy.
> i'd like to do some incremental improvements piece-by-piece on this issue.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-2312) Search on IndexWriter's RAM Buffer

[Jason Rutherglen (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920408#action_12920408
 ] 

Jason Rutherglen commented on LUCENE-2312:
--

An interesting question for this issue is how will norms be handled?  It's an 
issue because norms requires the total number of terms, which we can compute 
per reader, however as we add readers, we can easily generate too much garbage 
(ie, a new norms byte[] per field per reader).  Perhaps we can relax the 
accuracy of the calculation for RT?



> Search on IndexWriter's RAM Buffer
> --
>
> Key: LUCENE-2312
> URL: https://issues.apache.org/jira/browse/LUCENE-2312
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: Search
>Affects Versions: Realtime Branch
>Reporter: Jason Rutherglen
>Assignee: Michael Busch
> Fix For: Realtime Branch
>
>
> In order to offer user's near realtime search, without incurring
> an indexing performance penalty, we can implement search on
> IndexWriter's RAM buffer. This is the buffer that is filled in
> RAM as documents are indexed. Currently the RAM buffer is
> flushed to the underlying directory (usually disk) before being
> made searchable. 
> Todays Lucene based NRT systems must incur the cost of merging
> segments, which can slow indexing. 
> Michael Busch has good suggestions regarding how to handle deletes using max 
> doc ids.  
> https://issues.apache.org/jira/browse/LUCENE-2293?focusedCommentId=12841923&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12841923
> The area that isn't fully fleshed out is the terms dictionary,
> which needs to be sorted prior to queries executing. Currently
> IW implements a specialized hash table. Michael B has a
> suggestion here: 
> https://issues.apache.org/jira/browse/LUCENE-2293?focusedCommentId=12841915&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12841915

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Commented: (SOLR-2153) useFastVectorHighlighter does not respect hl.simple.pre/post

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi commented on SOLR-2153:
--

bq. is it out there somewhere?

Hmm, it should be at Solr wiki, but no. 

> useFastVectorHighlighter does not respect  hl.simple.pre/post
> -
>
> Key: SOLR-2153
> URL: https://issues.apache.org/jira/browse/SOLR-2153
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 3.1
> Environment: Oct 8 3.1 built from SVN, tomcat6 + solaris
>Reporter: Trey Hyde
>
> The highlighter is returning em's instead of the b's that we are specifying 
> in hl.simple.pre/post
> As configured in solrconfig.  This was working a while ago when we were still 
> trying to use the non-vector highlighter (had to turn it off due to 
> performance issues)
> {quote}true
>   true
> 3
> 1
> 200
> true
> 
> {quote}
> returns
> {quote}
>   
>  
>   hello ? world are you 
> there ? 
>   
> hello world
>  
>   
> {quote}

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Hudson build is back to normal : Lucene-Solr-tests-only-trunk #4

[Apache Hudson Server]

See 




-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Commented: (SOLR-2153) useFastVectorHighlighter does not respect hl.simple.pre/post

[Trey Hyde (JIRA)]

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

Trey Hyde commented on SOLR-2153:
-

Great, thanks.I haven't seen any documentation for the fragmentsBuilder 
element... is it out there somewhere?

> useFastVectorHighlighter does not respect  hl.simple.pre/post
> -
>
> Key: SOLR-2153
> URL: https://issues.apache.org/jira/browse/SOLR-2153
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 3.1
> Environment: Oct 8 3.1 built from SVN, tomcat6 + solaris
>Reporter: Trey Hyde
>
> The highlighter is returning em's instead of the b's that we are specifying 
> in hl.simple.pre/post
> As configured in solrconfig.  This was working a while ago when we were still 
> trying to use the non-vector highlighter (had to turn it off due to 
> performance issues)
> {quote}true
>   true
> 3
> 1
> 200
> true
> 
> {quote}
> returns
> {quote}
>   
>  
>   hello ? world are you 
> there ? 
>   
> hello world
>  
>   
> {quote}

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Solr SnapPuller fails to clear Old Index Directories

[Jayendra Patil]

We are working on the Solr trunk and have a Master and Two slaves
configuration .
Our indexing consists of Periodic Full and Incremental index building on the
master and replication on the slaves.

When a Full indexing (clean rebuilt) is performed, we always end with an
extra index folder copy, which holds the complete index and hence the size
just grows on, on the slaves.

drwxr-xr-x 2 tomcat tomcat 4096 2010-10-09 12:10 index
drwxr-xr-x 2 tomcat tomcat 4096 2010-10-11 09:43 index.20101009120649
drwxr-xr-x 2 tomcat tomcat 4096 2010-10-12 10:27 index.20101011094043
-rw-r--r-- 1 tomcattomcat   75 2010-10-11 09:43  index.properties
-rw-r--r-- 1 tomcattomcat  422 2010-10-12 10:26
replication.properties
drwxr-xr-x 2 tomcat tomcat   68 2010-10-12 10:27 spellchecker

Where index.20101011094043 is the active index and the other index.xxx
directories are no more used.

The SnapPuller deletes the temporary Index directory, but does not delete
the old one when the switch is performed.
The below code should do the trick.

 boolean fetchLatestIndex(SolrCore core) throws IOException {
..
  } finally {
if(deleteTmpIdxDir) {
delTree(tmpIndexDir);
} else {
*// Delete the old index directory
delTree(indexDir);*
}
  }
.
  }

Any suggestions ?? feedback 

[jira] Commented: (SOLR-1301) Solr + Hadoop

[Dhruv Bansal (JIRA)]

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

Dhruv Bansal commented on SOLR-1301:


I am unable to compile SOLR 1.4.1 after patching with the latest (2010-09-20 
04:40 AM) SOLR-1301.patch.

{code:borderStyle=solid}
$ wget 
http://mirror.cloudera.com/apache//lucene/solr/1.4.1/apache-solr-1.4.1.tgz
...
$ tar -xzf apache-solr-1.4.1.tgz
$ cd apache-solr-1.4.1/contrib
apache-solr-1.4.1/contrib$ wget 
https://issues.apache.org/jira/secure/attachment/12455023/SOLR-1301.patch
apache-solr-1.4.1/contrib$ patch -p2 -i SOLR-1301.patch
...
apache-solr-1.4.1/contrib$ mkdir lib
apache-solr-1.4.1/contrib$ cd lib
apache-solr-1.4.1/contrib/lib$ wget .. # download hadoop, log4j, 
commons-logging, commons-logging-api jars from top of this page
...
apache-solr-1.4.1/contrib/lib$ cd ../..
apache-solr-1.4.1$ ant dist -k

...

compile:
[javac] Compiling 9 source files to 
/home/dhruv/projects/infochimps/search/apache-solr-1.4.1/contrib/hadoop/build/classes
Target 'compile' failed with message 'The following error occurred while 
executing this line:
/home/dhruv/projects/infochimps/search/apache-solr-1.4.1/common-build.xml:159: 
Reference lucene.classpath not found.'.
Cannot execute 'build' - 'compile' failed or was not executed.
Cannot execute 'dist' - 'build' failed or was not executed.
   [subant] File 
'/home/dhruv/projects/infochimps/search/apache-solr-1.4.1/contrib/hadoop/build.xml'
 failed with message 'The following error occurred whil\
e executing this line:
   [subant] 
/home/dhruv/projects/infochimps/search/apache-solr-1.4.1/contrib/hadoop/build.xml:65:
 The following error occurred while executing this line:
   [subant] 
/home/dhruv/projects/infochimps/search/apache-solr-1.4.1/common-build.xml:159: 
Reference lucene.classpath not found.'.


{code} 

Am I following the procedure properly?  I'm able to build SOLR just fine out of 
the box as well as after applying 
[SOLR-1395|https://issues.apache.org/jira/browse/SOLR-1395].


> Solr + Hadoop
> -
>
> Key: SOLR-1301
> URL: https://issues.apache.org/jira/browse/SOLR-1301
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Andrzej Bialecki 
> Fix For: Next
>
> Attachments: commons-logging-1.0.4.jar, 
> commons-logging-api-1.0.4.jar, hadoop-0.19.1-core.jar, 
> hadoop-0.20.1-core.jar, hadoop.patch, log4j-1.2.15.jar, README.txt, 
> SOLR-1301-hadoop-0-20.patch, SOLR-1301-hadoop-0-20.patch, SOLR-1301.patch, 
> SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, 
> SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SolrRecordWriter.java
>
>
> This patch contains  a contrib module that provides distributed indexing 
> (using Hadoop) to Solr EmbeddedSolrServer. The idea behind this module is 
> twofold:
> * provide an API that is familiar to Hadoop developers, i.e. that of 
> OutputFormat
> * avoid unnecessary export and (de)serialization of data maintained on HDFS. 
> SolrOutputFormat consumes data produced by reduce tasks directly, without 
> storing it in intermediate files. Furthermore, by using an 
> EmbeddedSolrServer, the indexing task is split into as many parts as there 
> are reducers, and the data to be indexed is not sent over the network.
> Design
> --
> Key/value pairs produced by reduce tasks are passed to SolrOutputFormat, 
> which in turn uses SolrRecordWriter to write this data. SolrRecordWriter 
> instantiates an EmbeddedSolrServer, and it also instantiates an 
> implementation of SolrDocumentConverter, which is responsible for turning 
> Hadoop (key, value) into a SolrInputDocument. This data is then added to a 
> batch, which is periodically submitted to EmbeddedSolrServer. When reduce 
> task completes, and the OutputFormat is closed, SolrRecordWriter calls 
> commit() and optimize() on the EmbeddedSolrServer.
> The API provides facilities to specify an arbitrary existing solr.home 
> directory, from which the conf/ and lib/ files will be taken.
> This process results in the creation of as many partial Solr home directories 
> as there were reduce tasks. The output shards are placed in the output 
> directory on the default filesystem (e.g. HDFS). Such part-N directories 
> can be used to run N shard servers. Additionally, users can specify the 
> number of reduce tasks, in particular 1 reduce task, in which case the output 
> will consist of a single shard.
> An example application is provided that processes large CSV files and uses 
> this API. It uses a custom CSV processing to avoid (de)serialization overhead.
> This patch relies on hadoop-core-0.19.1.jar - I attached the jar to this 
> issue, you should put it in contrib/hadoop/lib.
> Note: the development of this patch was sponsored by an anonymous contributor 
> and approved for relea

[jira] Created: (LUCENE-2698) Intermittent exc in TestIndexWriter.testAddDocumentOnDiskFull

[Michael McCandless (JIRA)]

Intermittent exc in TestIndexWriter.testAddDocumentOnDiskFull
-

 Key: LUCENE-2698
 URL: https://issues.apache.org/jira/browse/LUCENE-2698
 Project: Lucene - Java
  Issue Type: Bug
  Components: Index
Affects Versions: 3.1
Reporter: Michael McCandless


3.x build just hit this:
{noformat}
Stacktrace

junit.framework.AssertionFailedError
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:693)
at 
org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:666)
at 
org.apache.lucene.index.TermVectorsReader.(TermVectorsReader.java:91)
at 
org.apache.lucene.index.SegmentReader$CoreReaders.openDocStores(SegmentReader.java:304)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:585)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:561)
at 
org.apache.lucene.index.DirectoryReader.(DirectoryReader.java:102)
at 
org.apache.lucene.index.ReadOnlyDirectoryReader.(ReadOnlyDirectoryReader.java:27)
at 
org.apache.lucene.index.DirectoryReader$1.doBody(DirectoryReader.java:78)
at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:692)
at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:72)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:344)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:230)
at 
org.apache.lucene.index.TestIndexWriter.testAddDocumentOnDiskFull(TestIndexWriter.java:515)
Standard Output

NOTE: reproduce with: ant test -Dtestcase=TestIndexWriter 
-Dtestmethod=testAddDocumentOnDiskFull 
-Dtests.seed=3136129128141482592:-2364438756268371069
NOTE: test params are: locale=nl_BE, timezone=Asia/Tel_Aviv
{noformat}

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Build failed in Hudson: Lucene-Solr-tests-only-3.x #1

[Michael McCandless]

Hm.  This looks spooky.  I think this is a new [intermittent]
issue... I'll open an issue.

Mike

On Tue, Oct 12, 2010 at 7:37 PM, Uwe Schindler  wrote:
> This is a real test failure!!! It looks known (3.x), Mike?
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
>> -Original Message-
>> From: Apache Hudson Server [mailto:hud...@hudson.apache.org]
>> Sent: Wednesday, October 13, 2010 1:34 AM
>> To: dev@lucene.apache.org
>> Subject: Build failed in Hudson: Lucene-Solr-tests-only-3.x #1
>>
>> See 
>>
>> --
>> [...truncated 7655 lines...]
>>     [junit] Testsuite: org.apache.lucene.search.TestMultiTermConstantScore
>>     [junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 1.787 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestMultiThreadTermVectors
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.4 sec
>>     [junit]
>>     [junit] Testsuite:
>> org.apache.lucene.search.TestMultiValuedNumericRangeQuery
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.128 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestNot
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestNumericRangeQuery32
>>     [junit] Tests run: 27, Failures: 0, Errors: 0, Time elapsed: 14.557 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestNumericRangeQuery64
>>     [junit] Tests run: 33, Failures: 0, Errors: 0, Time elapsed: 23.362 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestParallelMultiSearcher
>>     [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.116 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestPhrasePrefixQuery
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestPhraseQuery
>>     [junit] Tests run: 17, Failures: 0, Errors: 0, Time elapsed: 2.609 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestPositionIncrement
>>     [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.014 sec
>>     [junit]
>>     [junit] Testsuite: 
>> org.apache.lucene.search.TestPositiveScoresOnlyCollector
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.002 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestPrefixFilter
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.009 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestPrefixInBooleanQuery
>>     [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.737 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestPrefixQuery
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestQueryTermVector
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.002 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestQueryWrapperFilter
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
>>     [junit]
>>     [junit] Testsuite: 
>> org.apache.lucene.search.TestScoreCachingWrappingScorer
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.008 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestScorerPerf
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.708 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestSetNorm
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestSimilarity
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.009 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestSimpleExplanations
>>     [junit] Tests run: 53, Failures: 0, Errors: 0, Time elapsed: 1.473 sec
>>     [junit]
>>     [junit] Testsuite:
>> org.apache.lucene.search.TestSimpleExplanationsOfNonMatches
>>     [junit] Tests run: 53, Failures: 0, Errors: 0, Time elapsed: 0.082 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestSloppyPhraseQuery
>>     [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.254 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestSort
>>     [junit] Tests run: 25, Failures: 0, Errors: 0, Time elapsed: 19.442 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestSpanQueryFilter
>>     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.021 sec
>>     [junit]
>>     [junit] Testsuite: org.apache.lucene.search.TestSubScorerFreqs
>>     [junit] Tests run: 3, Failures: 0, Errors: 0, Tim

RE: Build failed in Hudson: Lucene-Solr-tests-only-3.x #1

[Uwe Schindler]

This is a real test failure!!! It looks known (3.x), Mike?

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


> -Original Message-
> From: Apache Hudson Server [mailto:hud...@hudson.apache.org]
> Sent: Wednesday, October 13, 2010 1:34 AM
> To: dev@lucene.apache.org
> Subject: Build failed in Hudson: Lucene-Solr-tests-only-3.x #1
> 
> See 
> 
> --
> [...truncated 7655 lines...]
> [junit] Testsuite: org.apache.lucene.search.TestMultiTermConstantScore
> [junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 1.787 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestMultiThreadTermVectors
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.4 sec
> [junit]
> [junit] Testsuite:
> org.apache.lucene.search.TestMultiValuedNumericRangeQuery
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.128 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestNot
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestNumericRangeQuery32
> [junit] Tests run: 27, Failures: 0, Errors: 0, Time elapsed: 14.557 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestNumericRangeQuery64
> [junit] Tests run: 33, Failures: 0, Errors: 0, Time elapsed: 23.362 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestParallelMultiSearcher
> [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.116 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestPhrasePrefixQuery
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestPhraseQuery
> [junit] Tests run: 17, Failures: 0, Errors: 0, Time elapsed: 2.609 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestPositionIncrement
> [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.014 sec
> [junit]
> [junit] Testsuite: 
> org.apache.lucene.search.TestPositiveScoresOnlyCollector
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.002 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestPrefixFilter
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.009 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestPrefixInBooleanQuery
> [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.737 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestPrefixQuery
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestQueryTermVector
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.002 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestQueryWrapperFilter
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestScoreCachingWrappingScorer
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.008 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestScorerPerf
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.708 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestSetNorm
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestSimilarity
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.009 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestSimpleExplanations
> [junit] Tests run: 53, Failures: 0, Errors: 0, Time elapsed: 1.473 sec
> [junit]
> [junit] Testsuite:
> org.apache.lucene.search.TestSimpleExplanationsOfNonMatches
> [junit] Tests run: 53, Failures: 0, Errors: 0, Time elapsed: 0.082 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestSloppyPhraseQuery
> [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.254 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestSort
> [junit] Tests run: 25, Failures: 0, Errors: 0, Time elapsed: 19.442 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestSpanQueryFilter
> [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.021 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestSubScorerFreqs
> [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.016 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestTermRangeFilter
> [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 2.39 sec
> [junit]
> [junit] Testsuite: org.apache.lucene.search.TestTermRangeQuery
>

RE: Build failed in Hudson: Lucene-Solr-tests-only-trunk #2

[Uwe Schindler]

Ignore these for now...

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Apache Hudson Server [mailto:hud...@hudson.apache.org]
> Sent: Wednesday, October 13, 2010 1:07 AM
> To: dev@lucene.apache.org
> Subject: Build failed in Hudson: Lucene-Solr-tests-only-trunk #2
> 
> See  trunk/2/changes>
> 
> Changes:
> 
> [uschindler] fix dirs :(
> 
> --
> [...truncated 624 lines...]
> clover.setup:
> 
> clover.info:
> 
> clover:
> 
> common.compile-core:
> 
> compile-core:
> 
> common.compile-test:
> [mkdir] Created dir: /usr Solr-tests-only-trunk/ws/trunk/modules/analysis/build/common/classes/test>
> [javac] Compiling 123 source files to
> /usr trunk/ws/trunk/modules/analysis/build/common/classes/test>
> [javac] Note: Some input files use or override a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
>  [copy] Copying 31 files to
> /usr trunk/ws/trunk/modules/analysis/build/common/classes/test>
>  [echo] Building analyzers-icu...
> 
> common.init:
> 
> build-lucene:
> 
> jflex-uptodate-check:
> 
> jflex-notice:
> 
> javacc-uptodate-check:
> 
> javacc-notice:
> 
> init:
> 
> clover.setup:
> 
> clover.info:
> 
> clover:
> 
> common.compile-core:
> 
> compile-core:
> 
> compile-test:
> [javac] Compiling 1 source file to
> /usr trunk/ws/trunk/lucene/build/classes/test>
> 
> init:
> 
> compile-test:
>  [echo] Building analyzers-icu...
> 
> build-analyzers-common:
> 
> common.init:
> 
> build-lucene:
> 
> init:
> 
> clover.setup:
> 
> clover.info:
> 
> clover:
> 
> common.compile-core:
> 
> compile-core:
> 
> common.compile-test:
> [mkdir] Created dir: /usr Solr-tests-only-trunk/ws/trunk/modules/analysis/build/icu/classes/test>
> [javac] Compiling 8 source files to
> /usr trunk/ws/trunk/modules/analysis/build/icu/classes/test>
> [javac] Note: /usr only-
> trunk/ws/trunk/modules/analysis/icu/src/test/org/apache/lucene/analysis/icu/s
> egmentation/TestLaoBreakIterator.java> uses or overrides a deprecated API.
> [javac] Note: Recompile with -Xlint:deprecation for details.
>  [echo] Building analyzers-phonetic...
> 
> common.init:
> 
> build-lucene:
> 
> jflex-uptodate-check:
> 
> jflex-notice:
> 
> javacc-uptodate-check:
> 
> javacc-notice:
> 
> init:
> 
> clover.setup:
> 
> clover.info:
> 
> clover:
> 
> common.compile-core:
> 
> compile-core:
> 
> compile-test:
> [javac] Compiling 1 source file to
> /usr trunk/ws/trunk/lucene/build/classes/test>
> 
> init:
> 
> compile-test:
>  [echo] Building analyzers-phonetic...
> 
> build-analyzers-common:
> 
> common.init:
> 
> build-lucene:
> 
> init:
> 
> clover.setup:
> 
> clover.info:
> 
> clover:
> 
> common.compile-core:
> 
> compile-core:
> 
> common.compile-test:
> [mkdir] Created dir: /usr Solr-tests-only-trunk/ws/trunk/modules/analysis/build/phonetic/classes/test>
> [javac] Compiling 2 source files to
> /usr trunk/ws/trunk/modules/analysis/build/phonetic/classes/test>
>  [echo] Building analyzers-smartcn...
> 
> common.init:
> 
> build-lucene:
> 
> jflex-uptodate-check:
> 
> jflex-notice:
> 
> javacc-uptodate-check:
> 
> javacc-notice:
> 
> init:
> 
> clover.setup:
> 
> clover.info:
> 
> clover:
> 
> common.compile-core:
> 
> compile-core:
> 
> compile-test:
> [javac] Compiling 1 source file to
> /usr trunk/ws/trunk/lucene/build/classes/test>
> 
> init:
> 
> compile-test:
>  [echo] Building analyzers-smartcn...
> 
> build-analyzers-common:
> 
> common.init:
> 
> build-lucene:
> 
> init:
> 
> clover.setup:
> 
> clover.info:
> 
> clover:
> 
> common.compile-core:
> 
> compile-core:
> 
> common.compile-test:
> [mkdir] Created dir: /usr Solr-tests-only-trunk/ws/trunk/modules/analysis/build/smartcn/classes/test>
> [javac] Compiling 1 source file to
> /usr trunk/ws/trunk/modules/analysis/build/smartcn/classes/test>
> [javac] Note: /usr only-
> trunk/ws/trunk/modules/analysis/smartcn/src/test/org/apache/lucene/analysis
> /cn/smart/TestSmartChineseAnalyzer.java> uses or overri

Build failed in Hudson: Lucene-Solr-tests-only-3.x #1

[Apache Hudson Server]

See 

--
[...truncated 7655 lines...]
[junit] Testsuite: org.apache.lucene.search.TestMultiTermConstantScore
[junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 1.787 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestMultiThreadTermVectors
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.4 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestMultiValuedNumericRangeQuery
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.128 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestNot
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestNumericRangeQuery32
[junit] Tests run: 27, Failures: 0, Errors: 0, Time elapsed: 14.557 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestNumericRangeQuery64
[junit] Tests run: 33, Failures: 0, Errors: 0, Time elapsed: 23.362 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestParallelMultiSearcher
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.116 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestPhrasePrefixQuery
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestPhraseQuery
[junit] Tests run: 17, Failures: 0, Errors: 0, Time elapsed: 2.609 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestPositionIncrement
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.014 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestPositiveScoresOnlyCollector
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.002 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestPrefixFilter
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.009 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestPrefixInBooleanQuery
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.737 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestPrefixQuery
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestQueryTermVector
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.002 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestQueryWrapperFilter
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestScoreCachingWrappingScorer
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.008 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestScorerPerf
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.708 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestSetNorm
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.003 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestSimilarity
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.009 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestSimpleExplanations
[junit] Tests run: 53, Failures: 0, Errors: 0, Time elapsed: 1.473 sec
[junit] 
[junit] Testsuite: 
org.apache.lucene.search.TestSimpleExplanationsOfNonMatches
[junit] Tests run: 53, Failures: 0, Errors: 0, Time elapsed: 0.082 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestSloppyPhraseQuery
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.254 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestSort
[junit] Tests run: 25, Failures: 0, Errors: 0, Time elapsed: 19.442 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestSpanQueryFilter
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.021 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestSubScorerFreqs
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.016 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestTermRangeFilter
[junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 2.39 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestTermRangeQuery
[junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.053 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestTermScorer
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.006 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestTermVectors
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.201 sec
[junit] 
[junit] Testsuite: org.apache.lucene.search.TestThreadSafe
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.229 sec
[junit] 
[junit]

Build failed in Hudson: Lucene-Solr-tests-only-trunk #2

[Apache Hudson Server]

See 


Changes:

[uschindler] fix dirs :(

--
[...truncated 624 lines...]
clover.setup:

clover.info:

clover:

common.compile-core:

compile-core:

common.compile-test:
[mkdir] Created dir: 
/usr
[javac] Compiling 123 source files to 
/usr
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
 [copy] Copying 31 files to 
/usr
 [echo] Building analyzers-icu...

common.init:

build-lucene:

jflex-uptodate-check:

jflex-notice:

javacc-uptodate-check:

javacc-notice:

init:

clover.setup:

clover.info:

clover:

common.compile-core:

compile-core:

compile-test:
[javac] Compiling 1 source file to 
/usr

init:

compile-test:
 [echo] Building analyzers-icu...

build-analyzers-common:

common.init:

build-lucene:

init:

clover.setup:

clover.info:

clover:

common.compile-core:

compile-core:

common.compile-test:
[mkdir] Created dir: 
/usr
[javac] Compiling 8 source files to 
/usr
[javac] Note: 
/usr
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
 [echo] Building analyzers-phonetic...

common.init:

build-lucene:

jflex-uptodate-check:

jflex-notice:

javacc-uptodate-check:

javacc-notice:

init:

clover.setup:

clover.info:

clover:

common.compile-core:

compile-core:

compile-test:
[javac] Compiling 1 source file to 
/usr

init:

compile-test:
 [echo] Building analyzers-phonetic...

build-analyzers-common:

common.init:

build-lucene:

init:

clover.setup:

clover.info:

clover:

common.compile-core:

compile-core:

common.compile-test:
[mkdir] Created dir: 
/usr
[javac] Compiling 2 source files to 
/usr
 [echo] Building analyzers-smartcn...

common.init:

build-lucene:

jflex-uptodate-check:

jflex-notice:

javacc-uptodate-check:

javacc-notice:

init:

clover.setup:

clover.info:

clover:

common.compile-core:

compile-core:

compile-test:
[javac] Compiling 1 source file to 
/usr

init:

compile-test:
 [echo] Building analyzers-smartcn...

build-analyzers-common:

common.init:

build-lucene:

init:

clover.setup:

clover.info:

clover:

common.compile-core:

compile-core:

common.compile-test:
[mkdir] Created dir: 
/usr
[javac] Compiling 1 source file to 
/usr
[javac] Note: 
/usr
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
 [echo] Building analyzers-stempel...

common.init:

build-lucene:

jflex-uptodate-check:

jflex-notice:

javacc-uptodate-check:

javacc-notice:

init:

clover.setup:

clover.info:

clover:

common.compile-core:

compile-core:

compile-test:
[javac] Compiling 1 source file to 
/usr

init:

compile-test:
 [echo] Building analyzers-stempel...

build-analyzers-common:

common.init:

build-lucene:

init:

clover.setup:

clover.info:

clover:

common.compile-core:

compile-core:

common.compile-test:
[mkdir] Created dir: 
/usr

[jira] Commented: (SOLR-2153) useFastVectorHighlighter does not respect hl.simple.pre/post

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi commented on SOLR-2153:
--

bq. useFastVectorHighlighter does not respect hl.simple.pre/post

Correct.

I think hl.simple.pre/post parameters are for HtmlFormatter (it implements 
SolrFormatter), and FVH doesn't use SolrFormatter, but uses fragListBuilder and 
fragmentsBuilder instead. And fragmentsBuilder respects hl.tag.pre/post:

{code}


  


  

{code}


> useFastVectorHighlighter does not respect  hl.simple.pre/post
> -
>
> Key: SOLR-2153
> URL: https://issues.apache.org/jira/browse/SOLR-2153
> Project: Solr
>  Issue Type: Bug
>  Components: highlighter
>Affects Versions: 3.1
> Environment: Oct 8 3.1 built from SVN, tomcat6 + solaris
>Reporter: Trey Hyde
>
> The highlighter is returning em's instead of the b's that we are specifying 
> in hl.simple.pre/post
> As configured in solrconfig.  This was working a while ago when we were still 
> trying to use the non-vector highlighter (had to turn it off due to 
> performance issues)
> {quote}true
>   true
> 3
> 1
> 200
> true
> 
> {quote}
> returns
> {quote}
>   
>  
>   hello ? world are you 
> there ? 
>   
> hello world
>  
>   
> {quote}

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Build failed in Hudson: Lucene-Solr-tests-only-trunk #1

[Apache Hudson Server]

See 

--
[...truncated 5010 lines...]
AU
lucene/contrib/spatial/src/java/org/apache/lucene/spatial/geohash/GeoHashUtils.java
AU
lucene/contrib/spatial/src/java/org/apache/lucene/spatial/geohash/package.html
AUlucene/contrib/spatial/src/java/overview.html
AUlucene/contrib/spatial/build.xml
A lucene/contrib/highlighter
AUlucene/contrib/highlighter/pom.xml.template
A lucene/contrib/highlighter/src
A lucene/contrib/highlighter/src/test
A lucene/contrib/highlighter/src/test/org
A lucene/contrib/highlighter/src/test/org/apache
A lucene/contrib/highlighter/src/test/org/apache/lucene
A lucene/contrib/highlighter/src/test/org/apache/lucene/search
A lucene/contrib/highlighter/src/test/org/apache/lucene/search/highlight
AU
lucene/contrib/highlighter/src/test/org/apache/lucene/search/highlight/HighlighterPhraseTest.java
AU
lucene/contrib/highlighter/src/test/org/apache/lucene/search/highlight/HighlighterTest.java
A 
lucene/contrib/highlighter/src/test/org/apache/lucene/search/vectorhighlight
AU
lucene/contrib/highlighter/src/test/org/apache/lucene/search/vectorhighlight/AbstractTestCase.java
AU
lucene/contrib/highlighter/src/test/org/apache/lucene/search/vectorhighlight/FieldTermStackTest.java
AU
lucene/contrib/highlighter/src/test/org/apache/lucene/search/vectorhighlight/FieldPhraseListTest.java
AU
lucene/contrib/highlighter/src/test/org/apache/lucene/search/vectorhighlight/IndexTimeSynonymTest.java
AU
lucene/contrib/highlighter/src/test/org/apache/lucene/search/vectorhighlight/SingleFragListBuilderTest.java
AU
lucene/contrib/highlighter/src/test/org/apache/lucene/search/vectorhighlight/ScoreOrderFragmentsBuilderTest.java
AU
lucene/contrib/highlighter/src/test/org/apache/lucene/search/vectorhighlight/SimpleFragmentsBuilderTest.java
AU
lucene/contrib/highlighter/src/test/org/apache/lucene/search/vectorhighlight/FieldQueryTest.java
AU
lucene/contrib/highlighter/src/test/org/apache/lucene/search/vectorhighlight/SimpleFragListBuilderTest.java
A lucene/contrib/highlighter/src/java
A lucene/contrib/highlighter/src/java/org
A lucene/contrib/highlighter/src/java/org/apache
A lucene/contrib/highlighter/src/java/org/apache/lucene
A lucene/contrib/highlighter/src/java/org/apache/lucene/search
A lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/InvalidTokenOffsetsException.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/SimpleHTMLFormatter.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/SpanGradientFormatter.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/Formatter.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/SimpleFragmenter.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/WeightedSpanTermExtractor.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/TextFragment.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/WeightedSpanTerm.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/QueryTermScorer.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/package.html
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/SimpleHTMLEncoder.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/Encoder.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/TokenStreamFromTermPositionVector.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/GradientFormatter.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/QueryScorer.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/DefaultEncoder.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/TokenSources.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/NullFragmenter.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/SimpleSpanFragmenter.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/WeightedTerm.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/QueryTermExtractor.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/search/highlight/Fragmenter.java
AU
lucene/contrib/highlighter/src/java/org/apache/lucene/sear

[jira] Commented: (SOLR-1395) Integrate Katta

[Dhruv Bansal (JIRA)]

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

Dhruv Bansal commented on SOLR-1395:


tom liu,

i'm unable to run the last patch file you uploaded, solr-1395-katta-0.6.2.patch 
on 2010-10-11, using apache-solr-1.4.1.

{code:title=patching_solr-1.4.1|borderStyle=solid}
$ wget 
http://mirror.cloudera.com/apache//lucene/solr/1.4.1/apache-solr-1.4.1.tgz
...
$ tar -xzf apache-solr-1.4.1.tgz
$ cd apache-solr-1.4.1/src
apache-solr-1.4.1/src$ wget 
https://issues.apache.org/jira/secure/attachment/12456924/solr-1395-katta-0.6.2.patch
...
apache-solr-1.4.1/src$ patch -p0 -i solr-1395-katta-0.6.2.patch

patching file java/org/apache/solr/katta/ISolrDocumentFactory.java
patching file java/org/apache/solr/katta/ISolrServer.java
patching file java/org/apache/solr/katta/KattaClient.java
patching file java/org/apache/solr/katta/KattaResponse.java
patching file java/org/apache/solr/katta/ZipService.java
patching file java/org/apache/solr/katta/KattaMultiServer.java
patching file java/org/apache/solr/katta/KattaComponent.java
patching file java/org/apache/solr/katta/DocumentWritable.java
Patching file java/org/apache/solr/katta/KattaSearchHandler.java
patching file java/org/apache/solr/katta/SolrKattaServer.java
patching file java/org/apache/solr/katta/DeployableSolrKattaServer.java
patching file java/org/apache/solr/katta/KattaRequest.java
patching file java/org/apache/solr/katta/SolrIndexer.java
patching file java/org/apache/solr/handler/KattaRequestHandler.java
patching file java/org/apache/solr/handler/component/SearchHandler.java
Hunk #1 succeeded at 216 (offset -14 lines).
Hunk #2 succeeded at 243 (offset -14 lines).
Hunk #3 succeeded at 301 (offset -14 lines).
Hunk #4 FAILED at 357.
1 out of 4 hunks FAILED -- saving rejects to file 
java/org/apache/solr/handler/component/SearchHandler.java.rej
patching file java/org/apache/solr/handler/component/SimpleSolrResponse.java
patching file java/org/apache/solr/handler/component/MultiShardHandler.java
patching file java/org/apache/solr/handler/component/HttpMultiShardHandler.java
patching file 
java/org/apache/solr/handler/component/EmbeddedMultiShardHandler.java
patching file java/org/apache/solr/handler/component/QueryComponent.java
Hunk #1 succeeded at 42 with fuzz 2 (offset 6 lines).
Hunk #2 succeeded at 174 (offset -2 lines).
Hunk #3 succeeded at 274 (offset -110 lines).
Hunk #4 FAILED at 432.
Hunk #5 succeeded at 361 (offset -109 lines).
Hunk #6 succeeded at 474 (offset -110 lines).
Hunk #7 succeeded at 525 (offset -110 lines).
Hunk #8 succeeded at 576 (offset -115 lines).
Hunk #9 FAILED at 711.
2 out of 9 hunks FAILED -- saving rejects to file 
java/org/apache/solr/handler/component/QueryComponent.java.rej
patching file 
java/org/apache/solr/handler/component/MultiEmbeddedSearchHandler.java
patching file 
java/org/apache/solr/handler/component/AbstractMultiShardHandler.java
patching file solrj/org/apache/solr/client/solrj/request/QueryRequest.java
patching file webapp/web/WEB-INF/web.xml
{code}

Did I do something incorrectly?


> Integrate Katta
> ---
>
> Key: SOLR-1395
> URL: https://issues.apache.org/jira/browse/SOLR-1395
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Priority: Minor
> Fix For: Next
>
> Attachments: back-end.log, front-end.log, hadoop-core-0.19.0.jar, 
> katta-core-0.6-dev.jar, katta.node.properties, katta.zk.properties, 
> log4j-1.2.13.jar, solr-1395-1431-3.patch, solr-1395-1431-4.patch, 
> solr-1395-1431-katta0.6.patch, solr-1395-1431-katta0.6.patch, 
> solr-1395-1431.patch, solr-1395-katta-0.6.2.patch, SOLR-1395.patch, 
> SOLR-1395.patch, SOLR-1395.patch, test-katta-core-0.6-dev.jar, 
> zkclient-0.1-dev.jar, zookeeper-3.2.1.jar
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> We'll integrate Katta into Solr so that:
> * Distributed search uses Hadoop RPC
> * Shard/SolrCore distribution and management
> * Zookeeper based failover
> * Indexes may be built using Hadoop

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-2621) Extend Codec to handle also stored fields and term vectors

[Simon Willnauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920335#action_12920335
 ] 

Simon Willnauer commented on LUCENE-2621:
-

bq. .. and norms while we're at it.
just for the record we should explore if norms could just be a doc payload see 
LUCENE-2186

> Extend Codec to handle also stored fields and term vectors
> --
>
> Key: LUCENE-2621
> URL: https://issues.apache.org/jira/browse/LUCENE-2621
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Index
>Affects Versions: 4.0
>Reporter: Andrzej Bialecki 
>
> Currently Codec API handles only writing/reading of term-related data, while 
> stored fields data and term frequency vector data writing/reading is handled 
> elsewhere.
> I propose to extend the Codec API to handle this data as well.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Updated: (LUCENE-2186) First cut at column-stride fields (index values storage)

[Simon Willnauer (JIRA)]

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

Simon Willnauer updated LUCENE-2186:


Fix Version/s: CSF branch

> First cut at column-stride fields (index values storage)
> 
>
> Key: LUCENE-2186
> URL: https://issues.apache.org/jira/browse/LUCENE-2186
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: Index
>Reporter: Michael McCandless
>Assignee: Simon Willnauer
> Fix For: CSF branch, 4.0
>
> Attachments: LUCENE-2186.patch, LUCENE-2186.patch, LUCENE-2186.patch, 
> LUCENE-2186.patch, LUCENE-2186.patch, mem.py
>
>
> I created an initial basic impl for storing "index values" (ie
> column-stride value storage).  This is still a work in progress... but
> the approach looks compelling.  I'm posting my current status/patch
> here to get feedback/iterate, etc.
> The code is standalone now, and lives under new package
> oal.index.values (plus some util changes, refactorings) -- I have yet
> to integrate into Lucene so eg you can mark that a given Field's value
> should be stored into the index values, sorting will use these values
> instead of field cache, etc.
> It handles 3 types of values:
>   * Six variants of byte[] per doc, all combinations of fixed vs
> variable length, and stored either "straight" (good for eg a
> "title" field), "deref" (good when many docs share the same value,
> but you won't do any sorting) or "sorted".
>   * Integers (variable bit precision used as necessary, ie this can
> store byte/short/int/long, and all precisions in between)
>   * Floats (4 or 8 byte precision)
> String fields are stored as the UTF8 byte[].  This patch adds a
> BytesRef, which does the same thing as flex's TermRef (we should merge
> them).
> This patch also adds basic initial impl of PackedInts (LUCENE-1990);
> we can swap that out if/when we get a better impl.
> This storage is dense (like field cache), so it's appropriate when the
> field occurs in all/most docs.  It's just like field cache, except the
> reading API is a get() method invocation, per document.
> Next step is to do basic integration with Lucene, and then compare
> sort performance of this vs field cache.
> For the "sort by String value" case, I think RAM usage & GC load of
> this index values API should be much better than field caache, since
> it does not create object per document (instead shares big long[] and
> byte[] across all docs), and because the values are stored in RAM as
> their UTF8 bytes.
> There are abstract Writer/Reader classes.  The current reader impls
> are entirely RAM resident (like field cache), but the API is (I think)
> agnostic, ie, one could make an MMAP impl instead.
> I think this is the first baby step towards LUCENE-1231.  Ie, it
> cannot yet update values, and the reading API is fully random-access
> by docID (like field cache), not like a posting list, though I
> do think we should add an iterator() api (to return flex's DocsEnum)
> -- eg I think this would be a good way to track avg doc/field length
> for BM25/lnu.ltc scoring.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Updated: (SOLR-2154) Spatial support for MultiValued fields

[Bill Bell (JIRA)]

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

Bill Bell updated SOLR-2154:


Description: 
Is this an issue - it appears to work ?

This appears to work on LatLon Spatial fields. It appears to find the right lat 
long... Is this supposed to work?
I read that this does not work on solr.PointType, but it appears to work on 
LatLonType.

 


Trying a few queries and I can get either of the 2 points.

{code}
http://localhost:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=41.9244,-87.6473&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(41.9244,-87.6473))+asc,+score+desc&debugQuery=on

1 result.

http://10.0.1.37:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=47.7651,-122.362&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+desc&debugQuery=on

2 results.
{code}


{code}
schema.xml:

 
 
sample.xml to import:

  
2300 North Childrens Plaza
1
41.9244,-87.6473
47.7651,-122.362
60614
  
  
357 North West Richmond Beach Road
2
48.7651,-122.362
98177
  
  
7555 North Overfield Road
3
32.948,-111.653
85294
  

{code}

  was:
Is this an issue - it appears to work ?

This appears to work on LatLon Spatial fields. It appears to find the right lat 
long... Is this supposed to work?
I read that this does not work on solr.PointType, but it appears to work on 
LatLonType.

 


Trying a few queries and I can get either of the 2 points.

{code}
http://localhost:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=41.9244,-87.6473&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(41.9244,-87.6473))+asc,+score+desc&debugQuery=on

1 result.

http://10.0.1.37:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=47.7651,-122.362&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+desc&debugQuery=on

2 results.
{code}


{code}
schema.xml:

 
 
sample.xml to import:

  
2300 North Childrens Plaza
1
41.9244,-87.6473
47.7651,-122.362
60614
  
  
357 North West Richmond Beach Road
2
47.7651,-122.362
98177
  
  
7555 North Overfield Road
3
32.948,-111.653
85294
  

{code}


> Spatial support for MultiValued fields
> --
>
> Key: SOLR-2154
> URL: https://issues.apache.org/jira/browse/SOLR-2154
> Project: Solr
>  Issue Type: New Feature
>  Components: Build
>Affects Versions: 4.0
>Reporter: Bill Bell
> Fix For: 4.0
>
>
> Is this an issue - it appears to work ?
> This appears to work on LatLon Spatial fields. It appears to find the right 
> lat long... Is this supposed to work?
> I read that this does not work on solr.PointType, but it appears to work on 
> LatLonType.
>   subFieldSuffix="_d"/>
>  multiValued="true"/>
> Trying a few queries and I can get either of the 2 points.
> {code}
> http://localhost:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=41.9244,-87.6473&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(41.9244,-87.6473))+asc,+score+desc&debugQuery=on
> 1 result.
> http://10.0.1.37:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=47.7651,-122.362&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+desc&debugQuery=on
> 2 results.
> {code}
> {code}
> schema.xml:
> 
>   multiValued="true"/>
>  
> sample.xml to import:
> 
>   
> 2300 North Childrens Plaza
> 1
> 41.9244,-87.6473
> 47.7651,-122.362
> 60614
>   
>   
> 357 North West Richmond Beach Road
> 2
> 48.7651,-122.362
> 98177
>   
>   
> 7555 North Overfield Road
> 3
> 32.948,-111.653
> 85294
>   
> 
> {code}

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-2621) Extend Codec to handle also stored fields and term vectors

[Andrzej Bialecki (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920332#action_12920332
 ] 

Andrzej Bialecki  commented on LUCENE-2621:
---

.. and norms while we're at it.

> Extend Codec to handle also stored fields and term vectors
> --
>
> Key: LUCENE-2621
> URL: https://issues.apache.org/jira/browse/LUCENE-2621
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Index
>Affects Versions: 4.0
>Reporter: Andrzej Bialecki 
>
> Currently Codec API handles only writing/reading of term-related data, while 
> stored fields data and term frequency vector data writing/reading is handled 
> elsewhere.
> I propose to extend the Codec API to handle this data as well.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Commented: (SOLR-2154) Spatial support for MultiValued fields

[Bill Bell (JIRA)]

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

Bill Bell commented on SOLR-2154:
-

The sort by does not work right. 

Sorting from 47.7651,-122.362 

http://localhost:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=47.7651,-122.362&d=200.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+desc&debugQuery=on
 

I get 48.7651,-122.362 (357 North West Richmond Beach Road) coming out first. 

> Spatial support for MultiValued fields
> --
>
> Key: SOLR-2154
> URL: https://issues.apache.org/jira/browse/SOLR-2154
> Project: Solr
>  Issue Type: New Feature
>  Components: Build
>Affects Versions: 4.0
>Reporter: Bill Bell
> Fix For: 4.0
>
>
> Is this an issue - it appears to work ?
> This appears to work on LatLon Spatial fields. It appears to find the right 
> lat long... Is this supposed to work?
> I read that this does not work on solr.PointType, but it appears to work on 
> LatLonType.
>   subFieldSuffix="_d"/>
>  multiValued="true"/>
> Trying a few queries and I can get either of the 2 points.
> {code}
> http://localhost:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=41.9244,-87.6473&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(41.9244,-87.6473))+asc,+score+desc&debugQuery=on
> 1 result.
> http://10.0.1.37:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=47.7651,-122.362&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+desc&debugQuery=on
> 2 results.
> {code}
> {code}
> schema.xml:
> 
>   multiValued="true"/>
>  
> sample.xml to import:
> 
>   
> 2300 North Childrens Plaza
> 1
> 41.9244,-87.6473
> 47.7651,-122.362
> 60614
>   
>   
> 357 North West Richmond Beach Road
> 2
> 47.7651,-122.362
> 98177
>   
>   
> 7555 North Overfield Road
> 3
> 32.948,-111.653
> 85294
>   
> 
> {code}

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Commented: (SOLR-1873) Commit Solr Cloud to trunk

[Robert Muir (JIRA)]

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

Robert Muir commented on SOLR-1873:
---

+1 to commit, i have no problems since the timeout has changed.

Additionally the tests don't cause a significant slowdown on my computer, and 
there is an issue open
already to speed them up. I think its better to have the code in trunk at this 
point so we can spend
time actually improving it and not merging.

> Commit Solr Cloud to trunk
> --
>
> Key: SOLR-1873
> URL: https://issues.apache.org/jira/browse/SOLR-1873
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 1.4
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: Next
>
> Attachments: log4j-over-slf4j-1.5.5.jar, SOLR-1873.patch, 
> SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, 
> SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, 
> SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, 
> SOLR-1873.patch, TEST-org.apache.solr.cloud.ZkSolrClientTest.txt, 
> zookeeper-3.2.2.jar, zookeeper-3.3.1.jar
>
>
> This is a real hassle - I didn't merge up to trunk before all the svn 
> scrambling, so integrating cloud is now a bit difficult. I'm running through 
> and just preparing a commit by hand though (applying changes/handling 
> conflicts a file at a time).

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Commented: (SOLR-1873) Commit Solr Cloud to trunk

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-1873:
---

Okay - I'd still like to push these tests to be quicker - but I'd like to 
commit this soon if there are no objections - getting this in trunk is going to 
make things a lot easier for a few people (including me - as fun as merging up 
to trunk always is) - and now that I know a couple people are using it (at 
least one in production), I feel pretty good about getting this in soon.

This is our base from which I hope a lot of further cool cloud stuff comes.


> Commit Solr Cloud to trunk
> --
>
> Key: SOLR-1873
> URL: https://issues.apache.org/jira/browse/SOLR-1873
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 1.4
>Reporter: Mark Miller
>Assignee: Mark Miller
> Fix For: Next
>
> Attachments: log4j-over-slf4j-1.5.5.jar, SOLR-1873.patch, 
> SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, 
> SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, 
> SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, SOLR-1873.patch, 
> SOLR-1873.patch, TEST-org.apache.solr.cloud.ZkSolrClientTest.txt, 
> zookeeper-3.2.2.jar, zookeeper-3.3.1.jar
>
>
> This is a real hassle - I didn't merge up to trunk before all the svn 
> scrambling, so integrating cloud is now a bit difficult. I'm running through 
> and just preparing a commit by hand though (applying changes/handling 
> conflicts a file at a time).

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Updated: (SOLR-2154) Spatial support for MultiValued fields

[Bill Bell (JIRA)]

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

Bill Bell updated SOLR-2154:


Description: 
Is this an issue - it appears to work ?

This appears to work on LatLon Spatial fields. It appears to find the right lat 
long... Is this supposed to work?
I read that this does not work on solr.PointType, but it appears to work on 
LatLonType.

 


Trying a few queries and I can get either of the 2 points.

{code}
http://localhost:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=41.9244,-87.6473&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(41.9244,-87.6473))+asc,+score+desc&debugQuery=on

1 result.

http://10.0.1.37:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=47.7651,-122.362&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+desc&debugQuery=on

2 results.
{code}


{code}
schema.xml:

 
 
sample.xml to import:

  
2300 North Childrens Plaza
1
41.9244,-87.6473
47.7651,-122.362
60614
  
  
357 North West Richmond Beach Road
2
47.7651,-122.362
98177
  
  
7555 North Overfield Road
3
32.948,-111.653
85294
  

{code}

  was:
Is this an issue - it appears to work ?

This appears to work on LatLon Spatial fields. It appears to find the right lat 
long... Is this supposed to work?
I read that this does not work on solr.PointType, but it appears to work on 
LatLonType.

 


Trying a few queries and I can get either of the 2 points.

http://localhost:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=41.9244,-87.6473&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(41.9244,-87.6473))+asc,+score+desc&debugQuery=on

1 result.

http://10.0.1.37:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=47.7651,-122.362&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+desc&debugQuery=on

2 results.



{code}
schema.xml:

 
 
sample.xml to import:

  
2300 North Childrens Plaza
1
41.9244,-87.6473
47.7651,-122.362
60614
  
  
357 North West Richmond Beach Road
2
47.7651,-122.362
98177
  
  
7555 North Overfield Road
3
32.948,-111.653
85294
  

{code}


> Spatial support for MultiValued fields
> --
>
> Key: SOLR-2154
> URL: https://issues.apache.org/jira/browse/SOLR-2154
> Project: Solr
>  Issue Type: New Feature
>  Components: Build
>Affects Versions: 4.0
>Reporter: Bill Bell
> Fix For: 4.0
>
>
> Is this an issue - it appears to work ?
> This appears to work on LatLon Spatial fields. It appears to find the right 
> lat long... Is this supposed to work?
> I read that this does not work on solr.PointType, but it appears to work on 
> LatLonType.
>   subFieldSuffix="_d"/>
>  multiValued="true"/>
> Trying a few queries and I can get either of the 2 points.
> {code}
> http://localhost:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=41.9244,-87.6473&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(41.9244,-87.6473))+asc,+score+desc&debugQuery=on
> 1 result.
> http://10.0.1.37:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=47.7651,-122.362&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+desc&debugQuery=on
> 2 results.
> {code}
> {code}
> schema.xml:
> 
>   multiValued="true"/>
>  
> sample.xml to import:
> 
>   
> 2300 North Childrens Plaza
> 1
> 41.9244,-87.6473
> 47.7651,-122.362
> 60614
>   
>   
> 357 North West Richmond Beach Road
> 2
> 47.7651,-122.362
> 98177
>   
>   
> 7555 North Overfield Road
> 3
> 32.948,-111.653
> 85294
>   
> 
> {code}

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Created: (SOLR-2154) Spatial support for MultiValued fields

[Bill Bell (JIRA)]

Spatial support for MultiValued fields
--

 Key: SOLR-2154
 URL: https://issues.apache.org/jira/browse/SOLR-2154
 Project: Solr
  Issue Type: New Feature
  Components: Build
Affects Versions: 4.0
Reporter: Bill Bell
 Fix For: 4.0


Is this an issue - it appears to work ?

This appears to work on LatLon Spatial fields. It appears to find the right lat 
long... Is this supposed to work?
I read that this does not work on solr.PointType, but it appears to work on 
LatLonType.

 


Trying a few queries and I can get either of the 2 points.

http://localhost:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=41.9244,-87.6473&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(41.9244,-87.6473))+asc,+score+desc&debugQuery=on

1 result.

http://10.0.1.37:8983/solr/core2/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=47.7651,-122.362&d=10.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store_lat_lon,vector(47.7651,-122.362))+asc,+score+desc&debugQuery=on

2 results.



{code}
schema.xml:

 
 
sample.xml to import:

  
2300 North Childrens Plaza
1
41.9244,-87.6473
47.7651,-122.362
60614
  
  
357 North West Richmond Beach Road
2
47.7651,-122.362
98177
  
  
7555 North Overfield Road
3
32.948,-111.653
85294
  

{code}

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Created: (SOLR-2153) useFastVectorHighlighter does not respect hl.simple.pre/post

[Trey Hyde (JIRA)]

useFastVectorHighlighter does not respect  hl.simple.pre/post
-

 Key: SOLR-2153
 URL: https://issues.apache.org/jira/browse/SOLR-2153
 Project: Solr
  Issue Type: Bug
  Components: highlighter
Affects Versions: 3.1
 Environment: Oct 8 3.1 built from SVN, tomcat6 + solaris
Reporter: Trey Hyde


The highlighter is returning em's instead of the b's that we are specifying in 
hl.simple.pre/post

As configured in solrconfig.  This was working a while ago when we were still 
trying to use the non-vector highlighter (had to turn it off due to performance 
issues)

{quote}true
  true
3
1
200
true

{quote}


returns

{quote}
  
 
  hello ? world are you 
there ? 
  
hello world
 
  
{quote}

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Commented: (LUCENE-2655) Get deletes working in the realtime branch

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920276#action_12920276
 ] 

Michael McCandless commented on LUCENE-2655:


bq. When a new segment is flushed, then the docid-upto is reset to what's in 
the latest segment?

Do you mean the flushedDocCount (in DocumentsWriter), by "docid-upto"?  Ie, 
this is what we use to "globalize" the docid-upto stored for each delete 
Term/Query.

bq.  Aren't we then losing point-in-timeness of the docid-uptos per DWPT by 
simply resetting dut to the highest value of the newest segment?

I'm confused... that flushedDocCount is just an int, tracking the total doc 
count of all already-flushed segments.  This shouldn't affect 
point-in-timeness?

> Get deletes working in the realtime branch
> --
>
> Key: LUCENE-2655
> URL: https://issues.apache.org/jira/browse/LUCENE-2655
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Index
>Affects Versions: Realtime Branch
>Reporter: Jason Rutherglen
> Fix For: Realtime Branch
>
> Attachments: LUCENE-2655.patch
>
>
> Deletes don't work anymore, a patch here will fix this.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[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=12920272#action_12920272
 ] 

Bill Bell commented on SOLR-773:


PB and SR:

http://:8983/solr/core0/select?fl=*,score&qf=namesearch&pf=namesearch&start=0&rows=10&q=bill&qt=standard&pt=39.7391536,-104.9847034&d=160.9344&fq={!sfilt%20fl=store_lat_lon}&sort=hsin(6371,true,store,vector(39.7391536,-104.9847034))+asc,+score+desc
 

This is an example, that queries the index and returns those points 100 miles 
(160.93km) away from Denver, CO (39.7391536,-104.9847034).

It also does a dismax query on namesearch for "bill".

It sorts the results by distance in km. To show the distance use a Javascript 
hsin() function when you loop through your results.

i.e.:
{code}
function toRad(val) {
return (Math.PI*val/180);
};
 
 
function hsin(lat1,lon1,lat2,lon2) {
 
var R = 3958.761; //miles
var dLat = toRad(lat2-lat1);
var dLon = toRad(lon2-lon1); 
var a = Math.sin(dLat/2) * Math.sin(dLat/2) +
Math.cos(toRad(lat1)) * Math.cos(toRad(lat2)) * 
Math.sin(dLon/2) * Math.sin(dLon/2); 
var c = 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1-a)); 
var d = R * c;
return d;
};
{code}




> 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: Next
>
> Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, 
> lucene.tar.gz, screenshot-1.jpg, 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.


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Using long instead of int for docIds

[Israel Ekpo]

Excellent response guys.

Thanks a lot for the input.

On Tue, Oct 12, 2010 at 9:13 AM, Yonik Seeley wrote:

> On Tue, Oct 12, 2010 at 8:19 AM, eks dev  wrote:
> > --- the practical limit for a single lucene index is ~100M docs anyway
> ---
> >
> > I do not see it that way, there are very practical cases (short
> documents)
> > with 250M docs and  sub-second response times :)
> > And I believe it can be pushed even further, especially when flex branch
> > stabilizes
>
> Of course... I've seen much bigger single indexes myself.
> But I think it's a good ballpark for a "practical" upper bound when
> you need to give one to people w/o further knowledge of their problem.
>  People are normally better off sharding at that level, and often far
> below that level, depending on the complexity of the queries,
> faceting, etc).
>
> -Yonik
> http://www.lucidimagination.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
°O°
"Good Enough" is not good enough.
To give anything less than your best is to sacrifice the gift.
Quality First. Measure Twice. Cut Once.
http://www.israelekpo.com/

[jira] Updated: (SOLR-2151) MappingUpdateProcessor

[JIRA]

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

Jan Høydahl updated SOLR-2151:
--

Attachment: SOLR-2151-solr1.4.patch

Updated so that fallback value is not set if null or empty

> MappingUpdateProcessor
> --
>
> Key: SOLR-2151
> URL: https://issues.apache.org/jira/browse/SOLR-2151
> Project: Solr
>  Issue Type: New Feature
>  Components: update
>Reporter: Jan Høydahl
> Attachments: SOLR-2151-solr1.4.patch, SOLR-2151-solr1.4.patch
>
>
> Implement an UpdateProcessor which can read one field, lookup the value in a 
> dictionary and write the mapped value to another field.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Commented: (SOLR-2152) Apply "filters" to mlt queries without using filters.

[Sven Almgren (JIRA)]

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

Sven Almgren commented on SOLR-2152:


The idea is to inject the additional query around the PriorityQueue created by 
the MoreLikeThis class. MLT query is basically a big OR'ed query from 
"interesting terms", and we want to add requirements to this query.

My solution would be to wrap the result from MoreLikeThis.like() with this 
"constraints query", like how the original document is excluded from the result.

Change

{code} 
// exclude current document from results
BooleanQuery mltQuery = new BooleanQuery();
mltQuery.add(mltquery, BooleanClause.Occur.MUST);
mltQuery.add(
new TermQuery(new Term(uniqueKeyField.getName(), 
uniqueKeyField.getType().storedToIndexed(doc.getFieldable(uniqueKeyField.getName(),
 
BooleanClause.Occur.MUST_NOT);
{code}

into something like

{code} 
BooleanQuery constraint = GetThisQueryFrom("mlt.constraint");
// exclude current document from results
BooleanQuery mltQuery = new BooleanQuery();
mltQuery.add(mltquery, BooleanClause.Occur.MUST);
mltQuery.add(constraint, BooleanClause.Occur.MUST);
mltQuery.add(
new TermQuery(new Term(uniqueKeyField.getName(), 
uniqueKeyField.getType().storedToIndexed(doc.getFieldable(uniqueKeyField.getName(),
 
BooleanClause.Occur.MUST_NOT);
{code} 


> Apply "filters" to mlt queries without using filters.
> -
>
> Key: SOLR-2152
> URL: https://issues.apache.org/jira/browse/SOLR-2152
> Project: Solr
>  Issue Type: New Feature
>  Components: MoreLikeThis
>Reporter: Sven Almgren
>
> We need to provide some additional constraints on the results from 
> MoreLikeThis but would prefer not to trash our caches with short lived 
> filters.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Created: (SOLR-2152) Apply "filters" to mlt queries without using filters.

[Sven Almgren (JIRA)]

Apply "filters" to mlt queries without using filters.
-

 Key: SOLR-2152
 URL: https://issues.apache.org/jira/browse/SOLR-2152
 Project: Solr
  Issue Type: New Feature
  Components: MoreLikeThis
Reporter: Sven Almgren


We need to provide some additional constraints on the results from MoreLikeThis 
but would prefer not to trash our caches with short lived filters.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Using long instead of int for docIds

[Yonik Seeley]

On Tue, Oct 12, 2010 at 8:19 AM, eks dev  wrote:
> --- the practical limit for a single lucene index is ~100M docs anyway ---
>
> I do not see it that way, there are very practical cases (short documents)
> with 250M docs and  sub-second response times :)
> And I believe it can be pushed even further, especially when flex branch
> stabilizes

Of course... I've seen much bigger single indexes myself.
But I think it's a good ballpark for a "practical" upper bound when
you need to give one to people w/o further knowledge of their problem.
 People are normally better off sharding at that level, and often far
below that level, depending on the complexity of the queries,
faceting, etc).

-Yonik
http://www.lucidimagination.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Updated: (SOLR-2151) MappingUpdateProcessor

[JIRA]

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

Jan Høydahl updated SOLR-2151:
--

Attachment: SOLR-2151-solr1.4.patch

First crash-implementation, without any tests or anything. It only supports a 
mapping file similar to the synonyms.txt file format, but currently supports 
only a simple from=>to mapping. No expand, no case insensitive, etc.

The patch SOLR-2151-solr1.4.patch is against the 1.4 branch, not trunk.

Configure the UpdateProcessor like this:

{code:xml}

  myInputField
  myOutputField
  id
  
  innbinding-sokeord_mapping.txt

{code}

> MappingUpdateProcessor
> --
>
> Key: SOLR-2151
> URL: https://issues.apache.org/jira/browse/SOLR-2151
> Project: Solr
>  Issue Type: New Feature
>  Components: update
>Reporter: Jan Høydahl
> Attachments: SOLR-2151-solr1.4.patch
>
>
> Implement an UpdateProcessor which can read one field, lookup the value in a 
> dictionary and write the mapped value to another field.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Created: (SOLR-2151) MappingUpdateProcessor

[JIRA]

MappingUpdateProcessor
--

 Key: SOLR-2151
 URL: https://issues.apache.org/jira/browse/SOLR-2151
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Jan Høydahl


Implement an UpdateProcessor which can read one field, lookup the value in a 
dictionary and write the mapped value to another field.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Using long instead of int for docIds

[eks dev]

--- the practical limit for a single lucene index is ~100M docs anyway ---

I do not see it that way, there are very practical cases (short documents)
with 250M docs and  sub-second response times :)
And I believe it can be pushed even further, especially when flex branch
stabilizes

Changes nothing on your int/long point, just doing the justice to Lucene

Cheers,
eks

On Tue, Oct 12, 2010 at 1:01 PM, Israel Ekpo  wrote:

> Thanks Yonik for responding.
>
> This clarifies a lot.
>
> On Mon, Oct 11, 2010 at 11:11 PM, Yonik Seeley  > wrote:
>
>> I think ints instead of longs for docids is still the best practical
>> choice for today.
>> - longs double the size it takes to store collected ids
>> - Java native arrays are indexed by int (hence we couldn't collect
>> more than 2B matches easily anyway)
>> - the practical limit for a single lucene index is ~100M docs anyway
>>
>> But, perhaps MultiSearcher (or a new class called BigMultiSearcher)
>> should start using longs.
>>
>> -Yonik
>>
>> On Mon, Oct 11, 2010 at 1:24 AM, Israel Ekpo 
>> wrote:
>> > Hi Solr Devs,
>> >
>> > I have always had this question at the back of my mind and I would love
>> to
>> > know the answers to a couple of questions.
>> >
>> > 1. Does using int for document ids place any restrictions on the number
>> of
>> > documents that can be stored in a single index? I am assuming we cannot
>> go
>> > beyond 2 to power 31 minus 1 documents but I have not actually test this
>> > yet.
>> >
>> > 2. What would it take to change the core to use long instead of int for
>> > document ids?
>> >
>> > 3. Would there be any practical gains or benefits of making such a
>> change?
>> >
>> > I initially wanted to send this question to the Stomp the Chomp
>> challenge
>> > but I figured it would be better to open it to all.
>> >
>> > Any useful feedbacks will be highly appreciated.
>> >
>> > --
>> > °O°
>> > "Good Enough" is not good enough.
>> > To give anything less than your best is to sacrifice the gift.
>> > Quality First. Measure Twice. Cut Once.
>> > http://www.israelekpo.com/
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
>
> --
> °O°
> "Good Enough" is not good enough.
> To give anything less than your best is to sacrifice the gift.
> Quality First. Measure Twice. Cut Once.
> http://www.israelekpo.com/
>

Re: Using long instead of int for docIds

[Israel Ekpo]

Thanks Yonik for responding.

This clarifies a lot.

On Mon, Oct 11, 2010 at 11:11 PM, Yonik Seeley
wrote:

> I think ints instead of longs for docids is still the best practical
> choice for today.
> - longs double the size it takes to store collected ids
> - Java native arrays are indexed by int (hence we couldn't collect
> more than 2B matches easily anyway)
> - the practical limit for a single lucene index is ~100M docs anyway
>
> But, perhaps MultiSearcher (or a new class called BigMultiSearcher)
> should start using longs.
>
> -Yonik
>
> On Mon, Oct 11, 2010 at 1:24 AM, Israel Ekpo  wrote:
> > Hi Solr Devs,
> >
> > I have always had this question at the back of my mind and I would love
> to
> > know the answers to a couple of questions.
> >
> > 1. Does using int for document ids place any restrictions on the number
> of
> > documents that can be stored in a single index? I am assuming we cannot
> go
> > beyond 2 to power 31 minus 1 documents but I have not actually test this
> > yet.
> >
> > 2. What would it take to change the core to use long instead of int for
> > document ids?
> >
> > 3. Would there be any practical gains or benefits of making such a
> change?
> >
> > I initially wanted to send this question to the Stomp the Chomp challenge
> > but I figured it would be better to open it to all.
> >
> > Any useful feedbacks will be highly appreciated.
> >
> > --
> > °O°
> > "Good Enough" is not good enough.
> > To give anything less than your best is to sacrifice the gift.
> > Quality First. Measure Twice. Cut Once.
> > http://www.israelekpo.com/
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>


-- 
°O°
"Good Enough" is not good enough.
To give anything less than your best is to sacrifice the gift.
Quality First. Measure Twice. Cut Once.
http://www.israelekpo.com/

[jira] Commented: (LUCENE-2186) First cut at column-stride fields (index values storage)

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920151#action_12920151
 ] 

Michael McCandless commented on LUCENE-2186:


bq. Implement bulk copies for merging where possible. 

I don't think this should block landing on trunk?  (Even in the non-deletes 
case).

But, yes, searching for next del doc is a linear op, but a very small constant 
in front (at least OpenBitSet.nextSetBit, though del docs are currently a 
BitVector), yet is very much worth it once we get the bulk copying in since 
presumably big chunks of docs can be bulk copied.

bq. Exposing the API via Fields / IndexReader. I think we should expose the 
Iterator API via Fields just like Terms is today. Currently it doesn't feel 
very natural to get the ValuesEnum via IR.

Ahh that does sound like the right place.

bq. Maybe if we wanna populate FieldsCache from it. 

We should be careful here -- it's best if things consume the docvalues instead 
of double-copying into the FC.

> First cut at column-stride fields (index values storage)
> 
>
> Key: LUCENE-2186
> URL: https://issues.apache.org/jira/browse/LUCENE-2186
> Project: Lucene - Java
>  Issue Type: New Feature
>  Components: Index
>Reporter: Michael McCandless
>Assignee: Simon Willnauer
> Fix For: 4.0
>
> Attachments: LUCENE-2186.patch, LUCENE-2186.patch, LUCENE-2186.patch, 
> LUCENE-2186.patch, LUCENE-2186.patch, mem.py
>
>
> I created an initial basic impl for storing "index values" (ie
> column-stride value storage).  This is still a work in progress... but
> the approach looks compelling.  I'm posting my current status/patch
> here to get feedback/iterate, etc.
> The code is standalone now, and lives under new package
> oal.index.values (plus some util changes, refactorings) -- I have yet
> to integrate into Lucene so eg you can mark that a given Field's value
> should be stored into the index values, sorting will use these values
> instead of field cache, etc.
> It handles 3 types of values:
>   * Six variants of byte[] per doc, all combinations of fixed vs
> variable length, and stored either "straight" (good for eg a
> "title" field), "deref" (good when many docs share the same value,
> but you won't do any sorting) or "sorted".
>   * Integers (variable bit precision used as necessary, ie this can
> store byte/short/int/long, and all precisions in between)
>   * Floats (4 or 8 byte precision)
> String fields are stored as the UTF8 byte[].  This patch adds a
> BytesRef, which does the same thing as flex's TermRef (we should merge
> them).
> This patch also adds basic initial impl of PackedInts (LUCENE-1990);
> we can swap that out if/when we get a better impl.
> This storage is dense (like field cache), so it's appropriate when the
> field occurs in all/most docs.  It's just like field cache, except the
> reading API is a get() method invocation, per document.
> Next step is to do basic integration with Lucene, and then compare
> sort performance of this vs field cache.
> For the "sort by String value" case, I think RAM usage & GC load of
> this index values API should be much better than field caache, since
> it does not create object per document (instead shares big long[] and
> byte[] across all docs), and because the values are stored in RAM as
> their UTF8 bytes.
> There are abstract Writer/Reader classes.  The current reader impls
> are entirely RAM resident (like field cache), but the API is (I think)
> agnostic, ie, one could make an MMAP impl instead.
> I think this is the first baby step towards LUCENE-1231.  Ie, it
> cannot yet update values, and the reading API is fully random-access
> by docID (like field cache), not like a posting list, though I
> do think we should add an iterator() api (to return flex's DocsEnum)
> -- eg I think this would be a good way to track avg doc/field length
> for BM25/lnu.ltc scoring.

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Resolved: (LUCENE-2696) TestIndexWriterDelete makes broken segments with payloads on

[Michael McCandless (JIRA)]

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

Michael McCandless resolved LUCENE-2696.


   Resolution: Fixed
Fix Version/s: 4.0

> TestIndexWriterDelete makes broken segments with payloads on
> 
>
> Key: LUCENE-2696
> URL: https://issues.apache.org/jira/browse/LUCENE-2696
> Project: Lucene - Java
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 4.0
>Reporter: Robert Muir
>Assignee: Michael McCandless
> Fix For: 4.0
>
> Attachments: LUCENE-2696.patch, LUCENE-2696.patch, 
> LUCENE-2696_test.patch
>
>
> This could just be a SimpleText problem but just in case
> Grant added payloads to MockAnalyzer in LUCENE-2692
> I wondered what would happen if i turned on his payload filter by default for 
> all tests.
> {noformat}
> [junit] Testsuite: org.apache.lucene.index.TestIndexWriterDelete
> [junit] Testcase: 
> testDeletesOnDiskFull(org.apache.lucene.index.TestIndexWriterDelete): 
> Caused an ERROR
> [junit] CheckIndex failed
> [junit] java.lang.RuntimeException: CheckIndex failed
> [junit] at 
> org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:80)
> [junit] at 
> org.apache.lucene.index.TestIndexWriterDelete.doTestOperationsOnDiskFull(TestIndexWriterDelete.java:5
> 38)
> [junit] at 
> org.apache.lucene.index.TestIndexWriterDelete.testDeletesOnDiskFull(TestIndexWriterDelete.java:401)
> [junit] at 
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:795)
> [junit] at 
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:768)
> [junit]
> [junit]
> [junit] Testcase: 
> testUpdatesOnDiskFull(org.apache.lucene.index.TestIndexWriterDelete): 
> Caused an ERROR
> [junit] CheckIndex failed
> [junit] java.lang.RuntimeException: CheckIndex failed
> [junit] at 
> org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:80)
> [junit] at 
> org.apache.lucene.index.TestIndexWriterDelete.doTestOperationsOnDiskFull(TestIndexWriterDelete.java:5
> 38)
> [junit] at 
> org.apache.lucene.index.TestIndexWriterDelete.testUpdatesOnDiskFull(TestIndexWriterDelete.java:405)
> [junit] at 
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:795)
> [junit] at 
> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:768)
> [junit]
> [junit]
> [junit] Tests run: 14, Failures: 0, Errors: 2, Time elapsed: 0.322 sec
> [junit]
> [junit] - Standard Output ---
> [junit] CheckIndex failed
> [junit] Segments file=segments_2 numSegments=1 version=FORMAT_4_0 [Lucene 
> 4.0]
> [junit]   1 of 1: name=_0 docCount=157
> [junit] codec=MockFixedIntBlock
> [junit] compound=true
> [junit] hasProx=true
> [junit] numFiles=2
> [junit] size (MB)=0,017
> [junit] diagnostics = {os.version=6.0, os=Windows Vista, 
> lucene.version=4.0-SNAPSHOT, source=flush, os.arch=x86,
>  java.version=1.6.0_21, java.vendor=Sun Microsystems Inc.}
> [junit] has deletions [delFileName=_0_1.del]
> [junit] test: open reader.OK [13 deleted docs]
> [junit] test: fields..OK [2 fields]
> [junit] test: field norms.OK [2 fields]
> [junit] test: terms, freq, prox...ERROR [read past EOF]
> [junit] java.io.IOException: read past EOF
> [junit] at 
> org.apache.lucene.store.BufferedIndexInput.refill(BufferedIndexInput.java:154)
> [junit] at 
> org.apache.lucene.store.BufferedIndexInput.readBytes(BufferedIndexInput.java:119)
> [junit] at 
> org.apache.lucene.store.BufferedIndexInput.readBytes(BufferedIndexInput.java:94)
> [junit] at 
> org.apache.lucene.index.codecs.sep.SepPostingsReaderImpl$SepDocsAndPositionsEnum.getPayload(SepPostin
> gsReaderImpl.java:689)
> [junit] at 
> org.apache.lucene.index.CheckIndex.testTermIndex(CheckIndex.java:693)
> [junit] at 
> org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:489)
> [junit] at 
> org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:290)
> [junit] at 
> org.apache.lucene.index.CheckIndex.checkIndex(CheckIndex.java:286)
> [junit] at 
> org.apache.lucene.util._TestUtil.checkIndex(_TestUtil.java:76)
> [junit] at 
> org.apache.lucene.index.TestIndexWriterDelete.doTestOperationsOnDiskFull(TestIndexWriterDelete.java:5
> 38)
> [junit] at 
> org.apache.lucene.index.TestIndexWriterDelete.testDeletesOnDiskFull(TestIndexWriterDelete.java:401)
> [junit] at sun.reflect.NativeMethodAccessorImpl.i

[jira] Updated: (LUCENE-2697) SortedVIntList should be Serializable

[Federico Fissore (JIRA)]

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

Federico Fissore updated LUCENE-2697:
-


Moreover, OpenBitSet IS both Serializable and Clonable
SortedVIntList should also be

> SortedVIntList should be Serializable
> -
>
> Key: LUCENE-2697
> URL: https://issues.apache.org/jira/browse/LUCENE-2697
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Search
>Affects Versions: 2.9.3, 3.0.2
>Reporter: Federico Fissore
>
> For some memory intensive searchers we have, it is important to temporarily 
> store the created bitsets to disk
> SortedVIntList does not implement Serializable: since it could be easily 
> serialized due to the raw data it contains, it should implement it
> We are currently working with a custom SerializableSortedVIntList: we've just 
> copied the code and added Serializable but we would definitely like to stick 
> on lucene official code rather than such customizations
> Hope you will accept the proposal

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Updated: (LUCENE-2697) SortedVIntList should be Serializable

[Federico Fissore (JIRA)]

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

Federico Fissore updated LUCENE-2697:
-

Affects Version/s: 3.0.2

> SortedVIntList should be Serializable
> -
>
> Key: LUCENE-2697
> URL: https://issues.apache.org/jira/browse/LUCENE-2697
> Project: Lucene - Java
>  Issue Type: Improvement
>  Components: Search
>Affects Versions: 2.9.3, 3.0.2
>Reporter: Federico Fissore
>
> For some memory intensive searchers we have, it is important to temporarily 
> store the created bitsets to disk
> SortedVIntList does not implement Serializable: since it could be easily 
> serialized due to the raw data it contains, it should implement it
> We are currently working with a custom SerializableSortedVIntList: we've just 
> copied the code and added Serializable but we would definitely like to stick 
> on lucene official code rather than such customizations
> Hope you will accept the proposal

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Hudson build is back to normal : Solr-trunk #1276

[Apache Hudson Server]

See 



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] Created: (LUCENE-2697) SortedVIntList should be Serializable

[Federico Fissore (JIRA)]

SortedVIntList should be Serializable
-

 Key: LUCENE-2697
 URL: https://issues.apache.org/jira/browse/LUCENE-2697
 Project: Lucene - Java
  Issue Type: Improvement
  Components: Search
Affects Versions: 2.9.3
Reporter: Federico Fissore


For some memory intensive searchers we have, it is important to temporarily 
store the created bitsets to disk
SortedVIntList does not implement Serializable: since it could be easily 
serialized due to the raw data it contains, it should implement it

We are currently working with a custom SerializableSortedVIntList: we've just 
copied the code and added Serializable but we would definitely like to stick on 
lucene official code rather than such customizations

Hope you will accept the proposal

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


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

multi cores vs filter queries for a multi tenant deployment

[Tharindu Mathew]

Hi everyone,

I'm sort of looking in to a deployment which will support multi tenancy.
This means that there will be 1000s of tenant domains each having 1000s of
users. I need to figure out which approach is better for this deployment
when using the solr server.

Approach #1 - Use multi cores for each tenant and thereby use separate
indexes for each. If necessary use filter queries with user ids for users.
Approach #2 - Use filter queries with tenant ids to filter out results of
different tenant domains. Similarly, as above, use user ids as needed.

My concern comes on aspects of performance and security.

Will using approach #1 be a killer for performance? With this many number of
users, this setup has to scale smoothly for so many number of users. When
the deployment potentially will have 1000s of cores, how can I prevent a
security vulnerability appearing between cores?

What are the implications of using approach #2? Will I have to constantly
check around for code with security checks since only a single index is
used?

Any feedback for the above concerns would be really appreciated.

Thanks in advance.

-- 
Regards,

Tharindu