Re: Editing the PyLucene web site
Hi, Attached is a patch for content/pylucene/jcc/features.mdtext, tested with build_site script. I do not get the automatic code formatting to work by indenting 4 spaces, so I have manually wrapped the code sections in codepre tags, but the result is the same. Regards /Petrus On 20 jun 2012, at 18:54, Andi Vajda wrote: Hi Petrus, On Tue, 19 Jun 2012, Petrus Hyvönen wrote: Attached is an diff update to the mdtext files with jcc documentation. I didn't manage to get the site build system to work, I think a perl markdown module is needed, which I get build error when installing. If you don't tell me what error, it's that much harder to help you. However there are some mdtext editors around, so I just updated some of the text in there, please check that it looks ok before activating. I took a quick look and your changes did not have much effect. Please test your changes using the CMS build system. For example, it seems that your addition of ``` line 23 in features.mdtext had no effect. It's going to be very difficult to do this blind. Did you follow all the steps listed in in LUCENE-2748 comment I sent you a link to, in particular, what's described at http://www.apache.org/dev/cmsref.html#local-build, especially these steps listed there ? $ cd /path/to/cms/build/tree $ export MARKDOWN_SOCKET=`pwd`/markdown.socket PYTHONPATH=`pwd` $ python markdownd.py Thanks for trying but if I end up spending more time debugging what you send me than doing it myself, the situation is even worse and going nowhere :-( Cheers ! Andi.. Best Regards /Petrus On 18 jun 2012, at 01:17, Andi Vajda wrote:
[jira] [Commented] (LUCENE-4167) Remove the use of SpatialOperation
[
https://issues.apache.org/jira/browse/LUCENE-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402883#comment-13402883
]
Ryan McKinley commented on LUCENE-4167:
---
This is essentially a java API vs 'query string' question. As is we
essentially pass the query string all the way to the SpatialStrategy before it
checks the operation; Chris proposes that the operation should be parsed
*before* it gets to the strategy and have real java functions for each
operation.
I support:
* removing the make* functions from SpatialStrategy
* for each possible strategy, we would create an interface like:
{code:java}
interface IntersectsSpatialQueryBuilder {
public Query makeIntersectsQuery(SpatialArgs args);
public Filter makeIntersectsFilter(SpatialArgs args);
}
interface IsWithinSpatialQueryBuilder {
public Query makeIsWithinQuery(SpatialArgs args);
public Filter makeIsWithinFilter(SpatialArgs args);
}
{code}
and then concrete SpatialStrategy implementations would implement everything
they can do. This may be just Intersects, or it may be a list of 10 things it
can do.
The advantage to this approach would be:
* clear java API and good place in javadocs to give the inevitable caveats for
the operation implementation details
* testing can check for instances of 'IsWithinSpatialQueryBuilder'
The end user query string can still look like INTERSECTS( ) but this
would let us take that parsing out of the indexing class.
- - - -
I'm going to go ahead and push the BBox strategy into trunk because it is a
strategy with a bunch of operations, and i want to make sure general operations
remain a top level concept.
Remove the use of SpatialOperation
--
Key: LUCENE-4167
URL: https://issues.apache.org/jira/browse/LUCENE-4167
Project: Lucene - Java
Issue Type: Bug
Components: modules/spatial
Reporter: Chris Male
Attachments: LUCENE-4167.patch
Looking at the code in TwoDoublesStrategy I noticed
SpatialOperations.BBoxWithin vs isWithin which confused me. Looking over the
other Strategys I see that really only isWithin and Intersects is supported.
Only TwoDoublesStrategy supports IsDisjointTo. The remainder of
SpatialOperations are not supported.
I don't think we should use SpatialOperation as this stage since it is not
clear what Operations are supported by what Strategys, many Operations are
not supported, and the code for handling the Operations is usually the same.
We can spin off the code for TwoDoublesStrategy's IsDisjointTo support into a
different Strategy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Make ivy search maven repo1/repo2?
Interesting. I think they should be identical mirrors of each other. Benson has more knowledge of Maven -- perheps he'll be able to tell if this is a bug in the repo sync or something to be expected? Dawid On Thu, Jun 28, 2012 at 4:11 AM, Lance Norskog goks...@gmail.com wrote: How can I get ivy to include the maven.org repo2 in the resolver list? Is there a reason it is not in the list? I ask because there is an artifact (extjwnl) which is only on repo2. -- Lance Norskog goks...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4157) Improve Spatial Testing
[ https://issues.apache.org/jira/browse/LUCENE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-4157: - Attachment: LUCENE-4157_Improve_TermQueryPrefixTreeStrategy_and_move_makeQuery_impl_to_SpatialStrategy.patch The attached patch improves TermQueryPrefixTreeStrategy: * based on TermsFilter instead of BooleanQuery * scores of Query are now via ValueSource and thus sorting is what we want now These changes made some tests pass. Those tests will be another patch (maybe tomorrow). Additionally: * refactored the generic makeQuery() impl from RecursivePrefixTreeFilter to become the default impl in SpatialStrategy, used by both PrefixTree Strategies. I'm going to commit this in a minute. Improve Spatial Testing --- Key: LUCENE-4157 URL: https://issues.apache.org/jira/browse/LUCENE-4157 Project: Lucene - Java Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Priority: Critical Fix For: 4.0 Attachments: LUCENE-4157_Improve_Lucene_Spatial_testing_p1.patch, LUCENE-4157_Improve_TermQueryPrefixTreeStrategy_and_move_makeQuery_impl_to_SpatialStrategy.patch Looking back at the tests for the Lucene Spatial Module, they seem half-baked. (At least Spatial4j is well tested). I've started working on some improvements: * Some tests are in an abstract base class which have a subclass that provides a SpatialContext. The idea was that the same tests could test other contexts (such as geo vs not or different distance calculators (haversine vs vincenty) but this can be done using RandomizedTesting's nifty parameterized test feature, once there is a need to do this. * Port the complex geohash recursive prefix tree test that was developed on the Solr side to the Lucene side where it belongs. And some things are not tested or aren't well tested: * Distance order as the query score * Indexing shapes other than points (i.e. shapes with area / regions) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Make ivy search maven repo1/repo2?
My mistake. I meant that Ivy was not using the maven.org repos at all. On Wed, Jun 27, 2012 at 11:17 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: Interesting. I think they should be identical mirrors of each other. Benson has more knowledge of Maven -- perheps he'll be able to tell if this is a bug in the repo sync or something to be expected? Dawid On Thu, Jun 28, 2012 at 4:11 AM, Lance Norskog goks...@gmail.com wrote: How can I get ivy to include the maven.org repo2 in the resolver list? Is there a reason it is not in the list? I ask because there is an artifact (extjwnl) which is only on repo2. -- Lance Norskog goks...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Lance Norskog goks...@gmail.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Make ivy search maven repo1/repo2?
I think it is? By default one of the resolvers pulls from
repo1.maven.org -- look at ivy-settings.xml:
include url=${ivy.default.settings.dir}/ivysettings-public.xml/
include url=${ivy.default.settings.dir}/ivysettings-shared.xml/
include url=${ivy.default.settings.dir}/ivysettings-local.xml/
include url=${ivy.default.settings.dir}/ivysettings-main-chain.xml/
the main chain includes shared repos and shared is:
ibiblio name=public m2compatible=true/
And ibiblio is by default pulling from maven repos:
http://ant.apache.org/ivy/history/latest-milestone/resolver/ibiblio.html
Dawid
On Thu, Jun 28, 2012 at 8:31 AM, Lance Norskog goks...@gmail.com wrote:
My mistake. I meant that Ivy was not using the maven.org repos at all.
On Wed, Jun 27, 2012 at 11:17 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
Interesting. I think they should be identical mirrors of each other.
Benson has more knowledge of Maven -- perheps he'll be able to tell if
this is a bug in the repo sync or something to be expected?
Dawid
On Thu, Jun 28, 2012 at 4:11 AM, Lance Norskog goks...@gmail.com wrote:
How can I get ivy to include the maven.org repo2 in the resolver list?
Is there a reason it is not in the list?
I ask because there is an artifact (extjwnl) which is only on repo2.
--
Lance Norskog
goks...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
Lance Norskog
goks...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4167) Remove the use of SpatialOperation
[ https://issues.apache.org/jira/browse/LUCENE-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402888#comment-13402888 ] David Smiley commented on LUCENE-4167: -- Thanks for your input Ryan. bq. Chris proposes that the operation should be parsed before it gets to the strategy and have real java functions for each operation. makeFilter makeQuery receives a SpatialArgs object which has already been parsed; it's not a string anymore. (The Command design pattern, by the way). And he's also proposing that SpatialArgs is gone, at least from these methods, and instead you get a Shape + distancePrecision pair of args. Somewhat related to this is the Filter/Query distinction. Minutes ago I had the realization that makeQuery() could have a fixed implementation based on makeFilter() with makeValueSource() (for the distance). It's already committed so you can see. Assuming you also think it makes a good default implementation, this suggests any variety of makeQuery would call the same method, which seems less than ideal but not terrible. Remove the use of SpatialOperation -- Key: LUCENE-4167 URL: https://issues.apache.org/jira/browse/LUCENE-4167 Project: Lucene - Java Issue Type: Bug Components: modules/spatial Reporter: Chris Male Attachments: LUCENE-4167.patch Looking at the code in TwoDoublesStrategy I noticed SpatialOperations.BBoxWithin vs isWithin which confused me. Looking over the other Strategys I see that really only isWithin and Intersects is supported. Only TwoDoublesStrategy supports IsDisjointTo. The remainder of SpatialOperations are not supported. I don't think we should use SpatialOperation as this stage since it is not clear what Operations are supported by what Strategys, many Operations are not supported, and the code for handling the Operations is usually the same. We can spin off the code for TwoDoublesStrategy's IsDisjointTo support into a different Strategy. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-3574) Create a Compound Word Filter (and Factory) extension that will allow support for (word) exceptions
[ https://issues.apache.org/jira/browse/SOLR-3574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Despot Jakimovski reassigned SOLR-3574: --- Assignee: Despot Jakimovski Create a Compound Word Filter (and Factory) extension that will allow support for (word) exceptions --- Key: SOLR-3574 URL: https://issues.apache.org/jira/browse/SOLR-3574 Project: Solr Issue Type: New Feature Components: SearchComponents - other Affects Versions: 4.0, 4.1, 5.0 Reporter: Despot Jakimovski Assignee: Despot Jakimovski Labels: compound-word, dictionary, feature, filter, word-exception Fix For: 4.0, 4.1, 5.0 Original Estimate: 72h Remaining Estimate: 72h When having the following use case: We have 2 words penslot and knoppen. One of them presents a compound word (penslot), the other one is a plural form of knop. When using the compound word filter, if we place the words pen slot and knop in the dictionary, for a search containing knoppen, we get results containing pen also, which shouldn't be the case, because knoppen is only a plural form (not a compound word). We need another dictionary to specify the words that are exceptions to the filter (like in this case knoppen). In this case, the filter would find compound words containing pen slot and knop, but will leave out dividing knoppen and searching on its parts. More info on the subject: http://stackoverflow.com/questions/11159839/can-we-make-the-compound-word-filter-not-divide-some-words-in-solr -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4174) Some test statistics (mean, stddev).
Dawid Weiss created LUCENE-4174: --- Summary: Some test statistics (mean, stddev). Key: LUCENE-4174 URL: https://issues.apache.org/jira/browse/LUCENE-4174 Project: Lucene - Java Issue Type: Bug Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: JIRA assignee options
Thanks to both! Now I am able to assign the task to myself. Cheers! On Wed, Jun 27, 2012 at 8:16 PM, Robert Muir rcm...@gmail.com wrote: I added you to the 'contributor' role. so you should be able to do this now: though I dont know if you need to logout and log back in, or if it takes place immediately Let me know if you have problems! On Wed, Jun 27, 2012 at 1:19 PM, Despot Jakimovski despot.jakimov...@gmail.com wrote: Hi, I would like to assign myself to the JIRA task, but I cannot find the Assign to button. Probably I am missing some privileges. Can someone help me fix this? Cheers, despot -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3580) In ExtendedDismax, lowercase 'not' operator is not being treated as an operator when 'lowercaseOperators' is enabled
[
https://issues.apache.org/jira/browse/SOLR-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402894#comment-13402894
]
Jan Høydahl commented on SOLR-3580:
---
Or redo the whole thing in a more generic way:
{noformat}
validOrOperators=OR,or (default=OR)
validAndOperators=AND,and (default=AND)
validNotOperators=NOT (default=NOT)
{noformat}
This way people cannot only add lowercase variants if wanted, but they can also
translate to their own language (Norwegian: ELLER / OG / IKKE) and take more
control alltogether; The old lowercaseOperators would be deprecated and removed
in next version.
In ExtendedDismax, lowercase 'not' operator is not being treated as an
operator when 'lowercaseOperators' is enabled
Key: SOLR-3580
URL: https://issues.apache.org/jira/browse/SOLR-3580
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 4.0
Reporter: Michael Dodsworth
Priority: Minor
Fix For: 4.0
Attachments: SOLR-3580.patch
When lowercase operator support is enabled (for edismax), the lowercase 'not'
operator is being wrongly treated as a literal term (and not as an operator).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4174) Some test statistics (mean, stddev).
[
https://issues.apache.org/jira/browse/LUCENE-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402898#comment-13402898
]
Dawid Weiss commented on LUCENE-4174:
-
I calculated simple stats from a dozen test runs on my build machine (trunk at
Jun 28, 2012).
h3. The slowest tests (mean time, stddev)
{noformat}
name | mean| stddev | min| max
BasicDistributedZkTest | 168155 | 12697 | 136591 | 192507
FullSolrCloudTest | 95912 | 5867 | 76449 | 102628
OverseerTest | 95801 | 9025 | 82868 | 108840
RecoveryZkTest | 82924 | 13524 | 63800 | 115504
TestJoinUtil | 69328 | 74451 | 7358 | 268199
SpellCheckComponentTest| 65744 | 14222 | 38798 | 85575
FullSolrCloudDistribCmdsTest | 49543 | 2837 | 45376 | 53916
TestReplicationHandler | 45352 | 1863 | 41645 | 48253
LeaderElectionIntegrationTest | 42893 | 5400 | 33565 | 50718
TestLBHttpSolrServer | 35746 | 704| 34841 | 37133
LeaderElectionTest | 33766 | 6039 | 23574 | 45419
DistributedSpellCheckComponentTest | 30688 | 3500 | 23605 | 36914
TestRealTimeGet| 30642 | 3960 | 24503 | 39594
TestJapaneseTokenizer | 27920 | 5575 | 22090 | 48021
TestDuelingAnalyzers | 26972 | 4330 | 18522 | 33446
ZkControllerTest | 26740 | 8703 | 16446 | 45590
TestSynonymMapFilter | 24929 | 3784 | 19259 | 31461
NGramTokenizerTest | 22886 | 8533 | 13972 | 49923
TestIndexWriterWithThreads | 22195 | 7698 | 14150 | 46912
TestExtendedMode | 19029 | 5525 | 12693 | 38139
TestDistributedGrouping| 18384 | 3128 | 12726 | 24952
TestRandomFaceting | 17223 | 5578 | 7514 | 27142
SamplingAccumulatorTest| 16966 | 7418 | 8858 | 30789
CloudStateUpdateTest | 16611 | 2728 | 10203 | 21394
TestDistributedSearch | 15850 | 2450 | 12915 | 22035
TestPackedInts | 15469 | 3433 | 11274 | 25217
SamplingWrapperTest| 14782 | 6307 | 7890 | 28589
AdaptiveAccumulatorTest| 14672 | 4603 | 8838 | 26736
SpellCheckCollatorTest | 13402 | 3775 | 5068 | 18996
SolrExampleStreamingBinaryTest | 12692 | 1110 | 11701 | 15060
TestJapaneseAnalyzer | 12538 | 3785 | 7372 | 24728
SolrExampleStreamingTest | 12441 | 882| 11635 | 14698
UIMAUpdateRequestProcessorTest | 12053 | 346| 11135 | 12807
TestNorms | 11652 | 8949 | 1861 | 35629
TestFSTs | 11421 | 3263 | 6679 | 16884
SoftAutoCommitTest | 11157 | 794| 9906 | 12756
TestExtendedDismaxParser | 11149 | 1469 | 8410 | 13435
AutoCommitTest | 10827 | 752| 9228 | 11822
TestPhoneticFilterFactory | 10273 | 2269 | 8453 | 17129
BasicZkTest| 10001 | 1108 | 7167 | 11637
TestFaceting | 9927| 3660 | 6748 | 19713
TestPerfTasksLogic | 9842| 768| 8519 | 11465
TestGraphTokenizers| 9379| 2526 | 5502 | 13915
TestAnalyzers | 9378| 4605 | 5109 | 22722
TestHashPartitioner| 9351| 3664 | 6645 | 22686
ZkSolrClientTest | 9290| 824| 7845 | 10847
UIMATypeAwareAnnotationsTokenizerFactoryTe | 8883| 240| 8540 | 9393
UIMAAnnotationsTokenizerFactoryTest| 8748| 393| 7883 | 9308
TestGrouping | 8656| 1154 | 6909 | 11361
TestSmartChineseAnalyzer | 8594| 2904 | 6694 | 18657
WordBreakSolrSpellCheckerTest | 8501| 2056 | 4204 | 12071
TestIndexWriterReader | 8303| 3168 | 4899 | 14695
TestRecovery | 8247| 3132 | 5854 | 17090
DistributedTermsComponentTest | 8132| 797| 6736 | 9315
TestLookaheadTokenFilter | 7896| 3085 | 3992 | 14377
StatsComponentTest | 7767| 1015 | 6230 | 9364
TestJoin | 7764| 2381 | 5615 | 14003
{noformat}
h3.
Re: Make ivy search maven repo1/repo2?
It is working now. I did a complete update- that might be it.
Now, the next question: what build target makes Solr use new Lucene jars?
On Wed, Jun 27, 2012 at 11:37 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
I think it is? By default one of the resolvers pulls from
repo1.maven.org -- look at ivy-settings.xml:
include url=${ivy.default.settings.dir}/ivysettings-public.xml/
include url=${ivy.default.settings.dir}/ivysettings-shared.xml/
include url=${ivy.default.settings.dir}/ivysettings-local.xml/
include url=${ivy.default.settings.dir}/ivysettings-main-chain.xml/
the main chain includes shared repos and shared is:
ibiblio name=public m2compatible=true/
And ibiblio is by default pulling from maven repos:
http://ant.apache.org/ivy/history/latest-milestone/resolver/ibiblio.html
Dawid
On Thu, Jun 28, 2012 at 8:31 AM, Lance Norskog goks...@gmail.com wrote:
My mistake. I meant that Ivy was not using the maven.org repos at all.
On Wed, Jun 27, 2012 at 11:17 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
Interesting. I think they should be identical mirrors of each other.
Benson has more knowledge of Maven -- perheps he'll be able to tell if
this is a bug in the repo sync or something to be expected?
Dawid
On Thu, Jun 28, 2012 at 4:11 AM, Lance Norskog goks...@gmail.com wrote:
How can I get ivy to include the maven.org repo2 in the resolver list?
Is there a reason it is not in the list?
I ask because there is an artifact (extjwnl) which is only on repo2.
--
Lance Norskog
goks...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
Lance Norskog
goks...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
Lance Norskog
goks...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4175) Include BBox Spatial Strategy
Ryan McKinley created LUCENE-4175: - Summary: Include BBox Spatial Strategy Key: LUCENE-4175 URL: https://issues.apache.org/jira/browse/LUCENE-4175 Project: Lucene - Java Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley This is an approach to indexing bounding boxes using 4 numeric fields (xmin,ymin,xmax,ymax) and a flag to say if it crosses the dateline. This is a modification from the Apache 2.0 code from the ESRI Geoportal: http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4174) Some test statistics (mean, stddev).
[ https://issues.apache.org/jira/browse/LUCENE-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-4174: Attachment: Selection_001.png Logarithmic scale test time distribution (by mean, desc). Some test statistics (mean, stddev). Key: LUCENE-4174 URL: https://issues.apache.org/jira/browse/LUCENE-4174 Project: Lucene - Java Issue Type: Bug Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Attachments: Selection_001.png -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Make ivy search maven repo1/repo2?
Are you talking about the maven build or the ant build?
D.
On Thu, Jun 28, 2012 at 9:23 AM, Lance Norskog goks...@gmail.com wrote:
It is working now. I did a complete update- that might be it.
Now, the next question: what build target makes Solr use new Lucene jars?
On Wed, Jun 27, 2012 at 11:37 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
I think it is? By default one of the resolvers pulls from
repo1.maven.org -- look at ivy-settings.xml:
include url=${ivy.default.settings.dir}/ivysettings-public.xml/
include url=${ivy.default.settings.dir}/ivysettings-shared.xml/
include url=${ivy.default.settings.dir}/ivysettings-local.xml/
include url=${ivy.default.settings.dir}/ivysettings-main-chain.xml/
the main chain includes shared repos and shared is:
ibiblio name=public m2compatible=true/
And ibiblio is by default pulling from maven repos:
http://ant.apache.org/ivy/history/latest-milestone/resolver/ibiblio.html
Dawid
On Thu, Jun 28, 2012 at 8:31 AM, Lance Norskog goks...@gmail.com wrote:
My mistake. I meant that Ivy was not using the maven.org repos at all.
On Wed, Jun 27, 2012 at 11:17 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
Interesting. I think they should be identical mirrors of each other.
Benson has more knowledge of Maven -- perheps he'll be able to tell if
this is a bug in the repo sync or something to be expected?
Dawid
On Thu, Jun 28, 2012 at 4:11 AM, Lance Norskog goks...@gmail.com wrote:
How can I get ivy to include the maven.org repo2 in the resolver list?
Is there a reason it is not in the list?
I ask because there is an artifact (extjwnl) which is only on repo2.
--
Lance Norskog
goks...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
Lance Norskog
goks...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
Lance Norskog
goks...@gmail.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4174) Some test statistics (mean, stddev).
[ https://issues.apache.org/jira/browse/LUCENE-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-4174. - Resolution: Not A Problem This is just informational. It'd be nice to have those slowest tests run a bit faster though. Or maybe move them to @Nightly since they're so long to execute? Some test statistics (mean, stddev). Key: LUCENE-4174 URL: https://issues.apache.org/jira/browse/LUCENE-4174 Project: Lucene - Java Issue Type: Bug Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Attachments: Selection_001.png -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4175) Include BBox Spatial Strategy
[ https://issues.apache.org/jira/browse/LUCENE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated LUCENE-4175: -- Attachment: LUCENE-4175-bbox-strategy.patch Here is a BBox strategy with some simple tests that touch each of the supported operations. This also passes all the other (weak) spatial tests Include BBox Spatial Strategy - Key: LUCENE-4175 URL: https://issues.apache.org/jira/browse/LUCENE-4175 Project: Lucene - Java Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: LUCENE-4175-bbox-strategy.patch This is an approach to indexing bounding boxes using 4 numeric fields (xmin,ymin,xmax,ymax) and a flag to say if it crosses the dateline. This is a modification from the Apache 2.0 code from the ESRI Geoportal: http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4138) Update morfologik (polish stemming) to 1.5.3
[ https://issues.apache.org/jira/browse/LUCENE-4138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-4138. - Resolution: Fixed Update morfologik (polish stemming) to 1.5.3 Key: LUCENE-4138 URL: https://issues.apache.org/jira/browse/LUCENE-4138 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 4.0, 5.0 Attachments: LUCENE-4138.patch, LUCENE-4138.patch, LUCENE-4138.patch Just released. Updates to the dictionary but most of all -- it comes with a clean BSD license (including dictionary data). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux-Java6-64 - Build # 1078 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64/1078/ All tests passed Build Log: [...truncated 17695 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build.xml:262: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/common-build.xml:1435: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/spatial/build.xml:28: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/module-build.xml:81: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/common-build.xml:1418: Javadocs warnings were found! Total time: 1 minute 54 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4175) Include BBox Spatial Strategy
[ https://issues.apache.org/jira/browse/LUCENE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402908#comment-13402908 ] Ryan McKinley commented on LUCENE-4175: --- I just added this to trunk in r1354841 I think we should ignore (remove?) 4.x for now... there will be some heavy committing in this area soon and keeping two branches is not very helpful. I'll take a stab at how this could look with LUCENE-4167 (remove SpatialOperation) Include BBox Spatial Strategy - Key: LUCENE-4175 URL: https://issues.apache.org/jira/browse/LUCENE-4175 Project: Lucene - Java Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: LUCENE-4175-bbox-strategy.patch This is an approach to indexing bounding boxes using 4 numeric fields (xmin,ymin,xmax,ymax) and a flag to say if it crosses the dateline. This is a modification from the Apache 2.0 code from the ESRI Geoportal: http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4175) Include BBox Spatial Strategy
[ https://issues.apache.org/jira/browse/LUCENE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved LUCENE-4175. --- Resolution: Fixed Include BBox Spatial Strategy - Key: LUCENE-4175 URL: https://issues.apache.org/jira/browse/LUCENE-4175 Project: Lucene - Java Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: LUCENE-4175-bbox-strategy.patch This is an approach to indexing bounding boxes using 4 numeric fields (xmin,ymin,xmax,ymax) and a flag to say if it crosses the dateline. This is a modification from the Apache 2.0 code from the ESRI Geoportal: http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3467) ExtendedDismax escaping is missing several reserved characters
[
https://issues.apache.org/jira/browse/SOLR-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402910#comment-13402910
]
Jan Høydahl commented on SOLR-3467:
---
Yea, I see that. Actually, I cannot get the test to fail, even with 3.6.0 - is
there a better way to trigger the missing escaping of particularly '', '\\'
and '|' ? If not, then I cannot see a need for a 3.6.x patch.
ExtendedDismax escaping is missing several reserved characters
--
Key: SOLR-3467
URL: https://issues.apache.org/jira/browse/SOLR-3467
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 3.6
Reporter: Michael Dodsworth
Assignee: Jan Høydahl
Priority: Minor
Fix For: 4.0, 3.6.1, 5.0
Attachments: SOLR-3467-lucene_solr_3_6.patch, SOLR-3467.patch,
SOLR-3467.patch, SOLR-3467.patch
When edismax is unable to parse the original user query, it retries using an
escaped version of that query (where all reserved chars have been escaped).
Currently, the escaping done in {{splitIntoClauses}} appears to be missing
several chars from {{QueryParserBase#escape(String)}}, namely {{'\\', '|',
'', '/'}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3467) ExtendedDismax escaping is missing several reserved characters
[
https://issues.apache.org/jira/browse/SOLR-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-3467:
--
Attachment: SOLR-3467.patch
New patch which also uncomments partialEscape() which is dead code
ExtendedDismax escaping is missing several reserved characters
--
Key: SOLR-3467
URL: https://issues.apache.org/jira/browse/SOLR-3467
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 3.6
Reporter: Michael Dodsworth
Assignee: Jan Høydahl
Priority: Minor
Fix For: 4.0, 3.6.1, 5.0
Attachments: SOLR-3467-lucene_solr_3_6.patch, SOLR-3467.patch,
SOLR-3467.patch, SOLR-3467.patch, SOLR-3467.patch
When edismax is unable to parse the original user query, it retries using an
escaped version of that query (where all reserved chars have been escaped).
Currently, the escaping done in {{splitIntoClauses}} appears to be missing
several chars from {{QueryParserBase#escape(String)}}, namely {{'\\', '|',
'', '/'}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-4.x - Build # 180 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-4.x/180/ All tests passed Build Log: [...truncated 23951 lines...] [javadoc] Standard Doclet version 1.6.0_32 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-4.x/checkout/lucene/build/docs/sandbox/stylesheet.css... [javadoc] Note: Custom tags that were not seen: @lucene.internal, @lucene.experimental [exec] Result: 1 [jar] Building jar: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-4.x/checkout/lucene/build/sandbox/lucene-sandbox-4.0-SNAPSHOT-javadoc.jar [echo] Building spatial... check-queries-javadocs-uptodate: javadocs-queries: check-queries-uptodate: jar-queries: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-4.x/checkout/lucene/ivy-settings.xml resolve: common.init: compile-lucene-core: jflex-uptodate-check: jflex-notice: javacc-uptodate-check: javacc-notice: ivy-availability-check: ivy-fail: ivy-configure: resolve: [ivy:retrieve] :: loading settings :: url = jar:file:/home/hudson/.ant/lib/ivy-2.2.0.jar!/org/apache/ivy/core/settings/ivysettings.xml init: clover.setup: clover.info: [echo] [echo] Clover not found. Code coverage reports disabled. [echo] clover: common.compile-core: [javac] Compiling 1 source file to /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-4.x/checkout/lucene/build/core/classes/java compile-core: init: clover.setup: clover.info: [echo] [echo] Clover not found. Code coverage reports disabled. [echo] clover: common.compile-core: compile-core: javadocs: [mkdir] Created dir: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-4.x/checkout/lucene/build/docs/spatial [echo] Building spatial... download-java6-javadoc-packagelist: [copy] Copying 1 file to /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-4.x/checkout/lucene/build/docs/spatial [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.spatial... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix.tree... [javadoc] Loading source files for package org.apache.lucene.spatial.util... [javadoc] Loading source files for package org.apache.lucene.spatial.vector... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.6.0_32 [javadoc] Building tree for all the packages and classes... [javadoc] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-4.x/checkout/lucene/spatial/src/java/org/apache/lucene/spatial/SpatialStrategy.java:71: warning - @return tag has no arguments. [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-4.x/checkout/lucene/build/docs/spatial/stylesheet.css... [javadoc] Note: Custom tags that were not seen: @lucene.internal, @lucene.experimental [javadoc] 1 warning [...truncated 16 lines...] [...truncated 24068 lines...] [...truncated 24068 lines...] [...truncated 24068 lines...] [...truncated 24068 lines...] [...truncated 24068 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS] Lucene-Solr-trunk-Linux-Java6-64 - Build # 1078 - Failure!
This failure is due to a javadocs warning: [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.6.0_32 [javadoc] Building tree for all the packages and classes... [javadoc] /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/spatial/src/java/org/apache/lucene/spatial/SpatialStrategy.java:71: warning - @return tag has no arguments. [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build/docs/spatial/stylesheet.css... [javadoc] Note: Custom tags that were not seen: @lucene.internal, @lucene.experimental [javadoc] 1 warning I'm looking into why this info didn't make it into the notification mail. -Original Message- From: Policeman Jenkins Server [mailto:jenk...@sd-datasolutions.de] Sent: Thursday, June 28, 2012 3:39 AM To: dev@lucene.apache.org; dwe...@apache.org; dsmi...@apache.org Subject: [JENKINS] Lucene-Solr-trunk-Linux-Java6-64 - Build # 1078 - Failure! Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64/1078/ All tests passed Build Log: [...truncated 17695 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build.xml:262: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/common-build.xml:1435: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/spatial/build.xml:28: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/module-build.xml:81: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/common-build.xml:1418: Javadocs warnings were found! Total time: 1 minute 54 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux-Java6-64 - Build # 298 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux-Java6-64/298/ All tests passed Build Log: [...truncated 17857 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux-Java6-64/checkout/lucene/build.xml:262: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux-Java6-64/checkout/lucene/common-build.xml:1434: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux-Java6-64/checkout/lucene/spatial/build.xml:28: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux-Java6-64/checkout/lucene/module-build.xml:81: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux-Java6-64/checkout/lucene/common-build.xml:1417: Javadocs warnings were found! Total time: 1 minute 55 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-4.x - Build # 22 - Failure
Build: https://builds.apache.org/job/Lucene-4.x/22/ No tests ran. Build Log: [...truncated 17156 lines...] resolve: common.init: compile-lucene-core: init: clover.setup: clover.info: [echo] [echo] Clover not found. Code coverage reports disabled. [echo] clover: compile-core: check-lucene-core-javadocs-uptodate: javadocs-lucene-core: javadocs: [echo] Building sandbox... download-java6-javadoc-packagelist: [delete] Deleting: /usr/home/hudson/hudson-slave/workspace/Lucene-4.x/checkout/lucene/build/docs/sandbox/stylesheet.css [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.sandbox.queries... [javadoc] Loading source files for package org.apache.lucene.sandbox.queries.regex... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.6.0_32 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /usr/home/hudson/hudson-slave/workspace/Lucene-4.x/checkout/lucene/build/docs/sandbox/stylesheet.css... [javadoc] Note: Custom tags that were not seen: @lucene.internal, @lucene.experimental [jar] Building jar: /usr/home/hudson/hudson-slave/workspace/Lucene-4.x/checkout/lucene/build/sandbox/lucene-sandbox-4.0-2012-06-28_07-58-10-javadoc.jar [echo] Building spatial... check-queries-javadocs-uptodate: javadocs-queries: check-queries-uptodate: jar-queries: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /usr/home/hudson/hudson-slave/workspace/Lucene-4.x/checkout/lucene/ivy-settings.xml resolve: common.init: compile-lucene-core: init: clover.setup: clover.info: [echo] [echo] Clover not found. Code coverage reports disabled. [echo] clover: common.compile-core: compile-core: javadocs: [mkdir] Created dir: /usr/home/hudson/hudson-slave/workspace/Lucene-4.x/checkout/lucene/build/docs/spatial [echo] Building spatial... download-java6-javadoc-packagelist: [copy] Copying 1 file to /usr/home/hudson/hudson-slave/workspace/Lucene-4.x/checkout/lucene/build/docs/spatial [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.spatial... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix.tree... [javadoc] Loading source files for package org.apache.lucene.spatial.util... [javadoc] Loading source files for package org.apache.lucene.spatial.vector... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.6.0_32 [javadoc] Building tree for all the packages and classes... [javadoc] /usr/home/hudson/hudson-slave/workspace/Lucene-4.x/checkout/lucene/spatial/src/java/org/apache/lucene/spatial/SpatialStrategy.java:71: warning - @return tag has no arguments. [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /usr/home/hudson/hudson-slave/workspace/Lucene-4.x/checkout/lucene/build/docs/spatial/stylesheet.css... [javadoc] Note: Custom tags that were not seen: @lucene.internal, @lucene.experimental [javadoc] 1 warning [...truncated 21 lines...] [...truncated 17278 lines...] [...truncated 17278 lines...] [...truncated 17278 lines...] [...truncated 17278 lines...] [...truncated 17278 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4172) clean up redundant throws clauses
[ https://issues.apache.org/jira/browse/LUCENE-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-4172: Attachment: LUCENE-4172.patch Patch with manually vetted IntelliJ finds for global Redundant throws clauses, Redundant throws declarations, and Duplicate throws. Compiles; LuceneSolr tests pass. Robert, I added another bullet at the top of your list of allowable contexts in which to remove redundant throws: * nuke the redundant throws if the method is either in an anonymous inner class or in a final class * nuke the redundant throws if its a static method, private, or package-private, or final * nuke the redundant throws if its a ctor (subclass can always declare its own) * keep the redundant throws if its public/protected non-final method that can be overridden clean up redundant throws clauses - Key: LUCENE-4172 URL: https://issues.apache.org/jira/browse/LUCENE-4172 Project: Lucene - Java Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-4172.patch, LUCENE-4172.patch examples are things like ctors that list throws XYZException but actually dont, and things like 'throws CorruptIndex, LockObtainedFailed, IOException' when all of these are actually IOException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-3832: Attachment: LUCENE-3832.patch A patch moving DaciukMihovAutomatonBuilder to automata package and hiding it effectively under BasicAutomata.makeStringUnion. Minor cleanups. Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Components: core/FSTs Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 4.0, 5.0 Attachments: LUCENE-3832.patch, LUCENE-3832.patch Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-3832: Component/s: core/FSTs Fix Version/s: (was: 4.1) 5.0 4.0 Labels: (was: newdev) Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Components: core/FSTs Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 4.0, 5.0 Attachments: LUCENE-3832.patch, LUCENE-3832.patch Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402945#comment-13402945 ] Dawid Weiss commented on LUCENE-3832: - Passes tests for me, I'll commit it in soon if there are no objections. Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Components: core/FSTs Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 4.0, 5.0 Attachments: LUCENE-3832.patch, LUCENE-3832.patch Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3467) ExtendedDismax escaping is missing several reserved characters
[
https://issues.apache.org/jira/browse/SOLR-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-3467:
--
Fix Version/s: (was: 3.6.1)
ExtendedDismax escaping is missing several reserved characters
--
Key: SOLR-3467
URL: https://issues.apache.org/jira/browse/SOLR-3467
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 3.6
Reporter: Michael Dodsworth
Assignee: Jan Høydahl
Priority: Minor
Fix For: 4.0, 5.0
Attachments: SOLR-3467-lucene_solr_3_6.patch, SOLR-3467.patch,
SOLR-3467.patch, SOLR-3467.patch, SOLR-3467.patch
When edismax is unable to parse the original user query, it retries using an
escaped version of that query (where all reserved chars have been escaped).
Currently, the escaping done in {{splitIntoClauses}} appears to be missing
several chars from {{QueryParserBase#escape(String)}}, namely {{'\\', '|',
'', '/'}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3467) ExtendedDismax escaping is missing several reserved characters
[
https://issues.apache.org/jira/browse/SOLR-3467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-3467.
---
Resolution: Fixed
Checked in to trunk and 4.x
ExtendedDismax escaping is missing several reserved characters
--
Key: SOLR-3467
URL: https://issues.apache.org/jira/browse/SOLR-3467
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 3.6
Reporter: Michael Dodsworth
Assignee: Jan Høydahl
Priority: Minor
Fix For: 4.0, 5.0
Attachments: SOLR-3467-lucene_solr_3_6.patch, SOLR-3467.patch,
SOLR-3467.patch, SOLR-3467.patch, SOLR-3467.patch
When edismax is unable to parse the original user query, it retries using an
escaped version of that query (where all reserved chars have been escaped).
Currently, the escaping done in {{splitIntoClauses}} appears to be missing
several chars from {{QueryParserBase#escape(String)}}, namely {{'\\', '|',
'', '/'}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4171) Performance improvements to Packed64
[
https://issues.apache.org/jira/browse/LUCENE-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402947#comment-13402947
]
Adrien Grand commented on LUCENE-4171:
--
Patch looks very good, all core tests pass on my computer too. Maybe still two
minor things to fix before commit:
- you shouldn't override {{getArray}}. This method must return a non-null
array only when the number of bits per value matches the backing array type
(some components use it to directly work with an array instead of a
PackedInts.Reader).
- could you use lower camelCase for instance variables (MASK_LEFT, MASK_RIGHT
and BPV_MINUS_BLOCK_SIZE)?
Performance improvements to Packed64
Key: LUCENE-4171
URL: https://issues.apache.org/jira/browse/LUCENE-4171
Project: Lucene - Java
Issue Type: Sub-task
Components: core/other
Affects Versions: 4.0, 5.0
Environment: Tested with 4 different Intel machines
Reporter: Toke Eskildsen
Priority: Minor
Labels: performance
Attachments: LUCENE-4171.patch
Original Estimate: 4h
Remaining Estimate: 4h
Based on the performance measurements of PackedInts.Mutable's in LUCENE-4062,
a new version of Packed64 has been created that is consistently faster than
the old Packed64 for both get and set.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: svn commit: r1354361 - /lucene/dev/trunk/lucene/test-framework/src/java/org/apache/lucene/analysis/BaseTokenStreamTestCase.java
Very Nice!
I prefer this one, too!
Uwe
P.S.: And now please also wrap with Collections.unmodifiableSet() :-)
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: dwe...@apache.org [mailto:dwe...@apache.org]
Sent: Wednesday, June 27, 2012 10:17 AM
To: comm...@lucene.apache.org
Subject: svn commit: r1354361 - /lucene/dev/trunk/lucene/test-
framework/src/java/org/apache/lucene/analysis/BaseTokenStreamTestCase.ja
va
Author: dweiss
Date: Wed Jun 27 08:16:37 2012
New Revision: 1354361
URL: http://svn.apache.org/viewvc?rev=1354361view=rev
Log:
Replacing hackish with stylish...
Modified:
lucene/dev/trunk/lucene/test-
framework/src/java/org/apache/lucene/analysis/BaseTokenStreamTestCase.ja
va
Modified: lucene/dev/trunk/lucene/test-
framework/src/java/org/apache/lucene/analysis/BaseTokenStreamTestCase.ja
va
URL: http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/test-
framework/src/java/org/apache/lucene/analysis/BaseTokenStreamTestCase.ja
va?rev=1354361r1=1354360r2=1354361view=diff
==
--- lucene/dev/trunk/lucene/test-
framework/src/java/org/apache/lucene/analysis/BaseTokenStreamTestCase.ja
va (original)
+++ lucene/dev/trunk/lucene/test-framework/src/java/org/apache/lucene/an
+++ alysis/BaseTokenStreamTestCase.java Wed Jun 27 08:16:37 2012
@@ -25,16 +25,9 @@ import java.io.Reader; import java.io.StringReader;
import java.io.StringWriter; import java.io.Writer; -import
java.util.ArrayList; -
import java.util.HashMap; -import java.util.HashSet; -import java.util.List; -
import java.util.Map; -import java.util.Random; -import java.util.Set;
+import java.util.*;
import org.apache.lucene.analysis.tokenattributes.*;
-import org.apache.lucene.codecs.PostingsFormat;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field; import
org.apache.lucene.document.FieldType;
@@ -480,14 +473,14 @@ public abstract class BaseTokenStreamTes
}
}
- static final SetString doesntSupportOffsets = new HashSetString() {{
-add(Lucene3x);
-add(MockFixedIntBlock);
-add(MockVariableIntBlock);
-add(MockSep);
-add(MockRandom);
- }};
-
+ static final SetString doesntSupportOffsets = new
HashSetString(Arrays.asList(
+Lucene3x,
+MockFixedIntBlock,
+MockVariableIntBlock,
+MockSep,
+MockRandom
+ ));
+
private static void checkRandomData(Random random, Analyzer a, int
iterations, int maxWordLength, boolean useCharFilter, boolean simple, boolean
offsetsAreCorrect, RandomIndexWriter iw) throws IOException {
final LineFileDocs docs = new LineFileDocs(random);
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1354361 - /lucene/dev/trunk/lucene/test-framework/src/java/org/apache/lucene/analysis/BaseTokenStreamTestCase.java
P.S.: And now please also wrap with Collections.unmodifiableSet() :-) Subclass-style initialization may look fancy in code but generates an additional .class file and in general is not clear to somebody who isn't familiar with the trick. The fact it's not a constant doesn't bother me that much as it's a test class. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-3394) Behavior on startup with empty core list is broken
[ https://issues.apache.org/jira/browse/SOLR-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-3394. - Resolution: Duplicate Please see SOLR-3477 for patch Behavior on startup with empty core list is broken -- Key: SOLR-3394 URL: https://issues.apache.org/jira/browse/SOLR-3394 Project: Solr Issue Type: Bug Components: multicore Affects Versions: 3.6 Reporter: Paul R. Brown Fix For: 3.6.1 Commit [1211827|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreContainer.java?r1=1153564r2=1211827diff_format=h] introduced an exception on an empty list of cores; the exception disappears in commit [1235888|http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/CoreContainer.java?r1=1232192r2=1235888diff_format=h], but 3.6.0 was released in the interceding time. I would call this a bug, since there are applications that will use Solr extensions to install cores at runtime, and being able to start up a fresh instance with no cores shouldn't result in an error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3477) SOLR does not start up when no cores are defined
[ https://issues.apache.org/jira/browse/SOLR-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-3477. --- Resolution: Fixed Checked in to 3.6 branch SOLR does not start up when no cores are defined Key: SOLR-3477 URL: https://issues.apache.org/jira/browse/SOLR-3477 Project: Solr Issue Type: Bug Components: search Affects Versions: 3.6 Environment: All environments Reporter: Sebastian Schaffert Assignee: Tommaso Teofili Priority: Critical Fix For: 4.0, 3.6.1 Attachments: SOLR-3477-3_6.patch, SOLR-3477-3_6.patch, SOLR-3477.patch Since version 3.6.0, Solr does not start up when no cores are defined in solr.xml. The problematic code is in CoresContainer.java, lines 171-173. org.apache.solr.common.SolrException: No cores were created, please check the logs for errors at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:172) ~[solr-core-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:38] at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:96) ~[solr-core-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:38] ... In our case, this is however a valid situation, because we create the cores programatically by calling the webservices to register new cores. The server is initially started with no cores defined, and depending on the configuration of our application, cores are then created dynamically. For the time being, we have to stick with version 3.5, which did not have this problem (or feature). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 14788 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/14788/ All tests passed Build Log: [...truncated 23835 lines...] [javadoc] Generating /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build/docs/sandbox/stylesheet.css... [javadoc] Note: Custom tags that were not seen: @lucene.internal, @lucene.experimental [exec] Result: 1 [jar] Building jar: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build/sandbox/lucene-sandbox-5.0-SNAPSHOT-javadoc.jar [echo] Building spatial... check-queries-javadocs-uptodate: javadocs-queries: check-queries-uptodate: jar-queries: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/ivy-settings.xml resolve: common.init: compile-lucene-core: jflex-uptodate-check: jflex-notice: javacc-uptodate-check: javacc-notice: ivy-availability-check: ivy-fail: ivy-configure: resolve: [ivy:retrieve] :: loading settings :: url = jar:file:/home/hudson/.ant/lib/ivy-2.2.0.jar!/org/apache/ivy/core/settings/ivysettings.xml init: clover.setup: clover.info: [echo] [echo] Clover not found. Code coverage reports disabled. [echo] clover: common.compile-core: [javac] Compiling 1 source file to /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build/core/classes/java compile-core: init: clover.setup: clover.info: [echo] [echo] Clover not found. Code coverage reports disabled. [echo] clover: common.compile-core: compile-core: javadocs: [mkdir] Created dir: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build/docs/spatial [echo] Building spatial... download-java6-javadoc-packagelist: [copy] Copying 1 file to /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build/docs/spatial [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.spatial... [javadoc] Loading source files for package org.apache.lucene.spatial.bbox... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix.tree... [javadoc] Loading source files for package org.apache.lucene.spatial.util... [javadoc] Loading source files for package org.apache.lucene.spatial.vector... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.6.0_32 [javadoc] Building tree for all the packages and classes... [javadoc] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/spatial/src/java/org/apache/lucene/spatial/bbox/BBoxSimilarityValueSource.java:48: warning - @param argument queryEnvelope is not a parameter name. [javadoc] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/spatial/src/java/org/apache/lucene/spatial/bbox/BBoxSimilarityValueSource.java:48: warning - @param argument queryPower is not a parameter name. [javadoc] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/spatial/src/java/org/apache/lucene/spatial/bbox/BBoxSimilarityValueSource.java:48: warning - @param argument targetPower is not a parameter name. [javadoc] /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/spatial/src/java/org/apache/lucene/spatial/bbox/BBoxSimilarityValueSource.java:71: warning - @param argument reader is not a parameter name. [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build/docs/spatial/stylesheet.css... [javadoc] Note: Custom tags that were not seen: @lucene.internal, @lucene.experimental [javadoc] 4 warnings [...truncated 16 lines...] [...truncated 23952 lines...] [...truncated 23952 lines...] [...truncated 23952 lines...] [...truncated 23952 lines...] [...truncated 23952 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4160) Bring back the functional equivalent of tests.iters.min
[
https://issues.apache.org/jira/browse/LUCENE-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402952#comment-13402952
]
Dawid Weiss commented on LUCENE-4160:
-
Thanks for the clarification, Hoss. We could also do:
{noformat}
-Dtests.iters=X -Dtests.minfailures=Y
{noformat}
What this would do is repeat everything X times but ignore anything after the
first Y failures... So if you'd like to quickly abort after the first failure,
you'd do:
{noformat}
-Dtests.iters=X -Dtests.minfailures=1
{noformat}
and if you wanted more (for whatever reason) you could wait for more, but still
abort earlier than X. I'll just provide a patch for this and we'll see how it
turns out in practice.
Bring back the functional equivalent of tests.iters.min
---
Key: LUCENE-4160
URL: https://issues.apache.org/jira/browse/LUCENE-4160
Project: Lucene - Java
Issue Type: Bug
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 5.0
What is needed is effectively saying: repeat this test N times, but stop
once you hit a failure.
Previously it was tests.iters.min=X which is (still) kind of confusing to
me because I don't understand how X is related to the original question.
I propose to implement a boolean tests.fastfail which would ignore any
tests running on the same JVM after the first failure has been hit.
Those with fond memories of tests.iters.min speak up, please.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4160) Bring back the functional equivalent of tests.iters.min
[ https://issues.apache.org/jira/browse/LUCENE-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402953#comment-13402953 ] Dawid Weiss commented on LUCENE-4160: - Now that I think of it minfailures or maxfailures depends on how you look at the problem :) Bring back the functional equivalent of tests.iters.min --- Key: LUCENE-4160 URL: https://issues.apache.org/jira/browse/LUCENE-4160 Project: Lucene - Java Issue Type: Bug Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 5.0 What is needed is effectively saying: repeat this test N times, but stop once you hit a failure. Previously it was tests.iters.min=X which is (still) kind of confusing to me because I don't understand how X is related to the original question. I propose to implement a boolean tests.fastfail which would ignore any tests running on the same JVM after the first failure has been hit. Those with fond memories of tests.iters.min speak up, please. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4172) clean up redundant throws clauses
[ https://issues.apache.org/jira/browse/LUCENE-4172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402956#comment-13402956 ] Robert Muir commented on LUCENE-4172: - +1 I think you should commit before the patch gets out of date! clean up redundant throws clauses - Key: LUCENE-4172 URL: https://issues.apache.org/jira/browse/LUCENE-4172 Project: Lucene - Java Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-4172.patch, LUCENE-4172.patch examples are things like ctors that list throws XYZException but actually dont, and things like 'throws CorruptIndex, LockObtainedFailed, IOException' when all of these are actually IOException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux-Java6-64 - Build # 1079 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64/1079/ All tests passed Build Log: [...truncated 17871 lines...] javadocs-lint: [...truncated 13 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build.xml:196: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/common-build.xml:1642: exec returned: 1 Total time: 3 minutes 5 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402958#comment-13402958 ] Robert Muir commented on LUCENE-3832: - I don't like the one that takes CharSequence and makes a new arraylist and sorts :) Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Components: core/FSTs Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 4.0, 5.0 Attachments: LUCENE-3832.patch, LUCENE-3832.patch Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402969#comment-13402969 ] Dawid Weiss commented on LUCENE-3832: - I don't like many things. For example the fact that it accepts UTF-8 but returns an automaton with codepoints on transitions -- this isn't intuitive ;) I think that method fits well with other methods in that class (accepting strings). Maybe it's a good idea to cutover to utf8 entirely but just having Collectionutf8 and everything else on char sequences seems odd to me. Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Components: core/FSTs Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 4.0, 5.0 Attachments: LUCENE-3832.patch, LUCENE-3832.patch Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1929) Index encrypted files
[
https://issues.apache.org/jira/browse/SOLR-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402967#comment-13402967
]
Jan Høydahl commented on SOLR-1929:
---
Committed to trunk in r1354887, please check it out on a few of your own files.
How to invoke:
{noformat}
curl
http://localhost:8983/solr/collection1/update/extract?commit=trueliteral.id=123resource.password=mypassword;
\
-H Content-Type: application/pdf --data-binary @my-encrypted-file.pdf
{noformat}
or
{noformat}
curl
http://localhost:8983/solr/collection1/update/extract?commit=trueliteral.id=123passwordsFile=mypass.propertiesresource.name=my-encrypted-file.pdf;
\
-H Content-Type: application/pdf --data-binary @my-encrypted-file.pdf
# contents of mypass.properties could be:
.*\.pdf = mySecretPassword
{noformat}
It could of course be nice to make the PasswordProvider class pluggable through
class-name as well, as we do for the CurrencyFieldType. But this is a first
step and probably goes a long way.
Will keep this open until it has baked for a while in trunk and been committed
to 4.x
Index encrypted files
-
Key: SOLR-1929
URL: https://issues.apache.org/jira/browse/SOLR-1929
Project: Solr
Issue Type: Improvement
Components: contrib - Solr Cell (Tika extraction)
Reporter: Yiannis Pericleous
Assignee: Jan Høydahl
Priority: Minor
Fix For: 4.0, 5.0
Attachments: SOLR-1929-extra-docs.zip, SOLR-1929.patch,
SOLR-1929.patch
SolrCell should be able to index encrypted files (pdfs, word docs).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[
https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402972#comment-13402972
]
Robert Muir commented on LUCENE-3832:
-
{quote}
For example the fact that it accepts UTF-8 but returns an automaton with
codepoints on transitions – this isn't intuitive
{quote}
Whats unintuitive? UTF-8 and UTF-32 share the same order.
Port BasicAutomata.stringUnion from Brics to Lucene
---
Key: LUCENE-3832
URL: https://issues.apache.org/jira/browse/LUCENE-3832
Project: Lucene - Java
Issue Type: Improvement
Components: core/FSTs
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 4.0, 5.0
Attachments: LUCENE-3832.patch, LUCENE-3832.patch
Brics has my code to build Automaton from a set of sorted strings in one step
(Daciuk/Mihov's algorithm again). This should be easily portable to Lucene
and is quite useful.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402974#comment-13402974 ] Dawid Weiss commented on LUCENE-3832: - You pass an array of bytes and get codepoint (ints) as transitions. Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Components: core/FSTs Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 4.0, 5.0 Attachments: LUCENE-3832.patch, LUCENE-3832.patch Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402975#comment-13402975 ] Robert Muir commented on LUCENE-3832: - So how is passing an array of shorts better? Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Components: core/FSTs Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 4.0, 5.0 Attachments: LUCENE-3832.patch, LUCENE-3832.patch Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3832) Port BasicAutomata.stringUnion from Brics to Lucene
[ https://issues.apache.org/jira/browse/LUCENE-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402979#comment-13402979 ] Dawid Weiss commented on LUCENE-3832: - My whining doesn't mean I want to change this because I realize most of the data in Lucene already comes as UTF8 and it wouldn't make sense to convert it back and forth. This doesn't change my feeling that it isn't intuitive when you look at the method's signature. Of course it's explained in the javadoc what it actually does, but so is conversion/ sorting in that other method that you don't like (and that I think is generally useful considering the rest of this package). Port BasicAutomata.stringUnion from Brics to Lucene --- Key: LUCENE-3832 URL: https://issues.apache.org/jira/browse/LUCENE-3832 Project: Lucene - Java Issue Type: Improvement Components: core/FSTs Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 4.0, 5.0 Attachments: LUCENE-3832.patch, LUCENE-3832.patch Brics has my code to build Automaton from a set of sorted strings in one step (Daciuk/Mihov's algorithm again). This should be easily portable to Lucene and is quite useful. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4171) Performance improvements to Packed64
[ https://issues.apache.org/jira/browse/LUCENE-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toke Eskildsen updated LUCENE-4171: --- Attachment: LUCENE-4171.patch I did wonder about the getArray-thing, but I did not look all the way back to the Reader interface, where the JavaDoc is very clear on the subject. I have removed the method and corrected the variable names. Performance improvements to Packed64 Key: LUCENE-4171 URL: https://issues.apache.org/jira/browse/LUCENE-4171 Project: Lucene - Java Issue Type: Sub-task Components: core/other Affects Versions: 4.0, 5.0 Environment: Tested with 4 different Intel machines Reporter: Toke Eskildsen Priority: Minor Labels: performance Attachments: LUCENE-4171.patch, LUCENE-4171.patch Original Estimate: 4h Remaining Estimate: 4h Based on the performance measurements of PackedInts.Mutable's in LUCENE-4062, a new version of Packed64 has been created that is consistently faster than the old Packed64 for both get and set. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Count of keys of an FST
I believe node and arc count are stored, but not key count. But check the sources to be sure! Mike McCandless http://blog.mikemccandless.com On Wed, Jun 27, 2012 at 4:53 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: If you need the count with constant time then yes, you should store it separately. You could also make a transducer that would store it at the root node as side-effect of values associated with keys, but it's kind of ugly. Please check the fst header though -- I'm not sure, maybe Mike wrote it so that the node count/ keys count is in there. Dawid On Wed, Jun 27, 2012 at 10:50 PM, Jason Rutherglen jason.rutherg...@gmail.com wrote: Sounds like I should just count as the keys are added and store the count separately. On Wed, Jun 27, 2012 at 3:48 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: I don't think there is one that you could use out of the box... but maybe I'm wrong and it's stored in the header somewhere (don't have the source in front of me). To calculate it by hand the worst case is that you'll need a recursive traversal, which would mean O(number of stored states) with intermediate count caches or O(number of keys) without any caches and memory overhead (just recursive traversal). Dawid On Wed, Jun 27, 2012 at 10:36 PM, Jason Rutherglen jason.rutherg...@gmail.com wrote: The FST class has a number of methods that return counts, which one returns the total number of keys that have been encoded into the FST? - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4160) Bring back the functional equivalent of tests.iters.min
[
https://issues.apache.org/jira/browse/LUCENE-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated LUCENE-4160:
Attachment: LUCENE-4160.patch
Patch against trunk.
{noformat}
ant -Dtests.maxfailures=M
{noformat}
will cause any test after the first M failures to be assumption-ignored.
Example:
{noformat}
[junit4] IGNOR/A 0.03s | TestBuhu.testFailSometimes {#96
seed=[15604D6381DA415B:BE5164F081683030]}
[junit4] Assumption #1: Ignored, failures limit reached (1 = 1).
[junit4] IGNOR/A 0.01s | TestBuhu.testFailSometimes {#97
seed=[15604D6381DA415B:E515E49B8D52E84E]}
[junit4] Assumption #1: Ignored, failures limit reached (1 = 1).
[junit4] IGNOR/A 0.02s | TestBuhu.testFailSometimes {#98
seed=[15604D6381DA415B:2128D6F71D04F74D]}
[junit4] Assumption #1: Ignored, failures limit reached (1 = 1).
[junit4] IGNOR/A 0.01s | TestBuhu.testFailSometimes {#99
seed=[15604D6381DA415B:EBBC938E1A402A5E]}
[junit4] Assumption #1: Ignored, failures limit reached (1 = 1).
[junit4] (@AfterClass output)
[junit4] 2 NOTE: test params are: codec=Lucene40: {},
sim=RandomSimilarityProvider(queryNorm=false,coord=true): {}, locale=hu,
timezone=US/Arizona
[junit4] 2 NOTE: Linux 3.0.0-21-generic amd64/Oracle Corporation 1.7.0
(64-bit)/cpus=2,threads=1,free=50888552,total=78512128
[junit4] 2 NOTE: All tests run in this JVM: [TestBuhu]
[junit4] 2
[junit4] Completed in 1.44s, 100 tests, 1 failure, 91 skipped FAILURES!
[junit4]
[junit4] JVM J0: 0.70 .. 3.16 = 2.47s
[junit4] Execution time total: 3.21 sec.
[junit4] Tests summary: 1 suite, 100 tests, 1 failure, 91 ignored (91
assumptions)
{noformat}
Bring back the functional equivalent of tests.iters.min
---
Key: LUCENE-4160
URL: https://issues.apache.org/jira/browse/LUCENE-4160
Project: Lucene - Java
Issue Type: Bug
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 5.0
Attachments: LUCENE-4160.patch
What is needed is effectively saying: repeat this test N times, but stop
once you hit a failure.
Previously it was tests.iters.min=X which is (still) kind of confusing to
me because I don't understand how X is related to the original question.
I propose to implement a boolean tests.fastfail which would ignore any
tests running on the same JVM after the first failure has been hit.
Those with fond memories of tests.iters.min speak up, please.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4160) Bring back the functional equivalent of tests.iters.min
[
https://issues.apache.org/jira/browse/LUCENE-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13402999#comment-13402999
]
Dawid Weiss commented on LUCENE-4160:
-
One note -- this property is per-jvm-global in the sense that you don't need
-Dtests.iters, you can wait for M failures in general, so for example:
{noformat}
ant test-core -Dtests.maxfailures=1
{noformat}
will ignore any remaining tests after the first failure. This applies per-JVM
though, so if you're running with 1 fork ed JVM then only that JVM's tests
will be ignored.
Bring back the functional equivalent of tests.iters.min
---
Key: LUCENE-4160
URL: https://issues.apache.org/jira/browse/LUCENE-4160
Project: Lucene - Java
Issue Type: Bug
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 5.0
Attachments: LUCENE-4160.patch
What is needed is effectively saying: repeat this test N times, but stop
once you hit a failure.
Previously it was tests.iters.min=X which is (still) kind of confusing to
me because I don't understand how X is related to the original question.
I propose to implement a boolean tests.fastfail which would ignore any
tests running on the same JVM after the first failure has been hit.
Those with fond memories of tests.iters.min speak up, please.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows-Java7-64 - Build # 408 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java7-64/408/ All tests passed Build Log: [...truncated 5356 lines...] [junit4] ERROR: Forked JVM execution exception: 0, execution line: C:\Program Files\Java\jdk1.7.0_04\jre\bin\java.exe -Dtests.prefix=tests -Dtests.seed=DE964F6C924B74B4 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.lockdir=C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\build -Dtests.codec=random -Dtests.postingsformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 -Dtests.cleanthreads=perMethod -Djava.util.logging.config.file=/dev/null -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=false -Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -classpath C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\build\test-framework\classes\java;C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\build\memory\lucene-memory-5.0-SNAPSHOT.jar;C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\build\highlighter\lucene-highlighter-5.0-SNAPSHOT.jar;C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\build\analysis\common\lucene-analyzers-common-5.0-SNAPSHOT.jar;C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\build\queryparser\lucene-queryparser-5.0-SNAPSHOT.jar;C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\build\facet\lucene-facet-5.0-SNAPSHOT.jar;C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\analysis\icu\lib\icu4j-4.8.1.1.jar;C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\build\core\classes\java;C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\benchmark\lib\commons-compress-1.2.jar;C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\benchmark\lib\xercesImpl-2.9.1.jar;C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\test-framework\lib\junit-4.10.jar;C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\test-framework\lib\randomizedtesting-runner-1.5.0.jar;C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\build\benchmark\classes\java;C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\build\benchmark\classes\test;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-launcher.jar;C:\Users\JenkinsSlave\.ant\lib\ivy-2.2.0.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-antlr.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-apache-bcel.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-apache-bsf.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-apache-log4j.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-apache-oro.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-apache-regexp.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-apache-resolver.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-apache-xalan2.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-commons-logging.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-commons-net.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-jai.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-javamail.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-jdepend.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-jmf.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-jsch.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-junit.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-junit4.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-netrexx.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-swing.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant-testutil.jar;C:\Jenkins\tools\apache-ant-1.8.2\lib\ant.jar;C:\Program Files\Java\jdk1.7.0_04\lib\tools.jar;C:\Users\JenkinsSlave\.ivy2\cache\com.carrotsearch.randomizedtesting\junit4-ant\jars\junit4-ant-1.5.0.jar -ea:org.apache.lucene... -ea:org.apache.solr... com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe -flush -eventsfile C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\build\benchmark\test\junit4-J0-11092693492b44f9e.events @C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\build\benchmark\test\junit4-J0-11092693492b44f9e.suites BUILD FAILED C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\build.xml:29: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\build.xml:456: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\common-build.xml:1433: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\module-build.xml:62: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows-Java7-64\lucene\common-build.xml:1035: The following error occurred while executing this line:
[jira] [Commented] (LUCENE-4160) Bring back the functional equivalent of tests.iters.min
[ https://issues.apache.org/jira/browse/LUCENE-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403004#comment-13403004 ] Robert Muir commented on LUCENE-4160: - What is the use case of the min/maxfailures (besides just your idea of a fastfail boolean, which I liked) Bring back the functional equivalent of tests.iters.min --- Key: LUCENE-4160 URL: https://issues.apache.org/jira/browse/LUCENE-4160 Project: Lucene - Java Issue Type: Bug Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 5.0 Attachments: LUCENE-4160.patch What is needed is effectively saying: repeat this test N times, but stop once you hit a failure. Previously it was tests.iters.min=X which is (still) kind of confusing to me because I don't understand how X is related to the original question. I propose to implement a boolean tests.fastfail which would ignore any tests running on the same JVM after the first failure has been hit. Those with fond memories of tests.iters.min speak up, please. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS] Lucene-Solr-trunk-Windows-Java7-64 - Build # 408 - Failure!
This build was hanging 23 hrs in, should I open bugreport?: (CPU: 100%, in benchmark) 2012-06-28 10:59:15 Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.0-b21 mixed mode): Thread-3 prio=4 tid=0x07b22800 nid=0xbf0 runnable [0x0bd6f000] java.lang.Thread.State: RUNNABLE at org.apache.lucene.benchmark.byTask.tasks.CountingSearchTestTask.incrNumSearches(CountingSearchTestTask.java:44) - locked 0xe027b748 (a java.lang.Class for org.apache.lucene.benchmark.byTask.tasks.CountingSearchTestTask) at org.apache.lucene.benchmark.byTask.tasks.CountingSearchTestTask.doLogic(CountingSearchTestTask.java:39) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:130) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doSerialTasks(TaskSequence.java:197) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doLogic(TaskSequence.java:138) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:141) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence$ParallelTask.run(TaskSequence.java:314) Thread-2 prio=4 tid=0x07b2 nid=0xf64 runnable [0x0735e000] java.lang.Thread.State: RUNNABLE at org.apache.lucene.search.BooleanScorer.score(BooleanScorer.java:276) at org.apache.lucene.search.BooleanScorer.score(BooleanScorer.java:323) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:574) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:453) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:410) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:250) at org.apache.lucene.benchmark.byTask.tasks.ReadTask.doLogic(ReadTask.java:130) at org.apache.lucene.benchmark.byTask.tasks.CountingSearchTestTask.doLogic(CountingSearchTestTask.java:38) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:130) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doSerialTasks(TaskSequence.java:197) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doLogic(TaskSequence.java:138) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:141) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence$ParallelTask.run(TaskSequence.java:314) Thread-1 prio=4 tid=0x07b21800 nid=0x610 in Object.wait() [0x0bc2e000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xe02d8030 (a org.apache.lucene.benchmark.byTask.tasks.TaskSequence$ParallelTask) at java.lang.Thread.join(Thread.java:1258) - locked 0xe02d8030 (a org.apache.lucene.benchmark.byTask.tasks.TaskSequence$ParallelTask) at java.lang.Thread.join(Thread.java:1332) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doParallelTasks(TaskSequence.java:360) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doLogic(TaskSequence.java:138) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:141) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence$RunBackgroundTask.run(TaskSequence.java:162) TEST-TestScope-org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testBGSearchTaskThreads-seed#[DE964F6C924B74B4] prio=6 tid=0x07b1b000 nid=0xfc4 in Object.wait() [0x0aabd000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xe0326398 (a org.apache.lucene.benchmark.byTask.tasks.TaskSequence$RunBackgroundTask) at java.lang.Thread.join(Thread.java:1258) - locked 0xe0326398 (a org.apache.lucene.benchmark.byTask.tasks.TaskSequence$RunBackgroundTask) at java.lang.Thread.join(Thread.java:1332) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doSerialTasks(TaskSequence.java:224) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doLogic(TaskSequence.java:138) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:141) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doSerialTasks(TaskSequence.java:197) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doLogic(TaskSequence.java:138) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:141) at org.apache.lucene.benchmark.byTask.utils.Algorithm.execute(Algorithm.java:301) at org.apache.lucene.benchmark.byTask.Benchmark.execute(Benchmark.java:76) - locked 0xe027baa0 (a org.apache.lucene.benchmark.byTask.Benchmark) at
[jira] [Commented] (LUCENE-4080) SegmentReader.numDeletedDocs() sometimes gives an incorrect numDeletedDocs
[ https://issues.apache.org/jira/browse/LUCENE-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403007#comment-13403007 ] Michael McCandless commented on LUCENE-4080: I only looked briefly at the patch ... but: could we do the liveDocs/numDeletedDocs copy up above, in IW (syncd), and pass them to RLD.getMergeReader? Then we don't need to cutover to ReentrantLock? SegmentReader.numDeletedDocs() sometimes gives an incorrect numDeletedDocs -- Key: LUCENE-4080 URL: https://issues.apache.org/jira/browse/LUCENE-4080 Project: Lucene - Java Issue Type: Bug Components: core/index Affects Versions: 4.0, 4.1 Reporter: Adrien Grand Priority: Trivial Fix For: 4.1 Attachments: LUCENE-4080.patch, LUCENE-4080.patch At merge time, SegmentReader sometimes gives an incorrect value for numDeletedDocs. From LUCENE-2357: bq. As far as I know, [SegmenterReader.numDeletedDocs() is] only unreliable in this context (SegmentReader passed to SegmentMerger for merging); this is because we allow newly marked deleted docs to happen concurrently up until the moment we need to pass the SR instance to the merger (search for // Must sync to ensure BufferedDeletesStream in IndexWriter.java) ... but it would be nice to fix that, so I think open a new issue (it won't block this one)? We should be able to make a new SR instance, sharing the same core as the current one but using the correct delCount... bq. It would be cleaner (but I think hairier) to create a new SR for merging that holds the correct delCount, but let's do that under the separate issue. bq. it would be best if the SegmentReader's numDeletedDocs were always correct, but, fixing that in IndexWriter is somewhat tricky. Ie, the fix could be hairy but the end result (SegmentReader.numDeletedDocs can always be trusted) would be cleaner... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4160) Bring back the functional equivalent of tests.iters.min
[ https://issues.apache.org/jira/browse/LUCENE-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403008#comment-13403008 ] Dawid Weiss commented on LUCENE-4160: - Maybe somebody would want to wait for 5 failures instead of 1 to get a bunch of stack traces? A boolean can be emulated at ant level, it's basically -Dtests.maxfailures=1... Don't know, really -- I admit I don't need this so I'm shooting at the dark here, it seemed to be useful for folks. To me it can be a boolean as well. Bring back the functional equivalent of tests.iters.min --- Key: LUCENE-4160 URL: https://issues.apache.org/jira/browse/LUCENE-4160 Project: Lucene - Java Issue Type: Bug Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 5.0 Attachments: LUCENE-4160.patch What is needed is effectively saying: repeat this test N times, but stop once you hit a failure. Previously it was tests.iters.min=X which is (still) kind of confusing to me because I don't understand how X is related to the original question. I propose to implement a boolean tests.fastfail which would ignore any tests running on the same JVM after the first failure has been hit. Those with fond memories of tests.iters.min speak up, please. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4080) SegmentReader.numDeletedDocs() sometimes gives an incorrect numDeletedDocs
[ https://issues.apache.org/jira/browse/LUCENE-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403011#comment-13403011 ] Robert Muir commented on LUCENE-4080: - I don't understand the concurrency here but thats what I read from the issue description: my concern was just that its not obvious in the first patch if we are actually just opening an SR with an existing core inside this sync or not, and I dont even know if its a problem :) SegmentReader.numDeletedDocs() sometimes gives an incorrect numDeletedDocs -- Key: LUCENE-4080 URL: https://issues.apache.org/jira/browse/LUCENE-4080 Project: Lucene - Java Issue Type: Bug Components: core/index Affects Versions: 4.0, 4.1 Reporter: Adrien Grand Priority: Trivial Fix For: 4.1 Attachments: LUCENE-4080.patch, LUCENE-4080.patch At merge time, SegmentReader sometimes gives an incorrect value for numDeletedDocs. From LUCENE-2357: bq. As far as I know, [SegmenterReader.numDeletedDocs() is] only unreliable in this context (SegmentReader passed to SegmentMerger for merging); this is because we allow newly marked deleted docs to happen concurrently up until the moment we need to pass the SR instance to the merger (search for // Must sync to ensure BufferedDeletesStream in IndexWriter.java) ... but it would be nice to fix that, so I think open a new issue (it won't block this one)? We should be able to make a new SR instance, sharing the same core as the current one but using the correct delCount... bq. It would be cleaner (but I think hairier) to create a new SR for merging that holds the correct delCount, but let's do that under the separate issue. bq. it would be best if the SegmentReader's numDeletedDocs were always correct, but, fixing that in IndexWriter is somewhat tricky. Ie, the fix could be hairy but the end result (SegmentReader.numDeletedDocs can always be trusted) would be cleaner... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4165) HunspellDictionary - AffixFile Reader closed, Dictionary Readers left unclosed
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Torsten Krah updated LUCENE-4165: - Attachment: LUCENE_4156_36.patch Updated patch for 36 branch which does handle StemFactory closing. Ported IOUtils change from trunk to branch (IOException removed from throws declaration). HunspellDictionary - AffixFile Reader closed, Dictionary Readers left unclosed -- Key: LUCENE-4165 URL: https://issues.apache.org/jira/browse/LUCENE-4165 Project: Lucene - Java Issue Type: Bug Components: modules/analysis Affects Versions: 3.6 Environment: Linux, Java 1.6 Reporter: Torsten Krah Priority: Minor Attachments: LUCENE-4156-trunk.patch, LUCENE_4156_36.patch, lucene_36.patch, lucene_trunk.patch The HunspellDictionary takes an InputStream for affix file and a List of Streams for dictionaries. Javadoc is not clear about i have to close those stream myself or the Dictionary constructor does this already. Looking at the code, at least reader.close() is called when the affix file is read via readAffixFile() method (although closing streams is not done in a finally block - so the constructor may fail to do so). The readDictionaryFile() method does miss the call to close the reader in contrast to readAffixFile(). So the question here is - have i have to close the streams myself after instantiating the dictionary? Or is the close call only missing for the dictionary streams? Either way, please add the close calls in a safe manner or clarify javadoc so i have to do this myself. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4160) Bring back the functional equivalent of tests.iters.min
[ https://issues.apache.org/jira/browse/LUCENE-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403012#comment-13403012 ] Robert Muir commented on LUCENE-4160: - I think i originally caused the complexity by wanting to still have a way to run a test like 1000 times and look at the failure rate. This is occasionally useful: e.g. this test fails 2% of the time and I improved the test to fail 10% of the time or whatever :) But really I think its more useful in general to have 'fastfail' on by default... especially now that in general tests are reproducing a lot better than before... Bring back the functional equivalent of tests.iters.min --- Key: LUCENE-4160 URL: https://issues.apache.org/jira/browse/LUCENE-4160 Project: Lucene - Java Issue Type: Bug Components: general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Fix For: 5.0 Attachments: LUCENE-4160.patch What is needed is effectively saying: repeat this test N times, but stop once you hit a failure. Previously it was tests.iters.min=X which is (still) kind of confusing to me because I don't understand how X is related to the original question. I propose to implement a boolean tests.fastfail which would ignore any tests running on the same JVM after the first failure has been hit. Those with fond memories of tests.iters.min speak up, please. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Windows-Java7-64 - Build # 408 - Failure!
I think so: something is up with this test. I was looking at a previous jenkins fail where the assert here failed and trying to figure out whats going on (but I cannot reproduce it) On Thu, Jun 28, 2012 at 7:04 AM, Uwe Schindler u...@thetaphi.de wrote: This build was hanging 23 hrs in, should I open bugreport?: (CPU: 100%, in benchmark) 2012-06-28 10:59:15 Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.0-b21 mixed mode): Thread-3 prio=4 tid=0x07b22800 nid=0xbf0 runnable [0x0bd6f000] java.lang.Thread.State: RUNNABLE at org.apache.lucene.benchmark.byTask.tasks.CountingSearchTestTask.incrNumSearches(CountingSearchTestTask.java:44) - locked 0xe027b748 (a java.lang.Class for org.apache.lucene.benchmark.byTask.tasks.CountingSearchTestTask) at org.apache.lucene.benchmark.byTask.tasks.CountingSearchTestTask.doLogic(CountingSearchTestTask.java:39) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:130) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doSerialTasks(TaskSequence.java:197) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doLogic(TaskSequence.java:138) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:141) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence$ParallelTask.run(TaskSequence.java:314) Thread-2 prio=4 tid=0x07b2 nid=0xf64 runnable [0x0735e000] java.lang.Thread.State: RUNNABLE at org.apache.lucene.search.BooleanScorer.score(BooleanScorer.java:276) at org.apache.lucene.search.BooleanScorer.score(BooleanScorer.java:323) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:574) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:453) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:410) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:261) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:250) at org.apache.lucene.benchmark.byTask.tasks.ReadTask.doLogic(ReadTask.java:130) at org.apache.lucene.benchmark.byTask.tasks.CountingSearchTestTask.doLogic(CountingSearchTestTask.java:38) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:130) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doSerialTasks(TaskSequence.java:197) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doLogic(TaskSequence.java:138) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:141) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence$ParallelTask.run(TaskSequence.java:314) Thread-1 prio=4 tid=0x07b21800 nid=0x610 in Object.wait() [0x0bc2e000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xe02d8030 (a org.apache.lucene.benchmark.byTask.tasks.TaskSequence$ParallelTask) at java.lang.Thread.join(Thread.java:1258) - locked 0xe02d8030 (a org.apache.lucene.benchmark.byTask.tasks.TaskSequence$ParallelTask) at java.lang.Thread.join(Thread.java:1332) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doParallelTasks(TaskSequence.java:360) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doLogic(TaskSequence.java:138) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:141) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence$RunBackgroundTask.run(TaskSequence.java:162) TEST-TestScope-org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testBGSearchTaskThreads-seed#[DE964F6C924B74B4] prio=6 tid=0x07b1b000 nid=0xfc4 in Object.wait() [0x0aabd000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xe0326398 (a org.apache.lucene.benchmark.byTask.tasks.TaskSequence$RunBackgroundTask) at java.lang.Thread.join(Thread.java:1258) - locked 0xe0326398 (a org.apache.lucene.benchmark.byTask.tasks.TaskSequence$RunBackgroundTask) at java.lang.Thread.join(Thread.java:1332) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doSerialTasks(TaskSequence.java:224) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doLogic(TaskSequence.java:138) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:141) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doSerialTasks(TaskSequence.java:197) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doLogic(TaskSequence.java:138) at
[JENKINS] Lucene-Solr-trunk-Linux-Java6-64 - Build # 1080 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64/1080/ All tests passed Build Log: [...truncated 17840 lines...] javadocs-lint: [...truncated 12 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build.xml:196: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/common-build.xml:1642: exec returned: 1 Total time: 2 minutes 50 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
help with release notes
Hello: I created drafts for the 4.0-alpha release notes: http://wiki.apache.org/lucene-java/ReleaseNote40alpha and http://wiki.apache.org/solr/ReleaseNote40alpha The lucene ones i did a while ago... there is an overwhelming number of changes and trying to summarize the biggest ones is pretty challenging. Can someone help me with the solr one? I think we at least want to make sure the biggest things are in there (e.g. NRT, distributed indexing, etc) (Also review the lucene one and look for typos or problems if you have time!) -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4080) SegmentReader.numDeletedDocs() sometimes gives an incorrect numDeletedDocs
[ https://issues.apache.org/jira/browse/LUCENE-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403017#comment-13403017 ] Adrien Grand commented on LUCENE-4080: -- @Robert I think this is an issue since one must hold the IndexWriter lock to perform deletes on any segment (cf. assert Thread.holdsLock(writer); in ReadersAndLiveDocs.delete). @Michael Oh right, I think I understand what you mean. I'll try to produce a better patch. SegmentReader.numDeletedDocs() sometimes gives an incorrect numDeletedDocs -- Key: LUCENE-4080 URL: https://issues.apache.org/jira/browse/LUCENE-4080 Project: Lucene - Java Issue Type: Bug Components: core/index Affects Versions: 4.0, 4.1 Reporter: Adrien Grand Priority: Trivial Fix For: 4.1 Attachments: LUCENE-4080.patch, LUCENE-4080.patch At merge time, SegmentReader sometimes gives an incorrect value for numDeletedDocs. From LUCENE-2357: bq. As far as I know, [SegmenterReader.numDeletedDocs() is] only unreliable in this context (SegmentReader passed to SegmentMerger for merging); this is because we allow newly marked deleted docs to happen concurrently up until the moment we need to pass the SR instance to the merger (search for // Must sync to ensure BufferedDeletesStream in IndexWriter.java) ... but it would be nice to fix that, so I think open a new issue (it won't block this one)? We should be able to make a new SR instance, sharing the same core as the current one but using the correct delCount... bq. It would be cleaner (but I think hairier) to create a new SR for merging that holds the correct delCount, but let's do that under the separate issue. bq. it would be best if the SegmentReader's numDeletedDocs were always correct, but, fixing that in IndexWriter is somewhat tricky. Ie, the fix could be hairy but the end result (SegmentReader.numDeletedDocs can always be trusted) would be cleaner... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4171) Performance improvements to Packed64
[
https://issues.apache.org/jira/browse/LUCENE-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403018#comment-13403018
]
Adrien Grand commented on LUCENE-4171:
--
Thanks, Toke. I think there are still a few minor fixes to perform:
* the maskLeft variable seems unused, can it be removed?
* the copyright header doens't need to be a javadoc comment (those that start
with /** instead of // or /*), can you fix it?
* since this impl uses the default format, there is no need to override
getFormat
I think it is not necessary to try to keep the same number of blocks as the old
impl (cf. comments in ctor #1 and #3). Could we just use {{size(valueCount,
bitsPerValue)}} to compute the required number of blocks?
Performance improvements to Packed64
Key: LUCENE-4171
URL: https://issues.apache.org/jira/browse/LUCENE-4171
Project: Lucene - Java
Issue Type: Sub-task
Components: core/other
Affects Versions: 4.0, 5.0
Environment: Tested with 4 different Intel machines
Reporter: Toke Eskildsen
Priority: Minor
Labels: performance
Attachments: LUCENE-4171.patch, LUCENE-4171.patch
Original Estimate: 4h
Remaining Estimate: 4h
Based on the performance measurements of PackedInts.Mutable's in LUCENE-4062,
a new version of Packed64 has been created that is consistently faster than
the old Packed64 for both get and set.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4176) Can not produce proper collation key for ICUCollatedTermAttributeImp
Nattapong Sirilappanich created LUCENE-4176: --- Summary: Can not produce proper collation key for ICUCollatedTermAttributeImp Key: LUCENE-4176 URL: https://issues.apache.org/jira/browse/LUCENE-4176 Project: Lucene - Java Issue Type: Bug Components: modules/analysis Affects Versions: 5.0 Reporter: Nattapong Sirilappanich org.apache.lucene.collation.tokenattributes.ICUCollatedTermAttributeImpl return a hash of collation key's byte. The given hash value produce incorrect comparison result. The source code below return 1 for Lucene 3.6. The code here return 0. Code to reproduce: IndexWriter writer = new IndexWriter(ramDir, conf); Document doc = new Document(); FieldType fieldType = new FieldType(); fieldType.setIndexed(true); fieldType.setStored(true); Field field = new Field(content,เข, fieldType); doc.add(field); writer.addDocument(doc); writer.close(); IndexSearcher is = new IndexSearcher(DirectoryReader.open(ramDir)); QueryParser qp = new AnalyzingQueryParser(Version.LUCENE_50,content, analyzer); ScoreDoc[] result = is.search(qp.parse([\u0e01 TO \u0e03]), null,1000).scoreDocs; System.out.println(result.length); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4165) HunspellDictionary - AffixFile Reader closed, Dictionary Readers left unclosed
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403037#comment-13403037 ] Chris Male commented on LUCENE-4165: Thanks for doing that Torsten. Would it be possible to make a version that doesn't change IOUtils but instead just catches the useless Exception? 3.6.1 is just a bug fix so I'd rather not change anything unnecessary. HunspellDictionary - AffixFile Reader closed, Dictionary Readers left unclosed -- Key: LUCENE-4165 URL: https://issues.apache.org/jira/browse/LUCENE-4165 Project: Lucene - Java Issue Type: Bug Components: modules/analysis Affects Versions: 3.6 Environment: Linux, Java 1.6 Reporter: Torsten Krah Priority: Minor Attachments: LUCENE-4156-trunk.patch, LUCENE_4156_36.patch, lucene_36.patch, lucene_trunk.patch The HunspellDictionary takes an InputStream for affix file and a List of Streams for dictionaries. Javadoc is not clear about i have to close those stream myself or the Dictionary constructor does this already. Looking at the code, at least reader.close() is called when the affix file is read via readAffixFile() method (although closing streams is not done in a finally block - so the constructor may fail to do so). The readDictionaryFile() method does miss the call to close the reader in contrast to readAffixFile(). So the question here is - have i have to close the streams myself after instantiating the dictionary? Or is the close call only missing for the dictionary streams? Either way, please add the close calls in a safe manner or clarify javadoc so i have to do this myself. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4176) Can not produce proper collation key for ICUCollatedTermAttributeImp
[ https://issues.apache.org/jira/browse/LUCENE-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4176: Component/s: (was: modules/analysis) modules/queryparser Can not produce proper collation key for ICUCollatedTermAttributeImp Key: LUCENE-4176 URL: https://issues.apache.org/jira/browse/LUCENE-4176 Project: Lucene - Java Issue Type: Bug Components: modules/queryparser Affects Versions: 5.0 Reporter: Nattapong Sirilappanich org.apache.lucene.collation.tokenattributes.ICUCollatedTermAttributeImpl return a hash of collation key's byte. The given hash value produce incorrect comparison result. The source code below return 1 for Lucene 3.6. The code here return 0. Code to reproduce: IndexWriter writer = new IndexWriter(ramDir, conf); Document doc = new Document(); FieldType fieldType = new FieldType(); fieldType.setIndexed(true); fieldType.setStored(true); Field field = new Field(content,เข, fieldType); doc.add(field); writer.addDocument(doc); writer.close(); IndexSearcher is = new IndexSearcher(DirectoryReader.open(ramDir)); QueryParser qp = new AnalyzingQueryParser(Version.LUCENE_50,content, analyzer); ScoreDoc[] result = is.search(qp.parse([\u0e01 TO \u0e03]), null,1000).scoreDocs; System.out.println(result.length); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4176) Can not produce proper collation key for ICUCollatedTermAttributeImp
[ https://issues.apache.org/jira/browse/LUCENE-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403038#comment-13403038 ] Robert Muir commented on LUCENE-4176: - Thanks for reporting this: the bug is actually AnalyzingQueryParser. it should not consume with CharTermAttribute.toString(), instead it should just consume the bytes. Can not produce proper collation key for ICUCollatedTermAttributeImp Key: LUCENE-4176 URL: https://issues.apache.org/jira/browse/LUCENE-4176 Project: Lucene - Java Issue Type: Bug Components: modules/queryparser Affects Versions: 5.0 Reporter: Nattapong Sirilappanich org.apache.lucene.collation.tokenattributes.ICUCollatedTermAttributeImpl return a hash of collation key's byte. The given hash value produce incorrect comparison result. The source code below return 1 for Lucene 3.6. The code here return 0. Code to reproduce: IndexWriter writer = new IndexWriter(ramDir, conf); Document doc = new Document(); FieldType fieldType = new FieldType(); fieldType.setIndexed(true); fieldType.setStored(true); Field field = new Field(content,เข, fieldType); doc.add(field); writer.addDocument(doc); writer.close(); IndexSearcher is = new IndexSearcher(DirectoryReader.open(ramDir)); QueryParser qp = new AnalyzingQueryParser(Version.LUCENE_50,content, analyzer); ScoreDoc[] result = is.search(qp.parse([\u0e01 TO \u0e03]), null,1000).scoreDocs; System.out.println(result.length); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4175) Include BBox Spatial Strategy
[ https://issues.apache.org/jira/browse/LUCENE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403039#comment-13403039 ] Chris Male commented on LUCENE-4175: bq. I think we should ignore (remove?) 4.x for now... there will be some heavy committing in this area soon and keeping two branches is not very helpful. what? Include BBox Spatial Strategy - Key: LUCENE-4175 URL: https://issues.apache.org/jira/browse/LUCENE-4175 Project: Lucene - Java Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: LUCENE-4175-bbox-strategy.patch This is an approach to indexing bounding boxes using 4 numeric fields (xmin,ymin,xmax,ymax) and a flag to say if it crosses the dateline. This is a modification from the Apache 2.0 code from the ESRI Geoportal: http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3582) Leader election zookeeper watcher is responding to con/discon notifications incorrectly.
[ https://issues.apache.org/jira/browse/SOLR-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403041#comment-13403041 ] Per Steffensen commented on SOLR-3582: -- Trym didnt mention it, but this is not only a negligible problem that will never cause any problems in real-world usage. Actually we discovered the problem during one of our performance/endurance test of our real world application in a real world setup and with real world workload (high). We are running with numerous Solr instances in a SolrCloud cluster, with numerous collections each having about 25 slices each with 2 shards (one replica for each slice). During the test Solrs lose their ZK connection (probably due to too long GC pause) and reconnect - resulting in more watchers. The next time a dis-/re-connect to ZK happens it gets many watcher-events resulting in even more watchers for the next time. All in all, seen from the outside, this breaks our performance/endurance test - at first things starts to slow down and eventually JVMs break down with OOM errors. This is a self-reinforcing problem, because for every iteration more time has to be used by the garbage collector collecting watchers (twice as many as last time), increasing the probability of new ZK timeouts, and more time has to be used creating new watchers (twice as many as last time). I think you should commit the fix. Basically because it makes a (our) real world application able to run for a long time - it wasnt before. Commit the fix, not so much for our sake, because we are using our own build of Solr (inkl this fix, other fixes and nice impl of optimistic locking etc (SOLR-3173, SOLR-3178, etc)) anyway, but to save others (that might also be among the first movers on using Solr 4.0 for high scale real world applications) from having to use weeks tracking down the essence of this issue and make a fix. If you think this observation/fix should lead to a walk through of the code, to check if watchers are used undesirably at other places, and maybe even come to a more generic fix, I would endorse such a task. But for now I urge you to commit to save others from weeks of debugging. If/when you come to a better or more generic solution, you can always go refactor. Regards, Per Steffensen Leader election zookeeper watcher is responding to con/discon notifications incorrectly. Key: SOLR-3582 URL: https://issues.apache.org/jira/browse/SOLR-3582 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.0, 5.0 As brought up by Trym R. Møller on the mailing list, we are responding to watcher events about connection/disconnection as if they were notifications about node changes. http://www.lucidimagination.com/search/document/e13ef390b882 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3842) Analyzing Suggester
[ https://issues.apache.org/jira/browse/LUCENE-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-3842: Attachment: LUCENE-3842.patch no changes: just syncing up with trunk Analyzing Suggester --- Key: LUCENE-3842 URL: https://issues.apache.org/jira/browse/LUCENE-3842 Project: Lucene - Java Issue Type: New Feature Components: modules/spellchecker Affects Versions: 3.6, 4.0 Reporter: Robert Muir Attachments: LUCENE-3842-TokenStream_to_Automaton.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch Since we added shortest-path wFSA search in LUCENE-3714, and generified the comparator in LUCENE-3801, I think we should look at implementing suggesters that have more capabilities than just basic prefix matching. In particular I think the most flexible approach is to integrate with Analyzer at both build and query time, such that we build a wFST with: input: analyzed text such as ghost0christmas0past -- byte 0 here is an optional token separator output: surface form such as the ghost of christmas past weight: the weight of the suggestion we make an FST with PairOutputsweight,output, but only do the shortest path operation on the weight side (like the test in LUCENE-3801), at the same time accumulating the output (surface form), which will be the actual suggestion. This allows a lot of flexibility: * Using even standardanalyzer means you can offer suggestions that ignore stopwords, e.g. if you type in ghost of chr..., it will suggest the ghost of christmas past * we can add support for synonyms/wdf/etc at both index and query time (there are tradeoffs here, and this is not implemented!) * this is a basis for more complicated suggesters such as Japanese suggesters, where the analyzed form is in fact the reading, so we would add a TokenFilter that copies ReadingAttribute into term text to support that... * other general things like offering suggestions that are more fuzzy like using a plural stemmer or ignoring accents or whatever. According to my benchmarks, suggestions are still very fast with the prototype (e.g. ~ 100,000 QPS), and the FST size does not explode (its short of twice that of a regular wFST, but this is still far smaller than TST or JaSpell, etc). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4176) Can not produce proper collation key for ICUCollatedTermAttributeImp
[ https://issues.apache.org/jira/browse/LUCENE-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4176: Attachment: LUCENE-4176.patch untested patch. Can not produce proper collation key for ICUCollatedTermAttributeImp Key: LUCENE-4176 URL: https://issues.apache.org/jira/browse/LUCENE-4176 Project: Lucene - Java Issue Type: Bug Components: modules/queryparser Affects Versions: 5.0 Reporter: Nattapong Sirilappanich Attachments: LUCENE-4176.patch org.apache.lucene.collation.tokenattributes.ICUCollatedTermAttributeImpl return a hash of collation key's byte. The given hash value produce incorrect comparison result. The source code below return 1 for Lucene 3.6. The code here return 0. Code to reproduce: IndexWriter writer = new IndexWriter(ramDir, conf); Document doc = new Document(); FieldType fieldType = new FieldType(); fieldType.setIndexed(true); fieldType.setStored(true); Field field = new Field(content,เข, fieldType); doc.add(field); writer.addDocument(doc); writer.close(); IndexSearcher is = new IndexSearcher(DirectoryReader.open(ramDir)); QueryParser qp = new AnalyzingQueryParser(Version.LUCENE_50,content, analyzer); ScoreDoc[] result = is.search(qp.parse([\u0e01 TO \u0e03]), null,1000).scoreDocs; System.out.println(result.length); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4177) TestPerfTasksLogic.testBGSearchTaskThreads sometimes fails or hangs on Windows
Robert Muir created LUCENE-4177: --- Summary: TestPerfTasksLogic.testBGSearchTaskThreads sometimes fails or hangs on Windows Key: LUCENE-4177 URL: https://issues.apache.org/jira/browse/LUCENE-4177 Project: Lucene - Java Issue Type: Bug Reporter: Robert Muir e.g. http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows-Java6-64/147/ http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java7-64/408/ this has happened a couple times... but always on Windows. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4171) Performance improvements to Packed64
[ https://issues.apache.org/jira/browse/LUCENE-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toke Eskildsen updated LUCENE-4171: --- Attachment: LUCENE-4171.patch I have corrected the issues. I do worry a little bit about the block count thing: As the change is seen in the constructor and the reader, and the writer uses valueCount, the persistent format should be the same, right? Performance improvements to Packed64 Key: LUCENE-4171 URL: https://issues.apache.org/jira/browse/LUCENE-4171 Project: Lucene - Java Issue Type: Sub-task Components: core/other Affects Versions: 4.0, 5.0 Environment: Tested with 4 different Intel machines Reporter: Toke Eskildsen Priority: Minor Labels: performance Attachments: LUCENE-4171.patch, LUCENE-4171.patch, LUCENE-4171.patch Original Estimate: 4h Remaining Estimate: 4h Based on the performance measurements of PackedInts.Mutable's in LUCENE-4062, a new version of Packed64 has been created that is consistently faster than the old Packed64 for both get and set. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4167) Remove the use of SpatialOperation
[
https://issues.apache.org/jira/browse/LUCENE-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403055#comment-13403055
]
Chris Male commented on LUCENE-4167:
{quote}
makeFilter makeQuery receives a SpatialArgs object which has already been
parsed; it's not a string anymore. (The Command design pattern, by the way).
And he's also proposing that SpatialArgs is gone, at least from these methods,
and instead you get a Shape + distancePrecision pair of args.
{quote}
I gather you don't like that idea, it reads that way at least.
We don't need SpatialArgs at the moment. It feels like a hack to allow us to
add whatever arguments we want without having to change method signature and so
we can have some defaults. The Strategy API should be explicit so users know
exactly what they need to provide (distance precision is used in both of the
PrefixTreeStrategys, it is important) and we should consider any changes to the
API very carefully. This API shouldnt have any mystery or surprises, it should
be extremely clear to what user what to expect. I cannot stress this enough.
Remove the use of SpatialOperation
--
Key: LUCENE-4167
URL: https://issues.apache.org/jira/browse/LUCENE-4167
Project: Lucene - Java
Issue Type: Bug
Components: modules/spatial
Reporter: Chris Male
Attachments: LUCENE-4167.patch
Looking at the code in TwoDoublesStrategy I noticed
SpatialOperations.BBoxWithin vs isWithin which confused me. Looking over the
other Strategys I see that really only isWithin and Intersects is supported.
Only TwoDoublesStrategy supports IsDisjointTo. The remainder of
SpatialOperations are not supported.
I don't think we should use SpatialOperation as this stage since it is not
clear what Operations are supported by what Strategys, many Operations are
not supported, and the code for handling the Operations is usually the same.
We can spin off the code for TwoDoublesStrategy's IsDisjointTo support into a
different Strategy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4167) Remove the use of SpatialOperation
[
https://issues.apache.org/jira/browse/LUCENE-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403056#comment-13403056
]
Chris Male commented on LUCENE-4167:
{quote}
This is essentially a java API vs 'query string' question. As is we essentially
pass the query string all the way to the SpatialStrategy before it checks the
operation; Chris proposes that the operation should be parsed before it gets to
the strategy and have real java functions for each operation.
{quote}
This is exactly what I'm suggesting. The Strategys shouldn't be doing decision
making, they are Factorys. The logic for parsing queries, validating, choosing
Strategys, constructing Shapes and identifying operations, shouldn't be their
concern at all.
Remove the use of SpatialOperation
--
Key: LUCENE-4167
URL: https://issues.apache.org/jira/browse/LUCENE-4167
Project: Lucene - Java
Issue Type: Bug
Components: modules/spatial
Reporter: Chris Male
Attachments: LUCENE-4167.patch
Looking at the code in TwoDoublesStrategy I noticed
SpatialOperations.BBoxWithin vs isWithin which confused me. Looking over the
other Strategys I see that really only isWithin and Intersects is supported.
Only TwoDoublesStrategy supports IsDisjointTo. The remainder of
SpatialOperations are not supported.
I don't think we should use SpatialOperation as this stage since it is not
clear what Operations are supported by what Strategys, many Operations are
not supported, and the code for handling the Operations is usually the same.
We can spin off the code for TwoDoublesStrategy's IsDisjointTo support into a
different Strategy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4167) Remove the use of SpatialOperation
[
https://issues.apache.org/jira/browse/LUCENE-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403059#comment-13403059
]
Chris Male commented on LUCENE-4167:
{quote}
Somewhat related to this is the Filter/Query distinction. Minutes ago I had the
realization that makeQuery() could have a fixed implementation based on
makeFilter() with makeValueSource() (for the distance). It's already committed
so you can see. Assuming you also think it makes a good default implementation,
this suggests any variety of makeQuery would call the same method, which
seems less than ideal but not terrible.
{quote}
Now I think about it, what exactly are the purposes of makeQuery and
makeValueSource()? I don't think it's clear. Does makeQuery() have to score
the same Documents as makeFilter() identifies? We don't verify that they do.
What does the score for makeQuery() mean? Is it always the distance between the
centre of two Shapes? I can think of a IsDisJoint scenario where the two Shapes
are disjoint but they have the same central point. Consequently is the score
related to the operation? What is makeValueSource() all about then? does it
return the same score for the same Document as makeQuery() just doesn't do any
filtering as well?
Remove the use of SpatialOperation
--
Key: LUCENE-4167
URL: https://issues.apache.org/jira/browse/LUCENE-4167
Project: Lucene - Java
Issue Type: Bug
Components: modules/spatial
Reporter: Chris Male
Attachments: LUCENE-4167.patch
Looking at the code in TwoDoublesStrategy I noticed
SpatialOperations.BBoxWithin vs isWithin which confused me. Looking over the
other Strategys I see that really only isWithin and Intersects is supported.
Only TwoDoublesStrategy supports IsDisjointTo. The remainder of
SpatialOperations are not supported.
I don't think we should use SpatialOperation as this stage since it is not
clear what Operations are supported by what Strategys, many Operations are
not supported, and the code for handling the Operations is usually the same.
We can spin off the code for TwoDoublesStrategy's IsDisjointTo support into a
different Strategy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Solr-trunk - Build # 1898 - Failure
Build: https://builds.apache.org/job/Solr-trunk/1898/
1 tests failed.
REGRESSION: org.apache.solr.cloud.RecoveryZkTest.testDistribSearch
Error Message:
Thread threw an uncaught exception, thread: Thread[Lucene Merge Thread #0,6,]
Stack Trace:
java.lang.RuntimeException: Thread threw an uncaught exception, thread:
Thread[Lucene Merge Thread #0,6,]
at
com.carrotsearch.randomizedtesting.RunnerThreadGroup.processUncaught(RunnerThreadGroup.java:96)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:857)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:669)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:695)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:734)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:745)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:56)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)
Caused by: org.apache.lucene.index.MergePolicy$MergeException:
org.apache.lucene.store.AlreadyClosedException: this Directory is closed
at __randomizedtesting.SeedInfo.seed([8ABB7755A967EF5A]:0)
at
org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:507)
at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:480)
Caused by: org.apache.lucene.store.AlreadyClosedException: this Directory is
closed
at org.apache.lucene.store.Directory.ensureOpen(Directory.java:244)
at org.apache.lucene.store.FSDirectory.listAll(FSDirectory.java:241)
at
org.apache.lucene.index.IndexFileDeleter.refresh(IndexFileDeleter.java:321)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3144)
at
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMergeScheduler.java:382)
at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:451)
Build Log:
[...truncated 43725 lines...]
[junit4] 2
commit{dir=/usr/home/hudson/hudson-slave/workspace/Solr-trunk/checkout/solr/build/solr-core/test/J0/org.apache.solr.cloud.RecoveryZkTest-1340887047962/control/data/index,segFN=segments_3,generation=3,filenames=[_4o_Lucene40_0.tip,
_4o.si, _4o_nrm.cfs, _4o.fnm, _4o.fdt, _4o_Lucene40_0.frq, _4o.fdx,
_4o_nrm.cfe, _4o_Lucene40_0.tim, _4o_Lucene40_0.prx, segments_3]
[junit4] 2 27262 T2847 C164 P59232 oasc.SolrDeletionPolicy.updateCommits
newest commit = 3
[junit4] 2 27270 T2852 oazs.PrepRequestProcessor.pRequest Processed
session termination for sessionid: 0x13833189f1f0002
[junit4] 2 27271 T2942 oascc.ZkStateReader$3.process Updating live nodes
[junit4] 2 27271 T2867 oascc.ZkStateReader$3.process Updating live nodes
[junit4] 2 27272 T2880 oascc.ZkStateReader$3.process Updating live nodes
[junit4] 2 27271 T2900 oascc.ZkStateReader$3.process Updating live nodes
[junit4] 2 27272 T2867 oascc.ZkStateReader$3.process WARNING ZooKeeper
watch triggered, but Solr cannot talk to ZK
[junit4] 2 27272 T2847 oaz.ZooKeeper.close Session: 0x13833189f1f0002
closed
[junit4] 2 27272 T2849 oazs.NIOServerCnxn.closeSock Closed socket
connection for client /140.211.11.196:54390 which had sessionid
0x13833189f1f0002
[junit4] 2
[jira] [Comment Edited] (LUCENE-4167) Remove the use of SpatialOperation
[
https://issues.apache.org/jira/browse/LUCENE-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403059#comment-13403059
]
Chris Male edited comment on LUCENE-4167 at 6/28/12 12:44 PM:
--
{quote}
Somewhat related to this is the Filter/Query distinction. Minutes ago I had the
realization that makeQuery() could have a fixed implementation based on
makeFilter() with makeValueSource() (for the distance). It's already committed
so you can see. Assuming you also think it makes a good default implementation,
this suggests any variety of makeQuery would call the same method, which
seems less than ideal but not terrible.
{quote}
Now I think about it, what exactly are the purposes of makeQuery and
makeValueSource()? I don't think it's clear. Does makeQuery() have to score
the same Documents as makeFilter() identifies? We don't verify that they do.
What does the score for makeQuery() mean? Is it always the distance between the
centre of two Shapes? I can think of a IsDisJoint scenario where the two Shapes
are disjoint but they have the same central point. Consequently is the score
related to the operation? What is makeValueSource() all about then? does it
return the same score for the same Document as makeQuery() just doesn't do any
filtering as well?
Whatever the answer is to all these questions, we really need to document them.
was (Author: cmale):
{quote}
Somewhat related to this is the Filter/Query distinction. Minutes ago I had the
realization that makeQuery() could have a fixed implementation based on
makeFilter() with makeValueSource() (for the distance). It's already committed
so you can see. Assuming you also think it makes a good default implementation,
this suggests any variety of makeQuery would call the same method, which
seems less than ideal but not terrible.
{quote}
Now I think about it, what exactly are the purposes of makeQuery and
makeValueSource()? I don't think it's clear. Does makeQuery() have to score
the same Documents as makeFilter() identifies? We don't verify that they do.
What does the score for makeQuery() mean? Is it always the distance between the
centre of two Shapes? I can think of a IsDisJoint scenario where the two Shapes
are disjoint but they have the same central point. Consequently is the score
related to the operation? What is makeValueSource() all about then? does it
return the same score for the same Document as makeQuery() just doesn't do any
filtering as well?
Remove the use of SpatialOperation
--
Key: LUCENE-4167
URL: https://issues.apache.org/jira/browse/LUCENE-4167
Project: Lucene - Java
Issue Type: Bug
Components: modules/spatial
Reporter: Chris Male
Attachments: LUCENE-4167.patch
Looking at the code in TwoDoublesStrategy I noticed
SpatialOperations.BBoxWithin vs isWithin which confused me. Looking over the
other Strategys I see that really only isWithin and Intersects is supported.
Only TwoDoublesStrategy supports IsDisjointTo. The remainder of
SpatialOperations are not supported.
I don't think we should use SpatialOperation as this stage since it is not
clear what Operations are supported by what Strategys, many Operations are
not supported, and the code for handling the Operations is usually the same.
We can spin off the code for TwoDoublesStrategy's IsDisjointTo support into a
different Strategy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: help with release notes
On Thu, Jun 28, 2012 at 7:32 AM, Robert Muir rcm...@gmail.com wrote: Hello: I created drafts for the 4.0-alpha release notes: http://wiki.apache.org/lucene-java/ReleaseNote40alpha and http://wiki.apache.org/solr/ReleaseNote40alpha The lucene ones i did a while ago... there is an overwhelming number of changes and trying to summarize the biggest ones is pretty challenging. Can someone help me with the solr one? I'll take a crack at it today -Yonik http://lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4062) More fine-grained control over the packed integer implementation that is chosen
[
https://issues.apache.org/jira/browse/LUCENE-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403064#comment-13403064
]
Toke Eskildsen commented on LUCENE-4062:
I have tried running the performance test again with different setups. Graphs
at http://ekot.dk/misc/packedints/
Most of the tests under JRE 1.7 are still running, but from the single JRE 1.6
vs. JRE 1.7 (at the bottom), it would seem that there is a difference in the
performance of Packed64SingleBlock vs. Packed64. Take that with a grain of salt
though, as the results from that machine are quite strange (especially for
Direct sets).
If the Java version influences which choice is best and if we throw valueCount
into the mix (or rather cache utilization, which is very much non-determinable
when a Mutable is requested), I am afraid that it will be very hard to
auto-recommend a specific implementation.
I will update the page and notify here, when more tests has finished.
More fine-grained control over the packed integer implementation that is
chosen
---
Key: LUCENE-4062
URL: https://issues.apache.org/jira/browse/LUCENE-4062
Project: Lucene - Java
Issue Type: Improvement
Components: core/other
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
Labels: performance
Fix For: 4.0, 5.0
Attachments: LUCENE-4062-2.patch, LUCENE-4062.patch,
LUCENE-4062.patch, LUCENE-4062.patch, LUCENE-4062.patch, LUCENE-4062.patch,
LUCENE-4062.patch, LUCENE-4062.patch, Packed64calc.java,
PackedIntsBenchmark.java, PackedIntsBenchmark.java,
measurements_te_graphs.pdf, measurements_te_i7.txt, measurements_te_p4.txt,
measurements_te_xeon.txt
In order to save space, Lucene has two main PackedInts.Mutable implentations,
one that is very fast and is based on a byte/short/integer/long array
(Direct*) and another one which packs bits in a memory-efficient manner
(Packed*).
The packed implementation tends to be much slower than the direct one, which
discourages some Lucene components to use it. On the other hand, if you store
21 bits integers in a Direct32, this is a space loss of (32-21)/32=35%.
If you accept to trade some space for speed, you could store 3 of these 21
bits integers in a long, resulting in an overhead of 1/3 bit per value. One
advantage of this approach is that you never need to read more than one block
to read or write a value, so this can be significantly faster than Packed32
and Packed64 which always need to read/write two blocks in order to avoid
costly branches.
I ran some tests, and for 1000 21 bits values, this implementation takes
less than 2% more space and has 44% faster writes and 30% faster reads. The
12 bits version (5 values per block) has the same performance improvement and
a 6% memory overhead compared to the packed implementation.
In order to select the best implementation for a given integer size, I wrote
the {{PackedInts.getMutable(valueCount, bitsPerValue,
acceptableOverheadPerValue)}} method. This method select the fastest
implementation that has less than {{acceptableOverheadPerValue}} wasted bits
per value. For example, if you accept an overhead of 20%
({{acceptableOverheadPerValue = 0.2f * bitsPerValue}}), which is pretty
reasonable, here is what implementations would be selected:
* 1: Packed64SingleBlock1
* 2: Packed64SingleBlock2
* 3: Packed64SingleBlock3
* 4: Packed64SingleBlock4
* 5: Packed64SingleBlock5
* 6: Packed64SingleBlock6
* 7: Direct8
* 8: Direct8
* 9: Packed64SingleBlock9
* 10: Packed64SingleBlock10
* 11: Packed64SingleBlock12
* 12: Packed64SingleBlock12
* 13: Packed64
* 14: Direct16
* 15: Direct16
* 16: Direct16
* 17: Packed64
* 18: Packed64SingleBlock21
* 19: Packed64SingleBlock21
* 20: Packed64SingleBlock21
* 21: Packed64SingleBlock21
* 22: Packed64
* 23: Packed64
* 24: Packed64
* 25: Packed64
* 26: Packed64
* 27: Direct32
* 28: Direct32
* 29: Direct32
* 30: Direct32
* 31: Direct32
* 32: Direct32
* 33: Packed64
* 34: Packed64
* 35: Packed64
* 36: Packed64
* 37: Packed64
* 38: Packed64
* 39: Packed64
* 40: Packed64
* 41: Packed64
* 42: Packed64
* 43: Packed64
* 44: Packed64
* 45: Packed64
* 46: Packed64
* 47: Packed64
* 48: Packed64
* 49: Packed64
* 50: Packed64
* 51: Packed64
* 52: Packed64
* 53: Packed64
* 54: Direct64
* 55: Direct64
* 56: Direct64
* 57: Direct64
* 58: Direct64
* 59: Direct64
* 60: Direct64
* 61: Direct64
* 62: Direct64
Under 32 bits per value, only 13, 17 and 22-26 bits per value would still
choose the slower Packed64 implementation. Allowing a 50% overhead would
prevent the
[jira] [Updated] (LUCENE-4176) Can not produce proper collation key for ICUCollatedTermAttributeImp
[ https://issues.apache.org/jira/browse/LUCENE-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4176: Attachment: LUCENE-4176.patch ok attached is a patch fixing the QP bug with your test. There was a bug in your test as well: it doesnt actually analyze the terms because because it doesnt set fieldType.setTokenized(true). This is separately a huge trap. I'll open another issue for that. Can not produce proper collation key for ICUCollatedTermAttributeImp Key: LUCENE-4176 URL: https://issues.apache.org/jira/browse/LUCENE-4176 Project: Lucene - Java Issue Type: Bug Components: modules/queryparser Affects Versions: 5.0 Reporter: Nattapong Sirilappanich Attachments: LUCENE-4176.patch, LUCENE-4176.patch org.apache.lucene.collation.tokenattributes.ICUCollatedTermAttributeImpl return a hash of collation key's byte. The given hash value produce incorrect comparison result. The source code below return 1 for Lucene 3.6. The code here return 0. Code to reproduce: IndexWriter writer = new IndexWriter(ramDir, conf); Document doc = new Document(); FieldType fieldType = new FieldType(); fieldType.setIndexed(true); fieldType.setStored(true); Field field = new Field(content,เข, fieldType); doc.add(field); writer.addDocument(doc); writer.close(); IndexSearcher is = new IndexSearcher(DirectoryReader.open(ramDir)); QueryParser qp = new AnalyzingQueryParser(Version.LUCENE_50,content, analyzer); ScoreDoc[] result = is.search(qp.parse([\u0e01 TO \u0e03]), null,1000).scoreDocs; System.out.println(result.length); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4178) FieldType.setTokenized shoudl be true by default
Robert Muir created LUCENE-4178:
---
Summary: FieldType.setTokenized shoudl be true by default
Key: LUCENE-4178
URL: https://issues.apache.org/jira/browse/LUCENE-4178
Project: Lucene - Java
Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir
This is really confusing, see LUCENE-4176 where a user hit this.
The example code from the user there reads:
{code}
FieldType fieldType = new FieldType();
fieldType.setIndexed(true);
fieldType.setStored(true);
{code}
Its really trappy that this does not invoke the analyzer: because historically
we did this unless you specified NOT_ANALYZED.
So i think fieldType.setTokenized(true) should be the default: things like
StringField can turn it off.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4171) Performance improvements to Packed64
[
https://issues.apache.org/jira/browse/LUCENE-4171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403070#comment-13403070
]
Adrien Grand commented on LUCENE-4171:
--
Even if {{Packed64}} used one or two additional blocks to avoid branches, the
reader and the writer always read/wrote the exact number of required blocks
(this is why ctor #3 reads {{size}} longs instead of {{blocks.length == size +
1}} blocks). So this should not be a problem.
Can you fix ctor #1 so that it uses the size method instead of {{valueCount *
bitsPerValue / BLOCK_SIZE + 1}} (this may create one more block than required:
for example, if bitsPerValue=1 and valueCount=64, blocks will have a length of
2 while only 1 block is required)?
Performance improvements to Packed64
Key: LUCENE-4171
URL: https://issues.apache.org/jira/browse/LUCENE-4171
Project: Lucene - Java
Issue Type: Sub-task
Components: core/other
Affects Versions: 4.0, 5.0
Environment: Tested with 4 different Intel machines
Reporter: Toke Eskildsen
Priority: Minor
Labels: performance
Attachments: LUCENE-4171.patch, LUCENE-4171.patch, LUCENE-4171.patch
Original Estimate: 4h
Remaining Estimate: 4h
Based on the performance measurements of PackedInts.Mutable's in LUCENE-4062,
a new version of Packed64 has been created that is consistently faster than
the old Packed64 for both get and set.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4062) More fine-grained control over the packed integer implementation that is chosen
[
https://issues.apache.org/jira/browse/LUCENE-4062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-4062:
-
Attachment: Packed64SingleBlock.java
Very interesting. Out of curiousity could you try to run the tests on your
machines with the attached Packed64SingleBlock.java? It generates sub-classes
that might help the JVM optimize some multiplications/remainders. I'd be
interested to see what the difference is on your machines (on mine, it is
slightly faster than the current Packed64SingleBlock impl).
More fine-grained control over the packed integer implementation that is
chosen
---
Key: LUCENE-4062
URL: https://issues.apache.org/jira/browse/LUCENE-4062
Project: Lucene - Java
Issue Type: Improvement
Components: core/other
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
Labels: performance
Fix For: 4.0, 5.0
Attachments: LUCENE-4062-2.patch, LUCENE-4062.patch,
LUCENE-4062.patch, LUCENE-4062.patch, LUCENE-4062.patch, LUCENE-4062.patch,
LUCENE-4062.patch, LUCENE-4062.patch, Packed64SingleBlock.java,
Packed64calc.java, PackedIntsBenchmark.java, PackedIntsBenchmark.java,
measurements_te_graphs.pdf, measurements_te_i7.txt, measurements_te_p4.txt,
measurements_te_xeon.txt
In order to save space, Lucene has two main PackedInts.Mutable implentations,
one that is very fast and is based on a byte/short/integer/long array
(Direct*) and another one which packs bits in a memory-efficient manner
(Packed*).
The packed implementation tends to be much slower than the direct one, which
discourages some Lucene components to use it. On the other hand, if you store
21 bits integers in a Direct32, this is a space loss of (32-21)/32=35%.
If you accept to trade some space for speed, you could store 3 of these 21
bits integers in a long, resulting in an overhead of 1/3 bit per value. One
advantage of this approach is that you never need to read more than one block
to read or write a value, so this can be significantly faster than Packed32
and Packed64 which always need to read/write two blocks in order to avoid
costly branches.
I ran some tests, and for 1000 21 bits values, this implementation takes
less than 2% more space and has 44% faster writes and 30% faster reads. The
12 bits version (5 values per block) has the same performance improvement and
a 6% memory overhead compared to the packed implementation.
In order to select the best implementation for a given integer size, I wrote
the {{PackedInts.getMutable(valueCount, bitsPerValue,
acceptableOverheadPerValue)}} method. This method select the fastest
implementation that has less than {{acceptableOverheadPerValue}} wasted bits
per value. For example, if you accept an overhead of 20%
({{acceptableOverheadPerValue = 0.2f * bitsPerValue}}), which is pretty
reasonable, here is what implementations would be selected:
* 1: Packed64SingleBlock1
* 2: Packed64SingleBlock2
* 3: Packed64SingleBlock3
* 4: Packed64SingleBlock4
* 5: Packed64SingleBlock5
* 6: Packed64SingleBlock6
* 7: Direct8
* 8: Direct8
* 9: Packed64SingleBlock9
* 10: Packed64SingleBlock10
* 11: Packed64SingleBlock12
* 12: Packed64SingleBlock12
* 13: Packed64
* 14: Direct16
* 15: Direct16
* 16: Direct16
* 17: Packed64
* 18: Packed64SingleBlock21
* 19: Packed64SingleBlock21
* 20: Packed64SingleBlock21
* 21: Packed64SingleBlock21
* 22: Packed64
* 23: Packed64
* 24: Packed64
* 25: Packed64
* 26: Packed64
* 27: Direct32
* 28: Direct32
* 29: Direct32
* 30: Direct32
* 31: Direct32
* 32: Direct32
* 33: Packed64
* 34: Packed64
* 35: Packed64
* 36: Packed64
* 37: Packed64
* 38: Packed64
* 39: Packed64
* 40: Packed64
* 41: Packed64
* 42: Packed64
* 43: Packed64
* 44: Packed64
* 45: Packed64
* 46: Packed64
* 47: Packed64
* 48: Packed64
* 49: Packed64
* 50: Packed64
* 51: Packed64
* 52: Packed64
* 53: Packed64
* 54: Direct64
* 55: Direct64
* 56: Direct64
* 57: Direct64
* 58: Direct64
* 59: Direct64
* 60: Direct64
* 61: Direct64
* 62: Direct64
Under 32 bits per value, only 13, 17 and 22-26 bits per value would still
choose the slower Packed64 implementation. Allowing a 50% overhead would
prevent the packed implementation to be selected for bits per value under 32.
Allowing an overhead of 32 bits per value would make sure that a Direct*
implementation is always selected.
Next steps would be to:
* make lucene components use this {{getMutable}} method and let users decide
what trade-off better suits them,
* write a Packed32SingleBlock implementation if necessary (I didn't do it
because I have no
[jira] [Commented] (LUCENE-4178) FieldType.setTokenized shoudl be true by default
[
https://issues.apache.org/jira/browse/LUCENE-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403083#comment-13403083
]
Chris Male commented on LUCENE-4178:
+1
FieldType.setTokenized shoudl be true by default
Key: LUCENE-4178
URL: https://issues.apache.org/jira/browse/LUCENE-4178
Project: Lucene - Java
Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir
This is really confusing, see LUCENE-4176 where a user hit this.
The example code from the user there reads:
{code}
FieldType fieldType = new FieldType();
fieldType.setIndexed(true);
fieldType.setStored(true);
{code}
Its really trappy that this does not invoke the analyzer: because
historically we did this unless you specified NOT_ANALYZED.
So i think fieldType.setTokenized(true) should be the default: things like
StringField can turn it off.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3582) Our ZooKeeper watchers respond to session events as if they are change events, creating undesirable side effects.
[ https://issues.apache.org/jira/browse/SOLR-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-3582: -- Summary: Our ZooKeeper watchers respond to session events as if they are change events, creating undesirable side effects. (was: Leader election zookeeper watcher is responding to con/discon notifications incorrectly.) Our ZooKeeper watchers respond to session events as if they are change events, creating undesirable side effects. - Key: SOLR-3582 URL: https://issues.apache.org/jira/browse/SOLR-3582 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.0, 5.0 As brought up by Trym R. Møller on the mailing list, we are responding to watcher events about connection/disconnection as if they were notifications about node changes. http://www.lucidimagination.com/search/document/e13ef390b882 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux-Java6-64 - Build # 1081 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64/1081/ All tests passed Build Log: [...truncated 17833 lines...] javadocs-lint: [...truncated 12 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build.xml:196: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/common-build.xml:1642: exec returned: 1 Total time: 3 minutes 1 second Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4176) Can not produce proper collation key for ICUCollatedTermAttributeImp
[ https://issues.apache.org/jira/browse/LUCENE-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-4176. - Resolution: Fixed Fix Version/s: 5.0 4.0 Thanks for reporting this: I committed the fix to AnalyzingQueryParser. But until LUCENE-4178 is resolved, be sure you setTokenized(true) in your fieldtype! Can not produce proper collation key for ICUCollatedTermAttributeImp Key: LUCENE-4176 URL: https://issues.apache.org/jira/browse/LUCENE-4176 Project: Lucene - Java Issue Type: Bug Components: modules/queryparser Affects Versions: 5.0 Reporter: Nattapong Sirilappanich Fix For: 4.0, 5.0 Attachments: LUCENE-4176.patch, LUCENE-4176.patch org.apache.lucene.collation.tokenattributes.ICUCollatedTermAttributeImpl return a hash of collation key's byte. The given hash value produce incorrect comparison result. The source code below return 1 for Lucene 3.6. The code here return 0. Code to reproduce: IndexWriter writer = new IndexWriter(ramDir, conf); Document doc = new Document(); FieldType fieldType = new FieldType(); fieldType.setIndexed(true); fieldType.setStored(true); Field field = new Field(content,เข, fieldType); doc.add(field); writer.addDocument(doc); writer.close(); IndexSearcher is = new IndexSearcher(DirectoryReader.open(ramDir)); QueryParser qp = new AnalyzingQueryParser(Version.LUCENE_50,content, analyzer); ScoreDoc[] result = is.search(qp.parse([\u0e01 TO \u0e03]), null,1000).scoreDocs; System.out.println(result.length); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Count of keys of an FST
I looked at the sources and didn't see a key count. Thanks Dawid and Mike. On Thu, Jun 28, 2012 at 6:37 AM, Michael McCandless luc...@mikemccandless.com wrote: I believe node and arc count are stored, but not key count. But check the sources to be sure! Mike McCandless http://blog.mikemccandless.com On Wed, Jun 27, 2012 at 4:53 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: If you need the count with constant time then yes, you should store it separately. You could also make a transducer that would store it at the root node as side-effect of values associated with keys, but it's kind of ugly. Please check the fst header though -- I'm not sure, maybe Mike wrote it so that the node count/ keys count is in there. Dawid On Wed, Jun 27, 2012 at 10:50 PM, Jason Rutherglen jason.rutherg...@gmail.com wrote: Sounds like I should just count as the keys are added and store the count separately. On Wed, Jun 27, 2012 at 3:48 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: I don't think there is one that you could use out of the box... but maybe I'm wrong and it's stored in the header somewhere (don't have the source in front of me). To calculate it by hand the worst case is that you'll need a recursive traversal, which would mean O(number of stored states) with intermediate count caches or O(number of keys) without any caches and memory overhead (just recursive traversal). Dawid On Wed, Jun 27, 2012 at 10:36 PM, Jason Rutherglen jason.rutherg...@gmail.com wrote: The FST class has a number of methods that return counts, which one returns the total number of keys that have been encoded into the FST? - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3582) Our ZooKeeper watchers respond to session events as if they are change events, creating undesirable side effects.
[ https://issues.apache.org/jira/browse/SOLR-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-3582. --- Resolution: Fixed Thanks Trym! Our ZooKeeper watchers respond to session events as if they are change events, creating undesirable side effects. - Key: SOLR-3582 URL: https://issues.apache.org/jira/browse/SOLR-3582 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.0, 5.0 As brought up by Trym R. Møller on the mailing list, we are responding to watcher events about connection/disconnection as if they were notifications about node changes. http://www.lucidimagination.com/search/document/e13ef390b882 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Count of keys of an FST
Let me know if you need that snippet of code to count the keys; or try it yourself -- should be good practice :) Dawid On Thu, Jun 28, 2012 at 3:32 PM, Jason Rutherglen jason.rutherg...@gmail.com wrote: I looked at the sources and didn't see a key count. Thanks Dawid and Mike. On Thu, Jun 28, 2012 at 6:37 AM, Michael McCandless luc...@mikemccandless.com wrote: I believe node and arc count are stored, but not key count. But check the sources to be sure! Mike McCandless http://blog.mikemccandless.com On Wed, Jun 27, 2012 at 4:53 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: If you need the count with constant time then yes, you should store it separately. You could also make a transducer that would store it at the root node as side-effect of values associated with keys, but it's kind of ugly. Please check the fst header though -- I'm not sure, maybe Mike wrote it so that the node count/ keys count is in there. Dawid On Wed, Jun 27, 2012 at 10:50 PM, Jason Rutherglen jason.rutherg...@gmail.com wrote: Sounds like I should just count as the keys are added and store the count separately. On Wed, Jun 27, 2012 at 3:48 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: I don't think there is one that you could use out of the box... but maybe I'm wrong and it's stored in the header somewhere (don't have the source in front of me). To calculate it by hand the worst case is that you'll need a recursive traversal, which would mean O(number of stored states) with intermediate count caches or O(number of keys) without any caches and memory overhead (just recursive traversal). Dawid On Wed, Jun 27, 2012 at 10:36 PM, Jason Rutherglen jason.rutherg...@gmail.com wrote: The FST class has a number of methods that return counts, which one returns the total number of keys that have been encoded into the FST? - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4178) FieldType.setTokenized shoudl be true by default
[
https://issues.apache.org/jira/browse/LUCENE-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-4178:
Attachment: LUCENE-4178.patch
FieldType.setTokenized shoudl be true by default
Key: LUCENE-4178
URL: https://issues.apache.org/jira/browse/LUCENE-4178
Project: Lucene - Java
Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir
Attachments: LUCENE-4178.patch
This is really confusing, see LUCENE-4176 where a user hit this.
The example code from the user there reads:
{code}
FieldType fieldType = new FieldType();
fieldType.setIndexed(true);
fieldType.setStored(true);
{code}
Its really trappy that this does not invoke the analyzer: because
historically we did this unless you specified NOT_ANALYZED.
So i think fieldType.setTokenized(true) should be the default: things like
StringField can turn it off.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4178) FieldType.setTokenized shoudl be true by default
[
https://issues.apache.org/jira/browse/LUCENE-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403096#comment-13403096
]
Chris Male commented on LUCENE-4178:
+1
FieldType.setTokenized shoudl be true by default
Key: LUCENE-4178
URL: https://issues.apache.org/jira/browse/LUCENE-4178
Project: Lucene - Java
Issue Type: Bug
Affects Versions: 4.0
Reporter: Robert Muir
Attachments: LUCENE-4178.patch
This is really confusing, see LUCENE-4176 where a user hit this.
The example code from the user there reads:
{code}
FieldType fieldType = new FieldType();
fieldType.setIndexed(true);
fieldType.setStored(true);
{code}
Its really trappy that this does not invoke the analyzer: because
historically we did this unless you specified NOT_ANALYZED.
So i think fieldType.setTokenized(true) should be the default: things like
StringField can turn it off.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 14789 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/14789/ All tests passed Build Log: [...truncated 24144 lines...] [...truncated 24144 lines...] [...truncated 24144 lines...] [...truncated 24118 lines...] javadocs-lint: [exec] [exec] Crawl/parse... [exec] [exec] build/docs/core/org/apache/lucene/store/package-use.html [exec] WARNING: anchor ../../../../org/apache/lucene/store/subclasses appears more than once [exec] [exec] Verify... [exec] [exec] build/docs/spatial/overview-summary.html [exec] missing: org.apache.lucene.spatial.bbox [exec] [exec] Missing javadocs were found! BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build.xml:196: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/common-build.xml:1642: exec returned: 1 Total time: 3 minutes 13 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Publishing Clover coverage report... No Clover report will be published due to a Build Failure Email was triggered for: Failure Sending email for trigger: Failure [...truncated 24144 lines...] [...truncated 24144 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4165) HunspellDictionary - AffixFile Reader closed, Dictionary Readers left unclosed
[ https://issues.apache.org/jira/browse/LUCENE-4165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Torsten Krah updated LUCENE-4165: - Attachment: LUCENE_4156_36.patch Updated patch, removed IOUtils change, catch useless Exception. HunspellDictionary - AffixFile Reader closed, Dictionary Readers left unclosed -- Key: LUCENE-4165 URL: https://issues.apache.org/jira/browse/LUCENE-4165 Project: Lucene - Java Issue Type: Bug Components: modules/analysis Affects Versions: 3.6 Environment: Linux, Java 1.6 Reporter: Torsten Krah Priority: Minor Attachments: LUCENE-4156-trunk.patch, LUCENE_4156_36.patch, lucene_36.patch, lucene_trunk.patch The HunspellDictionary takes an InputStream for affix file and a List of Streams for dictionaries. Javadoc is not clear about i have to close those stream myself or the Dictionary constructor does this already. Looking at the code, at least reader.close() is called when the affix file is read via readAffixFile() method (although closing streams is not done in a finally block - so the constructor may fail to do so). The readDictionaryFile() method does miss the call to close the reader in contrast to readAffixFile(). So the question here is - have i have to close the streams myself after instantiating the dictionary? Or is the close call only missing for the dictionary streams? Either way, please add the close calls in a safe manner or clarify javadoc so i have to do this myself. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
