[jira] Commented: (SOLR-272) SolrDocument performance testing
[ https://issues.apache.org/jira/browse/SOLR-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508478 ] Ryan McKinley commented on SOLR-272: Just so we are on the same page... Are you using SolrDocumentPerformanceTester.java with the changes from r551060 (trunk)? On my machine (core 2 duo) the SolrInputDocument is consistently faster. Are we running the same tests? SolrDocument performance testing Key: SOLR-272 URL: https://issues.apache.org/jira/browse/SOLR-272 Project: Solr Issue Type: Test Affects Versions: 1.3 Reporter: Ryan McKinley Attachments: SOLR-272-SolrDocumentPerformanceTesting.patch, SOLR-272-SolrDocumentPerformanceTesting.patch, SolrDocumentPerformanceTester.java, SolrInputDoc.patch In 1.3, we added SolrInputDocument -- a temporary class to hold document information. There is concern that this may be less then ideal performance-wise. To settle some concerns (mine included) I want to compare a few SolrDocument implementations to make sure we are not doing something crazy. I implemented a LuceneInputDocument subclass of SolrInputDocument that stores its values directly in Lucene Document (rather then a MapString,Collection). This is a quick test comparing: 1. Building documents with SolrInputDocument 2. Building documents with LuceneInputDocument (same interface writing directly to Document) 3. using DocumentBuilder (solr 1.2, solr 1.1) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-267) log handler + query + hits
[ https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-267: -- Attachment: LogQueryHitCounts.patch new patch that writes out request params as cgi instead of NL.toString() for pasting into a browser. i also figured out the HttpResponseHeader however i'm not sure how people feel about having that info duplicated in teh solr logs, the http headers/access logs and the actual solr response. in any case the following logic would go into SolrDispatchFilter: (but is not in this patch) log handler + query + hits -- Key: SOLR-267 URL: https://issues.apache.org/jira/browse/SOLR-267 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Will Johnson Priority: Minor Fix For: 1.3 Attachments: LogQueryHitCounts.patch, LogQueryHitCounts.patch, LogQueryHitCounts.patch, LogQueryHitCounts.patch, LogQueryHitCounts.patch, LogQueryHitCounts.patch adds a logger to log handler, query string and hit counts for each query -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-276) XML vs JSON writer performance issues
[ https://issues.apache.org/jira/browse/SOLR-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-276. --- Resolution: Fixed committed. XML vs JSON writer performance issues - Key: SOLR-276 URL: https://issues.apache.org/jira/browse/SOLR-276 Project: Solr Issue Type: Bug Reporter: Yonik Seeley Assignee: Yonik Seeley Priority: Minor Attachments: json_writer.patch JSON writer seems slower than the XML writer http://www.nabble.com/XML-vs-JSON-writer-performance-issues-tf3983443.html#a11309234 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Multiple indexes/cores (aka solr-215) functional value?
This http://www.nabble.com/multiple-indices-tf3982573.html thread triggers the question again. Solr-215 makes it easier to deploy multiple indexes than using multiple web applications; but is easier enough for not being just a superfluous feature? Henrib wrote: The idea of the multiple core/indexes feature has been discussed in many threads and it seems/seemed it has/had some functional value; how do we ensure this value is generic enough for the issue ( patch) to ever be solved? More importantly, is there an issue in the first place? For all use cases where it might make sense to use multiple indexes, the common (as in community and commiters) wisdom is that one index is enough and its schema will accommodate any functional need; from storing documents that have no field in common to documents in different languages or documents with varying publication workflows or lifetime, etc..., one index (schema/config/core) - fits the functional bill. In very rare hard cases, you might have to deploy multiple web applications. If having only one index is never a problem, the project has no need for a patch that introduces multiple indexes. Thus, if the solr-215 issue is a non-issue, what is the process to close it and mark it as 'invalid'? It would be of great community value to state that thinking about using multiple indexes is a mistake within the Solr project scope; use Lucene or else if this is what you need. Is/should the single index best practice the sole one the Solr community needs ? I should have asked this earlier, still learning... -- View this message in context: http://www.nabble.com/Multiple-indexes-cores-%28aka-solr-215%29-functional-value--tf3927076.html#a11325717 Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: Multiple indexes/cores (aka solr-215) functional value?
On 6/27/07, Henrib [EMAIL PROTECTED] wrote: This http://www.nabble.com/multiple-indices-tf3982573.html thread triggers the question again. Solr-215 makes it easier to deploy multiple indexes than using multiple web applications; but is easier enough for not being just a superfluous feature? With a fixed handful of indicies, IMO, no. Though if one needs to programmatically add new indicies/schemas, SOLR-215 becomes interesting. I don't know how common of a case that is though. There are probably other use cases I've not considered. SOLR-215 does seem unrelated to distributed search though. -Yonik
[jira] Updated: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Keller updated SOLR-236: - Attachment: SOLR-236-FieldCollapsing.patch This new patch resolves a performance issues. I have added time informations for monitoring performances: str name=time57/5/str The first value is the elapsed time (in milliseconds) needed to compute collapsed informations (CollapseFilter.ajacentCollapse method). The second value is the elapsed time needed to compute results informations (CollapseFilter.getMoreResults method). We are using Solr (with collapsing patch) on a large index in production environnment (120GB with more than 3 000 000 documents). P.S.: This time, the patch is relative to the solr root directory. Field collapsing Key: SOLR-236 URL: https://issues.apache.org/jira/browse/SOLR-236 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Emmanuel Keller Attachments: field_collapsing_1.1.0.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch This patch include a new feature called Field collapsing. Used in order to collapse a group of results with similar value for a given field to a single entry in the result set. Site collapsing is a special case of this, where all results for a given web site is collapsed into one or two entries in the result set, typically with an associated more documents from this site link. See also Duplicate detection. http://www.fastsearch.com/glossary.aspx?m=48amid=299 The implementation add 3 new query parameters (SolrParams): collapse.field to choose the field used to group results collapse.type normal (default value) or adjacent collapse.max to select how many continuous results are allowed before collapsing TODO (in progress): - More documentation (on source code) - Test cases Two patches: - field_collapsing.patch for current development version - field_collapsing_1.1.0.patch for Solr-1.1.0 P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Multiple indexes/cores (aka solr-215) functional value?
The starting point for Solr-215 was this http://www.nabble.com/Embedding-Solr-vs-Lucene%2C-multiple-Solr-cores--tf3572324.html thread in April. I'll still say that some of our customers IT are making deployment of multiple webapps something more complex than it should...but they do! IT is in fact managing an internal hosting service and do not want to deal with the functional part of the applications. In these environments, a webapp that starts a thread uses the file system is already a hard sell... In the same thread, I got the impression that removing the singletons would be useful anyway: hossman_lucene wrote: That said: If anyone is interested in tackling a patch to eliminate all of the static Singletons i (and many others i suspect) would be extremely gratefull .. both for how much it would improve hte reusability of Solr in embedded situatiosn like this, but also for how it would (hopefully) make hte code eaier to follow for future developers. More to your point, programmatic creation of indexes comes handy if you want to extend Solr with collection management (rather than dealing with them externally through scripts). You can easily add collections and/or languages and manage the collections definition/refresh/reindexing within the application; it seemed like a natural extension to the project. The main rationale being that since the Solr document/field format is most likely not the authoring format of the original resource (the authored source file), there is value in declaring how to transform a resource into an Solr-XML document from its collection/lang/suffix/etc. But this is beyond Solr-215. The same could be said for distributed search (aka solr-255) versus a 'Solr cluster management' application... At this point, Solr-215 just looks like a solution to my problem... My apologies for the clutter waste of community resources. Yonik Seeley wrote: On 6/27/07, Henrib [EMAIL PROTECTED] wrote: This http://www.nabble.com/multiple-indices-tf3982573.html thread triggers the question again. Solr-215 makes it easier to deploy multiple indexes than using multiple web applications; but is easier enough for not being just a superfluous feature? With a fixed handful of indicies, IMO, no. Though if one needs to programmatically add new indicies/schemas, SOLR-215 becomes interesting. I don't know how common of a case that is though. There are probably other use cases I've not considered. SOLR-215 does seem unrelated to distributed search though. -Yonik -- View this message in context: http://www.nabble.com/Multiple-indexes-cores-%28aka-solr-215%29-functional-value--tf3927076.html#a11327863 Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Updated: (SOLR-272) SolrDocument performance testing
[ https://issues.apache.org/jira/browse/SOLR-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-272: -- Attachment: SolrDocumentPerformanceTester.java Attraching the modified test prog I used. I modified it to accept separate counts, and do separate runs for the different implementations. For example, 10 0 0 and 0 0 1 This was to avoid any GC effects from one implementation to another, and to avoid hotspot optimizing for one path and then having a different implementation switch to a different path. The SolrInputDocument builder also needed that change from setField to addField to be equivalent. SolrDocument performance testing Key: SOLR-272 URL: https://issues.apache.org/jira/browse/SOLR-272 Project: Solr Issue Type: Test Affects Versions: 1.3 Reporter: Ryan McKinley Attachments: SOLR-272-SolrDocumentPerformanceTesting.patch, SOLR-272-SolrDocumentPerformanceTesting.patch, SolrDocumentPerformanceTester.java, SolrDocumentPerformanceTester.java, SolrInputDoc.patch In 1.3, we added SolrInputDocument -- a temporary class to hold document information. There is concern that this may be less then ideal performance-wise. To settle some concerns (mine included) I want to compare a few SolrDocument implementations to make sure we are not doing something crazy. I implemented a LuceneInputDocument subclass of SolrInputDocument that stores its values directly in Lucene Document (rather then a MapString,Collection). This is a quick test comparing: 1. Building documents with SolrInputDocument 2. Building documents with LuceneInputDocument (same interface writing directly to Document) 3. using DocumentBuilder (solr 1.2, solr 1.1) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-272) SolrDocument performance testing
[ https://issues.apache.org/jira/browse/SOLR-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508600 ] Yonik Seeley commented on SOLR-272: --- FYI, I tested on both P4 and Athlon with Java6 -server Of course this is still rather academic since I don't expect this to be a bottleneck in indexing. SolrDocument performance testing Key: SOLR-272 URL: https://issues.apache.org/jira/browse/SOLR-272 Project: Solr Issue Type: Test Affects Versions: 1.3 Reporter: Ryan McKinley Attachments: SOLR-272-SolrDocumentPerformanceTesting.patch, SOLR-272-SolrDocumentPerformanceTesting.patch, SolrDocumentPerformanceTester.java, SolrDocumentPerformanceTester.java, SolrInputDoc.patch In 1.3, we added SolrInputDocument -- a temporary class to hold document information. There is concern that this may be less then ideal performance-wise. To settle some concerns (mine included) I want to compare a few SolrDocument implementations to make sure we are not doing something crazy. I implemented a LuceneInputDocument subclass of SolrInputDocument that stores its values directly in Lucene Document (rather then a MapString,Collection). This is a quick test comparing: 1. Building documents with SolrInputDocument 2. Building documents with LuceneInputDocument (same interface writing directly to Document) 3. using DocumentBuilder (solr 1.2, solr 1.1) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-272) SolrDocument performance testing
[ https://issues.apache.org/jira/browse/SOLR-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508603 ] Ryan McKinley commented on SOLR-272: ok, now i'm getting the same results as you. thanks. SolrDocument performance testing Key: SOLR-272 URL: https://issues.apache.org/jira/browse/SOLR-272 Project: Solr Issue Type: Test Affects Versions: 1.3 Reporter: Ryan McKinley Attachments: SOLR-272-SolrDocumentPerformanceTesting.patch, SOLR-272-SolrDocumentPerformanceTesting.patch, SolrDocumentPerformanceTester.java, SolrDocumentPerformanceTester.java, SolrInputDoc.patch In 1.3, we added SolrInputDocument -- a temporary class to hold document information. There is concern that this may be less then ideal performance-wise. To settle some concerns (mine included) I want to compare a few SolrDocument implementations to make sure we are not doing something crazy. I implemented a LuceneInputDocument subclass of SolrInputDocument that stores its values directly in Lucene Document (rather then a MapString,Collection). This is a quick test comparing: 1. Building documents with SolrInputDocument 2. Building documents with LuceneInputDocument (same interface writing directly to Document) 3. using DocumentBuilder (solr 1.2, solr 1.1) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-266) Let the LukeRequestHandler return parsed schema information
[ https://issues.apache.org/jira/browse/SOLR-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-266. Resolution: Fixed Let the LukeRequestHandler return parsed schema information --- Key: SOLR-266 URL: https://issues.apache.org/jira/browse/SOLR-266 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Priority: Minor Fix For: 1.3 Attachments: SOLR-266-LukeSchemaInfo.patch The LukeRequestHandler currently just shows info for fields it finds in the index. It could also show info for fields in the schema. This patch adds: http://localhost:8983/solr/admin/luke?show=schema showing a list of all fields defined by the schema followed by the types and what fields use the types (if any) This is helpful for client apps to know what fields are available and is also a good sanity check to see what fields solr knows about after parsing the schema.xml. Chasing down xml parsing can be difficult: http://www.nabble.com/Keep-having-error-on-%22unknown-field%22-tf3923356.html#a11125764 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Running Unit Tests from inside Eclipse
Hi all, I always run into path issues when running the unit tests from inside of Eclipse... For example, when I run TestCSVLoader.java I get java.lang.ExceptionInInitializerError at org.apache.solr.util.TestHarness.init(TestHarness.java:101) at org.apache.solr.util.AbstractSolrTestCase.setUp (AbstractSolrTestCase.java:102) at org.apache.solr.handler.TestCSVLoader.setUp(TestCSVLoader.java:43) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run (JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run (TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests (RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests (RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run (RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main (RemoteTestRunner.java:196) Caused by: java.lang.RuntimeException: Error in solrconfig.xml at org.apache.solr.core.SolrConfig.clinit(SolrConfig.java:90) ... 16 more Caused by: java.lang.RuntimeException: Can't find resource 'solrconfig.xml' in classpath or 'solr/conf/', cwd=/Users/eric/ Documents/code/oss/apache/solr/trunk at org.apache.solr.core.Config.openResource(Config.java:357) at org.apache.solr.core.SolrConfig.initConfig(SolrConfig.java:79) at org.apache.solr.core.SolrConfig.clinit(SolrConfig.java:87) ... 16 more I have a tweak that gives it an alternate path to look up the file... Would that be of interest to anyone as a patch file? Is there a specific way to config my Eclipse project to find the path? Eric Pugh --- Principal OpenSource Connections Site: http://www.opensourceconnections.com Blog: http://blog.opensourceconnections.com Cell: 1-434-466-1467
[jira] Commented: (SOLR-272) SolrDocument performance testing
[
https://issues.apache.org/jira/browse/SOLR-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508614
]
Yonik Seeley commented on SOLR-272:
---
An alternate way to do SolrDocument would be to only add a Collection if there
were multiple values... something along the lines of:
public class SolrDocument2 {
private final HashMapString,Object _fields = new HashMapString,Object();
public SolrDocument2() {
}
public CollectionString getFieldNames() {
return _fields.keySet();
}
public void clear() {
_fields.clear();
}
public Object removeFields(String name) {
return _fields.remove( name ) != null;
}
public void setField(String name, Object value) {
_fields.put(name, value);
}
public void addField(String name, Object value)
{
Object existing = _fields.put(name, value);
if (existing == null) return;
if (existing instanceof Collection) {
Collection c = (Collection)existing;
c.add(value);
_fields.put(name, c);
}
}
/**
* returns the first value for this field
*/
public Object getFieldValue(String name) {
Object v = _fields.get( name );
if (v == null || !(v instanceof Collection)) return v;
Collection c = (Collection)v;
if (c.size() 0 ) {
return c.iterator().next();
}
return null;
}
/**
* Get the value(s) for a given field... a Collection, or an Object
*/
public Object getFieldValues(String name) {
return _fields.get( name );
}
}
SolrDocument performance testing
Key: SOLR-272
URL: https://issues.apache.org/jira/browse/SOLR-272
Project: Solr
Issue Type: Test
Affects Versions: 1.3
Reporter: Ryan McKinley
Attachments: SOLR-272-SolrDocumentPerformanceTesting.patch,
SOLR-272-SolrDocumentPerformanceTesting.patch,
SolrDocumentPerformanceTester.java, SolrDocumentPerformanceTester.java,
SolrInputDoc.patch
In 1.3, we added SolrInputDocument -- a temporary class to hold document
information. There is concern that this may be less then ideal
performance-wise.
To settle some concerns (mine included) I want to compare a few SolrDocument
implementations to make sure we are not doing something crazy.
I implemented a LuceneInputDocument subclass of SolrInputDocument that stores
its values directly in Lucene Document (rather then a MapString,Collection).
This is a quick test comparing:
1. Building documents with SolrInputDocument
2. Building documents with LuceneInputDocument (same interface writing
directly to Document)
3. using DocumentBuilder (solr 1.2, solr 1.1)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Running Unit Tests from inside Eclipse
I tell IntelliJ IDEA to set the working directory for all the tests to F:\code\solr\src\test\test-files -Yonik On 6/27/07, Eric Pugh [EMAIL PROTECTED] wrote: Hi all, I always run into path issues when running the unit tests from inside of Eclipse... For example, when I run TestCSVLoader.java I get java.lang.ExceptionInInitializerError at org.apache.solr.util.TestHarness.init(TestHarness.java:101) at org.apache.solr.util.AbstractSolrTestCase.setUp (AbstractSolrTestCase.java:102) at org.apache.solr.handler.TestCSVLoader.setUp(TestCSVLoader.java:43) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run (JUnit3TestReference.java:128) at org.eclipse.jdt.internal.junit.runner.TestExecution.run (TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests (RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests (RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run (RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main (RemoteTestRunner.java:196) Caused by: java.lang.RuntimeException: Error in solrconfig.xml at org.apache.solr.core.SolrConfig.clinit(SolrConfig.java:90) ... 16 more Caused by: java.lang.RuntimeException: Can't find resource 'solrconfig.xml' in classpath or 'solr/conf/', cwd=/Users/eric/ Documents/code/oss/apache/solr/trunk at org.apache.solr.core.Config.openResource(Config.java:357) at org.apache.solr.core.SolrConfig.initConfig(SolrConfig.java:79) at org.apache.solr.core.SolrConfig.clinit(SolrConfig.java:87) ... 16 more I have a tweak that gives it an alternate path to look up the file... Would that be of interest to anyone as a patch file? Is there a specific way to config my Eclipse project to find the path? Eric Pugh --- Principal OpenSource Connections Site: http://www.opensourceconnections.com Blog: http://blog.opensourceconnections.com Cell: 1-434-466-1467
Re: svn commit: r551060 - /lucene/solr/trunk/src/java/org/apache/solr/update/DocumentBuilder.java
: check for null copyField source, delay some allocations
i understanding delaying the allocation of missingFields, but why only a
size of 1 once it is allocated? (is this just an assumption thta
typically only a few fieldswill be missing? would it make sense to just
switch to a LinkedLIst since missingFields is only ever used for
iteration?)
: -ListString missingFields = new ArrayListString(
schema.getRequiredFields().size() );
: +ListString missingFields = null;
: for (SchemaField field : schema.getRequiredFields()) {
:if (doc.getField(field.getName() ) == null) {
: if (field.getDefaultValue() != null) {
:doc.add( field.createField( field.getDefaultValue(), 1.0f ) );
: } else {
: + if (missingFields==null) {
: +missingFields = new ArrayListString(1);
: + }
-Hoss
Re: svn commit: r551060 - /lucene/solr/trunk/src/java/org/apache/solr/update/DocumentBuilder.java
On 6/27/07, Chris Hostetter [EMAIL PROTECTED] wrote: : check for null copyField source, delay some allocations i understanding delaying the allocation of missingFields, but why only a size of 1 once it is allocated? Actually, it's an error case, so I don't really care about the speed or memory consumption, as long as it only happens in that error case. Could have just as easily left off the size. -Yonik
Re: Multiple indexes/cores (aka solr-215) functional value?
: At this point, Solr-215 just looks like a solution to my problem... : My apologies for the clutter waste of community resources. Please, please, PLEASE don't feel that way ... a functioning patch and/or a productive discussion is *NEVER* a waste of resources. I think Doug Cutting is the first person that told me the mantra all open source projects should live by a patch in the bug queue that never gets commited is still a useful patch because it's available to people that want it. ... but commiting a patch (especially a big one) requires taking on a lot of responsibility to stand behind the APIs/functionality it includes and commit to a best effort to support them in a backwards compatible way for as long as feasible. On a personal note: Please keep in mind that just because i make suggestions to people on how to achieve multiple indexes / schemas / doctypes that doesn't require your patch doesn't mean i think there's anything wrong with your patch ... i'm just trying to make sure people are aware of what's posisble out of the box.I think the appraoch you've advoated in teh jira issue description makes a lot of sense, and i kind of wish Solr had been implemented that way in the begining -- it just wasn't anticipated. the real question in my mind is: can we get from here to there cleanly, and is your patch the way to do it? i don't know the answer to that question yet. but please don't be discouraged. -Hoss
Re: Running Unit Tests from inside Eclipse
I was wondering about that, but also, how do you handle the two
system properties?
I added to public TestHarness(String dataDirectory,
String confFile,
String schemaFile) {
these lines:
System.setProperty(solr.test.sys.prop1, propone);
System.setProperty(solr.test.sys.prop2, proptwo);
Otherwise I always got an error about a missing system property.
Normally, via Ant, these are passed in via the JUnit test
definition. Would this change be worth an issue in Jira and a patch
file?
Also, mucking around with working-directories didn't work, so I added
the path in Config.java. Attached is a patch file for these two
changes.
Eric
On Jun 27, 2007, at 2:29 PM, Yonik Seeley wrote:
I tell IntelliJ IDEA to set the working directory for all the tests to
F:\code\solr\src\test\test-files
-Yonik
On 6/27/07, Eric Pugh [EMAIL PROTECTED] wrote:
Hi all,
I always run into path issues when running the unit tests from inside
of Eclipse...
For example, when I run TestCSVLoader.java I get
java.lang.ExceptionInInitializerError
at org.apache.solr.util.TestHarness.init
(TestHarness.java:101)
at org.apache.solr.util.AbstractSolrTestCase.setUp
(AbstractSolrTestCase.java:102)
at org.apache.solr.handler.TestCSVLoader.setUp
(TestCSVLoader.java:43)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:
124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run
(JUnit3TestReference.java:128)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run
(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run
(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main
(RemoteTestRunner.java:196)
Caused by: java.lang.RuntimeException: Error in solrconfig.xml
at org.apache.solr.core.SolrConfig.clinit
(SolrConfig.java:90)
... 16 more
Caused by: java.lang.RuntimeException: Can't find resource
'solrconfig.xml' in classpath or 'solr/conf/', cwd=/Users/eric/
Documents/code/oss/apache/solr/trunk
at org.apache.solr.core.Config.openResource(Config.java:357)
at org.apache.solr.core.SolrConfig.initConfig
(SolrConfig.java:79)
at org.apache.solr.core.SolrConfig.clinit
(SolrConfig.java:87)
... 16 more
I have a tweak that gives it an alternate path to look up the
file... Would that be of interest to anyone as a patch file? Is
there a specific way to config my Eclipse project to find the path?
Eric Pugh
---
Principal
OpenSource Connections
Site: http://www.opensourceconnections.com
Blog: http://blog.opensourceconnections.com
Cell: 1-434-466-1467
---
Principal
OpenSource Connections
Site: http://www.opensourceconnections.com
Blog: http://blog.opensourceconnections.com
Cell: 1-434-466-1467
Re: Running Unit Tests from inside Eclipse
You need to add something like:
-Dsolr.test.sys.prop1=xxx -Dsolr.test.sys.prop2=xxx to the VM
arguments in the Run panel.
It is kind of annoying they are required for all tests... ideally we
would move the schema property testing to an independent test, but that
has not happend yet.
Eric Pugh wrote:
I was wondering about that, but also, how do you handle the two system
properties?
I added to public TestHarness(String dataDirectory,
String confFile,
String schemaFile) {
these lines:
System.setProperty(solr.test.sys.prop1, propone);
System.setProperty(solr.test.sys.prop2, proptwo);
Otherwise I always got an error about a missing system property.
Normally, via Ant, these are passed in via the JUnit test definition.
Would this change be worth an issue in Jira and a patch file?
Also, mucking around with working-directories didn't work, so I added
the path in Config.java. Attached is a patch file for these two
changes.
Eric
On Jun 27, 2007, at 2:29 PM, Yonik Seeley wrote:
I tell IntelliJ IDEA to set the working directory for all the tests to
F:\code\solr\src\test\test-files
-Yonik
On 6/27/07, Eric Pugh [EMAIL PROTECTED] wrote:
Hi all,
I always run into path issues when running the unit tests from inside
of Eclipse...
For example, when I run TestCSVLoader.java I get
java.lang.ExceptionInInitializerError
at org.apache.solr.util.TestHarness.init(TestHarness.java:101)
at org.apache.solr.util.AbstractSolrTestCase.setUp
(AbstractSolrTestCase.java:102)
at
org.apache.solr.handler.TestCSVLoader.setUp(TestCSVLoader.java:43)
at junit.framework.TestCase.runBare(TestCase.java:125)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run
(JUnit3TestReference.java:128)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run
(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run
(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main
(RemoteTestRunner.java:196)
Caused by: java.lang.RuntimeException: Error in solrconfig.xml
at org.apache.solr.core.SolrConfig.clinit(SolrConfig.java:90)
... 16 more
Caused by: java.lang.RuntimeException: Can't find resource
'solrconfig.xml' in classpath or 'solr/conf/', cwd=/Users/eric/
Documents/code/oss/apache/solr/trunk
at org.apache.solr.core.Config.openResource(Config.java:357)
at
org.apache.solr.core.SolrConfig.initConfig(SolrConfig.java:79)
at org.apache.solr.core.SolrConfig.clinit(SolrConfig.java:87)
... 16 more
I have a tweak that gives it an alternate path to look up the
file... Would that be of interest to anyone as a patch file? Is
there a specific way to config my Eclipse project to find the path?
Eric Pugh
---
Principal
OpenSource Connections
Site: http://www.opensourceconnections.com
Blog: http://blog.opensourceconnections.com
Cell: 1-434-466-1467
---
Principal
OpenSource Connections
Site: http://www.opensourceconnections.com
Blog: http://blog.opensourceconnections.com
Cell: 1-434-466-1467
Re: Running Unit Tests from inside Eclipse
On 6/27/07, Eric Pugh [EMAIL PROTECTED] wrote:
I added to public TestHarness(String dataDirectory,
String confFile,
String schemaFile) {
these lines:
System.setProperty(solr.test.sys.prop1, propone);
System.setProperty(solr.test.sys.prop2, proptwo);
Otherwise I always got an error about a missing system property.
Normally, via Ant, these are passed in via the JUnit test
definition. Would this change be worth an issue in Jira and a patch
file?
Yes, either this, or make those specific tests use a separate config.
Also, mucking around with working-directories didn't work, so I added
the path in Config.java. Attached is a patch file for these two
changes.
Hmmm, don't know why fixing the working directory wouldn't work for
you... anyone else use Eclipse?
-Yonik
Re: Running Unit Tests from inside Eclipse
: the path in Config.java. Attached is a patch file for these two : changes. FYI; apache mailing lists strip most attachments ... i think it works if hte mime-type is text/plain, but the simplest thing to do is just include it inline in your message. (as a general philosophy, i'm opposed to code changes solely for the purpose of making IDEs happy ... IDEs should make developing code easier, not hte other way arround) -Hoss
