Hi,
We have upgraded our solrCloud from version 6.6.0 to 8.2.0
At the time of indexing intermittently we are observing socketTimeout
exception when using Collection apis. example when we try reloading one of
the collection using CloudSolrClient class.
Is there any performance degradation in
You are too much focus on the solution. If you would describe the business case
in more detail without including the solution itself more people could help.
Eg it ie not clear why you have a scoring model and why this can address
business needs.
> Am 18.02.2020 um 01:50 schrieb Ashwin Ramesh
Note, {!terms} query is more efficient for long ids list. I'd try to group
ids by boost, and cache long ids lists. Something like:
q=filter({!terms f=id}1,3,5)^=100 filter({!terms f=id}2,4,6)^=-1
Thus, it let to reuse heavy terms lists between queries.
Another idea, extract boost score to the
I didn’t respond because it seemed like you were stuck on an approach that would
never be efficient in Solr. It requires massive amounts of data applied to
documents
in a fine-grained way. Maybe it makes the math easier, but the data management
is impractical. I could not see any way to make
I don’t think anyone is responding because it’s too focused of a use case,
where you just simply have to figure out an alternative on your own.
> On Feb 19, 2020, at 12:28 AM, Ashwin Ramesh wrote:
>
> ping on this :)
>
>> On Tue, Feb 18, 2020 at 11:50 AM Ashwin Ramesh wrote:
>>
>> Hi,
>>
ping on this :)
On Tue, Feb 18, 2020 at 11:50 AM Ashwin Ramesh wrote:
> Hi,
>
> We are in the process of applying a scoring model to our search results.
> In particular, we would like to add scores for documents per query and user
> context.
>
> For example, we want to have a score from 500 to
I think what you want is to just configure TolerantUpdateProcessorFactory
in solrconfig.xml as part of your update chain and specify the _version_
field as appropriate in the URL you referenced.
You can configure TolerantUpdateProcessorFactory to limit the number
of errors allowed before
Hi,
I am trying to use *must-exist* and *must-not-exist* semantics of
optimistic concurrency provided by Solr. When doing batch updates SolrM
stops indexing immediately when it encounters a conflict. It does not
process subsequent records in the input list.
That is one extreme. And the other
Again depending on the version of Solr, but the metrics end point (added in
6.4) has a TON of information. Be prepared to wade through it for half a day to
find out the things you need ;). There are something like 150 different metrics
returned…
Frankly I don’t remember if cache RAM usage is
