The Learning To Rank result is treated as an input to a function

Hi all: How to embed a linear formula calculation in the outer layer of Learning To Rank? We need to do a calculation on the score of Learning To Rank. For example，normal use of Learning To Rank looks like this，I'm going to get a score: rq={!ltr model=myModel reRankDocs=100} I want the

Unable to start solr node with sysprop to form a nodeset

Hi, I am trying to apply some cluster level autoscaling policies and for that I am trying to create a nodeset. There are some of the ways to create a nodeset(selecting a set of nodes on basis of some rules) as per docs :

Fw: Unable to start solr node with sysprop to form a nodeset

From: Yatin Grover Sent: Wednesday, March 4, 2020 11:46 AM To: solr-user@lucene.apache.org Subject: Unable to start solr node with sysprop to form a nodeset Hi, I am trying to apply some cluster level autoscaling policies and for that I am trying to create a

Re: Custom update processor and race condition with concurrent requests

Thanks for the reply, Chris. Sure, I will start from the beginning and explain the problem I'm trying to solve. We have objects which we index in Solr. They go through state transitions based on various events in their life. But, the events can come out of sequence. So, to maintain that

RE: Solr Search cause high CPU with **

According to the documentation, the standard query parser uses asterisks to do wild card searches[1]. If you do not need to do wildcard queries and what you are trying to do is to use the asterisks as a search term, you should escape it[2] [1]

Sorting on an empty filter

Hi SOLR Community, I've observed while hosting a SOLR 6.6 installation that if I issue a query where the filter query returns an empty set but there is a sort associated with it, the query takes an extended time to execute over the query with only the filter query and no sort associated to it.

Re: Custom update processor and race condition with concurrent requests

I guess I’m missing something. Assuming that S1 and S2 are sent in different batches from different threads from your client, there are any number of ways they could arrive out of order. Network delays, client delays, etc. So I don’t se any way to serialize them reliably. If they’re sent

Re: Custom update processor and race condition with concurrent requests

It sounds like fundementally the problem you have is that you want solr to "block" all updates to docId=X ... at the update processor chain level ... until an existing update is done. but solr has no way to know that you want to block at that level. ie: you asked... : In the case of multiple

Re: Custom update processor and race condition with concurrent requests

Thank, Erick. I think I was not clear enough. With the custom update processor, I'm not using optimistic concurrency at all. The update processor just modifies the incoming document with updated field values and atomic update instructions. It then forwards the modified request further in the

Re: Custom update processor and race condition with concurrent requests

I don’t really see how this test setup can work, I think you’re just getting lucky with the 4 threads. But let’s be specific about what optimistic concurrency is. If you update a document that has a _version_ field, and that document already exists with a value in the _version_ field higher

Custom update processor and race condition with concurrent requests

Hi, We are using Solr where there are many update operations. This may not be the right use case for Solr but it's an old application and at this moment we are in no mood to replace Solr with something else. For one of our use case, we had to use optimistic concurrency for handling concurrent

Solr Search cause high CPU with **

Hello we are using SOLR 6.6. we recently noticed unusual CPU spike. while one of customer did search with ** in query string. we had customer who searched for following term q = N*W* 154 ** underpass it caused CPU to go above 80%. our normal range of CPU is around 20%. I wanted to know few

Re: collect reload causes a big latency spike

Hey Erick. Our CI process will do the following whenever it detects either a schema or solrconfig change: * Upload the new configuration to zookeeper * Link it to the existing collection * Reload collection This might be for something as simply as tweaking the caches. I'd say on

Re: collect reload causes a big latency spike

Reload throws most everything away, there's no provision for autowarming from the old caches. Consider that schema and solrconfig may have changed, so there would be lots of places could go wrong. I have to ask why you're reloading often enough to see this? This is a heavyweight action, really

collect reload causes a big latency spike

Hi Everyone, When we use the solr collections API to reload a collection, we get a large latency spike in requests. I'm surprised by this because when we do new soft commits, our warming means they're near enough undetectable. Could anyone confirm if solr collection reload not use the

Re: Solr on Openshift - Best practices (Kubernetes)

You may want to check out https://github.com/bloomberg/solr-operator (Not tried it) Jan > 2. mar. 2020 kl. 12:46 skrev Alvaro Lopez Medina : > > Good morning, > > I am currently working on a demo to run a Solr cluster on Openshift (OCP). > Currently, Openshift does not work with Helm out of