Facing issue while writing more than one DIH for a core.

Hi All, Below is the DIH configurations for the Data import handlers for a core. *For DIH-1:* https://stackoverflow.com/feeds/tag/solr"; processor="XPathEntityProcessor" dataSource="URLDataSource" forEach="/feed|/feed/entry" transformer="HTMLStripTransformer,RegexTransformer">

HDFS replication factor

Hi, when I configure my HDFS setup to use a specific replication factor, like 1, this only effects the index files that Solr writes. The write.lock files and backups are being created with a different replication factor. The reason for this should be that HdfsFileWriter is loading the default

Re: ***UNCHECKED*** Limit Solr search to number of character/words (without changing index)

Sure, use TruncateFieldUpdateProcessorFactory in your update chain, here's the base definition: trunc 5 This _can_ be configured to operate on "all StrField", or "all TextFields" as well, see the Javadocs. This is static, that is the field is truncated at index time s

Re: AW: AW: SolrClient#updateByQuery?

Clemens: Let's not raise a JIRA quite yet. I am 99% sure your test is not doing what you think or you have some invalid expectations. This is such a fundamental feature that it'd surprise me a _lot_ if it were a bug. Also, there are a bunch of DeleteByQuery tests in the junit tests that's run all

AW: AW: AW: SolrClient#updateByQuery?

Erick said/wrote: > If you commit after docs are deleted and _still_ see them in search results, > that's a JIRA should I JIRA it? -Ursprüngliche Nachricht- Von: Shawn Heisey [mailto:apa...@elyograg.org] Gesendet: Samstag, 27. Januar 2018 12:05 An: solr-user@lucene.apache.org Betreff: Re

Re: ***UNCHECKED*** Limit Solr search to number of character/words (without changing index)

Thanks. I do not want to search if the query is shorter than a certain number of terms/characters. For example, I have a 10MB document indexed in Solr what I want is to search query in first 1MB content of that indexed document. Any workaround e.g .can I send query to Solr to look for only 1MB f

Re: Using replicas in SOLR-6.5.1

1. You are right, due to memory and garbage collection issues I set each shard to different VM. So in my VM I has 50 GB RAM (10 GB for JVM and 40 GB for index) and it works good for my using case. Maybe I don't understand solr terms, but if you say to set one VM for 20 shards what does it mean? 20

Re: Using replicas in SOLR-6.5.1

1. You could just have 2 VMs, one has all 20 shards of your collection, the other one has the replicas for those shards. In this scenario, if one VM is not available, you still have application availability as at least one replica is available for each shard. This assumes that your VM can fit all t

Re: AW: AW: SolrClient#updateByQuery?

On 1/27/2018 12:49 AM, Clemens Wyss DEV wrote: Thanks for all these (main contributor's 😉) valuable inputs! First thing I did was getting getting rid of "expungeDeletes". My "single-deletion" unittest failed unti I added the optimize-param updateReques.setParam( "optimize", "true" ); Does thi

Using replicas in SOLR-6.5.1

I use SOLR-6.5.1. I would like to use SolrCloud replicas. And I have some questions: 1) What is the best architecture for this if my collection contains 20 shards, and each shard is in different vm? 40 vms where 20 for leaders and 20 for replicas? Or maybe stay with 20 vms where leader and replica

RE: 7.2.1 cluster dies within minutes after restart

Hello, I grepped for it yesterday and found nothing but 3 in the settings, but judging from the weird time out value, you may be right. Let me apply your patch early next week and check for spurious warnings. Another note worthy observation for those working on cloud stability and recovery

AW: AW: SolrClient#updateByQuery?

Thanks for all these (main contributor's 😉) valuable inputs! First thing I did was getting rid of "expungeDeletes". My "single-deletion" unittest failed until I added the optimize-param > updateReques.setParam( "optimize", "true" ); Does this make sense or should JIRA it? How expensive is this