Solr 5.2+ using SSL and non-SSL ports

Previously I have configured Solr 4.x deployments with both SSL (https) and non-SSL (http) via Jetty configurations. I know the way to configure SSL in Solr 5.2+ has changed. I followed these instructions and was able to successfully configure a standalone Solr instance for SSL on port 8984:

Re: How to train the model using user clicks when use ltr(learning to rank) module?

ah. very nice Diego. Thanks. On 1/6/2017 1:52 PM, Diego Ceccarelli (BLOOMBERG/ LONDON) wrote: Hi Jeffery, I submitted a patch to the README of the learning to rank example folder, trying to explain better how to produce a training set given a log with interaction data. Patch is available

use psuedo-field in json.facet api

Hi, can we use a psuedo-field in json.facet api ? is there any example like the one below ? json.facet={ my_histogram: { type: terms, field: new_field:my_function(my_solr_field, "return_as_integer") } } Thanks, Radhakrishnan D

Shards not working with basic authentication

Hello!We are on Solr 5.4.1 and basic authentication is enabled.We are trying to use shards to combine 2 Solr cores but getting a "401 Unauthorized" error while querying from the admin UI. Basically internal connection errors out with shards. Also tried using "shardcredentials" as mentioned here

Re: Subqueries

Denormalising works on small numbers, but it hits ceil quite soon, because it scales hard. People did such snippet enrichment in apps for ages. There is nothing special in it. Probably someone can port it to 4.10 as a plugin. On Sat, Jan 7, 2017 at 12:08 AM, Peter Matthew Eichman

Re: MLT Performance Degraded Between 4.6.1 and 5.5.2 Solr

After some more digging, I narrowed it down to filtering.  Without any filters, the MLT is back to it's normal performance (8ms average response time for our case).  The issue goes away with 6.0 upgrade.  The hot method is Lucene's DisiPriorityQueue downHeap(), which takes 5X more calls in

Re: Subqueries

Thanks, we will look into the feasibility of a Solr upgrade. If not, is there anything in 4.10 that would allow us to do something similar, or would we be stuck with denormalizing our data at index time? -Peter On Fri, Jan 6, 2017 at 4:03 PM, Mikhail Khludnev wrote: >

Re: Subqueries

https://issues.apache.org/jira/browse/SOLR-8208 is resolved for 6.1. I don't know why 4.10 didn't throw exception on referring to [subquery], which is absent there. On Fri, Jan 6, 2017 at 6:23 PM, Peter Matthew Eichman wrote: > Hi Mikhail, > > I've turned on DEBUG level

Re: Strange Index not mutable error

I'm assuming you're using classic schema factory? Do this error show up in the log correlated to your use of the config API to configure CDCR? If so, please do three things: 1> raise a JIRA 2> paste the command you use to configure CDCR 3> paste in any more info from the ERROR in the log,

Re: Empty facets on TextField

We've hit this issue again since solr defaults new fields to string type which has docvalues. Changing those to be lowercase text does not remove the docvalues and breaks faceting. Is there a way to remove docvalues for a field w/o starting fresh? On Tue, Oct 18, 2016 at 8:19 PM, Yonik Seeley

Re: How to train the model using user clicks when use ltr(learning to rank) module?

Hi Jeffery, I submitted a patch to the README of the learning to rank example folder, trying to explain better how to produce a training set given a log with interaction data. Patch is available here: https://issues.apache.org/jira/browse/SOLR-9929 And you can see the new version of the

Re: CDCR How to recover from Corrupted transaction log

On 1/6/2017 10:09 AM, Webster Homer wrote: > This happened while testing and was not in a production system. So we > just deleted both collections and recreated them after fixing the root > cause. If this had been a production system that would not have been > acceptable. What is the best way to

Re: CDCR How to recover from Corrupted transaction log

If you just deleted the tlog files on the source, you'd likely miss updates, right? I can think of two ways to get source and target back in sync: 1> go ahead and delete the tlogs, then re-index from some point guaranteed to have been propagated to the target _before_ the tlog went wonky. 2>

CDCR How to recover from Corrupted transaction log

We recently had a problem where the solr transaction log became corrupted during a data load. The collection was a CDCR source and we started seeing problems on both source and target. This happened while testing and was not in a production system. So we just deleted both collections and

Re: error during running my code java.lang.VerifyError: Bad type on operand stack

Hi, I found the same thing listed here at : http://googleweblight.com/?lite_url=http://stackoverflow.com/questions/32105513/solr-bad-return-type-error=xQ0ZJDXt=en-IN=1=940=www.google.co.in=1483722084=AF9NedkxZ3LIU1o5BOd8inhSmW5Q5azbHA HttpSolrClient has a constructor that accepts an HttpClient.

Re: Need help for this scenario

Hello Shahi, would you clarify your requirement or issue from Solr perspective. From the above its not clear what you are asking. You use Solr for indexing some data which later you can search upon. Keeping this in mind, can you elaborate what kind of data you are indexing and what are you

Re: error during running my code java.lang.VerifyError: Bad type on operand stack

Which solrj version are you using and can you point which line exactly throws the error? Thnx On Fri, Jan 6, 2017 at 2:04 AM, gayathri...@tcs.com wrote: > Hi > > Im using solr 5.4.0 while running my code i get below eroor please suggest > what has to be done > >

Re: SolrCloud different score for same document on different replicas.

I was seeing something like this, and it turned out to be a problem with our autoCommit and autoSoftCommit settings. We had overly aggressive settings that eventually started failing with errors around too many warming searchers etc... You can test this by doing a commit and seeing if the

Re: CDCR logging is Needlessly verbose, fills up the file system fast

On 1/6/2017 8:21 AM, Webster Homer wrote: > I figured our problem with the filesystem, by default the root logger > is configured with the CONSOLE logger, which is NOT rotated and > eventually filled up the file system. That doesn't exonerate the CDCR > logging problem though. The thing writes a

Re: Subqueries

Hi Mikhail, I've turned on DEBUG level logging, but I still only see the main request logged, and no requests for the subqueries. Could it be a version issue? We are running Solr 4.10. Thanks, -Peter On Fri, Jan 6, 2017 at 1:56 AM, Mikhail Khludnev wrote: > Peter, > Subquery

Strange Index not mutable error

I occasionally see this error in our logs: 2017-01-05 20:48:46.664 ERROR (SolrConfigHandler-refreshconf) [c:sial-catalog-material s:shard2 r:core_node2 x:sial-catalog-material_shard2_replica1] o.a.s.s.IndexSchema This IndexSchema is not mutable. None of our indexes are mutable, nor are we trying

Re: CDCR logging is Needlessly verbose, fills up the file system fast

I figured our problem with the filesystem, by default the root logger is configured with the CONSOLE logger, which is NOT rotated and eventually filled up the file system. That doesn't exonerate the CDCR logging problem though. The thing writes a huge amount of junk to the logs, information that

Re: Commit required after delete ?

Hello, Friend! You absolutely need to commit to make delete visible. And even more, when "softCommit" is issued in Lucene level, there is a flag which ignores deletes for sake of performance. 06 янв. 2017 г. 10:55 пользователь "Dorian Hoxha" написал: Hello friends,