Re: Could not find configName error
i am using SOLR 4.10.3 I am not sure I have them in source control. I don't actually know what that is. I am using SOLR on a pre-setup VM. On Tue, Sep 5, 2017 at 5:26 PM, Erick Erickson wrote: > What version of Solr? > > bin/solr zk -help > > In particular upconfig can be used to move configsets up to Zookeeper > (or back down or whatever) in relatively recent versions of Solr. Yo > are keeping them in source control right? ;) > > Best, > Erick > > On Mon, Sep 4, 2017 at 11:27 PM, Wael Kader wrote: > > Hi, > > > > I had some issues in SOLR shutting down on a single node application on > > Hadoop. > > > > After starting up i got the error: > > Could not find configName for collection XXX found. > > > > I know the issue is that the configs has issues in Zookeeper but I would > > like to know how I can push this configuration back to get the index > > running. > > > > -- > > Regards, > > Wael > -- Regards, Wael
Phrase boosting on multiple fields
I have a situation where I have to apply phrase boosting on multiple fields. I am using Edismax as query parser. For instance, I am accepting a keyword (phrase) from the user and I want the doc with the exact phrase to be on the top of the resultant list. The problem is, there are multiple fields to be queried upon. I could find some assistance from the code below but again it works on a single field only. q=java+design+patterns&defType=edismax&qf=name&pf2=name^30&ps=0 Any kind of suggestion would be helpful. Best, Ritesh Kumar
Solr6.6 Issue/Bug
Dear team, I am using solr 5.0 last 1 year, now we are planning to upgrade solr 6.6. While trying to start solr using root user, we need to pass -force parameter to start solr forcefully, please help to start solr using root user without -force command. Regards Kasim J.
Re: Could not find configName error
What version of Solr? bin/solr zk -help In particular upconfig can be used to move configsets up to Zookeeper (or back down or whatever) in relatively recent versions of Solr. Yo are keeping them in source control right? ;) Best, Erick On Mon, Sep 4, 2017 at 11:27 PM, Wael Kader wrote: > Hi, > > I had some issues in SOLR shutting down on a single node application on > Hadoop. > > After starting up i got the error: > Could not find configName for collection XXX found. > > I know the issue is that the configs has issues in Zookeeper but I would > like to know how I can push this configuration back to get the index > running. > > -- > Regards, > Wael
Re: Solr Poc -Help Needed
This might be useful: https://lucene.apache.org/solr/6_6_0//solr-core/org/apache/solr/update/processor/UUIDUpdateProcessorFactory.html On Tue, Sep 5, 2017 at 4:13 AM, Rick Leir wrote: > Harshal, > Look in solrconfig.xml, this needs to be configured based on one or more > fields. > Cheers -- Rick > > On September 4, 2017 11:40:29 PM EDT, "Agrawal, Harshal (GE Digital)" > wrote: >>Hello All, >> >>I am looking to index csv file/ PDF documents. I want solr to generate >>unique key itself. >>I tried to index one file. I am able to configure data config, Solr >>config and Schema file. But I am getting following error while >>indexing: >> >>org.apache.solr.common.SolrException: Document is missing mandatory >>uniqueKey field: id. >> >>Please find attached config files and data files which I am using. >> >>Kindly help me in fixing this issue: >> >>Regards >>Harshal > > -- > Sorry for being brief. Alternate email is rickleir at yahoo dot com
Re: unordered autocomplete search
Hi Mikhail, Thank you so much for your inpu. I am looking into this and let you know when I've tried this. @Walter: indeed, it should be included :). If my code works, I'll post it here. Many thanks, Niraj On Mon, Sep 4, 2017 at 5:27 PM, Walter Underwood wrote: > This should probably be a feature of the analyzing infix suggester. > > Right now, the fuzzy suggester is broken with the file dictionary, so we > can’t use fuzzy suggestions at all. > > wunder > Walter Underwood > wun...@wunderwood.org > http://observer.wunderwood.org/ (my blog) > > > > On Sep 4, 2017, at 4:50 AM, Mikhail Khludnev wrote: > > > > You probably can override AnalyzingInfixSuggester.finishQuery(Builder, > > boolean) where you can rip clauses from builder and change TermQueries/ > > PrefixQuery to FuzzyQueries. Let me know how it works, please. > > > > On Mon, Sep 4, 2017 at 2:27 PM, Niraj Aswani > wrote: > > > >> Hi Mikhali, > >> > >> Thank you very much for your quick response. > >> > >> This does seem to fix the issue of unordered words in the autocomplete, > >> however, then I loose the capability of matching misspelled words. > >> > >> Is there anything that can be done to combine the functionality of the > two? > >> > >> Regards, > >> Niraj > >> > >> > >> > >> On Mon, Sep 4, 2017 at 11:13 AM, Mikhail Khludnev > wrote: > >> > >>> The first question is, "sourceLocation">test.dict makes sense? > >>> Then, for me, it looks like a case for AnalyzingInfixLookupFactory > >>> https://lucidworks.com/2015/03/04/solr-suggester/ rather than > >>> > >>> - The FuzzyLookupFactory that creates suggestions for misspelled > words > >>> in fields. > >>> > >>> > >>> > >>> > >>> On Mon, Sep 4, 2017 at 11:57 AM, Niraj Aswani > >>> wrote: > >>> > Hi, > > I am using solr 5.5.4. > > I would like to perform an unordered autocomplete search however it > >> seems > that it only suggests phrases that start with my term in the query. > > For example, in my dictionary I have, > > *lamp desk* > > When searching for the term "lamp", it is able to show the the > >> suggestion > "lamp desk" as the suggestion is starting with the word "lamp". > >> However, > when I search for the term "desk", it doesn't show any suggestion. > > My field in the *managed-schema* is as below: > > positionIncrementGap="100"> > > > > > > > > > > My controller in *solconfig.xml* is defined as the following: > > > > > default > FuzzyLookupFactory > test.dict > suggest_field > > > > >>> startup="lazy"> > > true > 10 > > > suggest > > > > The *query* I fire is: > > http://localhost:8983/solr/core1/suggest?q=desk&suggest.build=true > > is there anyway, I can get the above scenario working? > > Many thanks, > Niraj > > >>> > >>> > >>> > >>> -- > >>> Sincerely yours > >>> Mikhail Khludnev > >>> > >> > > > > > > > > -- > > Sincerely yours > > Mikhail Khludnev > >
Re: slow solr facet processing
Toke Eskildsen kirjoitti 5.9.2017 klo 13.49: On Mon, 2017-09-04 at 11:03 -0400, Yonik Seeley wrote: It's due to this (see comments in UnInvertedField): I have read that. What I don't understand is the difference between 4.x and 6.x. But as you say, Ere seems to be in the process of verifying whether this is simply due to more segments in 6.x. During my testing I never optimized the 4.x index, so unless it maintains a minimal number of segments automatically, there's something else too. There's probably a number of ways we can speed this up somewhat: - optimize how much memory is used to store the term index and use the savings to store more than every 128th term - store the terms contiguously in block(s) I'm considering taking a shot at that. A fairly easy optimization would be to replace the BytesRef[] indexedTermsArray with a BytesRefArray. I'd be happy to try out any patches.. :) --Ere -- Ere Maijala Kansalliskirjasto / The National Library of Finland
RE: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
The java.security files are the same. I even copied over the files from a machine that is working and renamed the security files and it still did not work.. I am getting the same error. -Original Message- From: Younge, Kent A - Norman, OK - Contractor [mailto:kent.a.you...@usps.gov.INVALID] Sent: Tuesday, September 05, 2017 6:54 AM To: solr-user@lucene.apache.org Subject: RE: ERR_SSL_VERSION_OR_CIPHER_MISMATCH The new box is a clone of all the boxes so nothing should have changed other than the certificates and the keystore. That is why I am at such a loss on this issue. Java is the same across five servers all settings are the same across five servers. I will look into the JVM security and see if it is the same across all the boxes. -Original Message- From: Chris Hostetter [mailto:hossman_luc...@fucit.org] Sent: Friday, September 01, 2017 5:46 PM To: solr-user@lucene.apache.org Subject: Re: ERR_SSL_VERSION_OR_CIPHER_MISMATCH all of the low level SSL code used by Solr comes from the JVM. double check which version of java you are using and make sure it's consistent on all of your servers -- if you disable SSL on the affected server you can use the Solr Admin UI to be 100% certain of exactly which version of java is being used... https://lucene.apache.org/solr/guide/6_6/overview-of-the-solr-admin-ui.html If the JVM Runtime *versions* are identicle, the next thing to check would be the the JVM security settings which control which ciphers are used. For Oracle JVMs this file is named "java.security" -- compare that file between your functional/non-functional servers. There are lots of docs out there on SSL protocol and cipher configuration in java's java.security file, here's a quick one that links deep into the details of enabling/disabling protocols... http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSE_Protocols ...but the bottomline is: you probably want to fix your broken server to match your working servers, and unless the JVM versions are different, that means someone/thing must have modified the JVM security settings on one of your servers -- find out who & why. -Hoss http://www.lucidworks.com/
Re: slow solr facet processing
Yonik Seeley kirjoitti 4.9.2017 klo 18.03: It's due to this (see comments in UnInvertedField): * To further save memory, the terms (the actual string values) are not all stored in * memory, but a TermIndex is used to convert term numbers to term values only * for the terms needed after faceting has completed. Only every 128th term value * is stored, along with its corresponding term number, and this is used as an * index to find the closest term and iterate until the desired number is hit There's probably a number of ways we can speed this up somewhat: - optimize how much memory is used to store the term index and use the savings to store more than every 128th term - store the terms contiguously in block(s) - don't store the whole term, only store what's needed to seek to the Nth term correctly - when retrieving many terms, sort them first and convert from ord->str in order For what it's worth, I've now tested on our production servers that can hold the full index in memory, and the results are in line with the previous ones (47 million records, 1785 buckets in the tested facet): 1.) index with docValues="true": - unoptimized: ~6000ms if facet.method is not specified - unoptimized: ~7000ms with facet.method=uif - optimized: ~7800ms if facet.method is not specified - optimized: ~7700ms with facet.method=uif Note that optimization took its time and other activity varies throughout the day, so the numbers between optimized and unoptimized cannot be directly compared. Still bugs me a bit that the optimized index seems to be a bit slower here. 2.) index with docValues="false": - unoptimized: ~2600ms if facet.method is not specified - unoptimized ~1200ms with facet.method=uif - optimized: ~2600ms if facet.method is not specified - optimized: ~17ms with facet.method=uif --Ere -- Ere Maijala Kansalliskirjasto / The National Library of Finland
RE: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
The new box is a clone of all the boxes so nothing should have changed other than the certificates and the keystore. That is why I am at such a loss on this issue. Java is the same across five servers all settings are the same across five servers. I will look into the JVM security and see if it is the same across all the boxes. Thank you, Kent Younge Systems Engineer USPS MTSC IT Support 600 W. Rock Creek Rd, Norman, OK 73069-8357 O:405 573 2273 -Original Message- From: Chris Hostetter [mailto:hossman_luc...@fucit.org] Sent: Friday, September 01, 2017 5:46 PM To: solr-user@lucene.apache.org Subject: Re: ERR_SSL_VERSION_OR_CIPHER_MISMATCH all of the low level SSL code used by Solr comes from the JVM. double check which version of java you are using and make sure it's consistent on all of your servers -- if you disable SSL on the affected server you can use the Solr Admin UI to be 100% certain of exactly which version of java is being used... https://lucene.apache.org/solr/guide/6_6/overview-of-the-solr-admin-ui.html If the JVM Runtime *versions* are identicle, the next thing to check would be the the JVM security settings which control which ciphers are used. For Oracle JVMs this file is named "java.security" -- compare that file between your functional/non-functional servers. There are lots of docs out there on SSL protocol and cipher configuration in java's java.security file, here's a quick one that links deep into the details of enabling/disabling protocols... http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSE_Protocols ...but the bottomline is: you probably want to fix your broken server to match your working servers, and unless the JVM versions are different, that means someone/thing must have modified the JVM security settings on one of your servers -- find out who & why. -Hoss http://www.lucidworks.com/
Re: slow solr facet processing
The number-of-segments noise probably swamps this... but one optimization around deep-facet-paging that didn't get carried forward is https://issues.apache.org/jira/browse/SOLR-2092 -Yonik On Tue, Sep 5, 2017 at 6:49 AM, Toke Eskildsen wrote: > On Mon, 2017-09-04 at 11:03 -0400, Yonik Seeley wrote: >> It's due to this (see comments in UnInvertedField): > > I have read that. What I don't understand is the difference between 4.x > and 6.x. But as you say, Ere seems to be in the process of verifying > whether this is simply due to more segments in 6.x. > >> There's probably a number of ways we can speed this up somewhat: >> - optimize how much memory is used to store the term index and use >> the savings to store more than every 128th term >> - store the terms contiguously in block(s) > > I'm considering taking a shot at that. A fairly easy optimization would > be to replace the BytesRef[] indexedTermsArray with a BytesRefArray. > > - Toke Eskildsen, Royal Danish Library >
Re: Solr Poc -Help Needed
Harshal, Look in solrconfig.xml, this needs to be configured based on one or more fields. Cheers -- Rick On September 4, 2017 11:40:29 PM EDT, "Agrawal, Harshal (GE Digital)" wrote: >Hello All, > >I am looking to index csv file/ PDF documents. I want solr to generate >unique key itself. >I tried to index one file. I am able to configure data config, Solr >config and Schema file. But I am getting following error while >indexing: > >org.apache.solr.common.SolrException: Document is missing mandatory >uniqueKey field: id. > >Please find attached config files and data files which I am using. > >Kindly help me in fixing this issue: > >Regards >Harshal -- Sorry for being brief. Alternate email is rickleir at yahoo dot com
Re: slow solr facet processing
On Mon, 2017-09-04 at 11:03 -0400, Yonik Seeley wrote: > It's due to this (see comments in UnInvertedField): I have read that. What I don't understand is the difference between 4.x and 6.x. But as you say, Ere seems to be in the process of verifying whether this is simply due to more segments in 6.x. > There's probably a number of ways we can speed this up somewhat: > - optimize how much memory is used to store the term index and use > the savings to store more than every 128th term > - store the terms contiguously in block(s) I'm considering taking a shot at that. A fairly easy optimization would be to replace the BytesRef[] indexedTermsArray with a BytesRefArray. - Toke Eskildsen, Royal Danish Library
