Re: Solr 1.4
It makes sense to push some of the issues to 1.5 if they are really not urgent On Wed, Jun 24, 2009 at 8:10 PM, Mark Miller wrote: > How are we feeling about Solr 1.4? > > We have about 35 bugs in JIRA for 1.4 with about half assigned (though a > good chunk of those probably really do have an assignee). > > -- > - Mark > > http://www.lucidimagination.com > > > > -- - Noble Paul | Principal Engineer| AOL | http://aol.com
[jira] Commented: (SOLR-1245) DIH eats up SQL exception
[ https://issues.apache.org/jira/browse/SOLR-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723905#action_12723905 ] Noble Paul commented on SOLR-1245: -- committed r788252 > DIH eats up SQL exception > - > > Key: SOLR-1245 > URL: https://issues.apache.org/jira/browse/SOLR-1245 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1245.patch > > > see the mail thread http://markmail.org/thread/bdzhwch7ivkuvmk2 > org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:326) > > should throw an exception back -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1244) JdbcDataSource uses wrong overload of getConnection on JNDI DataSource
[ https://issues.apache.org/jira/browse/SOLR-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723904#action_12723904 ] Noble Paul edited comment on SOLR-1244 at 6/24/09 10:31 PM: committed r788265 thanks Chris was (Author: noble.paul): committed r788265 > JdbcDataSource uses wrong overload of getConnection on JNDI DataSource > -- > > Key: SOLR-1244 > URL: https://issues.apache.org/jira/browse/SOLR-1244 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 > Environment: Any. >Reporter: Chris Eldredge >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1244.patch, SOLR-1244.patch > > > When configured to use a JDBC DataSource via JNDI, JdbcDataSource checks to > see if initProps contains a property named "user." If that property is null, > DataSource.getConnection(String user, String password) is used where > DataSource.getConnection() should be called. I will provide a test case and > patch that fixes the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1244) JdbcDataSource uses wrong overload of getConnection on JNDI DataSource
[ https://issues.apache.org/jira/browse/SOLR-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1244. -- Resolution: Fixed committed r788265 > JdbcDataSource uses wrong overload of getConnection on JNDI DataSource > -- > > Key: SOLR-1244 > URL: https://issues.apache.org/jira/browse/SOLR-1244 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 > Environment: Any. >Reporter: Chris Eldredge >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1244.patch, SOLR-1244.patch > > > When configured to use a JDBC DataSource via JNDI, JdbcDataSource checks to > see if initProps contains a property named "user." If that property is null, > DataSource.getConnection(String user, String password) is used where > DataSource.getConnection() should be called. I will provide a test case and > patch that fixes the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1244) JdbcDataSource uses wrong overload of getConnection on JNDI DataSource
[ https://issues.apache.org/jira/browse/SOLR-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1244: - Attachment: SOLR-1244.patch synced w/ trunk . I shall commit this shortly > JdbcDataSource uses wrong overload of getConnection on JNDI DataSource > -- > > Key: SOLR-1244 > URL: https://issues.apache.org/jira/browse/SOLR-1244 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 > Environment: Any. >Reporter: Chris Eldredge >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1244.patch, SOLR-1244.patch > > > When configured to use a JDBC DataSource via JNDI, JdbcDataSource checks to > see if initProps contains a property named "user." If that property is null, > DataSource.getConnection(String user, String password) is used where > DataSource.getConnection() should be called. I will provide a test case and > patch that fixes the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1244) JdbcDataSource uses wrong overload of getConnection on JNDI DataSource
[ https://issues.apache.org/jira/browse/SOLR-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1244: - Fix Version/s: 1.4 > JdbcDataSource uses wrong overload of getConnection on JNDI DataSource > -- > > Key: SOLR-1244 > URL: https://issues.apache.org/jira/browse/SOLR-1244 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 > Environment: Any. >Reporter: Chris Eldredge >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1244.patch > > > When configured to use a JDBC DataSource via JNDI, JdbcDataSource checks to > see if initProps contains a property named "user." If that property is null, > DataSource.getConnection(String user, String password) is used where > DataSource.getConnection() should be called. I will provide a test case and > patch that fixes the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1245) DIH eats up SQL exception
[ https://issues.apache.org/jira/browse/SOLR-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1245: - Attachment: SOLR-1245.patch > DIH eats up SQL exception > - > > Key: SOLR-1245 > URL: https://issues.apache.org/jira/browse/SOLR-1245 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1245.patch > > > see the mail thread http://markmail.org/thread/bdzhwch7ivkuvmk2 > org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:326) > > should throw an exception back -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1245) DIH eats up SQL exception
[ https://issues.apache.org/jira/browse/SOLR-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1245: Assignee: Noble Paul > DIH eats up SQL exception > - > > Key: SOLR-1245 > URL: https://issues.apache.org/jira/browse/SOLR-1245 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > > see the mail thread http://markmail.org/thread/bdzhwch7ivkuvmk2 > org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:326) > > should throw an exception back -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1244) JdbcDataSource uses wrong overload of getConnection on JNDI DataSource
[ https://issues.apache.org/jira/browse/SOLR-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1244: Assignee: Noble Paul > JdbcDataSource uses wrong overload of getConnection on JNDI DataSource > -- > > Key: SOLR-1244 > URL: https://issues.apache.org/jira/browse/SOLR-1244 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 > Environment: Any. >Reporter: Chris Eldredge >Assignee: Noble Paul > Attachments: SOLR-1244.patch > > > When configured to use a JDBC DataSource via JNDI, JdbcDataSource checks to > see if initProps contains a property named "user." If that property is null, > DataSource.getConnection(String user, String password) is used where > DataSource.getConnection() should be called. I will provide a test case and > patch that fixes the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1245) DIH eats up SQL exception
DIH eats up SQL exception - Key: SOLR-1245 URL: https://issues.apache.org/jira/browse/SOLR-1245 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Noble Paul Priority: Minor Fix For: 1.4 see the mail thread http://markmail.org/thread/bdzhwch7ivkuvmk2 org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.hasnext(JdbcDataSource.java:326) should throw an exception back -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1244) JdbcDataSource uses wrong overload of getConnection on JNDI DataSource
[ https://issues.apache.org/jira/browse/SOLR-1244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Eldredge updated SOLR-1244: - Attachment: SOLR-1244.patch Patch against r788203 including unit tests. > JdbcDataSource uses wrong overload of getConnection on JNDI DataSource > -- > > Key: SOLR-1244 > URL: https://issues.apache.org/jira/browse/SOLR-1244 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 > Environment: Any. >Reporter: Chris Eldredge > Attachments: SOLR-1244.patch > > > When configured to use a JDBC DataSource via JNDI, JdbcDataSource checks to > see if initProps contains a property named "user." If that property is null, > DataSource.getConnection(String user, String password) is used where > DataSource.getConnection() should be called. I will provide a test case and > patch that fixes the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1244) JdbcDataSource uses wrong overload of getConnection on JNDI DataSource
JdbcDataSource uses wrong overload of getConnection on JNDI DataSource -- Key: SOLR-1244 URL: https://issues.apache.org/jira/browse/SOLR-1244 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.4 Environment: Any. Reporter: Chris Eldredge When configured to use a JDBC DataSource via JNDI, JdbcDataSource checks to see if initProps contains a property named "user." If that property is null, DataSource.getConnection(String user, String password) is used where DataSource.getConnection() should be called. I will provide a test case and patch that fixes the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1241) Use Lucene's CharFilter
[
https://issues.apache.org/jira/browse/SOLR-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-1241:
-
Attachment: SOLR-1241.patch
I added the diff of TokenizerChain:
{code}
$ svn diff src/java/org/apache/solr/analysis/TokenizerChain.java >>
SOLR-1241.patch
{code}
bq. We'd need to commit this together with SOLR-940 to avoid compile failures.
Right. This ticket covers only CharFilter issue. Shalin, when you are ready to
commit SOLR-940, use/commit this patch.
> Use Lucene's CharFilter
> ---
>
> Key: SOLR-1241
> URL: https://issues.apache.org/jira/browse/SOLR-1241
> Project: Solr
> Issue Type: Task
> Components: Analysis
>Affects Versions: 1.4
>Reporter: Koji Sekiguchi
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1241.patch, SOLR-1241.patch
>
>
> Now LUCENE-1466 has been committed, Solr should use Lucene's CharFilter
> before release 1.4. I'll just svn del (rather than deperecated) CharFilter
> classes in Solr:
> {code}
> $ svn status
> D src/test/org/apache/solr/analysis/TestMappingCharFilter.java
> D src/test/org/apache/solr/analysis/TestCharFilter.java
> D src/java/org/apache/solr/analysis/CharReader.java
> M src/java/org/apache/solr/analysis/CharFilterFactory.java
> D src/java/org/apache/solr/analysis/BaseCharFilter.java
> D src/java/org/apache/solr/analysis/CharFilter.java
> D
> src/java/org/apache/solr/analysis/CharStreamAwareCJKTokenizerFactory.java
> D
> src/java/org/apache/solr/analysis/CharStreamAwareWhitespaceTokenizerFactory.java
> M src/java/org/apache/solr/analysis/MappingCharFilterFactory.java
> D src/java/org/apache/solr/analysis/CharStreamAwareCJKTokenizer.java
> D src/java/org/apache/solr/analysis/NormalizeMap.java
> D src/java/org/apache/solr/analysis/MappingCharFilter.java
> D src/java/org/apache/solr/analysis/CharStreamAwareCharTokenizer.java
> D
> src/java/org/apache/solr/analysis/CharStreamAwareWhitespaceTokenizer.java
> D src/java/org/apache/solr/analysis/CharStream.java
> M example/solr/conf/schema.xml
> {code}
> This needs r787795 of lucene jar or later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-940) TrieRange support
[ https://issues.apache.org/jira/browse/SOLR-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723752#action_12723752 ] Shalin Shekhar Mangar commented on SOLR-940: Thanks Uwe! Regarding Collector#acceptsDocsOutOfOrder, I think we need to # Return true when we do not need scores, otherwise false. # DocSetCollector and DocSetDelegateCollector collect in order so we return false It'd be great if someone who know more about this stuff can confirm. SOLR-1241 must also be committed together with this issue to avoid compile errors. I'm also seeing this exception in many tests (DisMaxRequestHandlerTest, TestTrie, TestDistributedSearch) which, I guess, are related to LUCENE-1630 SEVERE: java.lang.UnsupportedOperationException at org.apache.lucene.search.Query.createQueryWeight(Query.java:102) at org.apache.lucene.search.BooleanQuery$BooleanWeight.(BooleanQuery.java:185) at org.apache.lucene.search.BooleanQuery.createQueryWeight(BooleanQuery.java:401) at org.apache.lucene.search.Query.queryWeight(Query.java:120) at org.apache.lucene.search.Searcher.createQueryWeight(Searcher.java:237) at org.apache.lucene.search.Searcher.search(Searcher.java:173) at org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1103) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:880) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:341) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:176) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1290) I'll try to have another look tomorrow. > TrieRange support > - > > Key: SOLR-940 > URL: https://issues.apache.org/jira/browse/SOLR-940 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: SOLR-940-LUCENE-1602.patch, SOLR-940-LUCENE-1602.patch, > SOLR-940-LUCENE-1701.patch, SOLR-940-newTrieAPI.patch, > SOLR-940-newTrieAPI.patch, SOLR-940-rangequery.patch, > SOLR-940-rangequery.patch, SOLR-940-test.patch, SOLR-940.patch, > SOLR-940.patch, SOLR-940.patch, SOLR-940.patch, SOLR-940.patch, > SOLR-940.patch, SOLR-940.patch, SOLR-940.patch, SOLR-940.patch, SOLR-940.patch > > > We need support in Solr for the new TrieRange Lucene functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1241) Use Lucene's CharFilter
[
https://issues.apache.org/jira/browse/SOLR-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723735#action_12723735
]
Shalin Shekhar Mangar commented on SOLR-1241:
-
Koji, the patch needs changes to TokenizerChain (add import for Lucene's
CharStream/CharReader).
We'd need to commit this together with SOLR-940 to avoid compile failures.
> Use Lucene's CharFilter
> ---
>
> Key: SOLR-1241
> URL: https://issues.apache.org/jira/browse/SOLR-1241
> Project: Solr
> Issue Type: Task
> Components: Analysis
>Affects Versions: 1.4
>Reporter: Koji Sekiguchi
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1241.patch
>
>
> Now LUCENE-1466 has been committed, Solr should use Lucene's CharFilter
> before release 1.4. I'll just svn del (rather than deperecated) CharFilter
> classes in Solr:
> {code}
> $ svn status
> D src/test/org/apache/solr/analysis/TestMappingCharFilter.java
> D src/test/org/apache/solr/analysis/TestCharFilter.java
> D src/java/org/apache/solr/analysis/CharReader.java
> M src/java/org/apache/solr/analysis/CharFilterFactory.java
> D src/java/org/apache/solr/analysis/BaseCharFilter.java
> D src/java/org/apache/solr/analysis/CharFilter.java
> D
> src/java/org/apache/solr/analysis/CharStreamAwareCJKTokenizerFactory.java
> D
> src/java/org/apache/solr/analysis/CharStreamAwareWhitespaceTokenizerFactory.java
> M src/java/org/apache/solr/analysis/MappingCharFilterFactory.java
> D src/java/org/apache/solr/analysis/CharStreamAwareCJKTokenizer.java
> D src/java/org/apache/solr/analysis/NormalizeMap.java
> D src/java/org/apache/solr/analysis/MappingCharFilter.java
> D src/java/org/apache/solr/analysis/CharStreamAwareCharTokenizer.java
> D
> src/java/org/apache/solr/analysis/CharStreamAwareWhitespaceTokenizer.java
> D src/java/org/apache/solr/analysis/CharStream.java
> M example/solr/conf/schema.xml
> {code}
> This needs r787795 of lucene jar or later.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1243) The admin System handler page (and others like it) should not be cached
[ https://issues.apache.org/jira/browse/SOLR-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1243: -- Attachment: SOLR-1243.patch quick rev > The admin System handler page (and others like it) should not be cached > --- > > Key: SOLR-1243 > URL: https://issues.apache.org/jira/browse/SOLR-1243 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1243.patch > > > appears the pages are cached now, so if you want to refresh the info you have > to clear your browser cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1243) The admin System handler page (and others like it) should not be cached
[ https://issues.apache.org/jira/browse/SOLR-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-1243: - Assignee: Mark Miller > The admin System handler page (and others like it) should not be cached > --- > > Key: SOLR-1243 > URL: https://issues.apache.org/jira/browse/SOLR-1243 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1243.patch > > > appears the pages are cached now, so if you want to refresh the info you have > to clear your browser cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1243) The admin System handler page (and others like it) should not be cached
[ https://issues.apache.org/jira/browse/SOLR-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723715#action_12723715 ] Shalin Shekhar Mangar commented on SOLR-1243: - bq. I'm going to upload a patch with all of the admin handlers changed to turn off http caching. +1 > The admin System handler page (and others like it) should not be cached > --- > > Key: SOLR-1243 > URL: https://issues.apache.org/jira/browse/SOLR-1243 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Priority: Minor > Fix For: 1.4 > > > appears the pages are cached now, so if you want to refresh the info you have > to clear your browser cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1243) The admin System handler page (and others like it) should not be cached
[ https://issues.apache.org/jira/browse/SOLR-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723708#action_12723708 ] Mark Miller commented on SOLR-1243: --- I'm going to upload a patch with all of the admin handlers changed to turn off http caching. Any objections? > The admin System handler page (and others like it) should not be cached > --- > > Key: SOLR-1243 > URL: https://issues.apache.org/jira/browse/SOLR-1243 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Priority: Minor > Fix For: 1.4 > > > appears the pages are cached now, so if you want to refresh the info you have > to clear your browser cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1242) The admin System handler returns bad JVM info
[ https://issues.apache.org/jira/browse/SOLR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1242: -- Attachment: SOLR-1242.patch tweak names > The admin System handler returns bad JVM info > - > > Key: SOLR-1242 > URL: https://issues.apache.org/jira/browse/SOLR-1242 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1242.patch, SOLR-1242.patch > > > FileUtils.byteCountToDisplaySize has a funny way of converting. > runtime.maxMemory() : 2092236800 bytes > commons-io display : 1 GB > Appears to be more than just a rounddown, because it will knock over 3 gig to > 2 gig as well. Odd stuff. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1242) The admin System handler returns bad JVM info
[ https://issues.apache.org/jira/browse/SOLR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723659#action_12723659 ] Mark Miller edited comment on SOLR-1242 at 6/24/09 10:59 AM: - Here we go - much better...rounds to one decimal rather than int (only round down cutoff) rounding. was (Author: markrmil...@gmail.com): Here we go - much better...rounds to one decimal rather than int rounding. > The admin System handler returns bad JVM info > - > > Key: SOLR-1242 > URL: https://issues.apache.org/jira/browse/SOLR-1242 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1242.patch > > > FileUtils.byteCountToDisplaySize has a funny way of converting. > runtime.maxMemory() : 2092236800 bytes > commons-io display : 1 GB > Appears to be more than just a rounddown, because it will knock over 3 gig to > 2 gig as well. Odd stuff. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1242) The admin System handler returns bad JVM info
[ https://issues.apache.org/jira/browse/SOLR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1242: -- Attachment: SOLR-1242.patch Here we go - much better...rounds to one decimal rather than int rounding. > The admin System handler returns bad JVM info > - > > Key: SOLR-1242 > URL: https://issues.apache.org/jira/browse/SOLR-1242 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1242.patch > > > FileUtils.byteCountToDisplaySize has a funny way of converting. > runtime.maxMemory() : 2092236800 bytes > commons-io display : 1 GB > Appears to be more than just a rounddown, because it will knock over 3 gig to > 2 gig as well. Odd stuff. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1243) The admin System handler page (and others like it) should not be cached
The admin System handler page (and others like it) should not be cached --- Key: SOLR-1243 URL: https://issues.apache.org/jira/browse/SOLR-1243 Project: Solr Issue Type: Bug Reporter: Mark Miller Priority: Minor appears the pages are cached now, so if you want to refresh the info you have to clear your browser cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1243) The admin System handler page (and others like it) should not be cached
[ https://issues.apache.org/jira/browse/SOLR-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1243: -- Fix Version/s: 1.4 > The admin System handler page (and others like it) should not be cached > --- > > Key: SOLR-1243 > URL: https://issues.apache.org/jira/browse/SOLR-1243 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Priority: Minor > Fix For: 1.4 > > > appears the pages are cached now, so if you want to refresh the info you have > to clear your browser cache. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1242) The admin System handler returns bad JVM info
[ https://issues.apache.org/jira/browse/SOLR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723643#action_12723643 ] Mark Miller commented on SOLR-1242: --- Nevermind. It is a round down issue. A bit over 3 gig in bytes just works out to round down to 2gig I guess. Anyway, when dealing with gb, just dropping the remainder (no round up) is not good. Rounding in general is not great. Gimme at least one decimal point :) I'll work up a patch. > The admin System handler returns bad JVM info > - > > Key: SOLR-1242 > URL: https://issues.apache.org/jira/browse/SOLR-1242 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.4 > > > FileUtils.byteCountToDisplaySize has a funny way of converting. > runtime.maxMemory() : 2092236800 bytes > commons-io display : 1 GB > Appears to be more than just a rounddown, because it will knock over 3 gig to > 2 gig as well. Odd stuff. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1242) The admin System handler returns bad JVM info
[ https://issues.apache.org/jira/browse/SOLR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723642#action_12723642 ] Mark Miller commented on SOLR-1242: --- Reported by Jay Hill. > The admin System handler returns bad JVM info > - > > Key: SOLR-1242 > URL: https://issues.apache.org/jira/browse/SOLR-1242 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Priority: Minor > Fix For: 1.4 > > > FileUtils.byteCountToDisplaySize has a funny way of converting. > runtime.maxMemory() : 2092236800 bytes > commons-io display : 1 GB > Appears to be more than just a rounddown, because it will knock over 3 gig to > 2 gig as well. Odd stuff. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1242) The admin System handler returns bad JVM info
[ https://issues.apache.org/jira/browse/SOLR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-1242: - Assignee: Mark Miller > The admin System handler returns bad JVM info > - > > Key: SOLR-1242 > URL: https://issues.apache.org/jira/browse/SOLR-1242 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Minor > Fix For: 1.4 > > > FileUtils.byteCountToDisplaySize has a funny way of converting. > runtime.maxMemory() : 2092236800 bytes > commons-io display : 1 GB > Appears to be more than just a rounddown, because it will knock over 3 gig to > 2 gig as well. Odd stuff. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1242) The admin System handler returns bad JVM info
The admin System handler returns bad JVM info - Key: SOLR-1242 URL: https://issues.apache.org/jira/browse/SOLR-1242 Project: Solr Issue Type: Bug Reporter: Mark Miller Priority: Minor Fix For: 1.4 FileUtils.byteCountToDisplaySize has a funny way of converting. runtime.maxMemory() : 2092236800 bytes commons-io display : 1 GB Appears to be more than just a rounddown, because it will knock over 3 gig to 2 gig as well. Odd stuff. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1145) Patch to set IndexWriter.defaultInfoStream from solr.xml
[ https://issues.apache.org/jira/browse/SOLR-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723586#action_12723586 ] Mark Miller commented on SOLR-1145: --- +1 > Patch to set IndexWriter.defaultInfoStream from solr.xml > > > Key: SOLR-1145 > URL: https://issues.apache.org/jira/browse/SOLR-1145 > Project: Solr > Issue Type: Improvement >Reporter: Chris Harris >Assignee: Mark Miller > Fix For: 1.4 > > Attachments: SOLR-1145.patch, SOLR-1145.patch, SOLR-1145.patch, > SOLR-1145.patch > > > Lucene IndexWriters use an infoStream to log detailed info about indexing > operations for debugging purpose. This patch is an extremely simple way to > allow logging this info to a file from within Solr: After applying the patch, > set the new "defaultInfoStreamFilePath" attribute of the solr element in > solr.xml to the path of the file where you'd like to save the logging > information. > Note that, in a multi-core setup, all cores will end up logging to the same > infoStream log file. This may not be desired. (But it does justify putting > the setting in solr.xml rather than solrconfig.xml.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1198) confine all solrconfig.xml parsing to SolrConfig.java
[ https://issues.apache.org/jira/browse/SOLR-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1198: -- Fix Version/s: 1.4 > confine all solrconfig.xml parsing to SolrConfig.java > - > > Key: SOLR-1198 > URL: https://issues.apache.org/jira/browse/SOLR-1198 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch, > SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch, SOLR-1198.patch > > > Currently , xpath evaluations are spread across Solr code. It would be > cleaner if if can do it all in one place . All the parsing can be done in > SolrConfig.java > another problem with the current design is that we are not able to benefit > from re-use of solrconfig object across cores. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1145) Patch to set IndexWriter.defaultInfoStream from solr.xml
[ https://issues.apache.org/jira/browse/SOLR-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723584#action_12723584 ] Noble Paul commented on SOLR-1145: -- I am moving all the xpath reading to solrconfig. I guess this too can go to solrconfig. SOLR-1198 > Patch to set IndexWriter.defaultInfoStream from solr.xml > > > Key: SOLR-1145 > URL: https://issues.apache.org/jira/browse/SOLR-1145 > Project: Solr > Issue Type: Improvement >Reporter: Chris Harris >Assignee: Mark Miller > Fix For: 1.4 > > Attachments: SOLR-1145.patch, SOLR-1145.patch, SOLR-1145.patch, > SOLR-1145.patch > > > Lucene IndexWriters use an infoStream to log detailed info about indexing > operations for debugging purpose. This patch is an extremely simple way to > allow logging this info to a file from within Solr: After applying the patch, > set the new "defaultInfoStreamFilePath" attribute of the solr element in > solr.xml to the path of the file where you'd like to save the logging > information. > Note that, in a multi-core setup, all cores will end up logging to the same > infoStream log file. This may not be desired. (But it does justify putting > the setting in solr.xml rather than solrconfig.xml.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1145) Patch to set IndexWriter.defaultInfoStream from solr.xml
[ https://issues.apache.org/jira/browse/SOLR-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-1145: - Assignee: Mark Miller > Patch to set IndexWriter.defaultInfoStream from solr.xml > > > Key: SOLR-1145 > URL: https://issues.apache.org/jira/browse/SOLR-1145 > Project: Solr > Issue Type: Improvement >Reporter: Chris Harris >Assignee: Mark Miller > Fix For: 1.4 > > Attachments: SOLR-1145.patch, SOLR-1145.patch, SOLR-1145.patch, > SOLR-1145.patch > > > Lucene IndexWriters use an infoStream to log detailed info about indexing > operations for debugging purpose. This patch is an extremely simple way to > allow logging this info to a file from within Solr: After applying the patch, > set the new "defaultInfoStreamFilePath" attribute of the solr element in > solr.xml to the path of the file where you'd like to save the logging > information. > Note that, in a multi-core setup, all cores will end up logging to the same > infoStream log file. This may not be desired. (But it does justify putting > the setting in solr.xml rather than solrconfig.xml.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Solr 1.4
How are we feeling about Solr 1.4? We have about 35 bugs in JIRA for 1.4 with about half assigned (though a good chunk of those probably really do have an assignee). -- - Mark http://www.lucidimagination.com
[jira] Updated: (SOLR-1145) Patch to set IndexWriter.defaultInfoStream from solr.xml
[ https://issues.apache.org/jira/browse/SOLR-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1145: -- Attachment: SOLR-1145.patch Changes made plus some other polish/finish > Patch to set IndexWriter.defaultInfoStream from solr.xml > > > Key: SOLR-1145 > URL: https://issues.apache.org/jira/browse/SOLR-1145 > Project: Solr > Issue Type: Improvement >Reporter: Chris Harris > Fix For: 1.4 > > Attachments: SOLR-1145.patch, SOLR-1145.patch, SOLR-1145.patch, > SOLR-1145.patch > > > Lucene IndexWriters use an infoStream to log detailed info about indexing > operations for debugging purpose. This patch is an extremely simple way to > allow logging this info to a file from within Solr: After applying the patch, > set the new "defaultInfoStreamFilePath" attribute of the solr element in > solr.xml to the path of the file where you'd like to save the logging > information. > Note that, in a multi-core setup, all cores will end up logging to the same > infoStream log file. This may not be desired. (But it does justify putting > the setting in solr.xml rather than solrconfig.xml.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-1229) deletedPkQuery feature does not work when pk and uniqueKey field do not have the same value
On Wed, Jun 24, 2009 at 4:05 PM, Erik Hatcher wrote: > > But... since transformations are applied, solr_id will be in that map too, > which is the uniqueKey value. Problem solved! :) > Erik, the most common use-case is the name of the table's primary key being different from Solr's uniqueKey. We should not force the user to write a Transformer to convert between them. This was the motivation behind keeping the pk attribute. I don't think pk should be removed at all. -- Regards, Shalin Shekhar Mangar.
[jira] Closed: (SOLR-1239) org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest FAILED
[ https://issues.apache.org/jira/browse/SOLR-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul closed SOLR-1239. Resolution: Fixed this got resolved as part of SOLR-1214 > org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest FAILED > -- > > Key: SOLR-1239 > URL: https://issues.apache.org/jira/browse/SOLR-1239 > Project: Solr > Issue Type: Bug >Reporter: Noble Paul > Fix For: 1.4 > > > this testcase fails -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-1229) deletedPkQuery feature does not work when pk and uniqueKey field do not have the same value
On Jun 24, 2009, at 12:28 AM, Noble Paul (JIRA) wrote:
let me explain with the above example .
{code:java}
// this code is taken from your patch
SchemaField uniqueKeyField =
dataImporter.getSchema().getUniqueKeyField();
// now the value of uniqueKeyField is 'solr_id'
if (uniqueKeyField == null) return;
Object key = map.get(uniqueKeyField.getName());
//the map contains {"db_id"-> "12345"}
//so key == null; and it will do nothing and return
// on the contrary if you set the pk="db_id" , then it works
But... since transformations are applied, solr_id will be in that map
too, which is the uniqueKey value. Problem solved! :)
Erik
[jira] Resolved: (SOLR-1214) differentiate between solr home and instanceDir
[ https://issues.apache.org/jira/browse/SOLR-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-1214. - Resolution: Fixed Committed revision 787967. > differentiate between solr home and instanceDir > --- > > Key: SOLR-1214 > URL: https://issues.apache.org/jira/browse/SOLR-1214 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1214.patch, SOLR-1214.patch, SOLR-1214.patch > > > There is a lot of confusion on what is an instanceDir in a multicore system. > The CoreContainer must have a field for solrHome and the instanceDir for > each core should be specific to that core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1214) differentiate between solr home and instanceDir
[ https://issues.apache.org/jira/browse/SOLR-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723519#action_12723519 ] Shalin Shekhar Mangar edited comment on SOLR-1214 at 6/24/09 3:24 AM: -- Changes: # Remove the CoreContainer(String home) constructor and un-deprecated the default no-param constructor # Initialize solrHome in CoreContainer() and CoreContainer(SolrResourceLoader loader) and CoreContainer#load() methods to tackle cases where solrHome is not set or load is called with a different directory than solrHome. # Use SolrResourceLoader#locateSolrHome instead of the deprecated locateInstanceDir method All tests pass. I'll commit this shortly. was (Author: shalinmangar): Changes: # Remove the CoreContainer(String home) constructor # Initialize solrHome in CoreContainer() and CoreContainer(SolrResourceLoader loader) and CoreContainer#load() methods to tackle cases where solrHome is not set or load is called with a different directory than solrHome. # Use SolrResourceLoader#locateSolrHome instead of the deprecated locateInstanceDir method All tests pass. I'll commit this shortly. > differentiate between solr home and instanceDir > --- > > Key: SOLR-1214 > URL: https://issues.apache.org/jira/browse/SOLR-1214 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1214.patch, SOLR-1214.patch, SOLR-1214.patch > > > There is a lot of confusion on what is an instanceDir in a multicore system. > The CoreContainer must have a field for solrHome and the instanceDir for > each core should be specific to that core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1214) differentiate between solr home and instanceDir
[ https://issues.apache.org/jira/browse/SOLR-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-1214: Attachment: SOLR-1214.patch Changes: # Remove the CoreContainer(String home) constructor # Initialize solrHome in CoreContainer() and CoreContainer(SolrResourceLoader loader) and CoreContainer#load() methods to tackle cases where solrHome is not set or load is called with a different directory than solrHome. # Use SolrResourceLoader#locateSolrHome instead of the deprecated locateInstanceDir method All tests pass. I'll commit this shortly. > differentiate between solr home and instanceDir > --- > > Key: SOLR-1214 > URL: https://issues.apache.org/jira/browse/SOLR-1214 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1214.patch, SOLR-1214.patch, SOLR-1214.patch > > > There is a lot of confusion on what is an instanceDir in a multicore system. > The CoreContainer must have a field for solrHome and the instanceDir for > each core should be specific to that core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SOLR-1214) differentiate between solr home and instanceDir
[ https://issues.apache.org/jira/browse/SOLR-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reopened SOLR-1214: - Re-opening because of test failures in MultiCoreEmbeddedTest, MergeIndexesEmbeddedTest and TestReplicationHandler due to incorrect solr home path (SOLR-1239) > differentiate between solr home and instanceDir > --- > > Key: SOLR-1214 > URL: https://issues.apache.org/jira/browse/SOLR-1214 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1214.patch, SOLR-1214.patch > > > There is a lot of confusion on what is an instanceDir in a multicore system. > The CoreContainer must have a field for solrHome and the instanceDir for > each core should be specific to that core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Build failed in Hudson: Solr-trunk #842
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/842/ -- [...truncated 2185 lines...] [junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 0.527 sec [junit] Running org.apache.solr.analysis.TestMappingCharFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.436 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.481 sec [junit] Running org.apache.solr.analysis.TestPatternTokenizerFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.17 sec [junit] Running org.apache.solr.analysis.TestPhoneticFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.344 sec [junit] Running org.apache.solr.analysis.TestRemoveDuplicatesTokenFilter [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.584 sec [junit] Running org.apache.solr.analysis.TestStopFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.969 sec [junit] Running org.apache.solr.analysis.TestSynonymFilter [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 2.564 sec [junit] Running org.apache.solr.analysis.TestSynonymMap [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.893 sec [junit] Running org.apache.solr.analysis.TestTrimFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.135 sec [junit] Running org.apache.solr.analysis.TestWordDelimiterFilter [junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 12.675 sec [junit] Running org.apache.solr.client.solrj.SolrExceptionTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.136 sec [junit] Running org.apache.solr.client.solrj.SolrQueryTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.403 sec [junit] Running org.apache.solr.client.solrj.TestBatchUpdate [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 9.884 sec [junit] Running org.apache.solr.client.solrj.TestLBHttpSolrServer [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.616 sec [junit] Running org.apache.solr.client.solrj.beans.TestDocumentObjectBinder [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.451 sec [junit] Running org.apache.solr.client.solrj.embedded.JettyWebappTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 6.371 sec [junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.612 sec [junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeEmbeddedTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.324 sec [junit] Running org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 5.157 sec [junit] Running org.apache.solr.client.solrj.embedded.MergeIndexesEmbeddedTest [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.116 sec [junit] Test org.apache.solr.client.solrj.embedded.MergeIndexesEmbeddedTest FAILED [junit] Running org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 1.755 sec [junit] Test org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest FAILED [junit] Running org.apache.solr.client.solrj.embedded.MultiCoreExampleJettyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4.154 sec [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleEmbeddedTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 10.021 sec [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleJettyTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 14.897 sec [junit] Running org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 17.148 sec [junit] Running org.apache.solr.client.solrj.embedded.TestSolrProperties [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.263 sec [junit] Running org.apache.solr.client.solrj.request.TestUpdateRequestCodec [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.478 sec [junit] Running org.apache.solr.client.solrj.response.AnlysisResponseBaseTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.424 sec [junit] Running org.apache.solr.client.solrj.response.DocumentAnalysisResponseTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.645 sec [junit] Running org.apache.solr.client.solrj.response.FieldAnalysisResponseTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.495 sec [junit] Running org.apache.solr.client.solrj.response.QueryResponseTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed:
Solr nightly build failure
init-forrest-entities: [mkdir] Created dir: /tmp/apache-solr-nightly/build [mkdir] Created dir: /tmp/apache-solr-nightly/build/web compile-solrj: [mkdir] Created dir: /tmp/apache-solr-nightly/build/solrj [javac] Compiling 83 source files to /tmp/apache-solr-nightly/build/solrj [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile: [mkdir] Created dir: /tmp/apache-solr-nightly/build/solr [javac] Compiling 375 source files to /tmp/apache-solr-nightly/build/solr [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compileTests: [mkdir] Created dir: /tmp/apache-solr-nightly/build/tests [javac] Compiling 162 source files to /tmp/apache-solr-nightly/build/tests [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. junit: [mkdir] Created dir: /tmp/apache-solr-nightly/build/test-results [junit] Running org.apache.solr.BasicFunctionalityTest [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 17.577 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 8.149 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 5.307 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 2.535 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 2.593 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.403 sec [junit] Running org.apache.solr.SolrInfoMBeanTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.917 sec [junit] Running org.apache.solr.TestDistributedSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 26.422 sec [junit] Running org.apache.solr.TestTrie [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 11.792 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.416 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.443 sec [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.683 sec [junit] Running org.apache.solr.analysis.HTMLStripReaderTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.241 sec [junit] Running org.apache.solr.analysis.LengthFilterTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.276 sec [junit] Running org.apache.solr.analysis.SnowballPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.446 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.07 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.824 sec [junit] Running org.apache.solr.analysis.TestCharFilter [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.509 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.485 sec [junit] Running org.apache.solr.analysis.TestKeepFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.57 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.711 sec [junit] Running org.apache.solr.analysis.TestMappingCharFilter [junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 0.688 sec [junit] Running org.apache.solr.analysis.TestMappingCharFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.538 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.629 sec [junit] Running org.apache.solr.analysis.TestPatternTokenizerFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.307 sec [junit] Running org.apache.solr.analysis.TestPhoneticFilter
[jira] Commented: (SOLR-1239) org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest FAILED
[ https://issues.apache.org/jira/browse/SOLR-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723489#action_12723489 ] Shalin Shekhar Mangar commented on SOLR-1239: - Both MultiCoreEmbeddedTest and MergeIndexesEmbeddedTest fail because cores are being loaded from the wrong directory after SOLR-1214 This happens because the TestHarness creates a CoreContainer using the current working directory as the solrHome. Now these multicore tests call CoreContainer#load specifying a directory from which config is to be loaded. The failure happens when a core is loaded using solrHome (current working directory) in the CoreContainer#create method. The CoreContainer#load needs to use loader.getInstanceDir instead of solrHome. In fact I think solrHome should be set in CoreContainer#load using loader.getInstanceDir to handle such cases. > org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest FAILED > -- > > Key: SOLR-1239 > URL: https://issues.apache.org/jira/browse/SOLR-1239 > Project: Solr > Issue Type: Bug >Reporter: Noble Paul > Fix For: 1.4 > > > this testcase fails -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
