[jira] Assigned: (SOLR-1769) Solr 1.4 Replication - Repeater throwing NullPointerException

[ https://issues.apache.org/jira/browse/SOLR-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1769: Assignee: Noble Paul > Solr 1.4 Replication - Repeater throwing NullPointerException > -

[jira] Commented: (SOLR-1769) Solr 1.4 Replication - Repeater throwing NullPointerException

[ https://issues.apache.org/jira/browse/SOLR-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832400#action_12832400 ] Noble Paul commented on SOLR-1769: -- can you share the deletionPolicy in the repeater? > So

RE: Field value tags

: I don't believe index-time will be involved in this sort of : functionality, as there's no way to know at index-time what 'tag groups' : a given term will be in at any given time. assuming it's a requirement that tags can be changed at any time, then no -- an index time expansion won't cut i

[jira] Updated: (SOLR-1765) HTTP Caching related headers are incorrect for distributed searches

[ https://issues.apache.org/jira/browse/SOLR-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1765: --- Component/s: (was: multicore) (was: search) Description: When searching across mu

Re: Short is buggish ?

: We have looked through the shards trying to find a value which is greater : than radix 10 which would throw this exception. We did not find any. We have Grant's guess doesn't make much sense to me ... it would explain why a "large" short might appear that way, but not why a "short" short would

[jira] Commented: (SOLR-534) Return all query results with parameter rows=-1

[ https://issues.apache.org/jira/browse/SOLR-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832351#action_12832351 ] Walter Underwood commented on SOLR-534: --- -1 This adds a denial of service vulnerabilit

[jira] Commented: (SOLR-534) Return all query results with parameter rows=-1

[ https://issues.apache.org/jira/browse/SOLR-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12832333#action_12832333 ] Hoss Man commented on SOLR-534: --- bq. But if you use the REALLY_BIG_NUMBER approach, the same ba

[jira] Created: (SOLR-1769) Solr 1.4 Replication - Repeater throwing NullPointerException

Solr 1.4 Replication - Repeater throwing NullPointerException - Key: SOLR-1769 URL: https://issues.apache.org/jira/browse/SOLR-1769 Project: Solr Issue Type: Bug Affects Version

Re: [jira] Created: (SOLR-1713) Carrot2 Clustering should have an option to cluster on a different number of rows than the DocList size

Hi, I figured out a solution putting all the logic in ClusterComponent. This component manages the logic between rows parameter and new rows parameters. The second one is the parameter which defines rows count to be clustered. I've attached a propousal in Jira. At the end describes an alternativ

[jira] Updated: (SOLR-1713) Carrot2 Clustering should have an option to cluster on a different number of rows than the DocList size

[ https://issues.apache.org/jira/browse/SOLR-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zacarias updated SOLR-1713: --- Attachment: Solr-1713 Improvement Proposal.pdf Propousal of improvement. Explains a posible solution, advanta

Re: SolrCloud - Using collections, slices and shards in the wild

Yeah my decision likely would have been different if it weren't for the fact that Katta is industrial strength already. On Wed, Feb 10, 2010 at 12:59 PM, Jon Gifford wrote: > > We currently use Katta and this system works really, really well. > > Katta does look nice, but the SolrCloud stuff

Re: SolrCloud - Using collections, slices and shards in the wild

On Wed, Feb 10, 2010 at 10:47 AM, Ted Dunning wrote: > This is analogous to the multiple data sources that we have at > Deepdyve. > In a fully sharded and balanced environment, I have found it *much* more > efficient to put all data sources into a single collection and use

Re: SolrCloud - Using collections, slices and shards in the wild

This is analogous to the multiple data sources that we have at Deepdyve. In a fully sharded and balanced environment, I have found it *much* more efficient to put all data sources into a single collection and use a filter to select one or the other. The rationale is that d

Re: SolrCloud - Using collections, slices and shards in the wild

By the way, and in case its not obvious, I don't mean to suggest that we should remove the ability to specify a set of shards in the search interface. What I'm saying is that using something like "group" instead is simpler in most cases. Jon On Wed, Feb 10, 2010 at 9:14 AM, Jon Gifford wrote: >

Re: SolrCloud - Using collections, slices and shards in the wild

On Wed, Feb 10, 2010 at 8:04 AM, Yonik Seeley wrote: > On Wed, Feb 10, 2010 at 12:02 AM, Jon Gifford wrote: >> Alternatively, I could create a collection per customer, which removes >> the need for slices, but means duplicating the schema many times. > > Multiple collections should be able to sha

Re: SolrCloud - Using collections, slices and shards in the wild

On Wed, Feb 10, 2010 at 12:02 AM, Jon Gifford wrote: > Alternatively, I could create a collection per customer, which removes > the need for slices, but means duplicating the schema many times. Multiple collections should be able to share a single config (schema and related config files). [...]

[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=12832008#action_12832008 ] Grant Ingersoll commented on SOLR-773: -- Just an update here on other work related to thi

Build failed in Hudson: Solr-trunk #1055

See Changes: [noble] SOLR-1767: dataimporter.functions.escapeSql() does not escape backslash character [noble] * SOLR-1766: DIH with threads enabled doesn't respond to the abort command [markrmiller] SOLR-1722: Allowing chang

Starting solr and connecting to it in the same process

There is something really interesting going on when I try to start Solr and then connect to it in the same process. I get a "connection refused" error. The code I try to use is found below. If I start solr with runtime.exec("java -jar start.jar") it works fine to connect to it afterwards, but if I