[jira] Commented: (SOLR-1698) load balanced distributed search
[ https://issues.apache.org/jira/browse/SOLR-1698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799430#action_12799430 ] patrick o'leary commented on SOLR-1698: --- How does this work with search domains in resolv.conf ? > load balanced distributed search > > > Key: SOLR-1698 > URL: https://issues.apache.org/jira/browse/SOLR-1698 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley > Attachments: SOLR-1698.patch, SOLR-1698.patch, SOLR-1698.patch, > SOLR-1698.patch, SOLR-1698.patch > > > Provide syntax and implementation of load-balancing across shard replicas. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1680) Provide an API to specify custom Collectors
[ https://issues.apache.org/jira/browse/SOLR-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797774#action_12797774 ] patrick o'leary commented on SOLR-1680: --- We've just done something like this recently and found the simplest was was to modify ResponseBuilder with setCustomCollector / getCustomCollector, update the QueryCommand to include the custom collector. It gets sticky in the SolrIndexSearcher with caching, and IIRC about 4 places to call the collector, the solution works, but is not in anyway elegant. It would be good to see if we could refactor SolrIndexSearcher first to make it more streamlined. > Provide an API to specify custom Collectors > --- > > Key: SOLR-1680 > URL: https://issues.apache.org/jira/browse/SOLR-1680 > Project: Solr > Issue Type: Sub-task > Components: search >Affects Versions: 1.3 >Reporter: Martijn van Groningen > Fix For: 1.5 > > Attachments: field-collapse-core.patch, SOLR-1680.patch > > > The issue is dedicated to incorporate fieldcollapse's changes to the Solr's > core code. > We want to make it possible for components to specify custom Collectors in > SolrIndexSearcher methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
[
https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12796524#action_12796524
]
patrick o'leary commented on SOLR-1568:
---
bq. A smart spatial filter, at a minimum, only does the distance calculation
for those documents that lie within the bounding box. That's the main point to
the bounding box. I had assumed this is what Patrick's local-solr already did?
It's a little more contrived - I actually executed the lucene query as part of
the filter,
* Bounded box
* Text query standard query
* And bitset
* Pass in that bitset to radial filter to only calculate distances of both text
search, and bounded box
Thus only doc's matching the query within the bounding box have their distances
calculated.
Check out
DistanceQueryBuilder
{code}
public Filter getFilter(Query query) {
// Chain the Query (as filter) with our distance filter
if (distanceFilter != null) {
distanceFilter.reset();
}
QueryWrapperFilter qf = new QueryWrapperFilter(query);
return new ChainedFilter(new Filter[] {qf, filter},
ChainedFilter.AND);
}
public Query getQuery(Query query){
return new ConstantScoreQuery(getFilter(query));
}
{code}
> Implement Spatial Filter
>
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash,
> SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be
> able to pass in a filter query that takes in the field name, lat, lon and
> distance and produces an appropriate Filter (i.e. one that is aware of the
> underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795932#action_12795932
]
patrick o'leary commented on SOLR-1602:
---
1) I agree that Solr needs shorter release cycles, and let me add to that, a
firm road map, that is more community driven.
* Tasks are tackled by trying to solve the hardest parts, rather than iterative
development.
* Users don't see benefits, just patches, most of which won't apply after a few
weeks or months.
*
2) Solr is still young
* it's only been around 4 years.
* It can afford changes, this one is minor, it's config driven, solrconfig
(e.g. where only experts dare) rather than schema-
{code}
{code}
3) We still don't identify who consumers of Solr are
* The end user, where search quality, and performance makes a difference
* The implementer, who downloads, installs, updates solr
* The experts, who customize solr
* The extender, who develop using Solr as a framework (embedded, and as a
webapp)
This change affects the last 2, experts, and extenders, and in a positive way.
The last two classes of users are continuously being affected by development,
just think of
packages being moved around in solr/common, solr/java, solr/solrj etc..
One compromise would be to have releases as sprints, say a minor release every
quarter, and major every 1 to 2 years?
Where you can deprecate something with the resolution of eliminating it before
2 minor releases. (6 months)
> Refactor SOLR package structure to include o.a.solr.response and move
> QueryResponseWriters in there
> ---
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
> Issue Type: Improvement
> Components: Response Writers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
>Reporter: Chris A. Mattmann
>Assignee: Noble Paul
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt,
> SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are
> curiously located in the o.a.solr.request package. Not only is this package
> getting big (30+ classes), a lot of them are misplaced. There should be a
> first-class o.a.solr.response package, and the response related classes
> should be given a home there. Patch forthcoming.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795907#action_12795907 ] patrick o'leary commented on SOLR-1602: --- I've been writing plugin's for solr for a couple of years, and I have seen several situations when we broke backwards compatibility, and configuration for absolutely no reasonable reason except for refactoring for the sake of refactoring. One that springs to mind is updateRequestProcessor going to updateRequestProcessorChain. Along with many more that over the years have caused me and anyone else who consumes solr to realize that upgrades cost time and money. Why should this be different? This at least, cleans things up, the deprecations strategy used in the past have caused more headache than anything, we deprecate, leave a class in place, sometimes even empty out the class so does nothing and force folks to use 'find' and 'grep' as a way to get solr working. Look at SOLR-489, as a prime example, that it's just not been a good practice in the past. To me that's not a helpful way to refactor. > Refactor SOLR package structure to include o.a.solr.response and move > QueryResponseWriters in there > --- > > Key: SOLR-1602 > URL: https://issues.apache.org/jira/browse/SOLR-1602 > Project: Solr > Issue Type: Improvement > Components: Response Writers >Affects Versions: 1.2, 1.3, 1.4 > Environment: independent of environment (code structure) >Reporter: Chris A. Mattmann >Assignee: Noble Paul > Fix For: 1.5 > > Attachments: SOLR-1602.Mattmann.112509.patch.txt, > SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config > > > Currently all o.a.solr.request.QueryResponseWriter implementations are > curiously located in the o.a.solr.request package. Not only is this package > getting big (30+ classes), a lot of them are misplaced. There should be a > first-class o.a.solr.response package, and the response related classes > should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795016#action_12795016 ] patrick o'leary commented on SOLR-1602: --- total +1 Makes it a pain to have to use find to code, and response seems like the right place for the writers. > Refactor SOLR package structure to include o.a.solr.response and move > QueryResponseWriters in there > --- > > Key: SOLR-1602 > URL: https://issues.apache.org/jira/browse/SOLR-1602 > Project: Solr > Issue Type: Improvement > Components: Response Writers >Affects Versions: 1.2, 1.3, 1.4 > Environment: independent of environment (code structure) >Reporter: Chris A. Mattmann > Fix For: 1.5 > > Attachments: SOLR-1602.Mattmann.112509.patch.txt, > SOLR-1602.Mattmann.112509_02.patch.txt > > > Currently all o.a.solr.request.QueryResponseWriter implementations are > curiously located in the o.a.solr.request package. Not only is this package > getting big (30+ classes), a lot of them are misplaced. There should be a > first-class o.a.solr.response package, and the response related classes > should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1568) Implement Spatial Filter
[
https://issues.apache.org/jira/browse/SOLR-1568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795014#action_12795014
]
patrick o'leary commented on SOLR-1568:
---
I would be concerned that this starts making it more complex for users to
implement.
we're going from
{code}
&lat=49.45&long=-77.33&radius=10
{code}
to :
{code}
&fq={!sfilt p=49.32,-79.0 f=location dist=20}
{code}
What do you get out of it?
I remember FAST tm, a subsidiary of microsoft (think I got all that right),
used have
{code}
geo_location:{-79.0,49.32,10)
{code}
And that was unnecessarily awkward to explain to folks, again because different
folks viewed GIS calculations in different manors
Remember GIS is often like an Abbot and Costello sketch, who's on first, lat or
long?
Keep it simple, and please don't obscure it
--1
> Implement Spatial Filter
>
>
> Key: SOLR-1568
> URL: https://issues.apache.org/jira/browse/SOLR-1568
> Project: Solr
> Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 1.5
>
> Attachments: CartesianTierQParserPlugin.java
>
>
> Given an index with spatial information (either as a geohash,
> SpatialTileField (see SOLR-1586) or just two lat/lon pairs), we should be
> able to pass in a filter query that takes in the field name, lat, lon and
> distance and produces an appropriate Filter (i.e. one that is aware of the
> underlying field type for use by Solr.
> The interface _could_ look like:
> {code}
> &fq={!sfilt dist=20}location:49.32,-79.0
> {code}
> or it could be:
> {code}
> &fq={!sfilt lat=49.32 lat=-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt p=49.32,-79.0 f=location dist=20}
> {code}
> or:
> {code}
> &fq={!sfilt lat=49.32,-79.0 fl=lat,lon dist=20}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1650) Consider being able to cache function results per request
[ https://issues.apache.org/jira/browse/SOLR-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12789770#action_12789770 ] patrick o'leary commented on SOLR-1650: --- Can we ensure that function queries have an isCachable method? Distance functions can have a lot of uniqueness (think dragging on a map for setting the center) with a lot of distances attached. Having a generic cache means setting a low cache to avoid distance bloating, would mean lowering the value for other functions queries wanting to use that cache. > Consider being able to cache function results per request > - > > Key: SOLR-1650 > URL: https://issues.apache.org/jira/browse/SOLR-1650 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll > Fix For: 1.5 > > > Once we can sort, filter and boost by functions, it may be the case that the > same function is executed for the same value over and over again. Consider > ways to cache this information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787663#action_12787663 ] patrick o'leary commented on SOLR-773: -- You can certainly implement a fuzzy scoring method, but you really want to avoid having to calculate distances for all your results, so some sort of restriction is good. If your data set is small ~100K docs, you might get away with using a value scorer and boost on distances. But if your data set is in the order of millions, that's not going to be a good idea. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, > lucene.tar.gz, screenshot-1.jpg, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-spatial_solr.patch, SOLR-773.patch, SOLR-773.patch, > solrGeoQuery.tar, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- 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-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785369#action_12785369 ] patrick o'leary edited comment on SOLR-1277 at 12/3/09 3:58 PM: bq. I've been thinking about the idea of perhaps "deprecating" the old single core mode and requiring a solr.xml -1, less required configuration please. I'd be happier if we went down the path of a solr/cores/xxx structure instead, and using solr.xml as an over ride like servlet container's use webapps and context.xml files But that's for another issue was (Author: pjaol): b.q. I've been thinking about the idea of perhaps "deprecating" the old single core mode and requiring a solr.xml -1, less required configuration please. I'd be happier if we went down the path of a solr/cores/xxx structure instead, and using solr.xml as an over ride like servlet container's use webapps and context.xml files But that's for another issue > Implement a Solr specific naming service (using Zookeeper) > -- > > Key: SOLR-1277 > URL: https://issues.apache.org/jira/browse/SOLR-1277 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch, > SOLR-1277.patch, zookeeper-3.2.1.jar > > Original Estimate: 672h > Remaining Estimate: 672h > > The goal is to give Solr server clusters self-healing attributes > where if a server fails, indexing and searching don't stop and > all of the partitions remain searchable. For configuration, the > ability to centrally deploy a new configuration without servers > going offline. > We can start with basic failover and start from there? > Features: > * Automatic failover (i.e. when a server fails, clients stop > trying to index to or search it) > * Centralized configuration management (i.e. new solrconfig.xml > or schema.xml propagates to a live Solr cluster) > * Optionally allow shards of a partition to be moved to another > server (i.e. if a server gets hot, move the hot segments out to > cooler servers). Ideally we'd have a way to detect hot segments > and move them seamlessly. With NRT this becomes somewhat more > difficult but not impossible? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785369#action_12785369 ] patrick o'leary commented on SOLR-1277: --- b.q. I've been thinking about the idea of perhaps "deprecating" the old single core mode and requiring a solr.xml -1, less required configuration please. I'd be happier if we went down the path of a solr/cores/xxx structure instead, and using solr.xml as an over ride like servlet container's use webapps and context.xml files But that's for another issue > Implement a Solr specific naming service (using Zookeeper) > -- > > Key: SOLR-1277 > URL: https://issues.apache.org/jira/browse/SOLR-1277 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch, > SOLR-1277.patch, zookeeper-3.2.1.jar > > Original Estimate: 672h > Remaining Estimate: 672h > > The goal is to give Solr server clusters self-healing attributes > where if a server fails, indexing and searching don't stop and > all of the partitions remain searchable. For configuration, the > ability to centrally deploy a new configuration without servers > going offline. > We can start with basic failover and start from there? > Features: > * Automatic failover (i.e. when a server fails, clients stop > trying to index to or search it) > * Centralized configuration management (i.e. new solrconfig.xml > or schema.xml propagates to a live Solr cluster) > * Optionally allow shards of a partition to be moved to another > server (i.e. if a server gets hot, move the hot segments out to > cooler servers). Ideally we'd have a way to detect hot segments > and move them seamlessly. With NRT this becomes somewhat more > difficult but not impossible? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785170#action_12785170 ] patrick o'leary commented on SOLR-773: -- I will be making some updates that fix a few bugs, and start working on polygon searching. Right now there's a very very basic example in svn https://locallucene.svn.sourceforge.net/svnroot/locallucene/trunk/contrib/polySpatial simple run ant in that directory to create dist/polySpatial.war Load is up in a web container like tomcat on port 8080 and hit http://localhost:8080/polySpatial/ Click on the map to start seeing results around the generated polygon. Let me know your thoughts > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, > lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, > SOLR-773.patch, solrGeoQuery.tar, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781317#action_12781317 ] patrick o'leary commented on SOLR-773: -- Already added, someone mailed me earlier about it, tar'd without following symlinks. What are you building against? Lucene / Solr are ASF, localsolr is sourceforge > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, > lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, > SOLR-773.patch, solrGeoQuery.tar, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781152#action_12781152 ] patrick o'leary commented on SOLR-773: -- Yeah, this has become a big re-arch of solr- The implementation of the spatial search is almost secondary to the key features 1) A method to add meta data to a document from a query life cycle - Should be common between lucene and solr (end goal) 2) Meta data can be used to perform sorting and boosting I think once those two things are completed then spatial search will just fit right in > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, > lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, > SOLR-773.patch, solrGeoQuery.tar, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781143#action_12781143 ] patrick o'leary commented on SOLR-773: -- It's important to realize that localsolr is just a stop gap until it's functionality / feature set is included in solr Grant is doing some fantastic work here, and I'm looking forward to seeing the outcome. Please feel free to join locallucene-users listserv on sourceforge http://sourceforge.net/mail/?group_id=208194 and send patches there, and I'll do my best to include them. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, > lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, > SOLR-773.patch, solrGeoQuery.tar, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781094#action_12781094 ] patrick o'leary commented on SOLR-773: -- 11/21/09 21:00 PDT patrick o'leary to locallucene-users, locallucene-developers Folks I've updated localsolr to work with solr-1.4 release, also works with solr-1.5?? nightly as of 11/21/09 There are a couple of changes needed to upgrade to this version. 1) schema.xml has to be updated lat / long fields and dynamic field _localTier* has to be updated to type="tdouble" 2) your index has to be rebuilt from scratch. This is not ideal, but unfortunately numeric util updates in lucene force us down this path. As always I've put a batteries included demo on http://www.nsshutdown.com/solr-example.tgz Thanks Patrick > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, > lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, > SOLR-773.patch, solrGeoQuery.tar, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1432) FunctionQueries aren't correctly weighted
[
https://issues.apache.org/jira/browse/SOLR-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779219#action_12779219
]
patrick o'leary commented on SOLR-1432:
---
Shouldn't ValueSource simply be updated to
{code}
public DocValues getValues(Map context, IndexReader reader) throws IOException {
return getValues(reader);
}
{code}
Rather than null, not ideal but at least it doesn't leave folks in a worse
position than using 1.3-
> FunctionQueries aren't correctly weighted
> -
>
> Key: SOLR-1432
> URL: https://issues.apache.org/jira/browse/SOLR-1432
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Yonik Seeley
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1432.patch, SOLR-1432.patch
>
>
> Nested queries in function queries aren't weighted correctly with the proper
> Searcher, and this is now even more serious with per-segment searching in
> Lucene/Solr.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12751994#action_12751994 ] patrick o'leary commented on SOLR-773: -- I'm holding off updating localsolr on SF until SOLR 1.4 comes out. There's a lot of flux right now, and I'm not maintaing a patch. There was a June version of solr-1.4-dev version I made available on http://www.nsshutdown.com/solr-example.tgz Once 1.4 comes out with a stabilized interface I'll adopt it, and re-release > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, > lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, > SOLR-773.patch, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747477#action_12747477 ] patrick o'leary commented on SOLR-773: -- Chris / Padraic I have to disagree - A patch is not an adequate way to maintain software for a company. If you have something small, and you don't mind the bleeding edge software, then go ahead and use this. But if you need stability, then use a completed piece of software such as localsolr. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, > lucene.tar.gz, SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-spatial_solr.patch, SOLR-773.patch, > SOLR-773.patch, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723088#action_12723088 ] patrick o'leary commented on SOLR-773: -- This is a dash and run comment, as I'm heading to the airport and am out of reach for a couple of weeks but: - Solr is in the run up to a 1.4 launch, I don't expect local / spatial solr to get into 1.4 at this stage. - This patch is out of date, it's a patch these things happen. - LocalSolr will continue in some format on sourceforge It's been there for over a year now playing catch up with both lucene and solr releases, and while I can't guarantee it will always have support I've done all that I can to bring in other engineers to help keep it going. It would be great to get local / spatial solr into solr, but I have no idea where in the road map function queries enhancements ( to provide localsolr's current feature's in a different format ) are for solr, or what priority they will be. For those reasons I cannot reasonably commit time to something that may / may not happen for who knows how long. But there are a multitude of components that folks are asking for on the localsolr side of things, and once I'm back I'll be posting a wish list to the localsolr community asking for features that folks would like. Again it will move things more out of date with solr, but there isn't much I can do about that. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: lucene.tar.gz, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773.patch, > SOLR-773.patch, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720995#action_12720995 ] patrick o'leary commented on SOLR-773: -- That comes from this patch- This was an older port of localsolr to solr that's fallen behind and hasn't been maintained. I'll take a look at it and see see about getting it working > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: lucene.tar.gz, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773.patch, > SOLR-773.patch, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720866#action_12720866 ] patrick o'leary commented on SOLR-773: -- It's in lucene trunk under contrib/spatial > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: lucene.tar.gz, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773.patch, > SOLR-773.patch, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708688#action_12708688 ] patrick o'leary commented on SOLR-773: -- On 1.2 LocalSolr has suffered from not being in the trunk of SOLR, it is popular and has successfully driven a lot of projects. But I have to put my hand up and say that I am it's biggest bottle neck in keep up to date with SOLR changes. And I think it would gain a lot from just the aspect of being current. Most of the changes that caused problems have been minor signature changes where any developer can resolve the issue, thus the 1 - many element really wins. Certainly improvements are always good, and there are plenty of ways to improve LocalSolr, but even at this stage, I've had to move the trunk of localsolr in SF forward to meet other needs. It would be good to centralize the development, even in a contrib manor. Thus working but open for improvement. On 2. GIS search can be defined in more ways than I can think of, the opengis consortium has a fairly large list of standards http://www.opengeospatial.org/standards/is LocalSolr supports only 1 set of those items, which is why I define localsolr as not a full GIS solution. It has a framework that can grow to be more. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: lucene.tar.gz, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773.patch, > SOLR-773.patch, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708679#action_12708679 ] patrick o'leary commented on SOLR-773: -- Misread positionIncrementGap as precisionStep, should would have been using the default which I guess is 8. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: lucene.tar.gz, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773.patch, > SOLR-773.patch, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708605#action_12708605 ] patrick o'leary commented on SOLR-773: -- Sorry for not getting into this sooner- Lets take a step back for a second, and ask a couple of questions, my thoughts are provided. 1) What is the goal we want to achieve? - Provide a first iteration of a geographical search entity to SOLR - Bring an external popular plugin, in out of the cold into ASF and SOLR, helps solr users out, increases developers from 1 to many. 2) What is the level of commitment, and road map of spatial solutions in lucene and solr? - The primary goal of SOLR is as a text search engine, not GIS search, there are other and better ways to do that without reinventing the wheel and shoe horn-ing it into lucene. (e.g. persistent doc id mappings that can be referenced outside of lucene, so things like postGis and other tools can be used) - We can never fully solve everyone's needs at once, lets start with what we have, and iterate upon it. - I'm happy for any improvements as long as they keep to two goals A. don't make it stupid B. don't make it complex. 3) Raw Math through trie data structures, Spatial ids geo hash, Tier Id's Cartesian tiers, which one? - Why not all? Again we can't solve everyone's needs so why not let them have the tools to help themselves. As for bench marking, I have performed some recently using tdouble precision 0, ~1 Million docs covering the state of NY Top density was ~300,000 between Manhattan & Brooklyn area. Returning all results, avg of 100 hits: Trie Double: 108ms Cartesian Tier: 12ms The reason for the difference, is with Trie Ranges, you are doing 2 sets of range filters/ queries. Cartesian you are doing 1 iteration for maybe 4 to 16 fielded id's. And maybe switching the _localTier fields from sdouble to tdouble might improve that, I haven't tried, 12ms is something I can live with. However, the distance calculation is the killer, 300,000 took about 1.8 seconds in a single thread on a 3.2GHz machine. I was working on some additional features in locallucene, such as poly lines, and convex hulls, which using the Cartesian tierIds can give some basic quick features such as intersect, contains, and a nifty feature of having sorted id's is nearby results. Also faceting on tierId's can give you hot spot results. One final feature, the projection method is a an implementation of IProjector, which allows you to create your own projection currently I'm using Sinusoidal, but you can do your own, such as say - Google Mercator (I use a similar quad grid concept, just different projection method) - Open Map etc.. There's a lot that can be done, but we should stay focused on primary goals, and iterate, iterate iterate. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: lucene.tar.gz, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773.patch, > SOLR-773.patch, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-773) Incorporate Local Lucene/Solr
[
https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
patrick o'leary updated SOLR-773:
-
Attachment: SOLR-773.patch
This fixes the query parsing issue, it defaults to the use the default
QParserPlugin
and allows you to specify a basedOn optional argument, to use a different
QParserPlugin
{code}
{code}
There are a couple of things to note
* Latest distance facet code not included
* Faster distance filter using query intersect isn't working (spatial lucene
fix)
* fsv for shard sorting not present
I feel fsv should be extracted to a separate component to reduce the
duplication of effort across
other search components. But this will give the basics for the moment.
> Incorporate Local Lucene/Solr
> -
>
> Key: SOLR-773
> URL: https://issues.apache.org/jira/browse/SOLR-773
> Project: Solr
> Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Attachments: lucene.tar.gz, SOLR-773-local-lucene.patch,
> SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch,
> SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773.patch,
> SOLR-773.patch, spatial-solr.tar.gz
>
>
> Local Lucene has been donated to the Lucene project. It has some Solr
> components, but we should evaluate how best to incorporate it into Solr.
> See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699851#action_12699851 ] patrick o'leary commented on SOLR-773: -- Looking at it, there's no actual query parsing going on. You could call LuceneQParser, but it just doesn't seem like the right place for it. The original LocalSolr code created a filter to perform the geo-distance stuff- but it did have to duplicate a lot the SearchComponent code. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: lucene.tar.gz, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773.patch, > spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699346#action_12699346 ] patrick o'leary commented on SOLR-773: -- GeoHash can be incorporated to reduce memory, but it should be optional as there's sill overhead in decoding the field for distance calculations. Again haven't been able to put a benchmark together for it, but i did notice it was slower. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Attachments: SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12698496#action_12698496 ] patrick o'leary commented on SOLR-773: -- Thanks Ryan, I've also updated local / spatial lucene to use the new FieldComparatorSource with LUCENE-1588 But haven't had a chance to test it in Solr yet > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Priority: Minor > Attachments: SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661198#action_12661198 ] patrick o'leary commented on SOLR-773: -- There is a patch LUCENE-1304 for SortComparatorSourceUncacheable, which hasn't had any TLC in a while It's been associated with LUCENE-1483 which looks like a major change that could take a while to get in. I'd like to see if we can get movement on LUCENE-1304 as it would help with some of the scope madness I've had to deal with, and resolve the issue once and for all. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Priority: Minor > Attachments: SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660389#action_12660389 ] patrick o'leary commented on SOLR-773: -- It's because of the FieldSortedHitQueue in lucene, even though sorts are generally created as new objects, the FieldSortedHitQueue maintains a static cache of them- Somebody actually had another work around http://mail-archives.apache.org/mod_mbox/lucene-java-user/200806.mbox/%3c571296.22735...@web50301.mail.re2.yahoo.com%3e I haven't tried it, but it might be an option. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Priority: Minor > Attachments: SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660384#action_12660384 ] patrick o'leary commented on SOLR-773: -- Lucene uses a static sort comparator getCachedComparator in lucene's FieldSortedHitQueue.java The assumption being that the sort comparator would never have any data in it I guess. As the distances in the geo sort are a hashmap produced by the distance query, the ScoreDocComparator creates a memory leak unless the scope of the distance query is within the process block. It's messy but the only work around I could find. Putting the distance query in the response builder could make this leak again. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Priority: Minor > Attachments: SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] patrick o'leary updated SOLR-773: - Attachment: spatial-solr.tar.gz Port of LocalSolr to spatial-solr for inclusion in solr's contrib. Provides geographical based search capabilities to solr > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Priority: Minor > Attachments: spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-850) Addition of timeouts for distributed searching
[ https://issues.apache.org/jira/browse/SOLR-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652158#action_12652158 ] patrick o'leary commented on SOLR-850: -- When not defined, it defaults to no timeout, which is the current experience, obviously not a desirable one. > Addition of timeouts for distributed searching > -- > > Key: SOLR-850 > URL: https://issues.apache.org/jira/browse/SOLR-850 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: patrick o'leary >Assignee: Otis Gospodnetic >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-850.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > Include configurable socket timeout and connection timeout settings for > distributed searching. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-850) Addition of timeouts for distributed searching
[
https://issues.apache.org/jira/browse/SOLR-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
patrick o'leary updated SOLR-850:
-
Attachment: SOLR-850.patch
Patches solr-1.3.0 release
Allows for 2 timeout settings to be configured per-request handler
shard-socket-timeout, which times out a socket which has been in read for too
long.
shard-connection-timeout, which times out a socket that's been in wait or
established too long.
All values are in ms's
config example:
{code:xml}
explicit
1000
1000
query
facet
mlt
highlight
debug
{code}
> Addition of timeouts for distributed searching
> --
>
> Key: SOLR-850
> URL: https://issues.apache.org/jira/browse/SOLR-850
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
>Reporter: patrick o'leary
> Fix For: 1.3
>
> Attachments: SOLR-850.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Include configurable socket timeout and connection timeout settings for
> distributed searching.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-850) Addition of timeouts for distributed searching
Addition of timeouts for distributed searching -- Key: SOLR-850 URL: https://issues.apache.org/jira/browse/SOLR-850 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: patrick o'leary Fix For: 1.3 Include configurable socket timeout and connection timeout settings for distributed searching. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632358#action_12632358 ] patrick o'leary commented on SOLR-773: -- Yep agree > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Priority: Minor > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632327#action_12632327 ] patrick o'leary commented on SOLR-773: -- I believe you guys are using a branch of the code as we were looking at using the mapquest sids. Both versions are solving the same basic problem, creating a sudo quad tree implementation. com.pjaol was the initial API I built, com.mapquest is donated to us by MapQuest. Both versions work by flattening out the earth onto a series of grids, the grids get progressively smaller with each _localTierN, in the MapQuest version there is a notion of zooming. Some quick info graphics here: http://www.nsshutdown.com/projects/lucene/whitepaper/locallucene_v2.html The differences are, com.pjaol uses pretty exact measurements, the flattening method is based on something called a sinusoidal projection, where I translate lat / longs to x,y coordinates which provide an equal spaced projection on a flat surface. Then I use GeoTools for the actual precise distance calculation. It comes at a slight performance cost to be that exact, but users have a need for it. The com.mapquest code, does a direct conversion to cartesian x,y coordinate from lat / long, encodes and generates sids and uses a standard great circle equation for distance calculation. So not as convoluted. It does come at a slight accuracy cost - but only in a few places, Greenland, New Zealand, some places around the poles and equator. So it's perfect for web based applications as the +/- error differential is small enough to be acceptable for most users. There is however a good audience for local lucene, who use it for more exact calculation, even down to the meter range. It's also used by some research groups for non-land based activities hence the desire to retain the exactness. > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Priority: Minor > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632239#action_12632239 ] patrick o'leary commented on SOLR-773: -- Hey guys Placing both lat and long in the same field is good when used internally, the majority of users of localsolr have separate fields representing lat long, so make sure the representation does not effect the original document. WKT uses point as the naming convention for single item's and I'd suggest that rather than just str, it would also be nice to get to a KML wt format as well. I've done some stuff integrating in mapping components and KML goes down real well. However be aware as soon as you start supporting WKT, you will be asked for ERSI support, and poly support, ray tracing, collision and a lot more fun things :-) P > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Priority: Minor > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-565) Component to abstract shards from clients
[ https://issues.apache.org/jira/browse/SOLR-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613370#action_12613370 ] patrick o'leary commented on SOLR-565: -- Been tied up with work recently The objective of this is to move shards away from a client implementation, with the nature of solr I would expect engineer resources to be used for solrconfig.xml updates, but operational updates to occur externally to this, hence hosting topology externally to the solrconfig. The distributor component should end up providing 3 main parts, that don't really fit into the xml config. 1. Component with the ability to enable shard-ing based upon a distributed=true parameter from a preset topology. 1.1 Overridden if isShard=true is passed. (thus local disk only) 2. a configurable plugin to allow loading of custom topologies, e.g. mysql, ec2-describe-instances, zoneedit-watch etc. 2.1. defaulting to use a standard file loader, which checks file mod time stamp for reload. 3. provide a configurable plugin for query routing, if users wish to apply taxonomies or other query identification methods, they can do so and direct requests to appropriate shards. I don't think this really is needed as part of solr's core, and if anything could be a contrib. > Component to abstract shards from clients > - > > Key: SOLR-565 > URL: https://issues.apache.org/jira/browse/SOLR-565 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: patrick o'leary >Assignee: Otis Gospodnetic >Priority: Minor > Attachments: distributor_component.patch > > > A component that will remove the need for calling clients to provide the > shards parameter for > a distributed search. > As systems grow, it's better to manage shards with in solr, rather than > managing each client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-469) Data Import RequestHandler
[ https://issues.apache.org/jira/browse/SOLR-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12604276#action_12604276 ] patrick o'leary commented on SOLR-469: -- With the arow, I noticed by nulling it, that CMS GC was cleaning items up faster in eden space. Without it, Full GC kicked in more frequently. This was with indexing about 250~MB from mysql. If you've not got that much data then there isn't much of a worry, it's just a little optimization that reduces the need to increase your jvm's mx and newsize settings. Another thing I was looking at is the SolrWriter, instead of calling an updateHandler directly, I think you should call the UpdateRequestProcessorFactory and allow the UpdateRequestProcessor chain handle the *processAdd *processDelete *processCommit *finish It allows for custom ChainedUpdateProcessor'Factory's which is a fantastic little known about item. > Data Import RequestHandler > -- > > Key: SOLR-469 > URL: https://issues.apache.org/jira/browse/SOLR-469 > Project: Solr > Issue Type: New Feature > Components: update >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Grant Ingersoll > Fix For: 1.3 > > Attachments: SOLR-469-contrib.patch, SOLR-469-contrib.patch, > SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, > SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch > > > We need a RequestHandler Which can import data from a DB or other dataSources > into the Solr index .Think of it as an advanced form of SqlUpload Plugin > (SOLR-103). > The way it works is as follows. > * Provide a configuration file (xml) to the Handler which takes in the > necessary SQL queries and mappings to a solr schema > - It also takes in a properties file for the data source > configuraution > * Given the configuration it can also generate the solr schema.xml > * It is registered as a RequestHandler which can take two commands > do-full-import, do-delta-import > - do-full-import - dumps all the data from the Database into the > index (based on the SQL query in configuration) > - do-delta-import - dumps all the data that has changed since last > import. (We assume a modified-timestamp column in tables) > * It provides a admin page > - where we can schedule it to be run automatically at regular > intervals > - It shows the status of the Handler (idle, full-import, > delta-import) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-469) Data Import RequestHandler
[
https://issues.apache.org/jira/browse/SOLR-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603662#action_12603662
]
patrick o'leary commented on SOLR-469:
--
There's a slight problem using Connector/J for mysql, in that it doesn't fully
implement the jdbc spec for
setFetchSize, resulting in all rows in mysql being selected into memory.
Connector/J states that you must pass ?useCursorFetch=true in the connect
string, but it exposes another mysql bug with server-side parsed queries
throwing an error of "incorrect key file" on the temp tables generated by the
cursor,
as yet there isn't a fix in mysql that I know of.
Something that seems to work is to set the batchSize to Integer.MIN_VALUE:
JdbcDataSource.java
{code}
if (bsz != null) {
try {
batchSize = Integer.parseInt(bsz);
if (batchSize < 0)
batchSize = Integer.MIN_VALUE; // pjaol : setting batchSize to <0
in dataSource forces connector / j to use Integer.MIN_VALUE
} catch (NumberFormatException e) {
LOG.log(Level.WARNING, "Invalid batch size: " + bsz);
}
}
{code}
This basically puts the result set size at 1 row, a little slow, but if you
can't set your JVM memory settings high enough
it gives you a option.
Also suggest null-ing the row hashmap in DocBuilder immediately after use to
allow GC to clean up
the reference faster within eden space.
DocBuilder.java
{code}
if (entity.isDocRoot) {
if (stop.get())
return;
boolean result = writer.upload(doc);
doc = null;
if (result)
importStatistics.docCount.incrementAndGet();
}
arow = null; // pjaol : set reference to hashmap to null to eliminate
strong reference
} catch (DataImportHandlerException e)
..
{code}
> Data Import RequestHandler
> --
>
> Key: SOLR-469
> URL: https://issues.apache.org/jira/browse/SOLR-469
> Project: Solr
> Issue Type: New Feature
> Components: update
>Affects Versions: 1.3
>Reporter: Noble Paul
>Assignee: Grant Ingersoll
> Fix For: 1.3
>
> Attachments: SOLR-469-contrib.patch, SOLR-469.patch, SOLR-469.patch,
> SOLR-469.patch, SOLR-469.patch, SOLR-469.patch, SOLR-469.patch,
> SOLR-469.patch, SOLR-469.patch
>
>
> We need a RequestHandler Which can import data from a DB or other dataSources
> into the Solr index .Think of it as an advanced form of SqlUpload Plugin
> (SOLR-103).
> The way it works is as follows.
> * Provide a configuration file (xml) to the Handler which takes in the
> necessary SQL queries and mappings to a solr schema
> - It also takes in a properties file for the data source
> configuraution
> * Given the configuration it can also generate the solr schema.xml
> * It is registered as a RequestHandler which can take two commands
> do-full-import, do-delta-import
> - do-full-import - dumps all the data from the Database into the
> index (based on the SQL query in configuration)
> - do-delta-import - dumps all the data that has changed since last
> import. (We assume a modified-timestamp column in tables)
> * It provides a admin page
> - where we can schedule it to be run automatically at regular
> intervals
> - It shows the status of the Handler (idle, full-import,
> delta-import)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-565) Component to abstract shards from clients
[ https://issues.apache.org/jira/browse/SOLR-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598664#action_12598664 ] patrick o'leary commented on SOLR-565: -- There's one change I was going to add to this today which was a copy parameter, I'll add that and look at some of the ideas here. Here's what I suggest. 1) Add the change I've got, just to have a base line to work from. 2) Add changes into ShardRequest and SearchHandler (Maybe even response builder) and this patch to handle essentially "named nodes" ? - with parameters 3) Add an optional interface to provide intelligent query routing - If not null, pass the response builder to the query routing class, and it should pass a list of named nodes back that can be used for the request. Before anyone asks, I do no believe that this component should be responsible for reformatting the query for each of the named nodes (which is open for renaming if someone has something cooler to call it), the individual nodes should be capable of taking user / client input and restructuring it to suit it own needs. > Component to abstract shards from clients > - > > Key: SOLR-565 > URL: https://issues.apache.org/jira/browse/SOLR-565 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: patrick o'leary >Priority: Minor > Attachments: distributor_component.patch > > > A component that will remove the need for calling clients to provide the > shards parameter for > a distributed search. > As systems grow, it's better to manage shards with in solr, rather than > managing each client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-565) Component to abstract shards from clients
[ https://issues.apache.org/jira/browse/SOLR-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598495#action_12598495 ] patrick o'leary commented on SOLR-565: -- That's a different aspect, where you either have a map reduce / ontology / hash based system to focus you queries to certain farms of servers. This component could act as an example of how to accomplish that, but there are so many possible implementations that it's not probable to provide a scope for it. > Component to abstract shards from clients > - > > Key: SOLR-565 > URL: https://issues.apache.org/jira/browse/SOLR-565 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: patrick o'leary >Priority: Minor > Attachments: distributor_component.patch > > > A component that will remove the need for calling clients to provide the > shards parameter for > a distributed search. > As systems grow, it's better to manage shards with in solr, rather than > managing each client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-565) Component to abstract shards from clients
[ https://issues.apache.org/jira/browse/SOLR-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598071#action_12598071 ] patrick o'leary commented on SOLR-565: -- I think I see where your going, so if you wanted to do a distributed search, and have different parameters passed to different shards. You'd store the configurations separately. Add or remove files as if you were turning on / off services you were searching upon with no down time. It's possible, would require a slight change to the SearchHandler, and ShardRequest.java, but it seems possible and pretty useful. > Component to abstract shards from clients > - > > Key: SOLR-565 > URL: https://issues.apache.org/jira/browse/SOLR-565 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: patrick o'leary >Priority: Minor > Fix For: 1.3 > > Attachments: distributor_component.patch > > > A component that will remove the need for calling clients to provide the > shards parameter for > a distributed search. > As systems grow, it's better to manage shards with in solr, rather than > managing each client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-565) Component to abstract shards from clients
[ https://issues.apache.org/jira/browse/SOLR-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594988#action_12594988 ] patrick o'leary commented on SOLR-565: -- There are 2 main differences 1) This provides optional enabling using distributed=true, where as setting defaults requires a client sending shards="" to disable. 2) Also allows you to keep your infrastructure topology out side of application configuration. There is a load method which also examines the time stamp on the topology file and reloads if a newer one exists. Saving you from having to restart the host to change your back end shards. > Component to abstract shards from clients > - > > Key: SOLR-565 > URL: https://issues.apache.org/jira/browse/SOLR-565 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: patrick o'leary >Priority: Minor > Fix For: 1.3 > > Attachments: distributor_component.patch > > > A component that will remove the need for calling clients to provide the > shards parameter for > a distributed search. > As systems grow, it's better to manage shards with in solr, rather than > managing each client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-565) Component to abstract shards from clients
[
https://issues.apache.org/jira/browse/SOLR-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
patrick o'leary updated SOLR-565:
-
Attachment: distributor_component.patch
Attaching patch for a DistributorComponent
Provides the ability to load shard urls from a topologyFile, and add parameters
to the outgoing url
Requires configuration in solr/conf/solrconfig.xml
Get's activated by adding distributed=true to search query.
Still accepts shards= parameter as an override.
Configuration:
{code}
shards.txt
shards.qt=geo
explicit
distributor
query
facet
mlt
highlight
debug
{code}
shards.txt file by default will exist in solr/conf directory and is line
delimited containing
host_1:port/solr_path
host_2:port/solr_path
etc..
> Component to abstract shards from clients
> -
>
> Key: SOLR-565
> URL: https://issues.apache.org/jira/browse/SOLR-565
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 1.3
>Reporter: patrick o'leary
>Priority: Minor
> Fix For: 1.3
>
> Attachments: distributor_component.patch
>
>
> A component that will remove the need for calling clients to provide the
> shards parameter for
> a distributed search.
> As systems grow, it's better to manage shards with in solr, rather than
> managing each client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-565) Component to abstract shards from clients
Component to abstract shards from clients - Key: SOLR-565 URL: https://issues.apache.org/jira/browse/SOLR-565 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: patrick o'leary Priority: Minor Fix For: 1.3 A component that will remove the need for calling clients to provide the shards parameter for a distributed search. As systems grow, it's better to manage shards with in solr, rather than managing each client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-560) Convert JDK logging to SLF4J
[ https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594211#action_12594211 ] patrick o'leary commented on SOLR-560: -- I'd suggest replacing logging.jsp with SOLR-554 might need to modify it slightly for SLF4J. > Convert JDK logging to SLF4J > > > Key: SOLR-560 > URL: https://issues.apache.org/jira/browse/SOLR-560 > Project: Solr > Issue Type: Wish >Reporter: Ryan McKinley > Fix For: 1.3 > > Attachments: slf4j-api-1.5.0.jar, slf4j-jdk14-1.5.0.jar, > SOLR-560-slf4j.patch, SOLR-560-slf4j.patch > > > After lots of discussion, we should consider using SLF4j to enable more > flexibility in logging configuration. > See: > http://www.nabble.com/Solr-Logging-td16836646.html > http://www.nabble.com/logging-through-log4j-td13747253.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-502) Add search time out support
[ https://issues.apache.org/jira/browse/SOLR-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593634#action_12593634 ] patrick o'leary commented on SOLR-502: -- Has this had any traction in the solr core yet? seems like a critical thing to have > Add search time out support > --- > > Key: SOLR-502 > URL: https://issues.apache.org/jira/browse/SOLR-502 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sean Timm >Priority: Minor > Attachments: SOLR-502-solrj.patch, solrTimeout.patch, > solrTimeout.patch, solrTimeout.patch, solrTimeout.patch, solrTimeout.patch > > > Uses LUCENE-997 to add time out support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-527) An XML commit only request handler
[ https://issues.apache.org/jira/browse/SOLR-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585702#action_12585702 ] patrick o'leary commented on SOLR-527: -- I guess there's a couple of questions I'd have around this. # Should there be a default update mechanism if none are specified in the solrconfig.xml? #* I can rip out the request handlers for /update, it's still available through SolrUpdateServlet, as SolrCore loads ChainUpdateProcessFactory by default, and that loads RunUpdateProcessorFactory by default. That's not what I'd expect. # Should the UpdateCmd maintain some form of context of origin of an update, even like a string? #* If embeded could be used to store anything from a file name to a db name, if http the peer ip could be stored through the UpdateServlet or RequestDispatcher. #* Would allow custom update chains some ability to make a decision based the origin of a document. Overall I'd like to have the ability to determine if I should in fact allow an add / update / commit to go through, for both web based and non-web containers. But I definitely want to have the ability to switch it off. > 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, 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. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567953#action_12567953
]
patrick o'leary commented on SOLR-303:
--
It looks pretty good, I really need the ShardDoc's classes to be split up into
public classes so I can use
them.
It would also be fantastic to open up QueryComponent, my component only needs
to over ride
a few functions, and it would so much cleaner to just extend QueryComponent
rather than duplicate the code.
Also through testing, it might be worth while to apply a few negative edge
cases.
e.g. duplicate documents in different shards. As systems get larger this is a
huge possibility. Only fixed hash indexing could ensure you don't get
duplicates, but if you try to have an extend-able environment that might not
be an option.
Took me a while to realize I had duplicated documents during indexing, but it
causes NPEs in the query response writers, so not obvious or easy to figure out.
A solution would be to maintain map of unique fields as adding the ShardDocs to
the priority queue, and continue on duplicates. You might also want to put some
logic in there to ensure same shard doc is used for each duplicate doc, simple
because the scores for identical doc's will be different across shards, and
could change based upon order of which Shard responds first. This should
eliminate that
So something like
QueryComponent.mergeIds
{code}
Map uniqueDoc = new HashMap();
for (ShardResponse srsp : sreq.responses) {
SolrDocumentList docs = srsp.rsp.getResults();
// go through every doc in this response, construct a ShardDoc, and
// put it in the priority queue so it can be ordered.
for (int i=0; i0){
continue;
}
}
..
queue.insert(shardDoc);
} // end for-each-doc-in-response
} // end for-each-response
{code}
> Distributed Search over HTTP
>
>
> Key: SOLR-303
> URL: https://issues.apache.org/jira/browse/SOLR-303
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Sharad Agarwal
>Assignee: Yonik Seeley
> Attachments: distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed_pjaol.patch, fedsearch.patch, fedsearch.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch,
> fedsearch.patch, fedsearch.stu.patch, fedsearch.stu.patch
>
>
> Searching over multiple shards and aggregating results.
> Motivated by http://wiki.apache.org/solr/DistributedSearch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-470) DateField throws error on iso8601 date
[ https://issues.apache.org/jira/browse/SOLR-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565637#action_12565637 ] patrick o'leary commented on SOLR-470: -- parseMath returns a Date object that's formated to the SDF in the LocalThread that's fine /scratch last un-caffeinated comment. I think the root of the problem is any call to 'toInternal(String)' with a string that end's in 'Z' is indexed directly, which now means there can be multiple date formats represented internally in the index. But in saying that, I'm guessing that a Field does not necessarily have to be indexed to call toObject. What would be nice is to switch from using SimpleDateFormat to org.apache.commons.lang.time.DateUtils Which supports parseDate(String str, String[] parsePatterns) , where multiple patterns can be tried, and using init to allow users supply their own patterns. And then using org.apache.commons.lang.time.FastDateFormat to represent the dates internally. Both of these are thread safe, which should make a Flexible DateField a lot easier to implement without much over head. > DateField throws error on iso8601 date > -- > > Key: SOLR-470 > URL: https://issues.apache.org/jira/browse/SOLR-470 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 >Reporter: patrick o'leary >Assignee: Hoss Man > Fix For: 1.3 > > > A correct iso 8601 date 2006-01-01T12:01:00Z throws an error. > Unparseable date: "2006-01-01T12:01:00Z" at > org.apache.solr.schema.DateField.toObject(DateField.java:173) at > org.apache.solr.schema.DateField.toObject(DateField.java:83) > The ThreadLocalDateFormat requires fractional seconds > "-MM-dd'T'HH:mm:ss.SSS" > to parse with simple date format. Where as the jdoc states their optional. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-470) DateField throws error on iso8601 date
[
https://issues.apache.org/jira/browse/SOLR-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565571#action_12565571
]
patrick o'leary commented on SOLR-470:
--
It's a little iffy but what if you just default the dateFields to have 0
milliseconds
unless specified.
e.g.
org.apache.solr.util.DateMathParser
{code}
public Date parseMath(String math) throws ParseException {
Calendar cal = Calendar.getInstance(zone, loc);
cal.setTime(getNow());
cal.add(Calendar.Calendar.MILLISECOND, 0);
...
{code}
And if a millisecond field is added, it over writes the default ?
> DateField throws error on iso8601 date
> --
>
> Key: SOLR-470
> URL: https://issues.apache.org/jira/browse/SOLR-470
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 1.3
>Reporter: patrick o'leary
>Assignee: Hoss Man
> Fix For: 1.3
>
>
> A correct iso 8601 date 2006-01-01T12:01:00Z throws an error.
> Unparseable date: "2006-01-01T12:01:00Z" at
> org.apache.solr.schema.DateField.toObject(DateField.java:173) at
> org.apache.solr.schema.DateField.toObject(DateField.java:83)
> The ThreadLocalDateFormat requires fractional seconds
> "-MM-dd'T'HH:mm:ss.SSS"
> to parse with simple date format. Where as the jdoc states their optional.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-470) DateField throws error on iso8601 date
DateField throws error on iso8601 date -- Key: SOLR-470 URL: https://issues.apache.org/jira/browse/SOLR-470 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.3 Reporter: patrick o'leary A correct iso 8601 date 2006-01-01T12:01:00Z throws an error. Unparseable date: "2006-01-01T12:01:00Z" at org.apache.solr.schema.DateField.toObject(DateField.java:173) at org.apache.solr.schema.DateField.toObject(DateField.java:83) The ThreadLocalDateFormat requires fractional seconds "-MM-dd'T'HH:mm:ss.SSS" to parse with simple date format. Where as the jdoc states their optional. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-457) A multi threaded implementation for solrJ
[ https://issues.apache.org/jira/browse/SOLR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561924#action_12561924 ] patrick o'leary commented on SOLR-457: -- An idea I've been thinking about is to change the addSolrServer to also include solr params for each shard. Definitely to get docs by id, it would be cleaner. The real purpose of the patch is to execute the individual shard requests as concurrent threads. To give you an idea, an implementation I've tested this on, the patch took a 200ms request down to 42ms. This may seem overkill to most folks, but is critical for my needs. >From load testing, I haven't noticed any significant over head in creating new >MultiThreadedHttpSolrServers SolrServers creation seem light as well, it's only processing the request that appears to be the main work horse. I'll make some changes now that SOLR-462 is added, as I don't need the overrides. > A multi threaded implementation for solrJ > - > > Key: SOLR-457 > URL: https://issues.apache.org/jira/browse/SOLR-457 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.3 >Reporter: patrick o'leary >Priority: Minor > Attachments: multithreaded-solrj.patch > > > Provide a multi threaded implementation of CommonsHttpSolrServer > For usage with distributed searching in solr-303 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-457) A multi threaded implementation for solrJ
[
https://issues.apache.org/jira/browse/SOLR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559349#action_12559349
]
patrick o'leary commented on SOLR-457:
--
In terms of reusing threads I used Executors.newCachedThreadPool which should
maintain a static pool of threads. Or so it says in the documentation. I'll try
profiling it when I get a chance.
The _connectionManger yep that's a good spot, need to overwrite
{code}
protected HttpClient getHttpConnection() {
return new HttpClient(getConnectionManager());
}
{code}
Makes sense to change the CommonsHttpSolrServer setConnectionTimeout,
setDefaultMaxConnectionsPerHost, setMaxTotalConnections to call
getConnectionManager() instead of using _connectionManager
unless having a setConnectionManager makes more sense.
At the moment I've just added a setConnectionManager in the
MultiThreadedHttpSolrServer, but that leaves me wondering do I need to abstract
the connection manger in the client implementation or is that over kill.
Because there will always be something new to set in your connection manager.
> A multi threaded implementation for solrJ
> -
>
> Key: SOLR-457
> URL: https://issues.apache.org/jira/browse/SOLR-457
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
>Affects Versions: 1.3
>Reporter: patrick o'leary
>Priority: Minor
> Fix For: 1.3
>
> Attachments: multithreaded-solrj.patch
>
>
> Provide a multi threaded implementation of CommonsHttpSolrServer
> For usage with distributed searching in solr-303
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-457) A multi threaded implementation for solrJ
[ https://issues.apache.org/jira/browse/SOLR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559308#action_12559308 ] patrick o'leary commented on SOLR-457: -- Not too concerned about which package it's in. There is a need to clarify the multi threaded statement. CommonsHttpSolrServer is thread-safe using MultiThreadedHttpConnectionManager which provides pooling. However you still have to implement a thread or runnable class to use it in a threaded manor, otherwise the connections are serial. That's what this implementation does. Could be used in anything that requires a request to multiple solr instances, not just distributed search. e.g. - add / update / delete documents to multiple solr severs e.g real time indexing and not using a master - slave implementation - If federate search ever gets kicked off, it has possible uses there. - large scale monitoring, if you have 100 boxes, it will save you considerable time doing them in a threaded fashion than serially. > A multi threaded implementation for solrJ > - > > Key: SOLR-457 > URL: https://issues.apache.org/jira/browse/SOLR-457 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.3 >Reporter: patrick o'leary >Priority: Minor > Fix For: 1.3 > > Attachments: multithreaded-solrj.patch > > > Provide a multi threaded implementation of CommonsHttpSolrServer > For usage with distributed searching in solr-303 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] patrick o'leary updated SOLR-303: - Attachment: distributed_pjaol.patch Hey Yonik Needed to make a couple of updates to ShardDoc as the nested outer classes were preventing me from using the patch. Also included SOLR-457, with a multi threaded implementation of solrj to query the shards. with this patch. P > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Attachments: distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, > distributed_pjaol.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.stu.patch, fedsearch.stu.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-457) A multi threaded implementation for solrJ
[
https://issues.apache.org/jira/browse/SOLR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
patrick o'leary updated SOLR-457:
-
Attachment: multithreaded-solrj.patch
Provides a multi-threaded implementation of CommonsHttpSolrServer
for use with distributed searching.
Example Usage :
{code}
MultiThreadedHttpSolrServer mtserver = new
MultiThreadedHttpSolrServer("http://"+shards[0]);
boolean first = true;
ModifiableSolrParams params = sreq.params;
params.remove("wt"); // use default response format (or let SolrJ
select)
params.remove("version");
params.remove("shards"); // not a top-level request
params.remove("indent");
params.remove("echoParams");
params.set("isShard", true); // a sub (shard) request
for (String shard : shards) {
String url = "http://"; + shard;
if (! first){
mtserver.addSolrServer("http://"+shard);
} else {
first = false;
}
}
// process all the shards
// and retrive the responses
QueryResponse[] responses = mtserver.process(params);
int sz = responses.length;
// Responses are maintained in an array matching
// the order they were added to the MultiThreadedSolrServer
for (int i = 0; i < sz; i++){
ShardResponse srsp = new ShardResponse();
srsp.req = sreq;
srsp.shard = shards[i];
srsp.rsp = responses[i];
sreq.responses.add(srsp);
}
{code}
> A multi threaded implementation for solrJ
> -
>
> Key: SOLR-457
> URL: https://issues.apache.org/jira/browse/SOLR-457
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
>Affects Versions: 1.3
>Reporter: patrick o'leary
>Priority: Minor
> Fix For: 1.3
>
> Attachments: multithreaded-solrj.patch
>
>
> Provide a multi threaded implementation of CommonsHttpSolrServer
> For usage with distributed searching in solr-303
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-457) A multi threaded implementation for solrJ
A multi threaded implementation for solrJ - Key: SOLR-457 URL: https://issues.apache.org/jira/browse/SOLR-457 Project: Solr Issue Type: New Feature Components: clients - java Affects Versions: 1.3 Reporter: patrick o'leary Priority: Minor Fix For: 1.3 Provide a multi threaded implementation of CommonsHttpSolrServer For usage with distributed searching in solr-303 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557324#action_12557324
]
patrick o'leary commented on SOLR-303:
--
Small thing but if you update org.apache.solr.handler.component.ResponseBuilder
and set the stages to final, you can use a switch statement in the
distributedProcess phase.
{code}
public class ResponseBuilder
{
public static final int STAGE_START = 0;
public static final int STAGE_PARSE_QUERY = 1000;
public static final int STAGE_EXECUTE_QUERY = 2000;
public static final int STAGE_GET_FIELDS = 3000;
public static final int STAGE_DONE= Integer.MAX_VALUE;
{code}
> Distributed Search over HTTP
>
>
> Key: SOLR-303
> URL: https://issues.apache.org/jira/browse/SOLR-303
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Sharad Agarwal
>Assignee: Yonik Seeley
> Attachments: distributed.patch, distributed.patch, distributed.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch,
> fedsearch.stu.patch
>
>
> Searching over multiple shards and aggregating results.
> Motivated by http://wiki.apache.org/solr/DistributedSearch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] patrick o'leary updated SOLR-303: - Attachment: (was: distributed_trunk.patch) > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Attachments: distributed.patch, distributed.patch, distributed.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557012#action_12557012 ] patrick o'leary commented on SOLR-303: -- Was missing a file from an svn add, so the patch I put in there misses out on SolrFieldSortedHitQueue I'll remove it to reduce confusion. > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Attachments: distributed.patch, distributed.patch, distributed.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] patrick o'leary updated SOLR-303: - Attachment: distributed_trunk.patch This might help, merged the distributed & federated patchs with trunk last night, fixed the rejects. Appears to work. The only things not included are the distributed searcher unit tests from the previous patch. Only the deltas were in the patch, so I had no way to rebuild them. Hope this helps P > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Attachments: distributed.patch, distributed.patch, distributed.patch, > distributed_trunk.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.stu.patch, fedsearch.stu.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12556644#action_12556644 ] patrick o'leary commented on SOLR-303: -- Hey Yonik Are you applying the federated search patch first before the distributed search? The patch itself won't apply cleanly against trunk Thanks P > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Attachments: distributed.patch, distributed.patch, distributed.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
