[jira] [Created] (SOLR-5110) Change default spell check query analyzer if not defined
Varun Thacker created SOLR-5110: --- Summary: Change default spell check query analyzer if not defined Key: SOLR-5110 URL: https://issues.apache.org/jira/browse/SOLR-5110 Project: Solr Issue Type: Improvement Components: SearchComponents - other Reporter: Varun Thacker Priority: Minor Fix For: 4.5, 5.0 The collection1 example uses the query analyzer from text_general FieldType as queryAnalyzerFieldType in the SpellCheck component. Now if someone removes this from the SpellCheckComponent configuration the query uses WhiteSpaceAnalyzer. I think we could change this to SimpleAnalyzer so that spell check results for foo and Foo give the same results. We should also log if the fieldType is not found. Are there more places in solrconfig which have dependencies on schema? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5104) Remove Default Core
[ https://issues.apache.org/jira/browse/SOLR-5104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727423#comment-13727423 ] Grant Ingersoll commented on SOLR-5104: --- +1 to removing default core. Remove Default Core --- Key: SOLR-5104 URL: https://issues.apache.org/jira/browse/SOLR-5104 Project: Solr Issue Type: Sub-task Reporter: Grant Ingersoll Fix For: 5.0 I see no reason to maintain the notion of a default Core/Collection. We can either default to Collection1, or just simply create a core on the fly based on the client's request. Thus, all APIs that are accessing a core would require the core to be in the address path. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] (SOLR-5111) Change SpellCheckComponent default analyzer when queryAnalyzerFieldType is not defined
Varun Thacker created SOLR-5111: --- Summary: Change SpellCheckComponent default analyzer when queryAnalyzerFieldType is not defined Key: SOLR-5111 URL: https://issues.apache.org/jira/browse/SOLR-5111 Project: Solr Issue Type: Improvement Reporter: Varun Thacker Priority: Minor Fix For: 4.5, 5.0 In the collection1 example, the SpellCheckComponent uses the query analyzer of text_general FieldType. If queryAnalyzerFieldType is removed from the configuration a WhitespaceAnalyzer is used by default. I suggest we could change the default to SimpleAnalyzer so that foo and Foo gives the same results and log that the analyzer is missing. Also are there more places in solrconfig which have dependencies on schema like this? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5156) CompressingTermVectors termsEnum should probably not support seek-by-ord
[ https://issues.apache.org/jira/browse/LUCENE-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727443#comment-13727443 ] Adrien Grand commented on LUCENE-5156: -- +1 this is trappy CompressingTermVectors termsEnum should probably not support seek-by-ord Key: LUCENE-5156 URL: https://issues.apache.org/jira/browse/LUCENE-5156 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Just like term vectors before it, it has a O(n) seek-by-term. But this one also advertises a seek-by-ord, only this is also O(n). This could cause e.g. checkindex to be very slow, because if termsenum supports ord it does a bunch of seeking tests. (Another solution would be to leave it, and add a boolean so checkindex never does seeking tests for term vectors, only real fields). However, I think its also kinda a trap, in my opinion if seek-by-ord is supported anywhere, you kinda expect it to be faster than linear time...? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Closed] (SOLR-5110) Change default spell check query analyzer if not defined
[ https://issues.apache.org/jira/browse/SOLR-5110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker closed SOLR-5110. --- Resolution: Duplicate I created SOLR-5111. I thought the creation of the JIRA had failed. Change default spell check query analyzer if not defined Key: SOLR-5110 URL: https://issues.apache.org/jira/browse/SOLR-5110 Project: Solr Issue Type: Improvement Components: SearchComponents - other Reporter: Varun Thacker Priority: Minor Fix For: 4.5, 5.0 The collection1 example uses the query analyzer from text_general FieldType as queryAnalyzerFieldType in the SpellCheck component. Now if someone removes this from the SpellCheckComponent configuration the query uses WhiteSpaceAnalyzer. I think we could change this to SimpleAnalyzer so that spell check results for foo and Foo give the same results. We should also log if the fieldType is not found. Are there more places in solrconfig which have dependencies on schema? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5111) Change SpellCheckComponent default analyzer when queryAnalyzerFieldType is not defined
[ https://issues.apache.org/jira/browse/SOLR-5111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Varun Thacker updated SOLR-5111: Attachment: SOLR-5111.patch Change SpellCheckComponent default analyzer when queryAnalyzerFieldType is not defined -- Key: SOLR-5111 URL: https://issues.apache.org/jira/browse/SOLR-5111 Project: Solr Issue Type: Improvement Reporter: Varun Thacker Priority: Minor Fix For: 4.5, 5.0 Attachments: SOLR-5111.patch In the collection1 example, the SpellCheckComponent uses the query analyzer of text_general FieldType. If queryAnalyzerFieldType is removed from the configuration a WhitespaceAnalyzer is used by default. I suggest we could change the default to SimpleAnalyzer so that foo and Foo gives the same results and log that the analyzer is missing. Also are there more places in solrconfig which have dependencies on schema like this? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5111) Change SpellCheckComponent default analyzer when queryAnalyzerFieldType is not defined
[ https://issues.apache.org/jira/browse/SOLR-5111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727472#comment-13727472 ] Varun Thacker commented on SOLR-5111: - Simple patch. Change SpellCheckComponent default analyzer when queryAnalyzerFieldType is not defined -- Key: SOLR-5111 URL: https://issues.apache.org/jira/browse/SOLR-5111 Project: Solr Issue Type: Improvement Reporter: Varun Thacker Priority: Minor Fix For: 4.5, 5.0 Attachments: SOLR-5111.patch In the collection1 example, the SpellCheckComponent uses the query analyzer of text_general FieldType. If queryAnalyzerFieldType is removed from the configuration a WhitespaceAnalyzer is used by default. I suggest we could change the default to SimpleAnalyzer so that foo and Foo gives the same results and log that the analyzer is missing. Also are there more places in solrconfig which have dependencies on schema like this? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727478#comment-13727478 ] Joern Kottmann commented on LUCENE-2899: @[~lancenorskog] we now have support in OpenNLP to train the name finder on a corpus in the Brat [1] data format, that makes it much easier to annotate custom data within a couple of days/weeks. [1] http://brat.nlplab.org/ Add OpenNLP Analysis capabilities as a module - Key: LUCENE-2899 URL: https://issues.apache.org/jira/browse/LUCENE-2899 Project: Lucene - Core Issue Type: New Feature Components: modules/analysis Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 5.0, 4.5 Attachments: LUCENE-2899-current.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899-RJN.patch, LUCENE-2899-x.patch, LUCENE-2899-x.patch, LUCENE-2899-x.patch, OpenNLPFilter.java, OpenNLPFilter.java, OpenNLPTokenizer.java, opennlp_trunk.patch Now that OpenNLP is an ASF project and has a nice license, it would be nice to have a submodule (under analysis) that exposed capabilities for it. Drew Farris, Tom Morton and I have code that does: * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it would have to change slightly to buffer tokens) * NamedEntity recognition as a TokenFilter We are also planning a Tokenizer/TokenFilter that can put parts of speech as either payloads (PartOfSpeechAttribute?) on a token or at the same position. I'd propose it go under: modules/analysis/opennlp -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4818) Create a boolean perceptron classifier
[ https://issues.apache.org/jira/browse/LUCENE-4818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727482#comment-13727482 ] Tommaso Teofili commented on LUCENE-4818: - some work in progress at : https://github.com/tteofili/lucene-solr/compare/apache:trunk...lucene-4818 once it's faster and stabler I'll create a new patch. Create a boolean perceptron classifier -- Key: LUCENE-4818 URL: https://issues.apache.org/jira/browse/LUCENE-4818 Project: Lucene - Core Issue Type: New Feature Components: modules/classification Reporter: Tommaso Teofili Assignee: Tommaso Teofili Priority: Minor Fix For: 5.0 Attachments: LUCENE-4818.patch Create a Lucene based classifier using the perceptron algorithm (see http://en.wikipedia.org/wiki/Perceptron) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
uniqueKey as non-string
Hmmm, comment on the user's list that routing using the ! notation fails if the uniqueKey is a long. Should we put up some kind of note that string id fields are pretty much required for full SolrCloud functionality? FWIW, Erick
[solr 4.4.0] SPLITSHARD: small inconvenience
Hello, SPLITSHARD is great, but has a small inconvenience in the core-level split mode. The following query: http://localhost:8982/solr/admin/cores?core=statementsaction=SPLITpath=multicore/core11path=multicore/core12 will create two sub-directories in multicore dir: core11 and core12 with partitioned index of the core1, but the directory structure does not follow data/index structure. Which, I think, in turn does not allow to add the two new cores via the solr dashboard properly. Regards, Dmitry Kan
[jira] [Commented] (SOLR-2570) randomize indexwriter settings in solr tests
[ https://issues.apache.org/jira/browse/SOLR-2570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727719#comment-13727719 ] Robert Muir commented on SOLR-2570: --- +1 randomize indexwriter settings in solr tests Key: SOLR-2570 URL: https://issues.apache.org/jira/browse/SOLR-2570 Project: Solr Issue Type: Sub-task Components: Build Reporter: Robert Muir Assignee: Robert Muir Fix For: 4.5, 5.0 Attachments: SOLR-2570.patch, SOLR-2570.patch we should randomize indexwriter settings like lucene tests do, to vary # of segments and such. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-MAVEN] Lucene-Solr-Maven-4.x #405: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/405/ 1 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch Error Message: IOException occured when talking to server at: http://127.0.0.1:43367 Stack Trace: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:43367 at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:129) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1535) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCustomCollectionsAPI(CollectionsAPIDistributedZkTest.java:677) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:159) Build Log: [...truncated 24558 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3069) Lucene should have an entirely memory resident term dictionary
[
https://issues.apache.org/jira/browse/LUCENE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Han Jiang updated LUCENE-3069:
--
Attachment: LUCENE-3069.patch
Uploaded patch.
It is optimized for wildcardquery, and I did a quick test on 1M wiki data:
{noformat}
TaskQPS base StdDevQPS comp StdDev
Pct diff
PKLookup 314.63 (1.5%) 314.64 (1.2%)
0.0% ( -2% -2%)
Fuzzy1 91.32 (3.7%) 92.50 (1.6%)
1.3% ( -3% -6%)
Respell 104.54 (3.9%) 106.97 (1.6%)
2.3% ( -2% -8%)
Fuzzy2 38.22 (4.1%) 39.16 (1.2%)
2.5% ( -2% -8%)
Wildcard 109.56 (3.1%) 273.42 (5.0%)
149.6% ( 137% - 162%)
{noformat}
and TempFSTOrd vs. Lucene41, on 1M data:
{noformat}
TaskQPS base StdDevQPS comp StdDev
Pct diff
Respell 134.85 (3.7%) 106.30 (0.6%)
-21.2% ( -24% - -17%)
Fuzzy2 47.78 (4.1%) 39.03 (0.9%)
-18.3% ( -22% - -13%)
Fuzzy1 112.02 (3.0%) 91.95 (0.6%)
-17.9% ( -20% - -14%)
Wildcard 326.68 (3.5%) 273.41 (1.9%)
-16.3% ( -20% - -11%)
PKLookup 194.61 (1.8%) 314.24 (0.7%)
61.5% ( 57% - 65%)
{noformat}
But I'm not happy with it :(, the hack I did here is to consume another big
block to store the last byte of each term. So for wildcard query ab*c, we have
external information to tell the ord of nearest term like *c. Knowing the ord,
we can use a similar approach like getByOutput to jump to the next target term.
Previously, we have to walk on fst to the stop node to find out whether the
last byte is 'c', so this optimization comes to be a big chunk.
However I don't really like this patch :(, we have to increase index size (521M
= 530M), and the code comes to be mess up, since we always have to foresee the
next arc on current stack.
Lucene should have an entirely memory resident term dictionary
--
Key: LUCENE-3069
URL: https://issues.apache.org/jira/browse/LUCENE-3069
Project: Lucene - Core
Issue Type: Improvement
Components: core/index, core/search
Affects Versions: 4.0-ALPHA
Reporter: Simon Willnauer
Assignee: Han Jiang
Labels: gsoc2013
Fix For: 5.0, 4.5
Attachments: df-ttf-estimate.txt, example.png, LUCENE-3069.patch,
LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch,
LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch
FST based TermDictionary has been a great improvement yet it still uses a
delta codec file for scanning to terms. Some environments have enough memory
available to keep the entire FST based term dict in memory. We should add a
TermDictionary implementation that encodes all needed information for each
term into the FST (custom fst.Output) and builds a FST from the entire term
not just the delta.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: Welcome Cassandra Targett as Lucene/Solr committer
Welcome Cassandra! And thanks for sharing your background; it's nice to know more about others in the community. I'm in the Boston area -- Lowell specifically. ~ David - Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/Welcome-Cassandra-Targett-as-Lucene-Solr-committer-tp4081767p4082233.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5152) Lucene FST is not immutable
[ https://issues.apache.org/jira/browse/LUCENE-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727927#comment-13727927 ] David Smiley commented on LUCENE-5152: -- I've been bitten by bugs in my code related to sharing BytesRefs. It's not clear in the APIs who owns a BytesRef received from a method call. In other words, can a recipient know wether it can safely cache it for use later or wether it's not safe because it could change suddenly later. It's not even just that since there are two levels of ownership, the BytesRef instance and then the underlying char array. This could be partially addressed with more documentation; I did that in my own code but that didn't stop another bug. I have a rough idea in which a BytesRef has a boolean flag or two to indicate how share-able it is, and then a conditional clone method that either returns the current instance or returns shallow copy, or does a deep copy depending on those flags. I dunno, just a half-baked idea. Lucene FST is not immutable --- Key: LUCENE-5152 URL: https://issues.apache.org/jira/browse/LUCENE-5152 Project: Lucene - Core Issue Type: Bug Components: core/FSTs Affects Versions: 4.4 Reporter: Simon Willnauer Priority: Blocker Fix For: 5.0, 4.5 Attachments: LUCENE-5152.patch, LUCENE-5152.patch, LUCENE-5152.patch a spinnoff from LUCENE-5120 where the analyzing suggester modified a returned output from and FST (BytesRef) which caused sideffects in later execution. I added an assertion into the FST that checks if a cached root arc is modified and in-fact this happens for instance in our MemoryPostingsFormat and I bet we find more places. We need to think about how to make this less trappy since it can cause bugs that are super hard to find. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5152) Lucene FST is not immutable
[ https://issues.apache.org/jira/browse/LUCENE-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727956#comment-13727956 ] ASF subversion and git services commented on LUCENE-5152: - Commit 1509805 from [~simonw] in branch 'dev/trunk' [ https://svn.apache.org/r1509805 ] LUCENE-5152: Fix MemoryPostingsFormat to not modify borrowed BytesRef from FSTEnum Lucene FST is not immutable --- Key: LUCENE-5152 URL: https://issues.apache.org/jira/browse/LUCENE-5152 Project: Lucene - Core Issue Type: Bug Components: core/FSTs Affects Versions: 4.4 Reporter: Simon Willnauer Priority: Blocker Fix For: 5.0, 4.5 Attachments: LUCENE-5152.patch, LUCENE-5152.patch, LUCENE-5152.patch a spinnoff from LUCENE-5120 where the analyzing suggester modified a returned output from and FST (BytesRef) which caused sideffects in later execution. I added an assertion into the FST that checks if a cached root arc is modified and in-fact this happens for instance in our MemoryPostingsFormat and I bet we find more places. We need to think about how to make this less trappy since it can cause bugs that are super hard to find. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5152) Lucene FST is not immutable
[ https://issues.apache.org/jira/browse/LUCENE-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727958#comment-13727958 ] Simon Willnauer commented on LUCENE-5152: - I committed the latest patch to get the assert in and fix memory postings format. I will keep this issue open for further discussions Lucene FST is not immutable --- Key: LUCENE-5152 URL: https://issues.apache.org/jira/browse/LUCENE-5152 Project: Lucene - Core Issue Type: Bug Components: core/FSTs Affects Versions: 4.4 Reporter: Simon Willnauer Priority: Blocker Fix For: 5.0, 4.5 Attachments: LUCENE-5152.patch, LUCENE-5152.patch, LUCENE-5152.patch a spinnoff from LUCENE-5120 where the analyzing suggester modified a returned output from and FST (BytesRef) which caused sideffects in later execution. I added an assertion into the FST that checks if a cached root arc is modified and in-fact this happens for instance in our MemoryPostingsFormat and I bet we find more places. We need to think about how to make this less trappy since it can cause bugs that are super hard to find. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5152) Lucene FST is not immutable
[ https://issues.apache.org/jira/browse/LUCENE-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727963#comment-13727963 ] ASF subversion and git services commented on LUCENE-5152: - Commit 1509812 from [~simonw] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1509812 ] LUCENE-5152: Fix MemoryPostingsFormat to not modify borrowed BytesRef from FSTEnum Lucene FST is not immutable --- Key: LUCENE-5152 URL: https://issues.apache.org/jira/browse/LUCENE-5152 Project: Lucene - Core Issue Type: Bug Components: core/FSTs Affects Versions: 4.4 Reporter: Simon Willnauer Priority: Blocker Fix For: 5.0, 4.5 Attachments: LUCENE-5152.patch, LUCENE-5152.patch, LUCENE-5152.patch a spinnoff from LUCENE-5120 where the analyzing suggester modified a returned output from and FST (BytesRef) which caused sideffects in later execution. I added an assertion into the FST that checks if a cached root arc is modified and in-fact this happens for instance in our MemoryPostingsFormat and I bet we find more places. We need to think about how to make this less trappy since it can cause bugs that are super hard to find. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5152) Lucene FST is not immutable
[ https://issues.apache.org/jira/browse/LUCENE-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727986#comment-13727986 ] Michael McCandless commented on LUCENE-5152: I know we make no claims about performance when assertions are enabled... But it seems like this commit could substantially slow things down, since we call assertRootArcs, which is O(N) where N = number of root arcs, for every call to findTargetArc = likely called in hotspots. Maybe, we could move the call to e.g. FST.getBytesReader? Lucene FST is not immutable --- Key: LUCENE-5152 URL: https://issues.apache.org/jira/browse/LUCENE-5152 Project: Lucene - Core Issue Type: Bug Components: core/FSTs Affects Versions: 4.4 Reporter: Simon Willnauer Priority: Blocker Fix For: 5.0, 4.5 Attachments: LUCENE-5152.patch, LUCENE-5152.patch, LUCENE-5152.patch a spinnoff from LUCENE-5120 where the analyzing suggester modified a returned output from and FST (BytesRef) which caused sideffects in later execution. I added an assertion into the FST that checks if a cached root arc is modified and in-fact this happens for instance in our MemoryPostingsFormat and I bet we find more places. We need to think about how to make this less trappy since it can cause bugs that are super hard to find. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5152) Lucene FST is not immutable
[ https://issues.apache.org/jira/browse/LUCENE-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727993#comment-13727993 ] Simon Willnauer commented on LUCENE-5152: - how is getBytesReader related to the root arcs? unless this slows things down when assertions are not enabled I'd vote for not moving it. This is a very trappy thing and we should catch any violation IMO very quickly. Lucene FST is not immutable --- Key: LUCENE-5152 URL: https://issues.apache.org/jira/browse/LUCENE-5152 Project: Lucene - Core Issue Type: Bug Components: core/FSTs Affects Versions: 4.4 Reporter: Simon Willnauer Priority: Blocker Fix For: 5.0, 4.5 Attachments: LUCENE-5152.patch, LUCENE-5152.patch, LUCENE-5152.patch a spinnoff from LUCENE-5120 where the analyzing suggester modified a returned output from and FST (BytesRef) which caused sideffects in later execution. I added an assertion into the FST that checks if a cached root arc is modified and in-fact this happens for instance in our MemoryPostingsFormat and I bet we find more places. We need to think about how to make this less trappy since it can cause bugs that are super hard to find. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5091) Clean up Servlets APIs, Kill SolrDispatchFilter, simplify API creation
[
https://issues.apache.org/jira/browse/SOLR-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated SOLR-5091:
--
Attachment: SOLR-5091.patch
This is _really_ early. None of the tests pass, etc. but it does show the
Guice integration and it shows what's involved in adding a new API (see
PingAPI).
Moreover, I think it also will make it easier to embed Solr in whatever
container we want going forward (since the top level things like CoreContainer
are injected)
Once you apply the patch and build example and start it up, you should be able
to see something like:
{code}
curl http://localhost:8983/solr/rest/ping
{ping:alive}
{code}
Other notes, the endpoints, etc. are all just preliminary.
Also, see the top level package.html for some of my thoughts on restructuring
the APIs for REST.
This will be a significant undertaking. If others are interested in this
overhaul, I'd suggest we start a branch against trunk.
Clean up Servlets APIs, Kill SolrDispatchFilter, simplify API creation
--
Key: SOLR-5091
URL: https://issues.apache.org/jira/browse/SOLR-5091
Project: Solr
Issue Type: Improvement
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Fix For: 5.0
Attachments: SOLR-5091.patch
This is an issue to track a series of sub issues related to deprecated and
crufty Servlet/REST API code. I'll create sub-tasks to manage them.
# Clean up all the old UI stuff (old redirects)
# Kill/Simplify SolrDispatchFilter -- for instance, why not make the user
always have a core name in 5.0? i.e. /collection1 is the default core
## I'd like to move to just using Guice's servlet extension to do this,
which, I think will also make it easier to run Solr in other containers (i.e.
non-servlet environments) due to the fact that you don't have to tie the
request handling logic specifically to a Servlet.
# Simplify the creation and testing of REST and other APIs via Guice +
Restlet, which I've done on a number of occasions.
## It might be also possible to move all of the APIs onto Restlet and
maintain back compat through a simple restlet proxy (still exploring this).
This would also have the benefit of abstracting the core request processing
out of the Servlet context and make that an implementation detail.
## Moving to Guice, IMO, will make it easier to isolate and test individual
components by being able to inject mocks easier.
I am close to a working patch for some of this. I will post incremental
updates/issues as I move forward on this, but I think we should take 5.x as
an opportunity to be more agnostic of container and I believe the approach I
have in mind will do so.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-5140) Slowdown of the span queries caused by LUCENE-4946
[ https://issues.apache.org/jira/browse/LUCENE-5140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728020#comment-13728020 ] Michael McCandless commented on LUCENE-5140: Looks like this fix did indeed recover the lost perf in SpanNearQuery and exact PhraseQuery, and then some: http://people.apache.org/~mikemccand/lucenebench/SpanNear.html Thanks! Slowdown of the span queries caused by LUCENE-4946 -- Key: LUCENE-5140 URL: https://issues.apache.org/jira/browse/LUCENE-5140 Project: Lucene - Core Issue Type: Bug Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 5.0, 4.5 Attachments: LUCENE-5140.patch [~romseygeek] noticed that span queries have been slower since LUCENE-4946 got committed. http://people.apache.org/~mikemccand/lucenebench/SpanNear.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-MAVEN] Lucene-Solr-Maven-trunk #927: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/927/ 1 tests failed. FAILED: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch Error Message: IOException occured when talking to server at: http://127.0.0.1:60165/rd_eev/ps Stack Trace: org.apache.solr.client.solrj.SolrServerException: IOException occured when talking to server at: http://127.0.0.1:60165/rd_eev/ps at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:129) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:365) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1535) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCustomCollectionsAPI(CollectionsAPIDistributedZkTest.java:677) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:159) Build Log: [...truncated 24081 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5112) Show full message in Admin UI Logging View
[ https://issues.apache.org/jira/browse/SOLR-5112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Keeney updated SOLR-5112: - Attachment: SOLR-5112.patch Show full message in Admin UI Logging View -- Key: SOLR-5112 URL: https://issues.apache.org/jira/browse/SOLR-5112 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.1, 4.2.1, 4.3, 4.4 Reporter: Matthew Keeney Priority: Minor Attachments: SOLR-5112.patch SOLR-3560 allows logged exceptions without a trace element to be handled, however the new trace element created here only shows the first line. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] (SOLR-5112) Show full message in Admin UI Logging View
Matthew Keeney created SOLR-5112: Summary: Show full message in Admin UI Logging View Key: SOLR-5112 URL: https://issues.apache.org/jira/browse/SOLR-5112 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.4, 4.3, 4.2.1, 4.1 Reporter: Matthew Keeney Priority: Minor Attachments: SOLR-5112.patch SOLR-3560 allows logged exceptions without a trace element to be handled, however the new trace element created here only shows the first line. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5091) Clean up Servlets APIs, Kill SolrDispatchFilter, simplify API creation
[ https://issues.apache.org/jira/browse/SOLR-5091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728134#comment-13728134 ] Grant Ingersoll commented on SOLR-5091: --- Should be noted, there is a lot left to do: # Handle existing request handlers # Deal w/ collections, etc # Kill the SolrDispatchFilter # Decide on what tests still need to pass and what don't Also, I'd like to suggest some sub tasks that simplify some other things, namely, I'm not sure why we need to have response writers be per core, but we can cover that later. Clean up Servlets APIs, Kill SolrDispatchFilter, simplify API creation -- Key: SOLR-5091 URL: https://issues.apache.org/jira/browse/SOLR-5091 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Grant Ingersoll Fix For: 5.0 Attachments: SOLR-5091.patch This is an issue to track a series of sub issues related to deprecated and crufty Servlet/REST API code. I'll create sub-tasks to manage them. # Clean up all the old UI stuff (old redirects) # Kill/Simplify SolrDispatchFilter -- for instance, why not make the user always have a core name in 5.0? i.e. /collection1 is the default core ## I'd like to move to just using Guice's servlet extension to do this, which, I think will also make it easier to run Solr in other containers (i.e. non-servlet environments) due to the fact that you don't have to tie the request handling logic specifically to a Servlet. # Simplify the creation and testing of REST and other APIs via Guice + Restlet, which I've done on a number of occasions. ## It might be also possible to move all of the APIs onto Restlet and maintain back compat through a simple restlet proxy (still exploring this). This would also have the benefit of abstracting the core request processing out of the Servlet context and make that an implementation detail. ## Moving to Guice, IMO, will make it easier to isolate and test individual components by being able to inject mocks easier. I am close to a working patch for some of this. I will post incremental updates/issues as I move forward on this, but I think we should take 5.x as an opportunity to be more agnostic of container and I believe the approach I have in mind will do so. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5103) Plugin Improvements
[ https://issues.apache.org/jira/browse/SOLR-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728138#comment-13728138 ] Grant Ingersoll commented on SOLR-5103: --- Should be noted that we would want classloader isolation for this packaging. Plugin Improvements --- Key: SOLR-5103 URL: https://issues.apache.org/jira/browse/SOLR-5103 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Grant Ingersoll Fix For: 5.0 I think for 5.0, we should make it easier to add plugins by defining a plugin package, ala a Hadoop Job jar, which is a self--contained archive of a plugin that can be easily installed (even from the UI!) and configured programmatically. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5103) Plugin Improvements
[ https://issues.apache.org/jira/browse/SOLR-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728149#comment-13728149 ] Yonik Seeley commented on SOLR-5103: +1 for this! Keep the configuration w/ the plugin and don't require any central place to wire it up. bq. Should be noted that we would want classloader isolation for this packaging. Any downsides to that? Also, any reason it can't be in 4x (provided it's done in time?) Plugin Improvements --- Key: SOLR-5103 URL: https://issues.apache.org/jira/browse/SOLR-5103 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Grant Ingersoll Fix For: 5.0 I think for 5.0, we should make it easier to add plugins by defining a plugin package, ala a Hadoop Job jar, which is a self--contained archive of a plugin that can be easily installed (even from the UI!) and configured programmatically. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-5152) Lucene FST is not immutable
[ https://issues.apache.org/jira/browse/LUCENE-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728317#comment-13728317 ] Michael McCandless commented on LUCENE-5152: bq. how is getBytesReader related to the root arcs? Well, anything that works with the FST APIs needs to call getBytesReader first, e.g. MemoryPF does this every time you pull a TermsEnum from it. bq. This is a very trappy thing and we should catch any violation IMO very quickly. I agree it's trappy and it's great to add this check. I'm simply proposing moving it to less of a hot-spot, and I don't think this will affect how quickly we catch violations but should reduce the cost of this added assertion. In fact, I think findTargetArc isn't great in this regard; e.g. I think MemoryPF only uses this API if the caller calls seekExact? So I think the current location of the assert is both more costly and lower coverage than if we moved it to FST.getBytesReader. Lucene FST is not immutable --- Key: LUCENE-5152 URL: https://issues.apache.org/jira/browse/LUCENE-5152 Project: Lucene - Core Issue Type: Bug Components: core/FSTs Affects Versions: 4.4 Reporter: Simon Willnauer Priority: Blocker Fix For: 5.0, 4.5 Attachments: LUCENE-5152.patch, LUCENE-5152.patch, LUCENE-5152.patch a spinnoff from LUCENE-5120 where the analyzing suggester modified a returned output from and FST (BytesRef) which caused sideffects in later execution. I added an assertion into the FST that checks if a cached root arc is modified and in-fact this happens for instance in our MemoryPostingsFormat and I bet we find more places. We need to think about how to make this less trappy since it can cause bugs that are super hard to find. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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: Welcome Cassandra Targett as Lucene/Solr committer
Welcome cassandra. . On 1 Aug 2013 04:18, Robert Muir rcm...@gmail.com wrote: I'm pleased to announce that Cassandra Targett has accepted to join our ranks as a committer. Cassandra worked on the donation of the new Solr Reference Guide [1] and getting things in order for its first official release [2]. Cassandra, it is tradition that you introduce yourself with a brief bio. Welcome! P.S. As soon as your SVN access is setup, you should then be able to add yourself to the committers list on the website as well. [1] https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide [2] https://www.apache.org/dyn/closer.cgi/lucene/solr/ref-guide/
[JENKINS] Lucene-Solr-SmokeRelease-4.x - Build # 96 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-4.x/96/
No tests ran.
Build Log:
[...truncated 33927 lines...]
prepare-release-no-sign:
[mkdir] Created dir:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/lucene/build/fakeRelease
[copy] Copying 416 files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/lucene/build/fakeRelease/lucene
[copy] Copying 194 files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/lucene/build/fakeRelease/solr
[exec] JAVA6_HOME is /home/hudson/tools/java/latest1.6
[exec] JAVA7_HOME is /home/hudson/tools/java/latest1.7
[exec] NOTE: output encoding is US-ASCII
[exec]
[exec] Load release URL
file:/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/lucene/build/fakeRelease/...
[exec]
[exec] Test Lucene...
[exec] test basics...
[exec] get KEYS
[exec] 0.1 MB in 0.01 sec (11.0 MB/sec)
[exec] check changes HTML...
[exec] download lucene-4.5.0-src.tgz...
[exec] 27.0 MB in 0.04 sec (668.5 MB/sec)
[exec] verify md5/sha1 digests
[exec] download lucene-4.5.0.tgz...
[exec] 50.6 MB in 0.13 sec (399.3 MB/sec)
[exec] verify md5/sha1 digests
[exec] download lucene-4.5.0.zip...
[exec] 60.3 MB in 0.10 sec (607.7 MB/sec)
[exec] verify md5/sha1 digests
[exec] unpack lucene-4.5.0.tgz...
[exec] verify JAR/WAR metadata...
[exec] test demo with 1.6...
[exec] got 5671 hits for query lucene
[exec] test demo with 1.7...
[exec] got 5671 hits for query lucene
[exec] check Lucene's javadoc JAR
[exec]
[exec]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/lucene/build/fakeReleaseTmp/unpack/lucene-4.5.0/docs/core/org/apache/lucene/util/AttributeSource.html
[exec] broken details HTML: Method Detail: addAttributeImpl: closing
/code does not match opening A
[exec] broken details HTML: Method Detail: getAttribute: closing
/code does not match opening A
[exec] Traceback (most recent call last):
[exec] File
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/dev-tools/scripts/smokeTestRelease.py,
line 1450, in module
[exec] main()
[exec] File
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/dev-tools/scripts/smokeTestRelease.py,
line 1394, in main
[exec] smokeTest(baseURL, svnRevision, version, tmpDir, isSigned,
testArgs)
[exec] File
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/dev-tools/scripts/smokeTestRelease.py,
line 1431, in smokeTest
[exec] unpackAndVerify('lucene', tmpDir, artifact, svnRevision,
version, testArgs)
[exec] File
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/dev-tools/scripts/smokeTestRelease.py,
line 607, in unpackAndVerify
[exec] verifyUnpacked(project, artifact, unpackPath, svnRevision,
version, testArgs)
[exec] File
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/dev-tools/scripts/smokeTestRelease.py,
line 786, in verifyUnpacked
[exec] checkJavadocpath('%s/docs' % unpackPath)
[exec] File
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/dev-tools/scripts/smokeTestRelease.py,
line 904, in checkJavadocpath
[exec] raise RuntimeError('missing javadocs package summaries!')
[exec] RuntimeError: missing javadocs package summaries!
BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-4.x/build.xml:314:
exec returned: 1
Total time: 22 minutes 32 seconds
Build step 'Invoke Ant' marked build as failure
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
