Re: Welcome back, Wolfgang Hoschek!
Welcome back, Wolfgang.
Dawid
On Fri, Sep 27, 2013 at 7:36 AM, J. Delgado joaquin.delg...@gmail.com wrote:
Percolator for Solr? :{
On Thursday, September 26, 2013, Otis Gospodnetic wrote:
Another welcome back! Any specific area where you plan on contributing?
Otis
--
Solr ElasticSearch Support -- http://sematext.com/
Performance Monitoring -- http://sematext.com/spm
On Fri, Sep 27, 2013 at 12:58 AM, Wolfgang Hoschek
whosc...@cloudera.com wrote:
Thanks to all! Looking forward to more contributions.
Wolfgang.
On Sep 26, 2013, at 3:21 AM, Uwe Schindler wrote:
Hi,
I'm pleased to announce that after a long abstinence, Wolfgang Hoschek
rejoined the Lucene/Solr committer team. He is working now at Cloudera and
plans to help with the integration of Solr and Hadoop.
Wolfgang originally wrote the MemoryIndex, which is used by the
classical Lucene highlighter and ElasticSearch's percolator module.
Looking forward to new contributions.
Welcome back heavy committing! :-)
Uwe
P.S.: Wolfgang, as soon as you have setup your subversion access, you
should add yourself back to the committers list on the website as well.
-
Uwe Schindler
uschind...@apache.org
Apache Lucene PMC Chair / Committer
Bremen, Germany
http://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
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome back, Wolfgang Hoschek!
Welcome back Wolfgang!
Shai
On Fri, Sep 27, 2013 at 9:15 AM, Dawid Weiss
dawid.we...@cs.put.poznan.plwrote:
Welcome back, Wolfgang.
Dawid
On Fri, Sep 27, 2013 at 7:36 AM, J. Delgado joaquin.delg...@gmail.com
wrote:
Percolator for Solr? :{
On Thursday, September 26, 2013, Otis Gospodnetic wrote:
Another welcome back! Any specific area where you plan on contributing?
Otis
--
Solr ElasticSearch Support -- http://sematext.com/
Performance Monitoring -- http://sematext.com/spm
On Fri, Sep 27, 2013 at 12:58 AM, Wolfgang Hoschek
whosc...@cloudera.com wrote:
Thanks to all! Looking forward to more contributions.
Wolfgang.
On Sep 26, 2013, at 3:21 AM, Uwe Schindler wrote:
Hi,
I'm pleased to announce that after a long abstinence, Wolfgang
Hoschek
rejoined the Lucene/Solr committer team. He is working now at
Cloudera and
plans to help with the integration of Solr and Hadoop.
Wolfgang originally wrote the MemoryIndex, which is used by the
classical Lucene highlighter and ElasticSearch's percolator module.
Looking forward to new contributions.
Welcome back heavy committing! :-)
Uwe
P.S.: Wolfgang, as soon as you have setup your subversion access, you
should add yourself back to the committers list on the website as
well.
-
Uwe Schindler
uschind...@apache.org
Apache Lucene PMC Chair / Committer
Bremen, Germany
http://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
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome back, Wolfgang Hoschek!
Welcome back! On Thu, Sep 26, 2013 at 6:21 AM, Uwe Schindler uschind...@apache.org wrote: Hi, I'm pleased to announce that after a long abstinence, Wolfgang Hoschek rejoined the Lucene/Solr committer team. He is working now at Cloudera and plans to help with the integration of Solr and Hadoop. Wolfgang originally wrote the MemoryIndex, which is used by the classical Lucene highlighter and ElasticSearch's percolator module. Looking forward to new contributions. Welcome back heavy committing! :-) Uwe P.S.: Wolfgang, as soon as you have setup your subversion access, you should add yourself back to the committers list on the website as well. - Uwe Schindler uschind...@apache.org Apache Lucene PMC Chair / Committer Bremen, Germany http://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
Re: Welcome back, Wolfgang Hoschek!
Welcome back Wolfgang! On Fri, Sep 27, 2013 at 2:19 PM, Robert Muir rcm...@gmail.com wrote: Welcome back! On Thu, Sep 26, 2013 at 6:21 AM, Uwe Schindler uschind...@apache.org wrote: Hi, I'm pleased to announce that after a long abstinence, Wolfgang Hoschek rejoined the Lucene/Solr committer team. He is working now at Cloudera and plans to help with the integration of Solr and Hadoop. Wolfgang originally wrote the MemoryIndex, which is used by the classical Lucene highlighter and ElasticSearch's percolator module. Looking forward to new contributions. Welcome back heavy committing! :-) Uwe P.S.: Wolfgang, as soon as you have setup your subversion access, you should add yourself back to the committers list on the website as well. - Uwe Schindler uschind...@apache.org Apache Lucene PMC Chair / Committer Bremen, Germany http://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 -- Han Jiang Team of Search Engine and Web Mining, School of Electronic Engineering and Computer Science, Peking University, China
Re: Welcome back, Wolfgang Hoschek!
Welcome back! Alan Woodward www.flax.co.uk On 27 Sep 2013, at 05:58, Wolfgang Hoschek wrote: Thanks to all! Looking forward to more contributions. Wolfgang. On Sep 26, 2013, at 3:21 AM, Uwe Schindler wrote: Hi, I'm pleased to announce that after a long abstinence, Wolfgang Hoschek rejoined the Lucene/Solr committer team. He is working now at Cloudera and plans to help with the integration of Solr and Hadoop. Wolfgang originally wrote the MemoryIndex, which is used by the classical Lucene highlighter and ElasticSearch's percolator module. Looking forward to new contributions. Welcome back heavy committing! :-) Uwe P.S.: Wolfgang, as soon as you have setup your subversion access, you should add yourself back to the committers list on the website as well. - Uwe Schindler uschind...@apache.org Apache Lucene PMC Chair / Committer Bremen, Germany http://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] [Created] (SOLR-5281) Incorrect access core.properties in IndexSchema.java
Jun Ohtani created SOLR-5281:
Summary: Incorrect access core.properties in IndexSchema.java
Key: SOLR-5281
URL: https://issues.apache.org/jira/browse/SOLR-5281
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Priority: Minor
IndexSchema use core name for logging.
But core name always output [null] Schema.., the following.
---
3814 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema –
[null] Schema name=example
---
Maybe, property name pattern changed name to solr.core.name at SOLR-5162.
--- IndexSchema.java
...
public static final String NAME = name;
...
if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
} else {
sb.append(null);
}
--
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 back, Wolfgang Hoschek!
Welcome back :) On Friday, September 27, 2013 at 9:44 AM, Alan Woodward wrote: Welcome back! Alan Woodward www.flax.co.uk (http://www.flax.co.uk) On 27 Sep 2013, at 05:58, Wolfgang Hoschek wrote: Thanks to all! Looking forward to more contributions. Wolfgang. On Sep 26, 2013, at 3:21 AM, Uwe Schindler wrote: Hi, I'm pleased to announce that after a long abstinence, Wolfgang Hoschek rejoined the Lucene/Solr committer team. He is working now at Cloudera and plans to help with the integration of Solr and Hadoop. Wolfgang originally wrote the MemoryIndex, which is used by the classical Lucene highlighter and ElasticSearch's percolator module. Looking forward to new contributions. Welcome back heavy committing! :-) Uwe P.S.: Wolfgang, as soon as you have setup your subversion access, you should add yourself back to the committers list on the website as well. - Uwe Schindler uschind...@apache.org (mailto:uschind...@apache.org) Apache Lucene PMC Chair / Committer Bremen, Germany http://lucene.apache.org/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org (mailto:dev-unsubscr...@lucene.apache.org) For additional commands, e-mail: dev-h...@lucene.apache.org (mailto:dev-h...@lucene.apache.org) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org (mailto:dev-unsubscr...@lucene.apache.org) For additional commands, e-mail: dev-h...@lucene.apache.org (mailto:dev-h...@lucene.apache.org)
[jira] [Created] (SOLR-5282) Committed (last commit time) in dataimport status is updated even when the commit fail
Etienne CHAMPETIER created SOLR-5282: Summary: Committed (last commit time) in dataimport status is updated even when the commit fail Key: SOLR-5282 URL: https://issues.apache.org/jira/browse/SOLR-5282 Project: Solr Issue Type: Bug Affects Versions: 4.0 Environment: OpenJDK 64-Bit Server VM (19.0-b09) Rhel 5 - 2.6.18-274.el5 Reporter: Etienne CHAMPETIER Commit failed because of faulty disk with: 23:53:46 SEVERE SolrWriter Exception while solr commit. But the Committed field on the status (/solr/core/dataimport?command=status) page show: str name=Committed2013-09-25 23:53:46/str -- 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 back, Wolfgang Hoschek!
Welcome back Wolfgang! -Yonik http://lucidworks.com On Fri, Sep 27, 2013 at 12:58 AM, Wolfgang Hoschek whosc...@cloudera.com wrote: Thanks to all! Looking forward to more contributions. Wolfgang. On Sep 26, 2013, at 3:21 AM, Uwe Schindler wrote: Hi, I'm pleased to announce that after a long abstinence, Wolfgang Hoschek rejoined the Lucene/Solr committer team. He is working now at Cloudera and plans to help with the integration of Solr and Hadoop. Wolfgang originally wrote the MemoryIndex, which is used by the classical Lucene highlighter and ElasticSearch's percolator module. Looking forward to new contributions. Welcome back heavy committing! :-) Uwe P.S.: Wolfgang, as soon as you have setup your subversion access, you should add yourself back to the committers list on the website as well. - Uwe Schindler uschind...@apache.org Apache Lucene PMC Chair / Committer Bremen, Germany http://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] (SOLR-5232) SolrCloud should distribute updates via streaming rather than buffering.
[ https://issues.apache.org/jira/browse/SOLR-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5232: -- Fix Version/s: (was: 4.5) 4.6 SolrCloud should distribute updates via streaming rather than buffering. Key: SOLR-5232 URL: https://issues.apache.org/jira/browse/SOLR-5232 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.6 Attachments: SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch The current approach was never the best for SolrCloud - it was designed for a pre SolrCloud Solr - it also uses too many connections and threads - nailing that down is likely wasted effort when we should really move away from explicitly buffering docs and sending small batches per thread as we have been doing. -- 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-5280) Json response doesn't take long field type well
[ https://issues.apache.org/jira/browse/SOLR-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13779893#comment-13779893 ] Erick Erickson commented on SOLR-5280: -- After reproducing this in Chrome, I tried to create a quick junit test and couldn't get it to fail there. So I tried Safari and it does NOT fail there, so it appears to be a browser problem. Not sure there's anything we can do about it, but don't have time to pursue it now. Checked the index and both the admin/schema browser and terms component show the correct value in the index, which I could infer from the Safari display too. Json response doesn't take long field type well --- Key: SOLR-5280 URL: https://issues.apache.org/jira/browse/SOLR-5280 Project: Solr Issue Type: Bug Components: Response Writers Affects Versions: 4.2 Reporter: Liu Xiang In my index, one field is defined as solr.LongField. After index, use solr webUI to fetch the doc. by default, xml response is as following, which is correct: long20584018100338/long long20584018102563/long Then Change wt to json, response is: [ 20584018100350, 20584018102560 ] -- 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-5283) Admin UI issues in IE7
Erik Hatcher created SOLR-5283:
--
Summary: Admin UI issues in IE7
Key: SOLR-5283
URL: https://issues.apache.org/jira/browse/SOLR-5283
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.4
Environment: IE Version 7.0.5730.11 64-bit edition.
Reporter: Erik Hatcher
Priority: Minor
A customer of ours reported:
{code}
IE Version 7.0.5730.11 64-bit edition.
Result:
Left nav area displays;
Main area: spinning loading icon displaying the word Loading ...
Script errors on page:
Line: 8
Char: 3
Error: 'CSSStyleDeclaration' is undefined
Code: 0
URL: http://server:/solr/js/lib/d3.js
Line: 17
Char: 5
Error: Unexpected call to method or property access.
Code: 0
URL : http://server:/solr/js/require.js
{code}
I've tried replicating this in a Windows virtual machine, but only have IE10
and have not seen this issue.
--
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-5232) SolrCloud should distribute updates via streaming rather than buffering.
[ https://issues.apache.org/jira/browse/SOLR-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5232: -- Attachment: SOLR-5232.patch This patch takes care of the nocommits in the previous patch. I'll commit shortly. SolrCloud should distribute updates via streaming rather than buffering. Key: SOLR-5232 URL: https://issues.apache.org/jira/browse/SOLR-5232 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.6 Attachments: SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch The current approach was never the best for SolrCloud - it was designed for a pre SolrCloud Solr - it also uses too many connections and threads - nailing that down is likely wasted effort when we should really move away from explicitly buffering docs and sending small batches per thread as we have been doing. -- 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 #459: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/459/ No tests ran. Build Log: [...truncated 11964 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5281) Incorrect access core.properties in IndexSchema.java
[
https://issues.apache.org/jira/browse/SOLR-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13779996#comment-13779996
]
Steve Rowe commented on SOLR-5281:
--
I can confirm that this is a regression. I ran the example in both 4.4 and 4.5:
4.4:
{noformat}
1995 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema –
[collection1] Schema name=example
{noformat}
4.5:
{noformat}
1939 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema –
[null] Schema name=example
{noformat}
Incorrect access core.properties in IndexSchema.java
Key: SOLR-5281
URL: https://issues.apache.org/jira/browse/SOLR-5281
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Priority: Minor
IndexSchema use core name for logging.
But core name always output [null] Schema.., the following.
---
3814 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– [null] Schema name=example
---
Maybe, property name pattern changed name to solr.core.name at SOLR-5162.
--- IndexSchema.java
...
public static final String NAME = name;
...
if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
} else {
sb.append(null);
}
--
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-5232) SolrCloud should distribute updates via streaming rather than buffering.
[ https://issues.apache.org/jira/browse/SOLR-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780008#comment-13780008 ] Shalin Shekhar Mangar commented on SOLR-5232: - fyi, ShardSplitTest is *much* slower with this patch e.g. ant -Dtests.seed=8FEFBE4A48F65343 -Dtestcase=ShardSplitTest clean test-core Without patch: Total time: 1 minute 48 seconds With patch: Total time: 4 minutes 25 seconds SolrCloud should distribute updates via streaming rather than buffering. Key: SOLR-5232 URL: https://issues.apache.org/jira/browse/SOLR-5232 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.6 Attachments: SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch The current approach was never the best for SolrCloud - it was designed for a pre SolrCloud Solr - it also uses too many connections and threads - nailing that down is likely wasted effort when we should really move away from explicitly buffering docs and sending small batches per thread as we have been doing. -- 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-5281) Incorrect access core.properties in IndexSchema.java
[
https://issues.apache.org/jira/browse/SOLR-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780012#comment-13780012
]
Steve Rowe commented on SOLR-5281:
--
Debugging 4.5, at the point in {{IndexSchema.java}} that Jun gave in the
description, loader.coreProperties has:
{noformat}
{
solr.core.config=solrconfig.xml,
absoluteInstDir=/Users/sarowe/svn/lucene/dev/branches/lucene_solr_4_5/solr/example/solr/collection1/,
solr.core.schema=schema.xml,
solr.core.transient=false,
solr.core.instanceDir=/Users/sarowe/svn/lucene/dev/branches/lucene_solr_4_5/solr/example/solr/collection1,
solr.core.dataDir=data/,
solr.core.loadOnStartup=true,
solr.core.name=collection1
}
{noformat}
So Jun's analysis appears to be correct: coreProperties no longer contains
name, but rather solr.core.name.
Incorrect access core.properties in IndexSchema.java
Key: SOLR-5281
URL: https://issues.apache.org/jira/browse/SOLR-5281
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Priority: Minor
IndexSchema use core name for logging.
But core name always output [null] Schema.., the following.
---
3814 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– [null] Schema name=example
---
Maybe, property name pattern changed name to solr.core.name at SOLR-5162.
--- IndexSchema.java
...
public static final String NAME = name;
...
if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
} else {
sb.append(null);
}
--
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-5162) Implicit core properties are no longer available
[ https://issues.apache.org/jira/browse/SOLR-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780014#comment-13780014 ] Steve Rowe commented on SOLR-5162: -- Was it intentional that the name property disappear? See SOLR-5281 Implicit core properties are no longer available Key: SOLR-5162 URL: https://issues.apache.org/jira/browse/SOLR-5162 Project: Solr Issue Type: Bug Affects Versions: 4.5 Reporter: Alan Woodward Assignee: Alan Woodward Priority: Minor Fix For: 4.5 Attachments: SOLR-5162.patch, SOLR-5162.patch As noted by ~elyograg on IRC, implicit property substitution doesn't work any more in 4.5. -- 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-5232) SolrCloud should distribute updates via streaming rather than buffering.
[ https://issues.apache.org/jira/browse/SOLR-5232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780026#comment-13780026 ] Mark Miller commented on SOLR-5232: --- Hmm, lost in the noise for me because 205.66ms (that test's runtime for me) doesn't increase the total run time with tests.jvms=8. I'll dig into it. SolrCloud should distribute updates via streaming rather than buffering. Key: SOLR-5232 URL: https://issues.apache.org/jira/browse/SOLR-5232 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.6 Attachments: SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch, SOLR-5232.patch The current approach was never the best for SolrCloud - it was designed for a pre SolrCloud Solr - it also uses too many connections and threads - nailing that down is likely wasted effort when we should really move away from explicitly buffering docs and sending small batches per thread as we have been doing. -- 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-5162) Implicit core properties are no longer available
[
https://issues.apache.org/jira/browse/SOLR-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780034#comment-13780034
]
Steve Rowe commented on SOLR-5162:
--
bq. Was it intentional that the name property disappear? See SOLR-5281
Answering my own question: Yes:
{code:java|title=CoreDescriptor.java line #213}
/**
* Create the properties object used by resource loaders, etc, for property
* substitution. The default solr properties are prefixed with 'solr.core.',
so,
* e.g., 'name' becomes 'solr.core.name'
*/
protected void buildSubstitutableProperties() {
for (String propName : coreProperties.stringPropertyNames()) {
String propValue = coreProperties.getProperty(propName);
if (!isUserDefinedProperty(propName))
propName = solr.core. + propName;
substitutableProperties.setProperty(propName, propValue);
}
}
{code}
Implicit core properties are no longer available
Key: SOLR-5162
URL: https://issues.apache.org/jira/browse/SOLR-5162
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
Fix For: 4.5
Attachments: SOLR-5162.patch, SOLR-5162.patch
As noted by ~elyograg on IRC, implicit property substitution doesn't work any
more in 4.5.
--
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-5281) Incorrect access core.properties in IndexSchema.java
[
https://issues.apache.org/jira/browse/SOLR-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-5281:
-
Attachment: SOLR-5281.patch
Trivial patch against trunk. I applied this to the lucene_solr_4_5 branch and
the core name shows up in the log message instead of null. Committing shortly.
Incorrect access core.properties in IndexSchema.java
Key: SOLR-5281
URL: https://issues.apache.org/jira/browse/SOLR-5281
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Priority: Minor
Attachments: SOLR-5281.patch
IndexSchema use core name for logging.
But core name always output [null] Schema.., the following.
---
3814 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– [null] Schema name=example
---
Maybe, property name pattern changed name to solr.core.name at SOLR-5162.
--- IndexSchema.java
...
public static final String NAME = name;
...
if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
} else {
sb.append(null);
}
--
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-5281) Incorrect access core.properties in IndexSchema.java
[
https://issues.apache.org/jira/browse/SOLR-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780052#comment-13780052
]
Shawn Heisey commented on SOLR-5281:
This is the problem that I had noticed and was looking into further when I
stumbled onto SOLR-5279.
Incorrect access core.properties in IndexSchema.java
Key: SOLR-5281
URL: https://issues.apache.org/jira/browse/SOLR-5281
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Priority: Minor
Attachments: SOLR-5281.patch
IndexSchema use core name for logging.
But core name always output [null] Schema.., the following.
---
3814 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– [null] Schema name=example
---
Maybe, property name pattern changed name to solr.core.name at SOLR-5162.
--- IndexSchema.java
...
public static final String NAME = name;
...
if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
} else {
sb.append(null);
}
--
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-5281) Incorrect access core.properties in IndexSchema.java
[
https://issues.apache.org/jira/browse/SOLR-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780055#comment-13780055
]
ASF subversion and git services commented on SOLR-5281:
---
Commit 1526972 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1526972 ]
SOLR-5281: IndexSchema log message was printing '[null]' instead of '[core
name]'
Incorrect access core.properties in IndexSchema.java
Key: SOLR-5281
URL: https://issues.apache.org/jira/browse/SOLR-5281
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Priority: Minor
Attachments: SOLR-5281.patch
IndexSchema use core name for logging.
But core name always output [null] Schema.., the following.
---
3814 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– [null] Schema name=example
---
Maybe, property name pattern changed name to solr.core.name at SOLR-5162.
--- IndexSchema.java
...
public static final String NAME = name;
...
if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
} else {
sb.append(null);
}
--
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-5281) Incorrect access core.properties in IndexSchema.java
[
https://issues.apache.org/jira/browse/SOLR-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780059#comment-13780059
]
ASF subversion and git services commented on SOLR-5281:
---
Commit 1526973 from [~steve_rowe] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1526973 ]
SOLR-5281: IndexSchema log message was printing '[null]' instead of '[core
name]' (merge trunk r1526972)
Incorrect access core.properties in IndexSchema.java
Key: SOLR-5281
URL: https://issues.apache.org/jira/browse/SOLR-5281
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Priority: Minor
Attachments: SOLR-5281.patch
IndexSchema use core name for logging.
But core name always output [null] Schema.., the following.
---
3814 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– [null] Schema name=example
---
Maybe, property name pattern changed name to solr.core.name at SOLR-5162.
--- IndexSchema.java
...
public static final String NAME = name;
...
if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
} else {
sb.append(null);
}
--
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] [Resolved] (SOLR-5281) Incorrect access core.properties in IndexSchema.java
[
https://issues.apache.org/jira/browse/SOLR-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe resolved SOLR-5281.
--
Resolution: Fixed
Fix Version/s: 4.6
5.0
Assignee: Steve Rowe
Committed to trunk and branch_4x.
Thanks Jun!
Incorrect access core.properties in IndexSchema.java
Key: SOLR-5281
URL: https://issues.apache.org/jira/browse/SOLR-5281
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Assignee: Steve Rowe
Priority: Minor
Fix For: 5.0, 4.6
Attachments: SOLR-5281.patch
IndexSchema use core name for logging.
But core name always output [null] Schema.., the following.
---
3814 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– [null] Schema name=example
---
Maybe, property name pattern changed name to solr.core.name at SOLR-5162.
--- IndexSchema.java
...
public static final String NAME = name;
...
if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
} else {
sb.append(null);
}
--
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-5281) Incorrect access core.properties in IndexSchema.java
[
https://issues.apache.org/jira/browse/SOLR-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780067#comment-13780067
]
Steve Rowe commented on SOLR-5281:
--
FYI, I looked and didn't find any other references to the implicit core name
property accessed via {{SolrResourceLoader}}'s {{coreProperties}} or
{{getCoreProperties()}}.
Incorrect access core.properties in IndexSchema.java
Key: SOLR-5281
URL: https://issues.apache.org/jira/browse/SOLR-5281
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Assignee: Steve Rowe
Priority: Minor
Fix For: 5.0, 4.6
Attachments: SOLR-5281.patch
IndexSchema use core name for logging.
But core name always output [null] Schema.., the following.
---
3814 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– [null] Schema name=example
---
Maybe, property name pattern changed name to solr.core.name at SOLR-5162.
--- IndexSchema.java
...
public static final String NAME = name;
...
if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
} else {
sb.append(null);
}
--
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-5027) Result Set Collapse and Expand Plugins
[
https://issues.apache.org/jira/browse/SOLR-5027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780136#comment-13780136
]
Joel Bernstein commented on SOLR-5027:
--
Simon,
Your idea sounds good and should be no problem to implement. When I finish up
the work on the Expand component I'll work on getting this in.
Result Set Collapse and Expand Plugins
--
Key: SOLR-5027
URL: https://issues.apache.org/jira/browse/SOLR-5027
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 5.0
Reporter: Joel Bernstein
Priority: Minor
Attachments: SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch,
SOLR-5027.patch
This ticket introduces two new Solr plugins, the *CollapsingQParserPlugin*
and the *ExpandComponent*.
The *CollapsingQParserPlugin* is a PostFilter that performs field collapsing.
Collapse based on the highest scoring document:
{code}
fq=(!collapse field=field_name}
{code}
Collapse based on the min value of a numeric field:
{code}
fq={!collapse field=field_name min=field_name}
{code}
Collapse based on the max value of a numeric field:
{code}
fq={!collapse field=field_name max=field_name}
{code}
Collapse with a null policy:
{code}
fq={!collapse field=field_name nullPolicy=null_policy}
{code}
There are three null policies:
ignore : removes docs with a null value in the collapse field (default).
expand : treats each doc with a null value in the collapse field as a
separate group.
collapse : collapses all docs with a null value into a single group using
either highest score, or min/max.
The *ExpandComponent* is a search component that takes the collapsed docList
and expands the groups for a single page based on parameters provided.
Initial syntax:
expand=true - Turns on the expand component.
expand.field=field - Expands results for this field
expand.limit=5 - Limits the documents for each expanded group.
expand.sort=sort spec - The sort spec for the expanded documents. Default
is score.
expand.rows=500 - The max number of expanded results to bring back. Default
is 500.
*Note:* Recent patches don't contain the expand component. The July 16 patch
does. This will be brought back in when the collapse is finished, or possible
moved to it's own ticket.
--
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-5279) Implicit properties don't seem to exist on core RELOAD
[ https://issues.apache.org/jira/browse/SOLR-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780147#comment-13780147 ] Steve Rowe commented on SOLR-5279: -- The test in the patch fails for me on lucene_solr_4_5 (after I first apply Hoss's test expansion patch to this branch: http://svn.apache.org/r1525733). I'm digging. Implicit properties don't seem to exist on core RELOAD -- Key: SOLR-5279 URL: https://issues.apache.org/jira/browse/SOLR-5279 Project: Solr Issue Type: Bug Affects Versions: 4.5 Environment: Solr 4.5.0 RC4 Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux java version 1.7.0_21 Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode) Reporter: Shawn Heisey Fix For: 4.5, 5.0, 4.6 Attachments: SOLR-5279-test.patch The implicit properties (specifically solr.core.name) work fine for Solr startup, but on core RELOAD, they no longer exist, so configurations that use them result in the core not initializing. Problem discovered on 4.5.0 RC4, works fine in 4.4.0. -- 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-5279) Implicit properties don't seem to exist on core RELOAD
[
https://issues.apache.org/jira/browse/SOLR-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-5279:
-
Attachment: SOLR-5279.patch
Patch, test passes under trunk and lucene_solr_4_5 branch; includes
{{SOLR-5279-test.patch}}.
The problem appears to be that when [~romseygeek] fixed implicit core
properties in {{CoreDescriptor.java}} under SOLR-5162, he forgot to include
copying over the new {{substitutableProperties}} in the
copy-constructor-with-new-core-name: {{CoreDescriptor(String,CoreDescriptor)}}.
I added this there, and that allowed the new test to pass.
Committing shortly.
Implicit properties don't seem to exist on core RELOAD
--
Key: SOLR-5279
URL: https://issues.apache.org/jira/browse/SOLR-5279
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Environment: Solr 4.5.0 RC4
Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24
03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
java version 1.7.0_21
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
Reporter: Shawn Heisey
Fix For: 4.5, 5.0, 4.6
Attachments: SOLR-5279.patch, SOLR-5279-test.patch
The implicit properties (specifically solr.core.name) work fine for Solr
startup, but on core RELOAD, they no longer exist, so configurations that use
them result in the core not initializing.
Problem discovered on 4.5.0 RC4, works fine in 4.4.0.
--
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: [VOTE] Release Lucene/Solr 4.5.0 RC4
I attached a fix to the issue Shawn created for the missing implicit
Solr-core-properties-on-RELOAD issue: SOLR-5279
IMHO, this regression should be fixed in 4.5.
Adrien, I tried to raise you on IRC but didn't get a response - is it okay with
you to do a respin? I'll commit to trunk and branch_4x with the CHANGES.txt
entry under 4.6 until you say it's okay.
Steve
On Sep 26, 2013, at 7:36 PM, Shawn Heisey s...@elyograg.org wrote:
On 9/26/2013 1:26 PM, Adrien Grand wrote:
Here is a new release candidate for which LUCENE-5218, LUCENE-5245 and
LUCENE-5233 have been backported. Please vote to release the following
artifacts:
http://people.apache.org/~jpountz/staging_area/lucene-solr-4.5.0-RC4-rev1526586/
This vote is open until Tuesday.
Smoke tester was happy on my end, so here is my +1.
I just ran into a problem with the release candidate, let me know if you
think it's a release-stopper. I wasn't looking for anything wrong, I was
just putting the release candidate on my dev server. I noticed a cosmetic
issue, and while I was trying to track down that, I stumbled across something
bigger. This is not running with zookeeper.
Pieces of my solrconfig.xml file are shared (via symlinks and xinclude
directives) with many different cores. In the file for the indexConfig
section, I have this:
infoStream file=INFOSTREAM-${solr.core.name}.txtfalse/infoStream
During startup, this doesn't cause any problem at all. On core reload,
however, I get a big exception and it can't initialize the core. The cause:
Caused by: org.apache.solr.common.SolrException: No system property or
default value specified for solr.core.name
value:INFOSTREAM-${solr.core.name}.txt
at
org.apache.solr.util.PropertiesUtil.substituteProperty(PropertiesUtil.java:66)
at org.apache.solr.util.DOMUtil.substituteProperties(DOMUtil.java:298)
at org.apache.solr.util.DOMUtil.substituteProperties(DOMUtil.java:300)
at org.apache.solr.util.DOMUtil.substituteProperties(DOMUtil.java:300)
at org.apache.solr.core.Config.init(Config.java:141)
at org.apache.solr.core.Config.init(Config.java:86)
at org.apache.solr.core.SolrConfig.init(SolrConfig.java:129)
at org.apache.solr.core.SolrCore.reload(SolrCore.java:403)
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:681)
... 31 more
I've run into problems with the implicit properties before, but that was at
Solr startup. This is the first time in quite a while that I've tried a
RELOAD on my dev server, so I don't know how long this problem has existed.
At one point, I had to use ${name} instead of ${solr.core.name} in branch_4x
versions, but that got fixed. If I need to use a different property going
forward, I'm OK with that. I know that Hoss was doing something recently
with implicit properties in the Reference Guide, but I haven't looked at it
closely.
Thanks,
Shawn
-
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] (SOLR-5279) Implicit properties don't seem to exist on core RELOAD
[ https://issues.apache.org/jira/browse/SOLR-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780295#comment-13780295 ] ASF subversion and git services commented on SOLR-5279: --- Commit 1527042 from [~steve_rowe] in branch 'dev/trunk' [ https://svn.apache.org/r1527042 ] SOLR-5279: Implicit properties don't seem to exist on core RELOAD Implicit properties don't seem to exist on core RELOAD -- Key: SOLR-5279 URL: https://issues.apache.org/jira/browse/SOLR-5279 Project: Solr Issue Type: Bug Affects Versions: 4.5 Environment: Solr 4.5.0 RC4 Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux java version 1.7.0_21 Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode) Reporter: Shawn Heisey Fix For: 4.5, 5.0, 4.6 Attachments: SOLR-5279.patch, SOLR-5279-test.patch The implicit properties (specifically solr.core.name) work fine for Solr startup, but on core RELOAD, they no longer exist, so configurations that use them result in the core not initializing. Problem discovered on 4.5.0 RC4, works fine in 4.4.0. -- 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-5279) Implicit properties don't seem to exist on core RELOAD
[ https://issues.apache.org/jira/browse/SOLR-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780297#comment-13780297 ] ASF subversion and git services commented on SOLR-5279: --- Commit 1527043 from [~steve_rowe] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1527043 ] SOLR-5279: Implicit properties don't seem to exist on core RELOAD (merged trunk r1527042) Implicit properties don't seem to exist on core RELOAD -- Key: SOLR-5279 URL: https://issues.apache.org/jira/browse/SOLR-5279 Project: Solr Issue Type: Bug Affects Versions: 4.5 Environment: Solr 4.5.0 RC4 Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux java version 1.7.0_21 Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode) Reporter: Shawn Heisey Fix For: 4.5, 5.0, 4.6 Attachments: SOLR-5279.patch, SOLR-5279-test.patch The implicit properties (specifically solr.core.name) work fine for Solr startup, but on core RELOAD, they no longer exist, so configurations that use them result in the core not initializing. Problem discovered on 4.5.0 RC4, works fine in 4.4.0. -- 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 #982: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/982/ No tests ran. Build Log: [...truncated 11778 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 (32bit/jdk1.7.0_40) - Build # 7639 - Failure!
This one reproduces; is anyone looking? Mike McCandless http://blog.mikemccandless.com On Thu, Sep 26, 2013 at 4:27 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/7639/ Java: 32bit/jdk1.7.0_40 -client -XX:+UseSerialGC 1 tests failed. REGRESSION: org.apache.lucene.index.TestNumericDocValuesUpdates.testChangeCodec Error Message: expected:12 but was:17 Stack Trace: java.lang.AssertionError: expected:12 but was:17 at __randomizedtesting.SeedInfo.seed([A099DBB8181A4538:C1FFAD77A92F9D1E]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.lucene.index.TestNumericDocValuesUpdates.testChangeCodec(TestNumericDocValuesUpdates.java:1074) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:724) Build Log: [...truncated 1511 lines...] [junit4]
Re: NumericRangeTermsEnum
Normally you'd create a NumericRangeFilter/Query and just use that? Under the hood, Lucene uses that protected API to visit all matching terms... Mike McCandless http://blog.mikemccandless.com On Thu, Sep 26, 2013 at 9:59 AM, Chet Vora chetv...@gmail.com wrote: Hi all I was trying to use the above enum to do some range search on dates... this enum is returned by NumericRangeQuery.getTermsEnum() but I realized that this is a protected method of the class and since this is a final class, I can't see how I can use it. Maybe I'm missing something ? Would appreciate any pointers. Thanks CV - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE RC0 Release apache-solr-ref-guide-4.5.pdf
I have just 3 chars to contribute: WOW
Otis
On Thu, Sep 26, 2013 at 8:29 AM, Steve Rowe sar...@gmail.com wrote:
Except for #1/#34 - internal links to beginning-of-page sections point one
page earlier than they should - and #8/#41 - missing Thai and Polish chars -
which I don't know how to fix, I'll try to address the other items on this
(um, very long) list of mostly minor stuff I found:
0. All examples in the exported PDF have an extra blank line at the top. I
was able to eliminate these from this page
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=32604227
(What is an analyzer?) by eliminating the newline between the initial {code
…} line and the first line of the examples. This doesn't have any apparent
effect on the layout of the page on the wiki, but the PDF export of that page
no longer has the extra blank lines. Any objections to switching all {code}
examples in the guide like this?
1. Pg 2: The section links from the TOC all take you to the previous page,
rather than to the top of the page where the section starts. (Same behavior
on OS X Preview, and under Windows, on Firefox's built-in PDF viewer and on
Adobe Reader.) This looks like a general problem - see e.g. #34.
2. Pg 68: Stray asterisks in the analyzer tags in the fieldType example
under Analysis Phases, apparently to make the surrounded text bold (which
also didn't happen).
3. Pg 69: The solr.KeywordTokenizerFactory example is missing one quotation
mark from each of the left and right hand sides.
4. Pg 70: Under solr.TokenizerFactory, there is a bogus StandardTokenizer
link in the sentence Theere aren't any filters that use StandardTokenizer's
types - the link is to the non-existent StandardTokenizer page on the Solr
wiki. (It might be useful to systematically link stuff like this to the
corresponding Lucene or Solr javadocs, but this should probably be templated
or scripted, so that the version-specific links are handled properly.)
5. Pg 71: Under Standard Tokenizer, the email addresses recognition claim
is false, and Internet domain name recognition isn't validation per se, e.g.
google.supercomputername will be tokenized as a single token along with
google.com. The Out example output needs fixup accordingly. I see that
the Classic Tokenizer section on pg 72 has the verbatim email/domain text;
for ClassicTokenizer, the email claim is true, but it has the same issue with
internet domain names as StandardTokenizer.
6. Pg 74: The NGram Tokenizer example output should be (bicy, bicyc,
icyc, icycl, cycl, cycle, ycle) instead of all of the 4grams before
the 5grams (I think this class's behavior was changed in 4.4 by LUCENE-5042).
7. Pg 75: The ICU tokenizer rulefiles argument is missing.
8. Pg 75: The ICU Tokenizer's In input and Out output are completely
missing the Thai text that's visible on the wiki.
9. Pg 75: Missing spaces in the Regular Expression Pattern Tokenizer's
group attribute description, at the boundaries between the first two
sentences: token(s).The and tokens.Non-negative.
10. Pg 72, 76, 77, etc.: Many analysis components' factory class names should
be styled with a fixed-width font.
11. Pg 77: UAX29 URL Email Tokenizer recognizes not only .com Internet domain
names, but also domain names including any other valid top-level domain
(i.e., unlike StandardTokenizer and ClassicTokenizer, domain names are
validated against the white list drawn from the IANA Root Zone database
http://www.internic.net/zones/root.zone as of the last time ant gen-tld
was performed and the tokenizer was generated.)
12. Pg 77: UAX29 tokenizer: file::// should be file://
13. Pg 77: UAX29 tokenizer's URL and EMAIL type names are missing angle
brackets.
14. Pg 77: UAX29 tokenizer's maxTokenLength attribute name should be styled
with a fixed-width font.
15. Pg 78: In the example demonstrating how arguments can be given to
filter elements via attributes, there is a stray asterisk, apparently
intended to bold the surrounding text, which also didn't work: *min=2
max=7/
16. Pg 79: The ASCII Folding Filter's Out output should have the accent
stripped from the á - a and the ASCII character value adjusted - (ASCII
character 97)
17. Pg 81: The Edge N-gram Filter's 4-6 gram size example Out should be
(four, scor, score, twen, twent, twenty) - some of these are
missing.
18. Pg 83: The ICU Normalizer 2 Filter example should include the name and
mode attributes in the filter element.
19. Pg 87: Stray asterisks in both of the N-Gram Filter examples:
*minGramSize=...
20. Pg 87: The N-Gram Filter 3-5 gram size example Out output should be
(fou, four, our, sco, scor, score, cor, core, ore) - rather
than ordering by gram size, output is now ordered first by position and then
by gram size.
21. Pg 88: Stray asterisk in the first occurrence only example of the Pattern
Replace Filter: *replace=first.
Re: [VOTE] Release Lucene/Solr 4.5.0 RC4
Hi Steve, On Fri, Sep 27, 2013 at 9:30 PM, Steve Rowe sar...@gmail.com wrote: I attached a fix to the issue Shawn created for the missing implicit Solr-core-properties-on-RELOAD issue: SOLR-5279 IMHO, this regression should be fixed in 4.5. Adrien, I tried to raise you on IRC but didn't get a response - is it okay with you to do a respin? I'll commit to trunk and branch_4x with the CHANGES.txt entry under 4.6 until you say it's okay. Indeed, I was not keeping an eye on IRC. I will respin tomorrow morning european time. Thanks for fixing this issue! -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5284) Solr Admin shows error message in Links GUI, even though no error
Eric Pugh created SOLR-5284: --- Summary: Solr Admin shows error message in Links GUI, even though no error Key: SOLR-5284 URL: https://issues.apache.org/jira/browse/SOLR-5284 Project: Solr Issue Type: Bug Affects Versions: 4.4 Reporter: Eric Pugh Priority: Minor Using the Links browser, when I browse to /solr/ the default admin interface shows the SolrCore error message SolrCore Initialization failure, even though there was no error! The CSS I think isn't properly hiding that standard div. -- 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-5281) Incorrect access core.properties in IndexSchema.java
[
https://issues.apache.org/jira/browse/SOLR-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780365#comment-13780365
]
ASF subversion and git services commented on SOLR-5281:
---
Commit 1527074 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1527074 ]
SOLR-5281: Move CHANGES.txt entry from 4.6 to 4.5
Incorrect access core.properties in IndexSchema.java
Key: SOLR-5281
URL: https://issues.apache.org/jira/browse/SOLR-5281
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Assignee: Steve Rowe
Priority: Minor
Fix For: 5.0, 4.6
Attachments: SOLR-5281.patch
IndexSchema use core name for logging.
But core name always output [null] Schema.., the following.
---
3814 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– [null] Schema name=example
---
Maybe, property name pattern changed name to solr.core.name at SOLR-5162.
--- IndexSchema.java
...
public static final String NAME = name;
...
if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
} else {
sb.append(null);
}
--
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-5281) Incorrect access core.properties in IndexSchema.java
[
https://issues.apache.org/jira/browse/SOLR-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780366#comment-13780366
]
ASF subversion and git services commented on SOLR-5281:
---
Commit 1527075 from [~steve_rowe] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1527075 ]
SOLR-5281: Move CHANGES.txt entry from 4.6 to 4.5 (merged trunk r1527074)
Incorrect access core.properties in IndexSchema.java
Key: SOLR-5281
URL: https://issues.apache.org/jira/browse/SOLR-5281
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Assignee: Steve Rowe
Priority: Minor
Fix For: 5.0, 4.6
Attachments: SOLR-5281.patch
IndexSchema use core name for logging.
But core name always output [null] Schema.., the following.
---
3814 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– [null] Schema name=example
---
Maybe, property name pattern changed name to solr.core.name at SOLR-5162.
--- IndexSchema.java
...
public static final String NAME = name;
...
if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
} else {
sb.append(null);
}
--
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-5279) Implicit properties don't seem to exist on core RELOAD
[ https://issues.apache.org/jira/browse/SOLR-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780370#comment-13780370 ] ASF subversion and git services commented on SOLR-5279: --- Commit 1527076 from [~steve_rowe] in branch 'dev/trunk' [ https://svn.apache.org/r1527076 ] SOLR-5279: Move CHANGES.txt entry from 4.6 to 4.5 Implicit properties don't seem to exist on core RELOAD -- Key: SOLR-5279 URL: https://issues.apache.org/jira/browse/SOLR-5279 Project: Solr Issue Type: Bug Affects Versions: 4.5 Environment: Solr 4.5.0 RC4 Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux java version 1.7.0_21 Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode) Reporter: Shawn Heisey Fix For: 4.5, 5.0, 4.6 Attachments: SOLR-5279.patch, SOLR-5279-test.patch The implicit properties (specifically solr.core.name) work fine for Solr startup, but on core RELOAD, they no longer exist, so configurations that use them result in the core not initializing. Problem discovered on 4.5.0 RC4, works fine in 4.4.0. -- 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-5279) Implicit properties don't seem to exist on core RELOAD
[ https://issues.apache.org/jira/browse/SOLR-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780371#comment-13780371 ] ASF subversion and git services commented on SOLR-5279: --- Commit 1527077 from [~steve_rowe] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1527077 ] SOLR-5279: Move CHANGES.txt entry from 4.6 to 4.5 (merged trunk r1527076) Implicit properties don't seem to exist on core RELOAD -- Key: SOLR-5279 URL: https://issues.apache.org/jira/browse/SOLR-5279 Project: Solr Issue Type: Bug Affects Versions: 4.5 Environment: Solr 4.5.0 RC4 Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux java version 1.7.0_21 Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode) Reporter: Shawn Heisey Fix For: 4.5, 5.0, 4.6 Attachments: SOLR-5279.patch, SOLR-5279-test.patch The implicit properties (specifically solr.core.name) work fine for Solr startup, but on core RELOAD, they no longer exist, so configurations that use them result in the core not initializing. Problem discovered on 4.5.0 RC4, works fine in 4.4.0. -- 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-5284) Solr Admin shows error message in Links GUI, even though no error
[ https://issues.apache.org/jira/browse/SOLR-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh updated SOLR-5284: Attachment: solr-error.png Screenshot of the CSS error. Links is a critical browser ;-) Solr Admin shows error message in Links GUI, even though no error - Key: SOLR-5284 URL: https://issues.apache.org/jira/browse/SOLR-5284 Project: Solr Issue Type: Bug Affects Versions: 4.4 Reporter: Eric Pugh Priority: Minor Attachments: solr-error.png Using the Links browser, when I browse to /solr/ the default admin interface shows the SolrCore error message SolrCore Initialization failure, even though there was no error! The CSS I think isn't properly hiding that standard div. -- 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-5281) Incorrect access core.properties in IndexSchema.java
[
https://issues.apache.org/jira/browse/SOLR-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780409#comment-13780409
]
ASF subversion and git services commented on SOLR-5281:
---
Commit 1527080 from [~steve_rowe] in branch 'dev/branches/lucene_solr_4_5'
[ https://svn.apache.org/r1527080 ]
SOLR-5281: IndexSchema log message was printing '[null]' instead of '[core
name]' (merge trunk r1526972 and 1527074)
Incorrect access core.properties in IndexSchema.java
Key: SOLR-5281
URL: https://issues.apache.org/jira/browse/SOLR-5281
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Assignee: Steve Rowe
Priority: Minor
Fix For: 5.0, 4.6
Attachments: SOLR-5281.patch
IndexSchema use core name for logging.
But core name always output [null] Schema.., the following.
---
3814 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– [null] Schema name=example
---
Maybe, property name pattern changed name to solr.core.name at SOLR-5162.
--- IndexSchema.java
...
public static final String NAME = name;
...
if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
} else {
sb.append(null);
}
--
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-5279) Implicit properties don't seem to exist on core RELOAD
[ https://issues.apache.org/jira/browse/SOLR-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780423#comment-13780423 ] ASF subversion and git services commented on SOLR-5279: --- Commit 1527085 from [~steve_rowe] in branch 'dev/branches/lucene_solr_4_5' [ https://svn.apache.org/r1527085 ] SOLR-5279: Implicit properties don't seem to exist on core RELOAD (merged trunk r1527042 and r1527076) Implicit properties don't seem to exist on core RELOAD -- Key: SOLR-5279 URL: https://issues.apache.org/jira/browse/SOLR-5279 Project: Solr Issue Type: Bug Affects Versions: 4.5 Environment: Solr 4.5.0 RC4 Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux java version 1.7.0_21 Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode) Reporter: Shawn Heisey Fix For: 4.5, 5.0, 4.6 Attachments: SOLR-5279.patch, SOLR-5279-test.patch The implicit properties (specifically solr.core.name) work fine for Solr startup, but on core RELOAD, they no longer exist, so configurations that use them result in the core not initializing. Problem discovered on 4.5.0 RC4, works fine in 4.4.0. -- 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] [Resolved] (SOLR-5279) Implicit properties don't seem to exist on core RELOAD
[ https://issues.apache.org/jira/browse/SOLR-5279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe resolved SOLR-5279. -- Resolution: Fixed Committed to trunk, branch_4x and lucene_solr_4_5 branch. Thanks Shawn! Implicit properties don't seem to exist on core RELOAD -- Key: SOLR-5279 URL: https://issues.apache.org/jira/browse/SOLR-5279 Project: Solr Issue Type: Bug Affects Versions: 4.5 Environment: Solr 4.5.0 RC4 Linux bigindy5 2.6.32-358.6.1.el6.centos.plus.x86_64 #1 SMP Wed Apr 24 03:21:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux java version 1.7.0_21 Java(TM) SE Runtime Environment (build 1.7.0_21-b11) Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode) Reporter: Shawn Heisey Fix For: 4.5, 5.0, 4.6 Attachments: SOLR-5279.patch, SOLR-5279-test.patch The implicit properties (specifically solr.core.name) work fine for Solr startup, but on core RELOAD, they no longer exist, so configurations that use them result in the core not initializing. Problem discovered on 4.5.0 RC4, works fine in 4.4.0. -- 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-5281) Incorrect access core.properties in IndexSchema.java
[
https://issues.apache.org/jira/browse/SOLR-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-5281:
-
Fix Version/s: 4.5
Incorrect access core.properties in IndexSchema.java
Key: SOLR-5281
URL: https://issues.apache.org/jira/browse/SOLR-5281
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Reporter: Jun Ohtani
Assignee: Steve Rowe
Priority: Minor
Fix For: 4.5, 5.0, 4.6
Attachments: SOLR-5281.patch
IndexSchema use core name for logging.
But core name always output [null] Schema.., the following.
---
3814 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– Reading Solr Schema from schema.xml
3926 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.schema.IndexSchema
– [null] Schema name=example
---
Maybe, property name pattern changed name to solr.core.name at SOLR-5162.
--- IndexSchema.java
...
public static final String NAME = name;
...
if (loader.getCoreProperties() != null) {
sb.append(loader.getCoreProperties().getProperty(NAME));
} else {
sb.append(null);
}
--
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: [VOTE] Release Lucene/Solr 4.5.0 RC4
Thanks Adrien. I've finished backporting SOLR-5279, and also backported SOLR-5281. Steve On Sep 27, 2013, at 4:30 PM, Adrien Grand jpou...@gmail.com wrote: Hi Steve, On Fri, Sep 27, 2013 at 9:30 PM, Steve Rowe sar...@gmail.com wrote: I attached a fix to the issue Shawn created for the missing implicit Solr-core-properties-on-RELOAD issue: SOLR-5279 IMHO, this regression should be fixed in 4.5. Adrien, I tried to raise you on IRC but didn't get a response - is it okay with you to do a respin? I'll commit to trunk and branch_4x with the CHANGES.txt entry under 4.6 until you say it's okay. Indeed, I was not keeping an eye on IRC. I will respin tomorrow morning european time. Thanks for fixing this issue! -- Adrien - 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] (SOLR-4816) Add document routing to CloudSolrServer
[ https://issues.apache.org/jira/browse/SOLR-4816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780568#comment-13780568 ] ASF subversion and git services commented on SOLR-4816: --- Commit 1527131 from [~steve_rowe] in branch 'dev/branches/lucene_solr_4_5' [ https://svn.apache.org/r1527131 ] SOLR-4816: add missing CHANGES credit (merged branch_4x r1524177) Add document routing to CloudSolrServer --- Key: SOLR-4816 URL: https://issues.apache.org/jira/browse/SOLR-4816 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.3 Reporter: Joel Bernstein Assignee: Mark Miller Priority: Minor Fix For: 4.5, 5.0 Attachments: RequestTask-removal.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816.patch, SOLR-4816-sriesenberg.patch This issue adds the following enhancements to CloudSolrServer's update logic: 1) Document routing: Updates are routed directly to the correct shard leader eliminating document routing at the server. 2) Optional parallel update execution: Updates for each shard are executed in a separate thread so parallel indexing can occur across the cluster. These enhancements should allow for near linear scalability on indexing throughput. Usage: CloudSolrServer cloudClient = new CloudSolrServer(zkAddress); cloudClient.setParallelUpdates(true); SolrInputDocument doc1 = new SolrInputDocument(); doc1.addField(id, 0); doc1.addField(a_t, hello1); SolrInputDocument doc2 = new SolrInputDocument(); doc2.addField(id, 2); doc2.addField(a_t, hello2); UpdateRequest request = new UpdateRequest(); request.add(doc1); request.add(doc2); request.setAction(AbstractUpdateRequest.ACTION.OPTIMIZE, false, false); NamedList response = cloudClient.request(request); // Returns a backwards compatible condensed response. //To get more detailed response down cast to RouteResponse: CloudSolrServer.RouteResponse rr = (CloudSolrServer.RouteResponse)response; -- 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: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_40) - Build # 7639 - Failure!
It appears to be a test bug -- the test indexes two documents, while changing Codec and commit in between (so two segments are created). It then assumes that the order of the documents in the reader remains the same (d0, d1), but it's actually d1,d0, hence the failure. I see that MockRandomMergePolicy is picked, and that it shuffles the segments. I'll fix the test to be less sensitive to that. Shai On Fri, Sep 27, 2013 at 11:11 PM, Michael McCandless luc...@mikemccandless.com wrote: This one reproduces; is anyone looking? Mike McCandless http://blog.mikemccandless.com On Thu, Sep 26, 2013 at 4:27 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/7639/ Java: 32bit/jdk1.7.0_40 -client -XX:+UseSerialGC 1 tests failed. REGRESSION: org.apache.lucene.index.TestNumericDocValuesUpdates.testChangeCodec Error Message: expected:12 but was:17 Stack Trace: java.lang.AssertionError: expected:12 but was:17 at __randomizedtesting.SeedInfo.seed([A099DBB8181A4538:C1FFAD77A92F9D1E]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.lucene.index.TestNumericDocValuesUpdates.testChangeCodec(TestNumericDocValuesUpdates.java:1074) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at
[jira] [Commented] (LUCENE-5189) Numeric DocValues Updates
[ https://issues.apache.org/jira/browse/LUCENE-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780670#comment-13780670 ] ASF subversion and git services commented on LUCENE-5189: - Commit 1527147 from [~shaie] in branch 'dev/trunk' [ https://svn.apache.org/r1527147 ] LUCENE-5189: disable merges in testChangeCodec Numeric DocValues Updates - Key: LUCENE-5189 URL: https://issues.apache.org/jira/browse/LUCENE-5189 Project: Lucene - Core Issue Type: New Feature Components: core/index Reporter: Shai Erera Assignee: Shai Erera Attachments: LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch In LUCENE-4258 we started to work on incremental field updates, however the amount of changes are immense and hard to follow/consume. The reason is that we targeted postings, stored fields, DV etc., all from the get go. I'd like to start afresh here, with numeric-dv-field updates only. There are a couple of reasons to that: * NumericDV fields should be easier to update, if e.g. we write all the values of all the documents in a segment for the updated field (similar to how livedocs work, and previously norms). * It's a fairly contained issue, attempting to handle just one data type to update, yet requires many changes to core code which will also be useful for updating other data types. * It has value in and on itself, and we don't need to allow updating all the data types in Lucene at once ... we can do that gradually. I have some working patch already which I'll upload next, explaining the changes. -- 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: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_40) - Build # 7639 - Failure!
Committed a fix - disabled merges in order to keep the test focused and simple. Shai On Sat, Sep 28, 2013 at 6:09 AM, Shai Erera ser...@gmail.com wrote: It appears to be a test bug -- the test indexes two documents, while changing Codec and commit in between (so two segments are created). It then assumes that the order of the documents in the reader remains the same (d0, d1), but it's actually d1,d0, hence the failure. I see that MockRandomMergePolicy is picked, and that it shuffles the segments. I'll fix the test to be less sensitive to that. Shai On Fri, Sep 27, 2013 at 11:11 PM, Michael McCandless luc...@mikemccandless.com wrote: This one reproduces; is anyone looking? Mike McCandless http://blog.mikemccandless.com On Thu, Sep 26, 2013 at 4:27 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/7639/ Java: 32bit/jdk1.7.0_40 -client -XX:+UseSerialGC 1 tests failed. REGRESSION: org.apache.lucene.index.TestNumericDocValuesUpdates.testChangeCodec Error Message: expected:12 but was:17 Stack Trace: java.lang.AssertionError: expected:12 but was:17 at __randomizedtesting.SeedInfo.seed([A099DBB8181A4538:C1FFAD77A92F9D1E]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.lucene.index.TestNumericDocValuesUpdates.testChangeCodec(TestNumericDocValuesUpdates.java:1074) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
Re: [VOTE] Release Lucene/Solr 4.5.0 RC4
I noticed when merging CHANGES.txt entries to the 4_5 branch that on Sept. 17th Mark Miller committed a 4.5 CHANGES.txt modification to add credit for somebody http://svn.apache.org/r1524177 (that's the branch_4x commit), but didn't also commit to the then-five-day-old 4_5 branch. So I merged Mark's branch_4x commit to the 4_5 branch. Steve On Sep 27, 2013, at 5:26 PM, Steve Rowe sar...@gmail.com wrote: Thanks Adrien. I've finished backporting SOLR-5279, and also backported SOLR-5281. Steve On Sep 27, 2013, at 4:30 PM, Adrien Grand jpou...@gmail.com wrote: Hi Steve, On Fri, Sep 27, 2013 at 9:30 PM, Steve Rowe sar...@gmail.com wrote: I attached a fix to the issue Shawn created for the missing implicit Solr-core-properties-on-RELOAD issue: SOLR-5279 IMHO, this regression should be fixed in 4.5. Adrien, I tried to raise you on IRC but didn't get a response - is it okay with you to do a respin? I'll commit to trunk and branch_4x with the CHANGES.txt entry under 4.6 until you say it's okay. Indeed, I was not keeping an eye on IRC. I will respin tomorrow morning european time. Thanks for fixing this issue! -- Adrien - 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] [Created] (SOLR-5285) Solr response format should support child Docs
Varun Thacker created SOLR-5285: --- Summary: Solr response format should support child Docs Key: SOLR-5285 URL: https://issues.apache.org/jira/browse/SOLR-5285 Project: Solr Issue Type: New Feature Reporter: Varun Thacker Fix For: 5.0, 4.6 Solr has added support for taking childDocs as input ( only XML till now ). It's currently used for BlockJoinQuery. I feel that if a user indexes a document with child docs, even if he isn't using the BJQ features and is just searching which results in a hit on the parentDoc, it's childDocs should be returned in the response format. [~hossman_luc...@fucit.org] on IRC suggested that the DocTransformers would be the place to add childDocs to the response. Now given a docId one needs to find out all the childDoc id's. A couple of approaches which I could think of are 1. Maintain the relation between a parentDoc and it's childDocs during indexing time in maybe a separate index? 2. Somehow emulate what happens in ToParentBlockJoinQuery.nextDoc() - Given a parentDoc it finds out all the childDocs but this requires a childScorer. Am I missing something obvious on how to find the relation between a parentDoc and it's childDocs because none of the above solutions for this look right. -- 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-2397) main example solrconfig.xml needs cleanup before 3.1
[ https://issues.apache.org/jira/browse/SOLR-2397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780692#comment-13780692 ] ASF subversion and git services commented on SOLR-2397: --- Commit 1527150 from [~dsmiley] in branch 'dev/trunk' [ https://svn.apache.org/r1527150 ] SOLR-5005: remove accidental inclusion of JavaScriptRequestHandler in r1075960 (SOLR-2397) main example solrconfig.xml needs cleanup before 3.1 Key: SOLR-2397 URL: https://issues.apache.org/jira/browse/SOLR-2397 Project: Solr Issue Type: Improvement Reporter: Hoss Man Assignee: Hoss Man Fix For: 3.1, 4.0-ALPHA Attachments: SOLR-2397.patch, SOLR-2397.patch, solrconfig.xml, solrconfig.xml the main solconfig.xml example file has gotten cluttered, doesn't use consistent indenting, lists various things in a haphazard order, and contains relics of outdated/deprecated plugins/terminology. this really needs to be dealt with prior to 3.1 since most people reuse this example as the basis for their own configs. rather then trying to opening individual issues for little one off changes (which is how a lot of the haphazard came about) i'm going to take a stab at one big cleanup here and seek feedback on the end result -- 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] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_40) - Build # 7568 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/7568/ Java: 32bit/jdk1.7.0_40 -client -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 1632 lines...] [junit4] ERROR: JVM J0 ended with an exception, command line: /var/lib/jenkins/tools/java/32bit/jdk1.7.0_40/jre/bin/java -client -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/heapdumps -Dtests.prefix=tests -Dtests.seed=94F1B34532F99A72 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=4.6 -Dtests.cleanthreads=perMethod -Djava.util.logging.config.file=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=3 -DtempDir=. -Djava.io.tmpdir=. -Djunit4.tempDir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/core/test/temp -Dclover.db.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/junit4/tests.policy -Dlucene.version=4.6-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Dtests.disableHdfs=true -classpath /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/test-framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/codecs/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/test-framework/lib/junit-4.10.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.0.10.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/core/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/core/classes/test:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-launcher.jar:/var/lib/jenkins/.ant/lib/ivy-2.3.0.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jai.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-swing.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-oro.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jmf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-xalan2.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-javamail.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-resolver.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-testutil.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-logging.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-log4j.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jsch.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-net.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bsf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jdepend.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-netrexx.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-regexp.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit4.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bcel.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-antlr.jar:/var/lib/jenkins/tools/java/32bit/jdk1.7.0_40/lib/tools.jar:/var/lib/jenkins/.ivy2/cache/com.carrotsearch.randomizedtesting/junit4-ant/jars/junit4-ant-2.0.10.jar -ea:org.apache.lucene... -ea:org.apache.solr... com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe -eventsfile /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/core/test/temp/junit4-J0-20130928_044816_071.events @/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build/core/test/temp/junit4-J0-20130928_044816_071.suites [junit4] ERROR: JVM J0 ended with an exception: Forked process returned with error code: 134. Very likely a JVM crash. Process output piped in logs above. [junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4.executeSlave(JUnit4.java:1254) [junit4] at
