[jira] [Updated] (SOLR-4474) The collection status API allows to get a comprehensive status information of one collection.
[
https://issues.apache.org/jira/browse/SOLR-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
milesli updated SOLR-4474:
--
Description:
api : http://ip:port/solr/admin/collections?action=status&collection=collection1
result:
{"responseHeader":{"status":0,"QTime":3812},
"collection":{"collection1":{
"index":{"leadSizeInBytes":65,"leadSize":"0.0634765625kb"},
"docs":{"numDocs":0,"maxDoc":0},
"shards":{
"shard1":["collection1",{
"routing"{
"shard":"shard1",
"roles":null,
"state":"active",
"core":"collection1",
"collection":"collection1",
"node_name":"10.224.202.81:8080_solr",
"base_url":"http://10.224.202.81:8080/solr";,
"leader":"true"},
"index"{
"numDocs":0,
"maxDoc":0,
"version":1,
"segmentCount":0,
"current":true,
"hasDeletions":false,
"directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(org.apache.lucene.store.SimpleFSDirectory@E:\\workspace\\ws_red5\\csp\\example\\solr\\collection1\\data\\index
lockFactory=org.apache.lucene.store.NativeFSLockFactory@14cdfcf;
maxCacheMB=48.0
maxMergeSizeMB=4.0)","userData":{},"sizeInBytes":1271,"size":"1.24 KB"}
}
]
}
}
}
}
was:
api : http://ip:port/solr/admin/collections?action=status&collection=collection1
result:
{ "responseHeader":{"status":0,"QTime":3812},
"collection":{"collection1":{
"index":{"leadSizeInBytes":65,"leadSize":"0.0634765625kb"},
"docs":{"numDocs":0,"maxDoc":0},
"shards":{
"shard1":["collection1",{
"routing"{
"shard":"shard1",
"roles":null,
"state":"active",
"core":"collection1",
"collection":"collection1",
"node_name":"10.224.202.81:8080_solr",
"base_url":"http://10.224.202.81:8080/solr";,
"leader":"true"},
"index"{
"numDocs":0,
"maxDoc":0,
"version":1,
"segmentCount":0,
"current":true,
"hasDeletions":false,
"directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(org.apache.lucene.store.SimpleFSDirectory@E:\\workspace\\ws_red5\\csp\\example\\solr\\collection1\\data\\index
lockFactory=org.apache.lucene.store.NativeFSLockFactory@14cdfcf;
maxCacheMB=48.0
maxMergeSizeMB=4.0)","userData":{},"sizeInBytes":1271,"size":"1.24 KB"}
}
}
}
}
> The collection status API allows to get a comprehensive status information of
> one collection.
> -
>
> Key: SOLR-4474
> URL: https://issues.apache.org/jira/browse/SOLR-4474
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 4.1
>Reporter: milesli
> Attachments: CollectionParams.patch, CollectionsHandler.patch
>
>
> api :
> http://ip:port/solr/admin/collections?action=status&collection=collection1
> result:
> {"responseHeader":{"status":0,"QTime":3812},
> "collection":{"collection1":{
> "index":{"leadSizeInBytes":65,"leadSize":"0.0634765625kb"},
> "docs":{"numDocs":0,"maxDoc":0},
> "shards":{
> "shard1":["collection1",{
> "routing"{
> "shard":"shard1",
> "roles":null,
> "state":"active",
> "core":"collection1",
> "collection":"collection1",
> "node_name":"10.224.202.81:8080_solr",
> "base_url":"http://10.224.202.81:8080/solr";,
> "leader":"true"},
> "index"{
> "numDocs":0,
> "maxDoc":0,
> "version":1,
> "segmentCount":0,
> "current
[jira] [Updated] (SOLR-4474) The collection status API allows to get a comprehensive status information of one collection.
[
https://issues.apache.org/jira/browse/SOLR-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
milesli updated SOLR-4474:
--
Description:
api : http://ip:port/solr/admin/collections?action=status&collection=collection1
result:
{ "responseHeader":{"status":0,"QTime":3812},
"collection":{"collection1":{
"index":{"leadSizeInBytes":65,"leadSize":"0.0634765625kb"},
"docs":{"numDocs":0,"maxDoc":0},
"shards":{
"shard1":["collection1",{
"routing"{
"shard":"shard1",
"roles":null,
"state":"active",
"core":"collection1",
"collection":"collection1",
"node_name":"10.224.202.81:8080_solr",
"base_url":"http://10.224.202.81:8080/solr";,
"leader":"true"},
"index"{
"numDocs":0,
"maxDoc":0,
"version":1,
"segmentCount":0,
"current":true,
"hasDeletions":false,
"directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(org.apache.lucene.store.SimpleFSDirectory@E:\\workspace\\ws_red5\\csp\\example\\solr\\collection1\\data\\index
lockFactory=org.apache.lucene.store.NativeFSLockFactory@14cdfcf;
maxCacheMB=48.0
maxMergeSizeMB=4.0)","userData":{},"sizeInBytes":1271,"size":"1.24 KB"}
}
}
}
}
> The collection status API allows to get a comprehensive status information of
> one collection.
> -
>
> Key: SOLR-4474
> URL: https://issues.apache.org/jira/browse/SOLR-4474
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 4.1
>Reporter: milesli
> Attachments: CollectionParams.patch, CollectionsHandler.patch
>
>
> api :
> http://ip:port/solr/admin/collections?action=status&collection=collection1
> result:
> { "responseHeader":{"status":0,"QTime":3812},
> "collection":{"collection1":{
>
> "index":{"leadSizeInBytes":65,"leadSize":"0.0634765625kb"},
> "docs":{"numDocs":0,"maxDoc":0},
> "shards":{
> "shard1":["collection1",{
> "routing"{
> "shard":"shard1",
> "roles":null,
> "state":"active",
> "core":"collection1",
> "collection":"collection1",
> "node_name":"10.224.202.81:8080_solr",
>
> "base_url":"http://10.224.202.81:8080/solr";,
> "leader":"true"},
> "index"{
> "numDocs":0,
> "maxDoc":0,
> "version":1,
> "segmentCount":0,
> "current":true,
> "hasDeletions":false,
>
> "directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(org.apache.lucene.store.SimpleFSDirectory@E:\\workspace\\ws_red5\\csp\\example\\solr\\collection1\\data\\index
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@14cdfcf;
> maxCacheMB=48.0
> maxMergeSizeMB=4.0)","userData":{},"sizeInBytes":1271,"size":"1.24 KB"}
> }
> }
> }
> }
--
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-4474) The collection status API allows to get a comprehensive status information of one collection.
[ https://issues.apache.org/jira/browse/SOLR-4474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] milesli updated SOLR-4474: -- Attachment: CollectionParams.patch CollectionsHandler.patch > The collection status API allows to get a comprehensive status information of > one collection. > - > > Key: SOLR-4474 > URL: https://issues.apache.org/jira/browse/SOLR-4474 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.1 >Reporter: milesli > Attachments: CollectionParams.patch, CollectionsHandler.patch > > -- 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-669) SOLR currently does not support caching for (Query, FacetFieldList)
[ https://issues.apache.org/jira/browse/SOLR-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581976#comment-13581976 ] Gunnar Wagenknecht commented on SOLR-669: - This bug is closed as duplicate but I can't actually see a link to the other issue this one duplicates. It would be nice if such a link can be added. > SOLR currently does not support caching for (Query, FacetFieldList) > --- > > Key: SOLR-669 > URL: https://issues.apache.org/jira/browse/SOLR-669 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Fuad Efendi > Original Estimate: 1,680h > Remaining Estimate: 1,680h > > It is huge performance bottleneck and it describes huge difference between > qtime and SolrJ's elapsedTime. I quickly browsed SolrIndexSearcher: it caches > only (Key, DocSet/DocList ) key-value pairs and it does not have > cache for (Query, FacetFieldList). > filterCache stores DocList for each 'filter' and is used for constant > recalculations... > This would be significant performance improvement. -- 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-4475) CachingDirectoryFactory uses File#getAbsolutePath when it should use DirectoryFactory#normalize
Mark Miller created SOLR-4475: - Summary: CachingDirectoryFactory uses File#getAbsolutePath when it should use DirectoryFactory#normalize Key: SOLR-4475 URL: https://issues.apache.org/jira/browse/SOLR-4475 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 4.2, 5.0 Not really a big deal the way it's used, but this is much more logical to the current design. -- 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-1632) Distributed IDF
[ https://issues.apache.org/jira/browse/SOLR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581945#comment-13581945 ] Mark Miller commented on SOLR-1632: --- Nice. I mentioned this to AB not too long ago, but I'm of the mind to simply commit this. It will default to off, and we can continue to work on it. So unless someone steps in, I'll commit what Markus has put up. Markus, have you tried this out at all beyond the unit tests - eg on a cluster? > Distributed IDF > --- > > Key: SOLR-1632 > URL: https://issues.apache.org/jira/browse/SOLR-1632 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.5 >Reporter: Andrzej Bialecki > Fix For: 5.0 > > Attachments: 3x_SOLR-1632_doesntwork.patch, distrib-2.patch, > distrib.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch > > > Distributed IDF is a valuable enhancement for distributed search across > non-uniform shards. This issue tracks the proposed implementation of an API > to support this functionality in Solr. -- 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-4260) Inconsistent numDocs between leader and replica
[ https://issues.apache.org/jira/browse/SOLR-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581942#comment-13581942 ] Mark Miller commented on SOLR-4260: --- No interesting exceptions in the logs? Perhaps dial them up to warn and run? > Inconsistent numDocs between leader and replica > --- > > Key: SOLR-4260 > URL: https://issues.apache.org/jira/browse/SOLR-4260 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 5.0 > Environment: 5.0.0.2013.01.04.15.31.51 >Reporter: Markus Jelsma >Priority: Critical > Fix For: 5.0 > > > After wiping all cores and reindexing some 3.3 million docs from Nutch using > CloudSolrServer we see inconsistencies between the leader and replica for > some shards. > Each core hold about 3.3k documents. For some reason 5 out of 10 shards have > a small deviation in then number of documents. The leader and slave deviate > for roughly 10-20 documents, not more. > Results hopping ranks in the result set for identical queries got my > attention, there were small IDF differences for exactly the same record > causing a record to shift positions in the result set. During those tests no > records were indexed. Consecutive catch all queries also return different > number of numDocs. > We're running a 10 node test cluster with 10 shards and a replication factor > of two and frequently reindex using a fresh build from trunk. I've not seen > this issue for quite some time until a few days ago. -- 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-4464) DIH - Processed documents counter resets to zero after first database request
[ https://issues.apache.org/jira/browse/SOLR-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581936#comment-13581936 ] Shawn Heisey commented on SOLR-4464: This is most likely due to basic operating system design. It's normal for all modern operating systems to utilize all physical memory. The memory that is not used for programs gets used by the OS to cache data on the disk for performance reasons. If a program or the OS requests additional memory, the OS will happily and instantly give up the lowest priority cache data to satisfy the memory request. Your Solr admin page seems to be locked up while trying to load the dashboard, so I can't see the actual numbers. I hope everything is OK. > DIH - Processed documents counter resets to zero after first database request > - > > Key: SOLR-4464 > URL: https://issues.apache.org/jira/browse/SOLR-4464 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 4.1 > Environment: CentOS 6.3 x64 / apache-tomcat-7.0.35 / > mysql-connector-java-5.1.23 - Large machine 5TB of drives and 280GB RAM - > Java Heap set to 250Gb - resources are not an issue. >Reporter: Dave Cook >Priority: Minor > Labels: patch > > [11:20] Solr 4.1 - Processed documents resets to 0 after > processing my first entity - all database schemas are identical > [11:21] However, all the documents get fetched and I can query > the results no problem. > Here's a link to a screenshot - http://findocs/gridworkz.com/solr > Everything works perfect except the screen doesn't increment the "Processed" > counter on subsequent database Requests. -- 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-4474) The collection status API allows to get a comprehensive status information of one collection.
milesli created SOLR-4474: - Summary: The collection status API allows to get a comprehensive status information of one collection. Key: SOLR-4474 URL: https://issues.apache.org/jira/browse/SOLR-4474 Project: Solr Issue Type: New Feature Affects Versions: 4.1 Reporter: milesli -- 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-4.x-Linux (32bit/jdk1.8.0-ea-b65) - Build # 4365 - Failure!
On Tue, Feb 19, 2013 at 3:38 PM, Policeman Jenkins Server wrote: > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4365/ > Java: 32bit/jdk1.8.0-ea-b65 -server -XX:+UseG1GC > > 38 tests failed. jvm bug (the entire slave's state became corrupt, as before). Hopefully we can upgrade jdk 1.8 soon - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4473) Reloading a core will not close (leak) associated DIH JDBC connection
[ https://issues.apache.org/jira/browse/SOLR-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581772#comment-13581772 ] Alexandre Rafalovitch commented on SOLR-4473: - My top of config: I can provide a full core zip if it is too hard to replicate from the above description. > Reloading a core will not close (leak) associated DIH JDBC connection > - > > Key: SOLR-4473 > URL: https://issues.apache.org/jira/browse/SOLR-4473 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 4.1 >Reporter: Alexandre Rafalovitch > Fix For: 4.2 > > > I have DIH configured with Derby database. After I start Solr, I can run DIH > import fine. After I reload the core, DIH can no longer run with the > following message (excerpts): > ... > EVERE: Exception while processing: vac document : > SolrInputDocument[]:org.apache.solr.handler.dataimport.DataImportHandlerException: > Unable to execute query: select * from ALERTS Processing Document # 1 > at > org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:71) > at > org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.(JdbcDataSource.java:253) > at > org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:210) > at > org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:38) > at > org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:59) > at > org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:73) > at > org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:243) > at > org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:465) > Caused by: java.sql.SQLException: Another instance of Derby may have already > booted the database . -- 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] [Comment Edited] (SOLR-4473) Reloading a core will not close (leak) associated DIH JDBC connection
[
https://issues.apache.org/jira/browse/SOLR-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581772#comment-13581772
]
Alexandre Rafalovitch edited comment on SOLR-4473 at 2/19/13 11:51 PM:
---
My top of config:
{code:xml}
{code}
I can provide a full core zip if it is too hard to replicate from the above
description.
was (Author: arafalov):
My top of config:
I can provide a full core zip if it is too hard to replicate from the above
description.
> Reloading a core will not close (leak) associated DIH JDBC connection
> -
>
> Key: SOLR-4473
> URL: https://issues.apache.org/jira/browse/SOLR-4473
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 4.1
>Reporter: Alexandre Rafalovitch
> Fix For: 4.2
>
>
> I have DIH configured with Derby database. After I start Solr, I can run DIH
> import fine. After I reload the core, DIH can no longer run with the
> following message (excerpts):
> ...
> EVERE: Exception while processing: vac document :
> SolrInputDocument[]:org.apache.solr.handler.dataimport.DataImportHandlerException:
> Unable to execute query: select * from ALERTS Processing Document # 1
> at
> org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:71)
> at
> org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.(JdbcDataSource.java:253)
> at
> org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:210)
> at
> org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:38)
> at
> org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:59)
> at
> org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:73)
> at
> org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:243)
> at
> org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:465)
> Caused by: java.sql.SQLException: Another instance of Derby may have already
> booted the database .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-894) Distributed Search in combination with fl=score returns inconsistent number of fields
[ https://issues.apache.org/jira/browse/SOLR-894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-894. Resolution: Cannot Reproduce Closing old issue, please re-open if necessary. Have not seen this bug in recent versions > Distributed Search in combination with fl=score returns inconsistent number > of fields > - > > Key: SOLR-894 > URL: https://issues.apache.org/jira/browse/SOLR-894 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 > Environment: Setup distributed search >Reporter: Mario Klaver >Priority: Minor > > 1) http://localhost:8983/solr/select?indent=true&q=ipod+solr > ==> Returns all configured fields > 2) http://localhost:8983/solr/select?indent=true&q=ipod+solr&fl=score > ==> Returns all configured fields + score > 3) > http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=ipod+solr > ==> Returns all configured fields > 4) > http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=ipod+solr&fl=score > ==> Returns unique ID and score field > Result 4) is inconsistent with result 2). > Solutions: > 1) Request 2) will only return score (in this case, also the java client > needs to be updated (query.addScoreField(true)) > 2) Request 4) will return all configured fields including score -- 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-4473) Reloading a core will not close (leak) associated DIH JDBC connection
[ https://issues.apache.org/jira/browse/SOLR-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandre Rafalovitch updated SOLR-4473: Description: I have DIH configured with Derby database. After I start Solr, I can run DIH import fine. After I reload the core, DIH can no longer run with the following message (excerpts): ... EVERE: Exception while processing: vac document : SolrInputDocument[]:org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to execute query: select * from ALERTS Processing Document # 1 at org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:71) at org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.(JdbcDataSource.java:253) at org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:210) at org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:38) at org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:59) at org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:73) at org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:243) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:465) Caused by: java.sql.SQLException: Another instance of Derby may have already booted the database . > Reloading a core will not close (leak) associated DIH JDBC connection > - > > Key: SOLR-4473 > URL: https://issues.apache.org/jira/browse/SOLR-4473 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 4.1 >Reporter: Alexandre Rafalovitch > Fix For: 4.2 > > > I have DIH configured with Derby database. After I start Solr, I can run DIH > import fine. After I reload the core, DIH can no longer run with the > following message (excerpts): > ... > EVERE: Exception while processing: vac document : > SolrInputDocument[]:org.apache.solr.handler.dataimport.DataImportHandlerException: > Unable to execute query: select * from ALERTS Processing Document # 1 > at > org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAndThrow(DataImportHandlerException.java:71) > at > org.apache.solr.handler.dataimport.JdbcDataSource$ResultSetIterator.(JdbcDataSource.java:253) > at > org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:210) > at > org.apache.solr.handler.dataimport.JdbcDataSource.getData(JdbcDataSource.java:38) > at > org.apache.solr.handler.dataimport.SqlEntityProcessor.initQuery(SqlEntityProcessor.java:59) > at > org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:73) > at > org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:243) > at > org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:465) > Caused by: java.sql.SQLException: Another instance of Derby may have already > booted the database . -- 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-4473) Reloading a core will not close (leak) associated DIH JDBC connection
Alexandre Rafalovitch created SOLR-4473: --- Summary: Reloading a core will not close (leak) associated DIH JDBC connection Key: SOLR-4473 URL: https://issues.apache.org/jira/browse/SOLR-4473 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 4.1 Reporter: Alexandre Rafalovitch Fix For: 4.2 -- 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-824) Remove references to removed "none" locking option
[ https://issues.apache.org/jira/browse/SOLR-824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581769#comment-13581769 ] Jan Høydahl commented on SOLR-824: -- This seems to be still relevant, yet no updates since 08 :) > Remove references to removed "none" locking option > -- > > Key: SOLR-824 > URL: https://issues.apache.org/jira/browse/SOLR-824 > Project: Solr > Issue Type: Task >Reporter: Lars Kotthoff >Priority: Minor > Attachments: SOLR-824.patch > > > The lock type "none", removed in SOLR-686, is still referenced in various > solrconfig.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-669) SOLR currently does not support caching for (Query, FacetFieldList)
[ https://issues.apache.org/jira/browse/SOLR-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-669. Resolution: Duplicate Closing old issue, please re-open if necessary. > SOLR currently does not support caching for (Query, FacetFieldList) > --- > > Key: SOLR-669 > URL: https://issues.apache.org/jira/browse/SOLR-669 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Fuad Efendi > Original Estimate: 1,680h > Remaining Estimate: 1,680h > > It is huge performance bottleneck and it describes huge difference between > qtime and SolrJ's elapsedTime. I quickly browsed SolrIndexSearcher: it caches > only (Key, DocSet/DocList ) key-value pairs and it does not have > cache for (Query, FacetFieldList). > filterCache stores DocList for each 'filter' and is used for constant > recalculations... > This would be significant performance improvement. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-527) An XML commit only request handler
[ https://issues.apache.org/jira/browse/SOLR-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-527. Resolution: Won't Fix Things have changed now with SolrCloud which needs to ADD docs to slaves. If you don't want to enable firewalls, then secure Solr with SSL auth instead, see SOLR-4470. Closing, please re-open if you feel this is still relevant. > An XML commit only request handler > -- > > Key: SOLR-527 > URL: https://issues.apache.org/jira/browse/SOLR-527 > Project: Solr > Issue Type: New Feature > Components: update >Affects Versions: 1.3 >Reporter: Sean Timm >Priority: Trivial > Attachments: ReadOnlyUpdateProcessorFactory.java, > ReadOnlyUpdateProcessorFactory.java, ReadOnlyUpdateProcessorFactory.java, > SOLR-527.patch > > > This request handler only permits messages. It is provided as one > way to prevent adds and deletes on a Solr slave machine that could > potentially be accessed by outside parties where a firewall or other access > control is either not possible or not desired. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-579) Extend SimplePost with RecurseDirectories, threads, document encoding , number of docs per commit
[ https://issues.apache.org/jira/browse/SOLR-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-579. Resolution: Won't Fix Closing old issue, please re-open if necessary. PS: Recursive and encoding already implemented. Discussions ongoing elsewhere whether to add threading or to refactor into a Simple and a ComplexPostTool :) > Extend SimplePost with RecurseDirectories, threads, document encoding , > number of docs per commit > - > > Key: SOLR-579 > URL: https://issues.apache.org/jira/browse/SOLR-579 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 > Environment: Applies to all platforms >Reporter: Patrick Debois >Priority: Minor > Original Estimate: 72h > Remaining Estimate: 72h > > -When specifying a directory, simplepost should read also the contents of a > directory > New options for the commandline (some only usefull in DATAMODE= files) > -RECURSEDIRS > Recursive read of directories as an option, this is usefull for > directories with a lot of files where the commandline expansion fails and > xargs is too slow > -DOCENCODING (default = system encoding or UTF-8) > For non utf-8 clients , simplepost should include a way to set the > encoding of the documents posted > -THREADSIZE (default =1 ) > For large volume posts, a threading pool makes sense , using JDK 1.5 > Threadpool model > -DOCSPERCOMMIT (default = 1) > Number of documents after which a commit is done, instead of only at > the end > Note: not to break the existing behaviour of the existing SimplePost tool > (post.sh) might be used in scripts -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-440) Should use longs for internal DateField storage
[ https://issues.apache.org/jira/browse/SOLR-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-440. Resolution: Duplicate This is fixed way back, closing. > Should use longs for internal DateField storage > --- > > Key: SOLR-440 > URL: https://issues.apache.org/jira/browse/SOLR-440 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.2, 1.3 >Reporter: Stu Hood > > The current DateField implementation uses formatted Strings internally to > store dates. > As a user creating a schema, I assumed that using the DateField type would be > more efficient than using an integer field to store seconds. In fact, the > DateField type is currently significantly less efficient: ~20 extra bytes are > required per value, and String sorting requires that all values fit in memory. > As soon as sorting on long fields has been implemented (SOLR-324), I'd > suggest that the date implementation be switched to use long values > internally, representing milliseconds since the epoch in UTC. Unfortunately, > this will cause index incompatibilities, so the schema version will need to > be bumped. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-526) moving ShardResponse to a publicly available class
[ https://issues.apache.org/jira/browse/SOLR-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-526. Resolution: Duplicate > moving ShardResponse to a publicly available class > -- > > Key: SOLR-526 > URL: https://issues.apache.org/jira/browse/SOLR-526 > Project: Solr > Issue Type: Wish > Components: search >Affects Versions: 1.3 >Reporter: patrik braun > > I'm working with the new federation code creating component for my > architecture and noticed that getting at individual ShardRepsonses is not > possible. Moving that to it's own public class would make outside development > much easier. -- 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-4196) Untangle XML-specific nature of Config and Container classes
[ https://issues.apache.org/jira/browse/SOLR-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-4196: - Attachment: SOLR-4196.patch OK, I finally figured out what was up with the failing BasicDistributedZkTest. Unfortunately, it was entirely due to the code changes in the rest of this patch, big surprise that . Persisting solr.xml is a pain. I doubt it had anything to do with the problem that seems to come up intermittently w/ that test but w/o this patch. Rats, I was hoping for a twofer. At any rate, after I run precommit now and hammer this patch with the stress test program, I intend to check this in to trunk sometime this week, let it bake for a while, and then merge it in to 4x. Next up is probably sharing schemas, maybe adding the stress test to the junit tests. > Untangle XML-specific nature of Config and Container classes > > > Key: SOLR-4196 > URL: https://issues.apache.org/jira/browse/SOLR-4196 > Project: Solr > Issue Type: Improvement > Components: Schema and Analysis >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Fix For: 4.2, 5.0 > > Attachments: SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, > SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, > SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, SOLR-4196.patch, > SOLR-4196.patch, StressTest.zip, StressTest.zip, StressTest.zip > > > sub-task for SOLR-4083. If we're going to try to obsolete solr.xml, we need > to pull all of the specific XML processing out of Config and Container. > Currently, we refer to xpaths all over the place. This JIRA is about > providing a thunking layer to isolate the XML-esque nature of solr.xml and > allow a simple properties file to be used instead which will lead, > eventually, to solr.xml going away. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-471) Distributed Solr Client
[ https://issues.apache.org/jira/browse/SOLR-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-471. Resolution: Duplicate Fix Version/s: 4.0-ALPHA Closing old issue, please re-open if necessary. No longer needed since SolrCloud implements this. > Distributed Solr Client > --- > > Key: SOLR-471 > URL: https://issues.apache.org/jira/browse/SOLR-471 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.3 >Reporter: Nguyen Kien Trung >Priority: Minor > Fix For: 4.0-ALPHA > > Attachments: distributedclient.patch > > > Inspired by memcached java clients. > The ability to update/search/delete among many solr instances > Client parametters: > - List of solr servers > - Number of replicas > Client functions: > - Update: using consistent hashing to determine what documents are going to > be stored in what server. Get the list of servers (equal to number of > replicas) and issue parallel UPDATE > - Search: parallel search all servers, aggregate distinct results > - Delete: parallel delete in all servers -- 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-4394) Add SSL tests and example configs
[ https://issues.apache.org/jira/browse/SOLR-4394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-4394. Resolution: Fixed Fix Version/s: 5.0 phase#2 patch committed to trunk: r1447885 CHANGES.txt updated on trunk to reflect 4x backmerge: r1447952 merge r1445971 + r1447885 + r1447952 to 4x: r1447956 > Add SSL tests and example configs > - > > Key: SOLR-4394 > URL: https://issues.apache.org/jira/browse/SOLR-4394 > Project: Solr > Issue Type: Improvement >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 4.2, 5.0 > > Attachments: SOLR-4394.patch, SOLR-4394.patch, SOLR-4394.patch, > SOLR-4394__phase2.patch > > > We should provide some examples of running Solr+Jetty with SSL enabled, and > have some basic tests using jetty over SSL -- 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-1632) Distributed IDF
[ https://issues.apache.org/jira/browse/SOLR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated SOLR-1632: -- Fix Version/s: 5.0 > Distributed IDF > --- > > Key: SOLR-1632 > URL: https://issues.apache.org/jira/browse/SOLR-1632 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.5 >Reporter: Andrzej Bialecki > Fix For: 5.0 > > Attachments: 3x_SOLR-1632_doesntwork.patch, distrib-2.patch, > distrib.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch > > > Distributed IDF is a valuable enhancement for distributed search across > non-uniform shards. This issue tracks the proposed implementation of an API > to support this functionality in Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-4407) SSL auth or basic auth in SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-4407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl closed SOLR-4407. - Resolution: Duplicate See SOLR-4470 > SSL auth or basic auth in SolrCloud > --- > > Key: SOLR-4407 > URL: https://issues.apache.org/jira/browse/SOLR-4407 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Affects Versions: 4.1 >Reporter: Sindre Fiskaa > Labels: Authentication, Certificate, SSL > Fix For: 4.2, 5.0 > > > I need to be able to secure sensitive information in solrnodes running in a > SolrCloud with either SSL client/server certificates or http basic auth.. -- 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-4464) DIH - Processed documents counter resets to zero after first database request
[ https://issues.apache.org/jira/browse/SOLR-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581669#comment-13581669 ] Dave Cook commented on SOLR-4464: - Hi Shawn: We're still going, however the physical memory is maxed out. Is that normal? http://76.72.160.178:8080/solr/#/ Cheers, Dave > DIH - Processed documents counter resets to zero after first database request > - > > Key: SOLR-4464 > URL: https://issues.apache.org/jira/browse/SOLR-4464 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 4.1 > Environment: CentOS 6.3 x64 / apache-tomcat-7.0.35 / > mysql-connector-java-5.1.23 - Large machine 5TB of drives and 280GB RAM - > Java Heap set to 250Gb - resources are not an issue. >Reporter: Dave Cook >Priority: Minor > Labels: patch > > [11:20] Solr 4.1 - Processed documents resets to 0 after > processing my first entity - all database schemas are identical > [11:21] However, all the documents get fetched and I can query > the results no problem. > Here's a link to a screenshot - http://findocs/gridworkz.com/solr > Everything works perfect except the screen doesn't increment the "Processed" > counter on subsequent database Requests. -- 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-4472) update javadocs for DateField, TrieDateField, and UUIDField to warn about using NEW/NOW default in SolrCloud
Hoss Man created SOLR-4472: -- Summary: update javadocs for DateField, TrieDateField, and UUIDField to warn about using NEW/NOW default in SolrCloud Key: SOLR-4472 URL: https://issues.apache.org/jira/browse/SOLR-4472 Project: Solr Issue Type: Improvement Reporter: Hoss Man Assignee: Hoss Man Fix For: 4.2 using defaults NEW in UUIDField, and NOW in DateField, probably wo't work the way people expect in SolrCloud ... SOLR-3495 added update processors to deal with these usecases in a better way, but I didn't think to updat the javadocs of UUIDField and DateField to point them out to people. -- 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 #251: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/251/ 1 tests failed. REGRESSION: org.apache.solr.cloud.SyncSliceTest.testDistribSearch Error Message: Test Setup Failure: shard1 should have just been set up to be inconsistent - but it's still consistent. Leader:http://127.0.0.1:25059/collection1skip list:[org.apache.solr.cloud.AbstractFullDistribZkTestBase$CloudJettyRunner@ad77aca2, org.apache.solr.cloud.AbstractFullDistribZkTestBase$CloudJettyRunner@dd16dc82] Stack Trace: java.lang.AssertionError: Test Setup Failure: shard1 should have just been set up to be inconsistent - but it's still consistent. Leader:http://127.0.0.1:25059/collection1skip list:[org.apache.solr.cloud.AbstractFullDistribZkTestBase$CloudJettyRunner@ad77aca2, org.apache.solr.cloud.AbstractFullDistribZkTestBase$CloudJettyRunner@dd16dc82] at __randomizedtesting.SeedInfo.seed([82067A7D80798C7E:3E0F465F726EC42]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:526) at org.apache.solr.cloud.SyncSliceTest.doTest(SyncSliceTest.java:216) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:794) 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:616) 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 com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) 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 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) 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(TestRu
Re: ApacheCon meetup
I've added a Lucene meetup to the Wednesday night meetup proposed schedule. I'm speaking on Wednesday morning. Let's get the word spread to the Portland tech community as well, making it a good way to bring in folks in the area that may not be also attending ApacheCon. Erik On Feb 19, 2013, at 13:35 , Chris Hostetter wrote: > > : Subject: ApacheCon meetup > : > : Any other Lucene/Solr enthusiasts attending ApacheCon in Portland next week? > > I won't make it to ApacheCon this year (first time in a long time > actually) but I'm fairly certain there will be a Lucene MeetUp of some > kind -- there always is. > > This is usually organized via the ApacheCon wiki, so interested > participants should sign up there... > > https://wiki.apache.org/apachecon/CommunityEventsNA13 > https://wiki.apache.org/apachecon/ApacheMeetupsNA13 > > > -Hoss > > - > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-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-4394) Add SSL tests and example configs
[ https://issues.apache.org/jira/browse/SOLR-4394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-4394: --- Attachment: SOLR-4394__phase2.patch Phase #2: promotes SSL randomization logic up to SolrJettyTestBase so all (non-distributed) jetty tests now randomly use SSL. i think this is solid, and ready to commit & backport to 4x > Add SSL tests and example configs > - > > Key: SOLR-4394 > URL: https://issues.apache.org/jira/browse/SOLR-4394 > Project: Solr > Issue Type: Improvement >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 4.2 > > Attachments: SOLR-4394.patch, SOLR-4394.patch, SOLR-4394.patch, > SOLR-4394__phase2.patch > > > We should provide some examples of running Solr+Jetty with SSL enabled, and > have some basic tests using jetty over SSL -- 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-1632) Distributed IDF
[ https://issues.apache.org/jira/browse/SOLR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Markus Jelsma updated SOLR-1632: Attachment: SOLR-1632.patch Updated patch to build for rev: 1447516 (Mon, 18 Feb 2013) All tests seem to pass. > Distributed IDF > --- > > Key: SOLR-1632 > URL: https://issues.apache.org/jira/browse/SOLR-1632 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.5 >Reporter: Andrzej Bialecki > Attachments: 3x_SOLR-1632_doesntwork.patch, distrib-2.patch, > distrib.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch > > > Distributed IDF is a valuable enhancement for distributed search across > non-uniform shards. This issue tracks the proposed implementation of an API > to support this functionality in Solr. -- 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-4383) DataImportHandler: Semantic inconsistency of column/name attribute
[ https://issues.apache.org/jira/browse/SOLR-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581288#comment-13581288 ] Alexandre Rafalovitch commented on SOLR-4383: - I can see this is marked for 5.0. If that's truly the case, the whole DIH documentation page needs to be refactored to avoid people just giving up on complex setups. Should I create a separate issue for that? > DataImportHandler: Semantic inconsistency of column/name attribute > -- > > Key: SOLR-4383 > URL: https://issues.apache.org/jira/browse/SOLR-4383 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler, documentation >Affects Versions: 4.1 >Reporter: Alexandre Rafalovitch > Fix For: 5.0 > > > Different DIH Entity Processor assign different meaning to 'column' > attribute. This can cause serious confusion to beginners but can also lead to > extremely hard to troubleshoot subtle bugs. -- 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] [Comment Edited] (SOLR-4383) DataImportHandler: Semantic inconsistency of column/name attribute
[
https://issues.apache.org/jira/browse/SOLR-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581286#comment-13581286
]
Alexandre Rafalovitch edited comment on SOLR-4383 at 2/19/13 2:01 PM:
--
This causes further confusion when using variable resolver (Wiki does not
help). In the example below, I have to have non-existant column names and then
I have to use _those_ names for my variable resolution.
{code:xml}
{code}
was (Author: arafalov):
This causes further confusion when using variable resolver (Wiki does not
help). In the example below, I have to have non-existant column names and then
I have to use _those_ names for my variable resolution.
{quote}
{quote}
> DataImportHandler: Semantic inconsistency of column/name attribute
> --
>
> Key: SOLR-4383
> URL: https://issues.apache.org/jira/browse/SOLR-4383
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler, documentation
>Affects Versions: 4.1
>Reporter: Alexandre Rafalovitch
> Fix For: 5.0
>
>
> Different DIH Entity Processor assign different meaning to 'column'
> attribute. This can cause serious confusion to beginners but can also lead to
> extremely hard to troubleshoot subtle bugs.
--
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] [Comment Edited] (SOLR-4383) DataImportHandler: Semantic inconsistency of column/name attribute
[
https://issues.apache.org/jira/browse/SOLR-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581286#comment-13581286
]
Alexandre Rafalovitch edited comment on SOLR-4383 at 2/19/13 2:00 PM:
--
This causes further confusion when using variable resolver (Wiki does not
help). In the example below, I have to have non-existant column names and then
I have to use _those_ names for my variable resolution.
{quote}
{quote}
was (Author: arafalov):
This causes further confusion when using variable resolver (Wiki does not
help). In the example below, I have to have non-existant column names and then
I have to use _those_ names for my variable resolution.
> DataImportHandler: Semantic inconsistency of column/name attribute
> --
>
> Key: SOLR-4383
> URL: https://issues.apache.org/jira/browse/SOLR-4383
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler, documentation
>Affects Versions: 4.1
>Reporter: Alexandre Rafalovitch
> Fix For: 5.0
>
>
> Different DIH Entity Processor assign different meaning to 'column'
> attribute. This can cause serious confusion to beginners but can also lead to
> extremely hard to troubleshoot subtle bugs.
--
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-4383) DataImportHandler: Semantic inconsistency of column/name attribute
[ https://issues.apache.org/jira/browse/SOLR-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581286#comment-13581286 ] Alexandre Rafalovitch commented on SOLR-4383: - This causes further confusion when using variable resolver (Wiki does not help). In the example below, I have to have non-existant column names and then I have to use _those_ names for my variable resolution. > DataImportHandler: Semantic inconsistency of column/name attribute > -- > > Key: SOLR-4383 > URL: https://issues.apache.org/jira/browse/SOLR-4383 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler, documentation >Affects Versions: 4.1 >Reporter: Alexandre Rafalovitch > Fix For: 5.0 > > > Different DIH Entity Processor assign different meaning to 'column' > attribute. This can cause serious confusion to beginners but can also lead to > extremely hard to troubleshoot subtle bugs. -- 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-4260) Inconsistent numDocs between leader and replica
[
https://issues.apache.org/jira/browse/SOLR-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13581189#comment-13581189
]
Markus Jelsma commented on SOLR-4260:
-
Here's the index information for two cores of the same shard, running on
different nodes.
{code}
0
1
117744
118160
416
3802
15
true
true
org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/opt/solr/cores/shard_h/data/index.20130211094737738
lockFactory=org.apache.lucene.store.NativeFSLockFactory@2ca7563d;
maxCacheMB=48.0 maxMergeSizeMB=4.0)
1361265544970
2013-02-19T09:19:04.97Z
{code}
{code}
0
0
117767
118181
414
3772
13
true
true
org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(org.apache.lucene.store.MMapDirectory@/opt/solr/cores/shard_h/data/index.20130211105622621
lockFactory=org.apache.lucene.store.NativeFSLockFactory@684b4388;
maxCacheMB=48.0 maxMergeSizeMB=4.0)
1361265544937
2013-02-19T09:19:04.937Z
{code}
We send updates/deletes to the cluster every 10-15 minutes. The shard will not
become synchronized, unless i remove the index of one of the nodes.
> Inconsistent numDocs between leader and replica
> ---
>
> Key: SOLR-4260
> URL: https://issues.apache.org/jira/browse/SOLR-4260
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 5.0
> Environment: 5.0.0.2013.01.04.15.31.51
>Reporter: Markus Jelsma
>Priority: Critical
> Fix For: 5.0
>
>
> After wiping all cores and reindexing some 3.3 million docs from Nutch using
> CloudSolrServer we see inconsistencies between the leader and replica for
> some shards.
> Each core hold about 3.3k documents. For some reason 5 out of 10 shards have
> a small deviation in then number of documents. The leader and slave deviate
> for roughly 10-20 documents, not more.
> Results hopping ranks in the result set for identical queries got my
> attention, there were small IDF differences for exactly the same record
> causing a record to shift positions in the result set. During those tests no
> records were indexed. Consecutive catch all queries also return different
> number of numDocs.
> We're running a 10 node test cluster with 10 shards and a replication factor
> of two and frequently reindex using a fresh build from trunk. I've not seen
> this issue for quite some time until a few days ago.
--
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] (LUCENE-4781) Backport classification module to branch_4x
Tommaso Teofili created LUCENE-4781: --- Summary: Backport classification module to branch_4x Key: LUCENE-4781 URL: https://issues.apache.org/jira/browse/LUCENE-4781 Project: Lucene - Core Issue Type: Task Components: modules/classification Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 4.2 Backport lucene/classification from trunk to branch_4x. -- 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] [Comment Edited] (SOLR-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580705#comment-13580705 ] Per Steffensen edited comment on SOLR-4470 at 2/19/13 8:06 AM: --- bq. Acording to HTTP-URL syntax, you can give the basic auth params using http://user:password@host:port/. As Solr is using Commons-Httpsclient for connections, wouldnt this work automatically if you configure the node's HTTP adress using this syntax? This is a way to specify the credentials, yes. But it can be done in other ways and is already done in other ways in the code - see HttpClientUtil.setBasicAuth (have to say that I am currently looking at 4.0 code, but guess it hasnt changed). The problem is not so much setting the credentials for the internal request, but to figure out which credentials to use. As I described above I would like the credentials for requests issued by Solr-nodes themselves, to be copied from the originals super-request in cases where such exist - e.g. for search and update. For some of the requests that Solr-nodes issue themselves there are no such super-request (e.g. for sync stuff) and for other requests the sub-requests are issued asynchronously from its super-request (e.g. replica-creation-request are issued asynchronously from a create request to the Collection API). For both such kind of request we need some credentials to include. Thats where configuring "internal credentials" is needed. If you where thinking about actually writing URLs like "http://user:password@host:port/"; in ZK, that is not going to work, since username/password is not (necessarily) static per target-node. I want to "forward" whatever credentials are given in the super-request to the sub-requests triggered synchronously by this super-requests (e.g. search and update) whereas "internal credentials" will be used when there is no such super-request (sync stuff) or when there is an asynchronous border between the super-request and the sub-requests (e.g. Collection API operations). Besides that we plan to (later) go for HTTPS in order to encrypt the clear text (or base64 encoded, but that can easily be decoded) username/password in the requests, and I believe that the URL itself is not being encrypted in HTTPS. Very concrete in our usage of Solr, we (for now) would like to have two users * Admin-user which is allowed to do everything * Search-user which is only allowed to search We will configure solr-nodes with the "Admin-user credentials" as "internal credentials". So they will be used for replica-creation and sync stuff. But "outside users" of our application we only be given the Search-user credentials, and we want to make sure that they are not allowed to do anything but search. It is not cool if a request made with the Search-user credentials results in sub-requests with Admin-user credentials. Hope it makes a little bit of sense, of else I hope it will when I provide some code. I will post patch soon with early version of my work. was (Author: steff1193): bq. Acording to HTTP-URL syntax, you can give the basic auth params using http://user:password@host:port/. As Solr is using Commons-Httpsclient for connections, wouldnt this work automatically if you configure the node's HTTP adress using this syntax? This is a way to specify the credentials, yes. But it can be done in other ways and is already done in other ways in the code - see HttpClientUtil.setBasicAuth (have to say that I am currently looking at 4.0 code, but guess it hasnt changed). The problem is not so much setting the credentials for the internal request, but to figure out which credentials to use. As I described above I would like the credentials for requests issued by Solr-nodes themselves, to be copied from the originals super-request in cases where such exist - e.g. for search and update. For some of the requests that Solr-nodes issue themselves there are no such super-request (e.g. for sync stuff) and for other requests the sub-requests are issued asynchronously from its super-request (e.g. replica-creation-request are issued asynchronously from a create request to the Collection API). For both such kind of request we need some credentials to include. Thats where configuring "internal credentials" is needed. If you where thinking about actually writing URLs like "http://user:password@host:port/"; in ZK, that is not going to work, since username/password is not (necessarily) static per target-node. I want to "forward" whatever credentials are given in the super-request to the sub-requests triggered synchronously by this super-requests (e.g. search and update) whereas "internal credentials" will be used when there is no such super-request (sync stuff) or when there is an asynchronous border between the super-request and the sub-requests (e.g. Collection
