UpdateProcessorChains -cdcr processor along with ignore commit processor

[Natarajan, Rajeswari]

Resending this again as I still could not make this work. So would like to know 
if this is even possible to have
both solr.CdcrUpdateProcessorFactory and 
solr.IgnoreCommitOptimizeUpdateProcessorFactory  in solrconfig.xml and get both 
functionalities work.
Please let me know.

Thank you,
Rajeswari
 
On 7/14/20, 12:40 PM, "Natarajan, Rajeswari"  
wrote:

Hi ,

Would like to have these two processors (cdcr and ignorecommit)  in 
solrconfig.xml .

But cdcr fails with below error , with either cdcr-processor-chain or 
ignore-commit-from-client chain

version conflict for 60d35f0850afac66 expected=1671629672447737856 
actual=-1, retry=0 commError=false errorCode=409



 

  

cdcr-processor-chain

  







  

  









  

200

  



  





Also tried as below. Getting error comaplining about custom processor



  

custom

  
>









 200






  



Is there a way these two processors can be applied together.

Thanks,
Rajeswari

Re: [ANNOUNCE] Apache Solr 8.6.0 released

[Aroop Ganguly]

May we ask what in hdfs support is being deprecated? Is Hdfs backup and restore 
being deprecated ? 

Sent from my iPhone

> On Jul 15, 2020, at 3:41 PM, Houston Putman  wrote:
> 
> To address your concern Bernd,
> 
> The goal of this deprecation is not to remove the functionality entirely.
> The primary purpose is to remove the code from Solr Core. Before removing a
> feature we aim to either:
> 
>   - Move the code to another repository, and have it be loadable via a
>   plugin
>   - Replace the feature with something more stable and/or scalable.
>   (Likely loadable via a plugin or run in a separate application)
> 
> I understand your frustration, but the ultimate goal here is to make Solr
> more customizable and plugable (and therefore learner by default). This way
> the base Solr functionality can be as bug-free and performant as possible,
> and any extra features can be added on top as needed.
> 
> We would appreciate feedback for how the community would prefer these
> features be provided in the future, so that we make the transition smoother
> and the end product better.
> 
> - Houston
> 
>> On Wed, Jul 15, 2020 at 5:51 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> 
>> On Wed, 15 Jul, 2020, 8:37 pm Bernd Fehling, <
>> bernd.fehl...@uni-bielefeld.de>
>> wrote:
>> 
>>> 
>>> 
>>> Am 15.07.20 um 16:07 schrieb Ishan Chattopadhyaya:
 Dear Solr Users,
 
 In this release (Solr 8.6), we have deprecated the following:
 
  1. Data Import Handler
 
  2. HDFS support
 
  3. Cross Data Center Replication (CDCR)
 
>>> 
>>> Seriously? :-(
>>> 
>> 
>> Please see SOLR-14022.
>> 
>> 
>>> So next steps will be kicking out Cloud and go back to single node or
>> what?
>>> 
>> 
>> Not something we've considered yet.
>> 
>> 
>>> Why don't you just freeze the whole Solr development and switch to
>> Elastic?
>>> 
>> 
>> Not something we've considered yet.
>> 
>> 
>>> 
 
 
 All of these are scheduled to be removed in a future 9.x release.
 
 It was decided that these components did not meet the standards of
>>> quality
 and support that we wish to ensure for all components we ship. Some of
 these also relied on design patterns that we no longer recommend for
>> use
>>> in
 critical production environments.
 
 If you rely on these features, you are encouraged to try out community
 supported versions of these, where available [0]. Where such community
 support is not available, we encourage you to participate in the
>>> migration
 of these components into community supported packages and help continue
>>> the
 development. We envision that using packages for these components via
 package manager will actually make it easier for users to use such
>>> features.
 
 Regards,
 
 Ishan Chattopadhyaya
 
 (On behalf of the Apache Lucene/Solr PMC)
 
 [0] -
 
>>> 
>> https://cwiki.apache.org/confluence/display/SOLR/Community+supported+packages+for+Solr
 
 On Wed, Jul 15, 2020 at 2:30 PM Bruno Roustant <
>> bruno.roust...@gmail.com
 
 wrote:
 
> The Lucene PMC is pleased to announce the release of Apache Solr
>> 8.6.0.
> 
> 
> Solr is the popular, blazing fast, open source NoSQL search platform
>>> from
> the Apache Lucene project. Its major features include powerful
>> full-text
> search, hit highlighting, faceted search, dynamic clustering, database
> integration, rich document handling, and geospatial search. Solr is
>>> highly
> scalable, providing fault tolerant distributed search and indexing,
>> and
> powers the search and navigation features of many of the world's
>> largest
> internet sites.
> 
> 
> Solr 8.6.0 is available for immediate download at:
> 
> 
>  
> 
> 
> ### Solr 8.6.0 Release Highlights:
> 
> 
> * Cross-Collection Join Queries: Join queries can now work
> cross-collection, even when shared or when spanning nodes.
> 
> * Search: Performance improvement for some types of queries when
>> exact
> hit count isn't needed by using BlockMax WAND algorithm.
> 
> * Streaming Expression: Percentiles and standard deviation
>> aggregations
> added to stats, facet and time series.  Streaming expressions added to
> /export handler.  Drill Streaming Expression for efficient and
>> accurate
> high cardinality aggregation.
> 
> * Package manager: Support for cluster (CoreContainer) level plugins.
> 
> * Health Check: HealthCheckHandler can now require that all cores are
> healthy before returning OK.
> 
> * Zookeeper read API: A read API at /api/cluster/zk/* to fetch raw ZK
> data and view contents of a ZK directory.
> 
> * Admin UI: New panel with security info in admin UI's dashboard.
> 
> * Query DSL: Support for {param:ref} and {bool: 

Re: [ANNOUNCE] Apache Solr 8.6.0 released

[Houston Putman]

To address your concern Bernd,

The goal of this deprecation is not to remove the functionality entirely.
The primary purpose is to remove the code from Solr Core. Before removing a
feature we aim to either:

   - Move the code to another repository, and have it be loadable via a
   plugin
   - Replace the feature with something more stable and/or scalable.
   (Likely loadable via a plugin or run in a separate application)

I understand your frustration, but the ultimate goal here is to make Solr
more customizable and plugable (and therefore learner by default). This way
the base Solr functionality can be as bug-free and performant as possible,
and any extra features can be added on top as needed.

We would appreciate feedback for how the community would prefer these
features be provided in the future, so that we make the transition smoother
and the end product better.

- Houston

On Wed, Jul 15, 2020 at 5:51 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> On Wed, 15 Jul, 2020, 8:37 pm Bernd Fehling, <
> bernd.fehl...@uni-bielefeld.de>
> wrote:
>
> >
> >
> > Am 15.07.20 um 16:07 schrieb Ishan Chattopadhyaya:
> > > Dear Solr Users,
> > >
> > > In this release (Solr 8.6), we have deprecated the following:
> > >
> > >   1. Data Import Handler
> > >
> > >   2. HDFS support
> > >
> > >   3. Cross Data Center Replication (CDCR)
> > >
> >
> > Seriously? :-(
> >
>
> Please see SOLR-14022.
>
>
> > So next steps will be kicking out Cloud and go back to single node or
> what?
> >
>
> Not something we've considered yet.
>
>
> > Why don't you just freeze the whole Solr development and switch to
> Elastic?
> >
>
> Not something we've considered yet.
>
>
> >
> > >
> > >
> > > All of these are scheduled to be removed in a future 9.x release.
> > >
> > > It was decided that these components did not meet the standards of
> > quality
> > > and support that we wish to ensure for all components we ship. Some of
> > > these also relied on design patterns that we no longer recommend for
> use
> > in
> > > critical production environments.
> > >
> > > If you rely on these features, you are encouraged to try out community
> > > supported versions of these, where available [0]. Where such community
> > > support is not available, we encourage you to participate in the
> > migration
> > > of these components into community supported packages and help continue
> > the
> > > development. We envision that using packages for these components via
> > > package manager will actually make it easier for users to use such
> > features.
> > >
> > > Regards,
> > >
> > > Ishan Chattopadhyaya
> > >
> > > (On behalf of the Apache Lucene/Solr PMC)
> > >
> > > [0] -
> > >
> >
> https://cwiki.apache.org/confluence/display/SOLR/Community+supported+packages+for+Solr
> > >
> > > On Wed, Jul 15, 2020 at 2:30 PM Bruno Roustant <
> bruno.roust...@gmail.com
> > >
> > > wrote:
> > >
> > >> The Lucene PMC is pleased to announce the release of Apache Solr
> 8.6.0.
> > >>
> > >>
> > >> Solr is the popular, blazing fast, open source NoSQL search platform
> > from
> > >> the Apache Lucene project. Its major features include powerful
> full-text
> > >> search, hit highlighting, faceted search, dynamic clustering, database
> > >> integration, rich document handling, and geospatial search. Solr is
> > highly
> > >> scalable, providing fault tolerant distributed search and indexing,
> and
> > >> powers the search and navigation features of many of the world's
> largest
> > >> internet sites.
> > >>
> > >>
> > >> Solr 8.6.0 is available for immediate download at:
> > >>
> > >>
> > >>   
> > >>
> > >>
> > >> ### Solr 8.6.0 Release Highlights:
> > >>
> > >>
> > >>  * Cross-Collection Join Queries: Join queries can now work
> > >> cross-collection, even when shared or when spanning nodes.
> > >>
> > >>  * Search: Performance improvement for some types of queries when
> exact
> > >> hit count isn't needed by using BlockMax WAND algorithm.
> > >>
> > >>  * Streaming Expression: Percentiles and standard deviation
> aggregations
> > >> added to stats, facet and time series.  Streaming expressions added to
> > >> /export handler.  Drill Streaming Expression for efficient and
> accurate
> > >> high cardinality aggregation.
> > >>
> > >>  * Package manager: Support for cluster (CoreContainer) level plugins.
> > >>
> > >>  * Health Check: HealthCheckHandler can now require that all cores are
> > >> healthy before returning OK.
> > >>
> > >>  * Zookeeper read API: A read API at /api/cluster/zk/* to fetch raw ZK
> > >> data and view contents of a ZK directory.
> > >>
> > >>  * Admin UI: New panel with security info in admin UI's dashboard.
> > >>
> > >>  * Query DSL: Support for {param:ref} and {bool: {excludeTags:""}}
> > >>
> > >>  * Ref Guide: Major redesign of Solr's documentation.
> > >>
> > >>
> > >> Please read CHANGES.txt for a full list of new features and changes:
> > >>
> > >>
> > >>   

Re: [ANNOUNCE] Apache Solr 8.6.0 released

[Ishan Chattopadhyaya]

On Wed, 15 Jul, 2020, 8:37 pm Bernd Fehling, 
wrote:

>
>
> Am 15.07.20 um 16:07 schrieb Ishan Chattopadhyaya:
> > Dear Solr Users,
> >
> > In this release (Solr 8.6), we have deprecated the following:
> >
> >   1. Data Import Handler
> >
> >   2. HDFS support
> >
> >   3. Cross Data Center Replication (CDCR)
> >
>
> Seriously? :-(
>

Please see SOLR-14022.


> So next steps will be kicking out Cloud and go back to single node or what?
>

Not something we've considered yet.


> Why don't you just freeze the whole Solr development and switch to Elastic?
>

Not something we've considered yet.


>
> >
> >
> > All of these are scheduled to be removed in a future 9.x release.
> >
> > It was decided that these components did not meet the standards of
> quality
> > and support that we wish to ensure for all components we ship. Some of
> > these also relied on design patterns that we no longer recommend for use
> in
> > critical production environments.
> >
> > If you rely on these features, you are encouraged to try out community
> > supported versions of these, where available [0]. Where such community
> > support is not available, we encourage you to participate in the
> migration
> > of these components into community supported packages and help continue
> the
> > development. We envision that using packages for these components via
> > package manager will actually make it easier for users to use such
> features.
> >
> > Regards,
> >
> > Ishan Chattopadhyaya
> >
> > (On behalf of the Apache Lucene/Solr PMC)
> >
> > [0] -
> >
> https://cwiki.apache.org/confluence/display/SOLR/Community+supported+packages+for+Solr
> >
> > On Wed, Jul 15, 2020 at 2:30 PM Bruno Roustant  >
> > wrote:
> >
> >> The Lucene PMC is pleased to announce the release of Apache Solr 8.6.0.
> >>
> >>
> >> Solr is the popular, blazing fast, open source NoSQL search platform
> from
> >> the Apache Lucene project. Its major features include powerful full-text
> >> search, hit highlighting, faceted search, dynamic clustering, database
> >> integration, rich document handling, and geospatial search. Solr is
> highly
> >> scalable, providing fault tolerant distributed search and indexing, and
> >> powers the search and navigation features of many of the world's largest
> >> internet sites.
> >>
> >>
> >> Solr 8.6.0 is available for immediate download at:
> >>
> >>
> >>   
> >>
> >>
> >> ### Solr 8.6.0 Release Highlights:
> >>
> >>
> >>  * Cross-Collection Join Queries: Join queries can now work
> >> cross-collection, even when shared or when spanning nodes.
> >>
> >>  * Search: Performance improvement for some types of queries when exact
> >> hit count isn't needed by using BlockMax WAND algorithm.
> >>
> >>  * Streaming Expression: Percentiles and standard deviation aggregations
> >> added to stats, facet and time series.  Streaming expressions added to
> >> /export handler.  Drill Streaming Expression for efficient and accurate
> >> high cardinality aggregation.
> >>
> >>  * Package manager: Support for cluster (CoreContainer) level plugins.
> >>
> >>  * Health Check: HealthCheckHandler can now require that all cores are
> >> healthy before returning OK.
> >>
> >>  * Zookeeper read API: A read API at /api/cluster/zk/* to fetch raw ZK
> >> data and view contents of a ZK directory.
> >>
> >>  * Admin UI: New panel with security info in admin UI's dashboard.
> >>
> >>  * Query DSL: Support for {param:ref} and {bool: {excludeTags:""}}
> >>
> >>  * Ref Guide: Major redesign of Solr's documentation.
> >>
> >>
> >> Please read CHANGES.txt for a full list of new features and changes:
> >>
> >>
> >>   
> >>
> >>
> >> Solr 8.6.0 also includes features, optimizations  and bugfixes in the
> >> corresponding Apache Lucene release:
> >>
> >>
> >>   
> >>
> >>
> >> Note: The Apache Software Foundation uses an extensive mirroring network
> >> for
> >>
> >> distributing releases. It is possible that the mirror you are using may
> >> not have
> >>
> >> replicated the release yet. If that is the case, please try another
> mirror.
> >>
> >> This also applies to Maven access.
> >>
> >
>

Re: sorting help

[Dave]

That’s a good place to start. The idea was to make sure titles that started 
with a date would not always be at the forefront and the actual title of the 
doc would be sorted. 

> On Jul 15, 2020, at 4:58 PM, Erick Erickson  wrote:
> 
> Yeah, it’s always a question “how much is enough/too much”.
> 
> That looks reasonable for alphatitle, but what about title? Your original
> question was that the sorting changes depending on which field you 
> sort on. If your title field uses something that tokenizes or doesn’t
> include the same analysis chain (particularly the lowercasing
> and patternreplace) then I’d expect the order to change.
> 
> Best,
> Erick
> 
>> On Jul 15, 2020, at 4:49 PM, David Hastings  
>> wrote:
>> 
>> thanks, ill check the admin, didnt want to send a big clock of text but:
>> 
>> 
>>  -
>> -
>> 
>> Tokenizer:
>> org.apache.lucene.analysis.core.KeywordTokenizerFactoryclass:
>> solr.KeywordTokenizerFactoryluceneMatchVersion: 7.1.0
>> -
>> 
>> Token Filters:
>> org.apache.lucene.analysis.core.LowerCaseFilterFactoryclass:
>> solr.LowerCaseFilterFactoryluceneMatchVersion: 7.1.0
>> org.apache.lucene.analysis.miscellaneous.TrimFilterFactoryclass:
>> solr.TrimFilterFactoryluceneMatchVersion: 7.1.0
>> org.apache.lucene.analysis.pattern.PatternReplaceFilterFactorypattern:
>> ([^a-z])replace: allclass: solr.PatternReplaceFilterFactoryreplacement
>> luceneMatchVersion: 7.1.0
>>  -
>> 
>>  Query Analyzer:
>>  
>> 
>>  org.apache.solr.analysis.TokenizerChain
>> -
>> 
>> Tokenizer:
>> org.apache.lucene.analysis.core.KeywordTokenizerFactoryclass:
>> solr.KeywordTokenizerFactoryluceneMatchVersion: 7.1.0
>> -
>> 
>> Token Filters:
>> org.apache.lucene.analysis.core.LowerCaseFilterFactoryclass:
>> solr.LowerCaseFilterFactoryluceneMatchVersion: 7.1.0
>> org.apache.lucene.analysis.miscellaneous.TrimFilterFactoryclass:
>> solr.TrimFilterFactoryluceneMatchVersion: 7.1.0
>> org.apache.lucene.analysis.pattern.PatternReplaceFilterFactorypattern:
>> ([^a-z])replace: allclass: solr.PatternReplaceFilterFactoryreplacement
>> luceneMatchVersion: 7.1.0
>> 
>> 
>>> On Wed, Jul 15, 2020 at 4:47 PM Erick Erickson 
>>> wrote:
>>> 
>>> I’d look two places:
>>> 
>>> 1> try the admin/analysis page from the admin UI. In particular, look at
>>> what tokens actually get in the index.
>>> 
>>> 2> again, the admin UI will let you choose the field (alphatitle and
>>> title) and see what the actual indexed tokens are.
>>> 
>>> Both have the issue that I don’t know what tokenizer you are using. For
>>> sorting it better be something
>>> like KeywordTokenizer. Anything that breaks up the input into separate
>>> tokens will produce surprises.
>>> 
>>> And unless you have lowercaseFilter in front of your patternreplace,
>>> you’re removing uppercase characters.
>>> 
>>> Best,
>>> Erick
>>> 
 On Jul 15, 2020, at 3:06 PM, David Hastings <
>>> hastings.recurs...@gmail.com> wrote:
 
 howdy,
 i have a field that sorts fine all other content, and i cant seem to
>>> debug
 why it wont sort for me on this one chunk of it.
 "sort":"alphatitle asc", "debugQuery":"on", "_":"1594733127740"}},
>>> "response
 ":{"numFound":3,"start":0,"docs":[ { "title":"Money orders", {
 "title":"Finance,
 consolidation and rescheduling of debts", { "title":"Rights in former
 German Islands in Pacific", },
 
 its using a copyfield from "title" to "alphatitle" that replaces all
 punctuation
 pattern: ([^a-z])replace: allclass: solr.PatternReplaceFilterFactory
 
 and if i use just title it flips:
 
 "title":"Finance, consolidation and rescheduling of debts"}, {
>>> "title":"Rights
 in former German Islands in Pacific"}, { "title":"Money orders"}]
 
 and im banging my head trying to figure out what it is about this
 content in particular that is not sorting the way I would expect.
 don't suppose someone would be able to lead me to a good place to look?
>>> 
>>> 
> 

Re: sorting help

[Erick Erickson]

Yeah, it’s always a question “how much is enough/too much”.

That looks reasonable for alphatitle, but what about title? Your original
question was that the sorting changes depending on which field you 
sort on. If your title field uses something that tokenizes or doesn’t
include the same analysis chain (particularly the lowercasing
and patternreplace) then I’d expect the order to change.

Best,
Erick

> On Jul 15, 2020, at 4:49 PM, David Hastings  
> wrote:
> 
> thanks, ill check the admin, didnt want to send a big clock of text but:
> 
> 
>   -
>  -
> 
>  Tokenizer:
>  org.apache.lucene.analysis.core.KeywordTokenizerFactoryclass:
>  solr.KeywordTokenizerFactoryluceneMatchVersion: 7.1.0
>  -
> 
>  Token Filters:
>  org.apache.lucene.analysis.core.LowerCaseFilterFactoryclass:
>  solr.LowerCaseFilterFactoryluceneMatchVersion: 7.1.0
>  org.apache.lucene.analysis.miscellaneous.TrimFilterFactoryclass:
>  solr.TrimFilterFactoryluceneMatchVersion: 7.1.0
>  org.apache.lucene.analysis.pattern.PatternReplaceFilterFactorypattern:
>  ([^a-z])replace: allclass: solr.PatternReplaceFilterFactoryreplacement
>  luceneMatchVersion: 7.1.0
>   -
> 
>   Query Analyzer:
>   
> 
>   org.apache.solr.analysis.TokenizerChain
>  -
> 
>  Tokenizer:
>  org.apache.lucene.analysis.core.KeywordTokenizerFactoryclass:
>  solr.KeywordTokenizerFactoryluceneMatchVersion: 7.1.0
>  -
> 
>  Token Filters:
>  org.apache.lucene.analysis.core.LowerCaseFilterFactoryclass:
>  solr.LowerCaseFilterFactoryluceneMatchVersion: 7.1.0
>  org.apache.lucene.analysis.miscellaneous.TrimFilterFactoryclass:
>  solr.TrimFilterFactoryluceneMatchVersion: 7.1.0
>  org.apache.lucene.analysis.pattern.PatternReplaceFilterFactorypattern:
>  ([^a-z])replace: allclass: solr.PatternReplaceFilterFactoryreplacement
>  luceneMatchVersion: 7.1.0
> 
> 
> On Wed, Jul 15, 2020 at 4:47 PM Erick Erickson 
> wrote:
> 
>> I’d look two places:
>> 
>> 1> try the admin/analysis page from the admin UI. In particular, look at
>> what tokens actually get in the index.
>> 
>> 2> again, the admin UI will let you choose the field (alphatitle and
>> title) and see what the actual indexed tokens are.
>> 
>> Both have the issue that I don’t know what tokenizer you are using. For
>> sorting it better be something
>> like KeywordTokenizer. Anything that breaks up the input into separate
>> tokens will produce surprises.
>> 
>> And unless you have lowercaseFilter in front of your patternreplace,
>> you’re removing uppercase characters.
>> 
>> Best,
>> Erick
>> 
>>> On Jul 15, 2020, at 3:06 PM, David Hastings <
>> hastings.recurs...@gmail.com> wrote:
>>> 
>>> howdy,
>>> i have a field that sorts fine all other content, and i cant seem to
>> debug
>>> why it wont sort for me on this one chunk of it.
>>> "sort":"alphatitle asc", "debugQuery":"on", "_":"1594733127740"}},
>> "response
>>> ":{"numFound":3,"start":0,"docs":[ { "title":"Money orders", {
>>> "title":"Finance,
>>> consolidation and rescheduling of debts", { "title":"Rights in former
>>> German Islands in Pacific", },
>>> 
>>> its using a copyfield from "title" to "alphatitle" that replaces all
>>> punctuation
>>> pattern: ([^a-z])replace: allclass: solr.PatternReplaceFilterFactory
>>> 
>>> and if i use just title it flips:
>>> 
>>> "title":"Finance, consolidation and rescheduling of debts"}, {
>> "title":"Rights
>>> in former German Islands in Pacific"}, { "title":"Money orders"}]
>>> 
>>> and im banging my head trying to figure out what it is about this
>>> content in particular that is not sorting the way I would expect.
>>> don't suppose someone would be able to lead me to a good place to look?
>> 
>> 

Re: Disk usage with useDocValuesAsStored

[Erick Erickson]

You’re off track a bit. useDocValuesAsStored has no effect on the size on disk. 
It’s purely a runtime option that pulls the data to return from either the 
stored or docValues parts of the index. If you change the definition and 
reindex, you should see significant differences in the size of your index, 
particularly the “*.fdt/*.fdx” and “*.dvd*I.dvm” files, where stored and 
docValues are kept respectively. 

However, it’s also apples and oranges. Specifically, using docValues as stored 
will _not_ necessarily return the fields the same way they were sent in the 
multiValued case. The docValues data is kept as a SORTED_SET, which means it’s 
both lexically sorted and deduplicated. So input like “a” “z” “h” “a” will 
return “a” “h” “z”.

Best,
Erick

> On Jul 15, 2020, at 1:35 PM, Gael Jourdan-Weil 
>  wrote:
> 
> Hello,
> 
> I was wondering if we can expect significant disk usage reduction (index 
> size) if we move from fields defined as "docValues=true + stored=true" to 
> "docValues=true + stored=false" (with useDocValuesAsStored=true as default in 
> both cases)?
> 
> Considering the use case we are targeting is only Streaming Expression with 
> /export handler, I also understand that we might also set 
> useDocValuesAsStored=false from what is described at 
> https://lucene.apache.org/solr/guide/8_4/docvalues.html.
> If so, would setting useDocValuesAsStored=false help reduce the index size as 
> well?
> 
> We will obviously try it and see by ourselves the results but I was wondering 
> if you already have an idea about it.
> Also if you have any good link to how data are physically stored depending on 
> the fields options (indexed/stored/docValues), this could really be 
> interesting.
> 
> Thanks,
> Gaël

Re: sorting help

[David Hastings]

thanks, ill check the admin, didnt want to send a big clock of text but:


   -
  -

  Tokenizer:
  org.apache.lucene.analysis.core.KeywordTokenizerFactoryclass:
  solr.KeywordTokenizerFactoryluceneMatchVersion: 7.1.0
  -

  Token Filters:
  org.apache.lucene.analysis.core.LowerCaseFilterFactoryclass:
  solr.LowerCaseFilterFactoryluceneMatchVersion: 7.1.0
  org.apache.lucene.analysis.miscellaneous.TrimFilterFactoryclass:
  solr.TrimFilterFactoryluceneMatchVersion: 7.1.0
  org.apache.lucene.analysis.pattern.PatternReplaceFilterFactorypattern:
  ([^a-z])replace: allclass: solr.PatternReplaceFilterFactoryreplacement
  luceneMatchVersion: 7.1.0
   -

   Query Analyzer:
   
   org.apache.solr.analysis.TokenizerChain
  -

  Tokenizer:
  org.apache.lucene.analysis.core.KeywordTokenizerFactoryclass:
  solr.KeywordTokenizerFactoryluceneMatchVersion: 7.1.0
  -

  Token Filters:
  org.apache.lucene.analysis.core.LowerCaseFilterFactoryclass:
  solr.LowerCaseFilterFactoryluceneMatchVersion: 7.1.0
  org.apache.lucene.analysis.miscellaneous.TrimFilterFactoryclass:
  solr.TrimFilterFactoryluceneMatchVersion: 7.1.0
  org.apache.lucene.analysis.pattern.PatternReplaceFilterFactorypattern:
  ([^a-z])replace: allclass: solr.PatternReplaceFilterFactoryreplacement
  luceneMatchVersion: 7.1.0


On Wed, Jul 15, 2020 at 4:47 PM Erick Erickson 
wrote:

> I’d look two places:
>
> 1> try the admin/analysis page from the admin UI. In particular, look at
> what tokens actually get in the index.
>
> 2> again, the admin UI will let you choose the field (alphatitle and
> title) and see what the actual indexed tokens are.
>
> Both have the issue that I don’t know what tokenizer you are using. For
> sorting it better be something
> like KeywordTokenizer. Anything that breaks up the input into separate
> tokens will produce surprises.
>
> And unless you have lowercaseFilter in front of your patternreplace,
> you’re removing uppercase characters.
>
> Best,
> Erick
>
> > On Jul 15, 2020, at 3:06 PM, David Hastings <
> hastings.recurs...@gmail.com> wrote:
> >
> > howdy,
> > i have a field that sorts fine all other content, and i cant seem to
> debug
> > why it wont sort for me on this one chunk of it.
> > "sort":"alphatitle asc", "debugQuery":"on", "_":"1594733127740"}},
> "response
> > ":{"numFound":3,"start":0,"docs":[ { "title":"Money orders", {
> > "title":"Finance,
> > consolidation and rescheduling of debts", { "title":"Rights in former
> > German Islands in Pacific", },
> >
> > its using a copyfield from "title" to "alphatitle" that replaces all
> > punctuation
> > pattern: ([^a-z])replace: allclass: solr.PatternReplaceFilterFactory
> >
> > and if i use just title it flips:
> >
> > "title":"Finance, consolidation and rescheduling of debts"}, {
> "title":"Rights
> > in former German Islands in Pacific"}, { "title":"Money orders"}]
> >
> > and im banging my head trying to figure out what it is about this
> > content in particular that is not sorting the way I would expect.
> > don't suppose someone would be able to lead me to a good place to look?
>
>

Re: sorting help

[Erick Erickson]

I’d look two places:

1> try the admin/analysis page from the admin UI. In particular, look at what 
tokens actually get in the index.

2> again, the admin UI will let you choose the field (alphatitle and title) and 
see what the actual indexed tokens are.

Both have the issue that I don’t know what tokenizer you are using. For sorting 
it better be something
like KeywordTokenizer. Anything that breaks up the input into separate tokens 
will produce surprises.

And unless you have lowercaseFilter in front of your patternreplace, you’re 
removing uppercase characters.

Best,
Erick

> On Jul 15, 2020, at 3:06 PM, David Hastings  
> wrote:
> 
> howdy,
> i have a field that sorts fine all other content, and i cant seem to debug
> why it wont sort for me on this one chunk of it.
> "sort":"alphatitle asc", "debugQuery":"on", "_":"1594733127740"}}, "response
> ":{"numFound":3,"start":0,"docs":[ { "title":"Money orders", {
> "title":"Finance,
> consolidation and rescheduling of debts", { "title":"Rights in former
> German Islands in Pacific", },
> 
> its using a copyfield from "title" to "alphatitle" that replaces all
> punctuation
> pattern: ([^a-z])replace: allclass: solr.PatternReplaceFilterFactory
> 
> and if i use just title it flips:
> 
> "title":"Finance, consolidation and rescheduling of debts"}, { "title":"Rights
> in former German Islands in Pacific"}, { "title":"Money orders"}]
> 
> and im banging my head trying to figure out what it is about this
> content in particular that is not sorting the way I would expect.
> don't suppose someone would be able to lead me to a good place to look?

sorting help

[David Hastings]

howdy,
i have a field that sorts fine all other content, and i cant seem to debug
why it wont sort for me on this one chunk of it.
"sort":"alphatitle asc", "debugQuery":"on", "_":"1594733127740"}}, "response
":{"numFound":3,"start":0,"docs":[ { "title":"Money orders", {
"title":"Finance,
consolidation and rescheduling of debts", { "title":"Rights in former
German Islands in Pacific", },

its using a copyfield from "title" to "alphatitle" that replaces all
punctuation
pattern: ([^a-z])replace: allclass: solr.PatternReplaceFilterFactory

and if i use just title it flips:

"title":"Finance, consolidation and rescheduling of debts"}, { "title":"Rights
in former German Islands in Pacific"}, { "title":"Money orders"}]

and im banging my head trying to figure out what it is about this
content in particular that is not sorting the way I would expect.
don't suppose someone would be able to lead me to a good place to look?

Disk usage with useDocValuesAsStored

[Gael Jourdan-Weil]

Hello,

I was wondering if we can expect significant disk usage reduction (index size) 
if we move from fields defined as "docValues=true + stored=true" to 
"docValues=true + stored=false" (with useDocValuesAsStored=true as default in 
both cases)?

Considering the use case we are targeting is only Streaming Expression with 
/export handler, I also understand that we might also set 
useDocValuesAsStored=false from what is described at 
https://lucene.apache.org/solr/guide/8_4/docvalues.html.
If so, would setting useDocValuesAsStored=false help reduce the index size as 
well?

We will obviously try it and see by ourselves the results but I was wondering 
if you already have an idea about it.
Also if you have any good link to how data are physically stored depending on 
the fields options (indexed/stored/docValues), this could really be interesting.

Thanks,
Gaël

Re: Solr fails to start with G1 GC

[Walter Underwood]

I don’t see a heap size specified, so it is probably trying to run with
a 512 Megabyte heap. That might just not work with the 32M region
size.

Here are the options we have been using for 3+ years on about 150 hosts.

SOLR_HEAP=8g
# Use G1 GC  -- wunder 2017-01-23
# Settings from https://wiki.apache.org/solr/ShawnHeisey
GC_TUNE=" \
-XX:+UseG1GC \
-XX:+ParallelRefProcEnabled \
-XX:G1HeapRegionSize=8m \
-XX:MaxGCPauseMillis=200 \
-XX:+UseLargePages \
-XX:+AggressiveOpts \
"

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Jul 15, 2020, at 4:24 AM, krishan goyal  wrote:
> 
> Hi,
> 
> I am using Solr 7.7
> 
> I am trying to start my solr server with G1 GC instead of the default CMS
> but the solr service doesn't get up.
> 
> The command I use to start solr is
> 
> bin/solr start -p 25280 -a "-Dsolr.solr.home=
> -Denable.slave=true -Denable.master=false -XX:+UseG1GC
> -XX:MaxGCPauseMillis=500 -XX:+UnlockExperimentalVMOptions
> -XX:G1MaxNewSizePercent=30 -XX:G1NewSizePercent=5 -XX:G1HeapRegionSize=32M
> -XX:InitiatingHeapOccupancyPercent=70"
> 
> I have tried various permutations of the start command by dropping / adding
> other parameters but it doesn't work. However starts up just fine with
> just "-Dsolr.solr.home= -Denable.slave=true
> -Denable.master=false" and starts up with the default CMS collector
> 
> I don't get any useful error logs too. It waits for default 180 secs and
> then prints
> 
> Warning: Available entropy is low. As a result, use of the UUIDField, SSL,
> or any other features that require
> RNG might not work properly. To check for the amount of available entropy,
> use 'cat /proc/sys/kernel/random/entropy_avail'.
> 
> Waiting up to 180 seconds to see Solr running on port 25280 [|]  Still not
> seeing Solr listening on 25280 after 180 seconds!
> 2020-07-15 07:07:52.042 INFO  (coreCloseExecutor-60-thread-6) [
> x:coreName] o.a.s.c.SolrCore [coreName]  CLOSING SolrCore
> org.apache.solr.core.SolrCore@7cc638d8
> 2020-07-15 07:07:52.099 INFO  (coreCloseExecutor-60-thread-6) [
> x:coreName] o.a.s.m.SolrMetricManager Closing metric reporters for
> registry=solr.core.coreName, tag=7cc638d8
> 2020-07-15 07:07:52.100 INFO  (coreCloseExecutor-60-thread-6) [
> x:coreName] o.a.s.m.r.SolrJmxReporter Closing reporter
> [org.apache.solr.metrics.reporters.SolrJmxReporter@5216981f: rootName =
> null, domain = solr.core.coreName, service url = null, agent id = null] for
> registry solr.core.coreName / com.codahale.metrics.MetricRegistry@32988ddf
> 2020-07-15 07:07:52.173 INFO  (ShutdownMonitor) [   ]
> o.a.s.m.SolrMetricManager Closing metric reporters for registry=solr.node,
> tag=null
> 2020-07-15 07:07:52.173 INFO  (ShutdownMonitor) [   ]
> o.a.s.m.r.SolrJmxReporter Closing reporter
> [org.apache.solr.metrics.reporters.SolrJmxReporter@28952dea: rootName =
> null, domain = solr.node, service url = null, agent id = null] for registry
> solr.node / com.codahale.metrics.MetricRegistry@655f4a3f
> 2020-07-15 07:07:52.175 INFO  (ShutdownMonitor) [   ]
> o.a.s.m.SolrMetricManager Closing metric reporters for registry=solr.jvm,
> tag=null
> 2020-07-15 07:07:52.175 INFO  (ShutdownMonitor) [   ]
> o.a.s.m.r.SolrJmxReporter Closing reporter
> [org.apache.solr.metrics.reporters.SolrJmxReporter@69c6161d: rootName =
> null, domain = solr.jvm, service url = null, agent id = null] for registry
> solr.jvm / com.codahale.metrics.MetricRegistry@1252ce77
> 2020-07-15 07:07:52.176 INFO  (ShutdownMonitor) [   ]
> o.a.s.m.SolrMetricManager Closing metric reporters for registry=solr.jetty,
> tag=null
> 2020-07-15 07:07:52.176 INFO  (ShutdownMonitor) [   ]
> o.a.s.m.r.SolrJmxReporter Closing reporter
> [org.apache.solr.metrics.reporters.SolrJmxReporter@3aefae67: rootName =
> null, domain = solr.jetty, service url = null, agent id = null] for
> registry solr.jetty / com.codahale.metrics.MetricRegistry@3a538ecd

Re: [ANNOUNCE] Apache Solr 8.6.0 released

[Bernd Fehling]

Am 15.07.20 um 16:07 schrieb Ishan Chattopadhyaya:
> Dear Solr Users,
> 
> In this release (Solr 8.6), we have deprecated the following:
> 
>   1. Data Import Handler
> 
>   2. HDFS support
> 
>   3. Cross Data Center Replication (CDCR)
> 

Seriously? :-(

So next steps will be kicking out Cloud and go back to single node or what?

Why don't you just freeze the whole Solr development and switch to Elastic?


> 
> 
> All of these are scheduled to be removed in a future 9.x release.
> 
> It was decided that these components did not meet the standards of quality
> and support that we wish to ensure for all components we ship. Some of
> these also relied on design patterns that we no longer recommend for use in
> critical production environments.
> 
> If you rely on these features, you are encouraged to try out community
> supported versions of these, where available [0]. Where such community
> support is not available, we encourage you to participate in the migration
> of these components into community supported packages and help continue the
> development. We envision that using packages for these components via
> package manager will actually make it easier for users to use such features.
> 
> Regards,
> 
> Ishan Chattopadhyaya
> 
> (On behalf of the Apache Lucene/Solr PMC)
> 
> [0] -
> https://cwiki.apache.org/confluence/display/SOLR/Community+supported+packages+for+Solr
> 
> On Wed, Jul 15, 2020 at 2:30 PM Bruno Roustant 
> wrote:
> 
>> The Lucene PMC is pleased to announce the release of Apache Solr 8.6.0.
>>
>>
>> Solr is the popular, blazing fast, open source NoSQL search platform from
>> the Apache Lucene project. Its major features include powerful full-text
>> search, hit highlighting, faceted search, dynamic clustering, database
>> integration, rich document handling, and geospatial search. Solr is highly
>> scalable, providing fault tolerant distributed search and indexing, and
>> powers the search and navigation features of many of the world's largest
>> internet sites.
>>
>>
>> Solr 8.6.0 is available for immediate download at:
>>
>>
>>   
>>
>>
>> ### Solr 8.6.0 Release Highlights:
>>
>>
>>  * Cross-Collection Join Queries: Join queries can now work
>> cross-collection, even when shared or when spanning nodes.
>>
>>  * Search: Performance improvement for some types of queries when exact
>> hit count isn't needed by using BlockMax WAND algorithm.
>>
>>  * Streaming Expression: Percentiles and standard deviation aggregations
>> added to stats, facet and time series.  Streaming expressions added to
>> /export handler.  Drill Streaming Expression for efficient and accurate
>> high cardinality aggregation.
>>
>>  * Package manager: Support for cluster (CoreContainer) level plugins.
>>
>>  * Health Check: HealthCheckHandler can now require that all cores are
>> healthy before returning OK.
>>
>>  * Zookeeper read API: A read API at /api/cluster/zk/* to fetch raw ZK
>> data and view contents of a ZK directory.
>>
>>  * Admin UI: New panel with security info in admin UI's dashboard.
>>
>>  * Query DSL: Support for {param:ref} and {bool: {excludeTags:""}}
>>
>>  * Ref Guide: Major redesign of Solr's documentation.
>>
>>
>> Please read CHANGES.txt for a full list of new features and changes:
>>
>>
>>   
>>
>>
>> Solr 8.6.0 also includes features, optimizations  and bugfixes in the
>> corresponding Apache Lucene release:
>>
>>
>>   
>>
>>
>> Note: The Apache Software Foundation uses an extensive mirroring network
>> for
>>
>> distributing releases. It is possible that the mirror you are using may
>> not have
>>
>> replicated the release yet. If that is the case, please try another mirror.
>>
>> This also applies to Maven access.
>>
> 

Re: [ANNOUNCE] Apache Solr 8.6.0 released

[Ishan Chattopadhyaya]

Dear Solr Users,

In this release (Solr 8.6), we have deprecated the following:

  1. Data Import Handler

  2. HDFS support

  3. Cross Data Center Replication (CDCR)



All of these are scheduled to be removed in a future 9.x release.

It was decided that these components did not meet the standards of quality
and support that we wish to ensure for all components we ship. Some of
these also relied on design patterns that we no longer recommend for use in
critical production environments.

If you rely on these features, you are encouraged to try out community
supported versions of these, where available [0]. Where such community
support is not available, we encourage you to participate in the migration
of these components into community supported packages and help continue the
development. We envision that using packages for these components via
package manager will actually make it easier for users to use such features.

Regards,

Ishan Chattopadhyaya

(On behalf of the Apache Lucene/Solr PMC)

[0] -
https://cwiki.apache.org/confluence/display/SOLR/Community+supported+packages+for+Solr

On Wed, Jul 15, 2020 at 2:30 PM Bruno Roustant 
wrote:

> The Lucene PMC is pleased to announce the release of Apache Solr 8.6.0.
>
>
> Solr is the popular, blazing fast, open source NoSQL search platform from
> the Apache Lucene project. Its major features include powerful full-text
> search, hit highlighting, faceted search, dynamic clustering, database
> integration, rich document handling, and geospatial search. Solr is highly
> scalable, providing fault tolerant distributed search and indexing, and
> powers the search and navigation features of many of the world's largest
> internet sites.
>
>
> Solr 8.6.0 is available for immediate download at:
>
>
>   
>
>
> ### Solr 8.6.0 Release Highlights:
>
>
>  * Cross-Collection Join Queries: Join queries can now work
> cross-collection, even when shared or when spanning nodes.
>
>  * Search: Performance improvement for some types of queries when exact
> hit count isn't needed by using BlockMax WAND algorithm.
>
>  * Streaming Expression: Percentiles and standard deviation aggregations
> added to stats, facet and time series.  Streaming expressions added to
> /export handler.  Drill Streaming Expression for efficient and accurate
> high cardinality aggregation.
>
>  * Package manager: Support for cluster (CoreContainer) level plugins.
>
>  * Health Check: HealthCheckHandler can now require that all cores are
> healthy before returning OK.
>
>  * Zookeeper read API: A read API at /api/cluster/zk/* to fetch raw ZK
> data and view contents of a ZK directory.
>
>  * Admin UI: New panel with security info in admin UI's dashboard.
>
>  * Query DSL: Support for {param:ref} and {bool: {excludeTags:""}}
>
>  * Ref Guide: Major redesign of Solr's documentation.
>
>
> Please read CHANGES.txt for a full list of new features and changes:
>
>
>   
>
>
> Solr 8.6.0 also includes features, optimizations  and bugfixes in the
> corresponding Apache Lucene release:
>
>
>   
>
>
> Note: The Apache Software Foundation uses an extensive mirroring network
> for
>
> distributing releases. It is possible that the mirror you are using may
> not have
>
> replicated the release yet. If that is the case, please try another mirror.
>
> This also applies to Maven access.
>

SSL + Solr 8.5.1 in cloud mode + Java 8

[Natarajan, Rajeswari]

Yes ,that's correct . I did that and  the exception is gone. 

But I see bel.ow exception , not sure what is the reason for this NPE.

2020-07-15 10:28:14.453 INFO  (MetricsHistoryHandler-12-thread-1) [   ] 
o.a.s.c.s.i.SolrClientNodeStateProvider Error on getting remote info, trying 
again: IOException occurred when talking to server at: 
http://10-169-50-16.search-solrcloud-solrcloud.service:8983/solr
2020-07-15 10:28:14.956 INFO  (MetricsHistoryHandler-12-thread-1) [   ] 
o.a.s.c.s.i.SolrClientNodeStateProvider Error on getting remote info, trying 
again: IOException occurred when talking to server at: 
http://10-169-50-16.search-solrcloud-solrcloud.service:8983/solr
2020-07-15 10:28:15.459 INFO  (MetricsHistoryHandler-12-thread-1) [   ] 
o.a.s.c.s.i.SolrClientNodeStateProvider Error on getting remote info, trying 
again: IOException occurred when talking to server at: 
http://10-169-50-16.search-solrcloud-solrcloud.service:8983/solr
2020-07-15 10:28:15.960 WARN  (MetricsHistoryHandler-12-thread-1) [   ] 
o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node 
10-169-50-16.search-solrcloud-solrcloud.service:8983_solr => 
java.lang.NullPointerException
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.lambda$fetchReplicaMetrics$7(SolrClientNodeStateProvider.java:226)
java.lang.NullPointerException: null
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.lambda$fetchReplicaMetrics$7(SolrClientNodeStateProvider.java:226)
 ~[solr-solrj-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera 
- 2020-04-08 09:01:44]
at java.util.HashMap.forEach(HashMap.java:1289) ~[?:1.8.0_211]
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:225)
 ~[solr-solrj-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera 
- 2020-04-08 09:01:44]
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:271)
 ~[solr-solrj-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera 
- 2020-04-08 09:01:44]
at 
org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
 ~[solr-solrj-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera 
- 2020-04-08 09:01:44]
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
 ~[solr-solrj-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera 
- 2020-04-08 09:01:44]
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
 ~[solr-solrj-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera 
- 2020-04-08 09:01:44]
at 
org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:506)
 ~[solr-core-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera - 
2020-04-08 09:01:41]
at 
org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:378)
 ~[solr-core-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera - 
2020-04-08 09:01:41]
at 
org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:235)
 ~[solr-core-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera - 
2020-04-08 09:01:41]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[?:1.8.0_211]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
~[?:1.8.0_211]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
 ~[?:1.8.0_211]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
 ~[?:1.8.0_211]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
~[?:1.8.0_211]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
~[?:1.8.0_211]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_211]

Thanks,
Rajeswari
On 7/15/20, 6:29 AM, "Kevin Risden"  wrote:

You need to remove the references from bin/solr or bin/solr.cmd to
SOLR_SSL_CLIENT_KEY_STORE and "-Djavax.net.ssl.keyStore". This is different
from solr.in.sh.

The way the bin/solr script is written it is falling back to whatever is
provided as SOLR_SSL_KEY_STORE for the client keystore which is causing
issues.

Kevin Risden



On Wed, Jul 15, 2020 at 3:45 AM Natarajan, Rajeswari <
rajeswari.natara...@sap.com> wrote:

> Thank you for your reply. I looked at solr.in.sh I see that
> SOLR_SSL_CLIENT_KEY_STORE  is already commented out by default. But you 
are
> right I looked at the running solr,  I see the option
> -Djavax.net.ssl.keyStore pointing to 

Re: [CAUTION] SSL + Solr 8.5.1 in cloud mode + Java 8

[Kevin Risden]

You need to remove the references from bin/solr or bin/solr.cmd to
SOLR_SSL_CLIENT_KEY_STORE and "-Djavax.net.ssl.keyStore". This is different
from solr.in.sh.

The way the bin/solr script is written it is falling back to whatever is
provided as SOLR_SSL_KEY_STORE for the client keystore which is causing
issues.

Kevin Risden



On Wed, Jul 15, 2020 at 3:45 AM Natarajan, Rajeswari <
rajeswari.natara...@sap.com> wrote:

> Thank you for your reply. I looked at solr.in.sh I see that
> SOLR_SSL_CLIENT_KEY_STORE  is already commented out by default. But you are
> right I looked at the running solr,  I see the option
> -Djavax.net.ssl.keyStore pointing to solr-ssl.keystore.p12 , not sure how
> it is getting that value. Let me dig more. Thanks for the pointer. Also if
> you have a pointer how it get's populated  other than
> SOLR_SSL_CLIENT_KEY_STORE config in solr.in.sh , please let me know
>
> #SOLR_SSL_CLIENT_KEY_STORE=
> #SOLR_SSL_CLIENT_KEY_STORE_PASSWORD=
> #SOLR_SSL_CLIENT_KEY_STORE_TYPE=
> #SOLR_SSL_CLIENT_TRUST_STORE=
> #SOLR_SSL_CLIENT_TRUST_STORE_PASSWORD=
> #SOLR_SSL_CLIENT_TRUST_STORE_TYPE=
>
> Yes we are not using Solr client auth.
>
> Thanks,
> Rajeswari
>
> On 7/14/20, 5:55 PM, "Kevin Risden"  wrote:
>
> Hmmm so I looked closer - it looks like a side effect of the default
> passthrough of the keystore being passed to the client keystore.
>
> https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L229
>
> Can you remove or commout the entire SOLR_SSL_CLIENT_KEY_STORE section
> from
> bin/solr or bin/solr.cmd depending on which version you are using? The
> key
> being to make sure to not set "-Djavax.net.ssl.keyStore".
>
> This assumes that you aren't using Solr client auth (which based on
> your
> config you aren't) and you aren't trying to use Solr to connect to
> anything
> that is secured via clientAuth (most likely you aren't).
>
> If you can try this and report back that would be awesome. I think this
> will fix the issue and it would be possible to make client auth opt in
> instead of default fall back.
> Kevin Risden
>
>
>
> On Tue, Jul 14, 2020 at 1:46 AM Natarajan, Rajeswari <
> rajeswari.natara...@sap.com> wrote:
>
> > Thank you so much for the response.  Below are the configs I have in
> > solr.in.sh and I followed
> > https://lucene.apache.org/solr/guide/8_5/enabling-ssl.html
> documentation
> >
> > # Enables HTTPS. It is implicitly true if you set
> SOLR_SSL_KEY_STORE. Use
> > this config
> > # to enable https module with custom jetty configuration.
> > SOLR_SSL_ENABLED=true
> > # Uncomment to set SSL-related system properties
> > # Be sure to update the paths to the correct keystore for your
> environment
> > SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.p12
> > SOLR_SSL_KEY_STORE_PASSWORD=secret
> > SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.p12
> > SOLR_SSL_TRUST_STORE_PASSWORD=secret
> > # Require clients to authenticate
> > SOLR_SSL_NEED_CLIENT_AUTH=false
> > # Enable clients to authenticate (but not require)
> > SOLR_SSL_WANT_CLIENT_AUTH=false
> > # SSL Certificates contain host/ip "peer name" information that is
> > validated by default. Setting
> > # this to false can be useful to disable these checks when re-using a
> > certificate on many hosts
> > SOLR_SSL_CHECK_PEER_NAME=true
> >
> > In local , with the below certificate it works
> > ---
> >
> > keytool -list -keystore solr-ssl.keystore.p12
> > Enter keystore password:
> > Keystore type: PKCS12
> > Keystore provider: SUN
> >
> > Your keystore contains 1 entry
> >
> > solr-18, Jun 26, 2020, PrivateKeyEntry,
> > Certificate fingerprint (SHA1):
> > AB:F2:C8:84:E8:E7:A2:BF:2D:0D:2F:D3:95:4A:98:5B:2A:88:81:50
> > C02W48C6HTD6:solr-8.5.1 i843100$ keytool -list -v -keystore
> > solr-ssl.keystore.p12
> > Enter keystore password:
> > Keystore type: PKCS12
> > Keystore provider: SUN
> >
> > Your keystore contains 1 entry
> >
> > Alias name: solr-18
> > Creation date: Jun 26, 2020
> > Entry type: PrivateKeyEntry
> > Certificate chain length: 1
> > Certificate[1]:
> > Owner: CN=localhost, OU=Organizational Unit, O=Organization,
> L=Location,
> > ST=State, C=Country
> > Issuer: CN=localhost, OU=Organizational Unit, O=Organization,
> L=Location,
> > ST=State, C=Country
> > Serial number: 45a822c8
> > Valid from: Fri Jun 26 00:13:03 PDT 2020 until: Sun Nov 10 23:13:03
> PST
> > 2047
> > Certificate fingerprints:
> >  MD5:  0B:80:54:89:44:65:93:07:1F:81:88:8D:EC:BD:38:41
> >  SHA1:
> AB:F2:C8:84:E8:E7:A2:BF:2D:0D:2F:D3:95:4A:98:5B:2A:88:81:50
> >  SHA256:
> >
> 9D:65:A6:55:D7:22:B2:72:C2:20:55:66:F8:0C:9C:48:B1:F6:48:40:A4:FB:CB:26:77:DE:C4:97:34:69:25:42
> > Signature 

Re: Elevation with distributed search causes NPE

[Erick Erickson]

Hmmm, looking at the code that line looks like this:

sortSpec.getSort().getSort();

I’m curious what happens if you specify a sort on the query? If that makes the 
problem go away, 
it’s a smoking gun.

Whether or not adding sorting makes the problem go away, this looks like 
something
that’s a legitimate JIRA, please go ahead and raise one.

Best,
Erick

> On Jul 15, 2020, at 4:34 AM, Marc Linden  
> wrote:
> 
> Hi all,
> 
> I'm facing the problem that Solr is throwing a NullPointerException when 
> performing a distributed search with multiple shards having elevation 
> configured where one or more shards do have elevated results but others do 
> not.
> 
> We are using Solr 8.2 and have the QueryElevationComponent configured with 
> "last-components" of the default search handler "/select". But the problem 
> also occurs when using the explicit "/elevate" search handler.
>  
> ...
> 
>  elevator
> 
>  
>  ...
>  
> 
> string
> elevate.xml
>  
> 
> ### Steps to reproduce:
> 
> (1) Add entries to the elevate.xml of each core to elevate a specific 
> document for the text "searchTerm":
> 
>   core1:
>   
> ...
> 
>   
>   core2:
>   
> ...
> 
>   
> 
> (2) Execute query (we use port 9983): 
> http://localhost:9983/solr/web/select?q=elevatedTerm=false=text_en=edismax=lang:en=localhost:9983/solr/core1,localhost:9983/solr/core2=[elevated],[shard],area,id=10=0
> 
> Now as both shards have elevated documents for the requested "searchTerm" the 
> search results are as expected:
> 
> response: {
> numFound: 5192,
> start: 0,
> maxScore: 1.9032197,
> docs: [{
> area: "press",
> id: "core1docId1",
> [elevated]: true,
> [shard]: "localhost:9983/solr/core1"
> }, {
> area: "products",
> id: "core2docId1",
> [elevated]: true,
> [shard]: "localhost:9983/solr/core2"
> }, {
> area: "press",
> id: "core1docId2",
> [elevated]: false,
> [shard]: "localhost:9983/solr/core1"
> },
> ...
> 
> (3) Remove the elevation entry for that "searchTerm" from one of the cores, 
> e.g. via comment
> 
>   core2:
>   
> ...
> 
>   
> 
> 
> (4) Reload the modified core: 
> http://localhost:9983/solr/admin/cores?action=RELOAD=core2
> 
> (5) Request same query again and you get the NPE:
> 
> error: {
> trace: "java.lang.NullPointerException
>   at 
> org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1068)
>   at 
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:917)
>   at 
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:613)
>   at 
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:592)
>   at 
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:431)
>   at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
>   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2578)
>   at 
> org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:780)
>   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:423)
>   at 
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350)
>   at 
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
>   at 
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
>   ...
> 
> 
> I want to ask the community if I'm missing something or if this really is a 
> bug.
> 
> Thanks in advance,
> Marc
> Marc Linden
> Developer
> 
> Virtual Identity AG
> Grünwälderstraße 10-14
> 79098 Freiburg
> 
> +49 761 20758-422
> --
> 
> marc.lin...@virtual-identity.com
> http://www.virtual-identity.com
> 
> Freiburg | München | Wien | Porto
> 
> 
> 
> Virtual Identity AG
> Grünwälderstraße 10-14
> 79098 Freiburg
> Amtsgericht Freiburg, HRB 6218
> Vorstand: Ralf Heller
> Vorsitzende des Aufsichtsrates: Kirsten Heller
> Umsatzsteuer-ID: DE208002218

Re: SOLR Exact phrase search issue

[Erick Erickson]

Heck, Charlie, it explains 90% of the problems I’ve personally had with
programming in general over my entire career...

> On Jul 15, 2020, at 5:08 AM, Charlie Hull  wrote:
> 
> On 14/07/2020 12:48, Erick Erickson wrote:
>>  This is almost certainly a mismatch between what you think is 
>> happening and what you’ve actually told Solr to do ;).
> That's a great one-line explanation of 90% of the issues people face with 
> Solr :-)
> 
> Charlie
>> 
>> Best,
>> Erick
>> 
>>> On Jul 14, 2020, at 7:05 AM, Villalba Sans, Raúl  
>>> wrote:
>>> 
>>> Hello,
>>> 
>>> We have an app that uses SOLR as search engine. We have detected incorrect 
>>> behavior for which we find no explanation. If we perform a search with the 
>>> phrase "Què t’hi jugues" we do not receive any results, although we know 
>>> that there is a result that contains this phrase. However, if we search for 
>>> "Què t’hi" or for "t’hi jugues" we do find results, including "Què t’hi 
>>> jugues ". We attach screenshots of the search tool and the xml of the 
>>> results. We would greatly appreciate it if you could lend a hand in trying 
>>> to find a solution or identify the cause of the problem.
>>>  Search 1 – “Què t’hi jugues”
>>> 
>>>  Search 2 – “Què t’hi”
>>>  
>>> 
>>> Search 3 – “t’hi jugues”
>>> 
>>> 
>>> Best regards,
>>>  
>>>  Raül Villalba Sans
>>> Delivery Centers – Centros de Producción
>>>  Parque de Gardeny, Edificio 28
>>> 25071 Lleida, España
>>> T +34 973 193 580
>>>  
> 
> 
> -- 
> Charlie Hull
> OpenSource Connections, previously Flax
> 
> tel/fax: +44 (0)8700 118334
> mobile:  +44 (0)7767 825828
> web: www.o19s.com

Re: Solr fails to start with G1 GC

[Erick Erickson]

Well, the first thing I’d do is not use _any_ options. Just bin/solr start.
If that works, try adding things in.

-Denable.master and -Denable.slave are specifically for the old master/slave
architecture. Is that your intent? At any rate, leave them out at first.

Second, there’s not much heap allocated by default. So the next thing I’d
try is to specify some more heap, i.e. "bin/solr start -m 4g”.

Third, if it’s a memory issue you may get some joy by specifying
the oom_killer script on startup, see the docs.

Lots of people run with G1GC, so it’s almost certainly something in your 
environment.

And what do you see if you follow the instructions and look at
entropy? (cat /proc/sys/kernel/random/entropy_avail). NOTE: this is unlikely
to be the root of your problem, but it does point to an environment
issue.

Best,
Erick

> On Jul 15, 2020, at 7:24 AM, krishan goyal  wrote:
> 
> Hi,
> 
> I am using Solr 7.7
> 
> I am trying to start my solr server with G1 GC instead of the default CMS
> but the solr service doesn't get up.
> 
> The command I use to start solr is
> 
> bin/solr start -p 25280 -a "-Dsolr.solr.home=
> -Denable.slave=true -Denable.master=false -XX:+UseG1GC
> -XX:MaxGCPauseMillis=500 -XX:+UnlockExperimentalVMOptions
> -XX:G1MaxNewSizePercent=30 -XX:G1NewSizePercent=5 -XX:G1HeapRegionSize=32M
> -XX:InitiatingHeapOccupancyPercent=70"
> 
> I have tried various permutations of the start command by dropping / adding
> other parameters but it doesn't work. However starts up just fine with
> just "-Dsolr.solr.home= -Denable.slave=true
> -Denable.master=false" and starts up with the default CMS collector
> 
> I don't get any useful error logs too. It waits for default 180 secs and
> then prints
> 
> Warning: Available entropy is low. As a result, use of the UUIDField, SSL,
> or any other features that require
> RNG might not work properly. To check for the amount of available entropy,
> use 'cat /proc/sys/kernel/random/entropy_avail'.
> 
> Waiting up to 180 seconds to see Solr running on port 25280 [|]  Still not
> seeing Solr listening on 25280 after 180 seconds!
> 2020-07-15 07:07:52.042 INFO  (coreCloseExecutor-60-thread-6) [
> x:coreName] o.a.s.c.SolrCore [coreName]  CLOSING SolrCore
> org.apache.solr.core.SolrCore@7cc638d8
> 2020-07-15 07:07:52.099 INFO  (coreCloseExecutor-60-thread-6) [
> x:coreName] o.a.s.m.SolrMetricManager Closing metric reporters for
> registry=solr.core.coreName, tag=7cc638d8
> 2020-07-15 07:07:52.100 INFO  (coreCloseExecutor-60-thread-6) [
> x:coreName] o.a.s.m.r.SolrJmxReporter Closing reporter
> [org.apache.solr.metrics.reporters.SolrJmxReporter@5216981f: rootName =
> null, domain = solr.core.coreName, service url = null, agent id = null] for
> registry solr.core.coreName / com.codahale.metrics.MetricRegistry@32988ddf
> 2020-07-15 07:07:52.173 INFO  (ShutdownMonitor) [   ]
> o.a.s.m.SolrMetricManager Closing metric reporters for registry=solr.node,
> tag=null
> 2020-07-15 07:07:52.173 INFO  (ShutdownMonitor) [   ]
> o.a.s.m.r.SolrJmxReporter Closing reporter
> [org.apache.solr.metrics.reporters.SolrJmxReporter@28952dea: rootName =
> null, domain = solr.node, service url = null, agent id = null] for registry
> solr.node / com.codahale.metrics.MetricRegistry@655f4a3f
> 2020-07-15 07:07:52.175 INFO  (ShutdownMonitor) [   ]
> o.a.s.m.SolrMetricManager Closing metric reporters for registry=solr.jvm,
> tag=null
> 2020-07-15 07:07:52.175 INFO  (ShutdownMonitor) [   ]
> o.a.s.m.r.SolrJmxReporter Closing reporter
> [org.apache.solr.metrics.reporters.SolrJmxReporter@69c6161d: rootName =
> null, domain = solr.jvm, service url = null, agent id = null] for registry
> solr.jvm / com.codahale.metrics.MetricRegistry@1252ce77
> 2020-07-15 07:07:52.176 INFO  (ShutdownMonitor) [   ]
> o.a.s.m.SolrMetricManager Closing metric reporters for registry=solr.jetty,
> tag=null
> 2020-07-15 07:07:52.176 INFO  (ShutdownMonitor) [   ]
> o.a.s.m.r.SolrJmxReporter Closing reporter
> [org.apache.solr.metrics.reporters.SolrJmxReporter@3aefae67: rootName =
> null, domain = solr.jetty, service url = null, agent id = null] for
> registry solr.jetty / com.codahale.metrics.MetricRegistry@3a538ecd

Solr fails to start with G1 GC

[krishan goyal]

Hi,

I am using Solr 7.7

I am trying to start my solr server with G1 GC instead of the default CMS
but the solr service doesn't get up.

The command I use to start solr is

bin/solr start -p 25280 -a "-Dsolr.solr.home=
-Denable.slave=true -Denable.master=false -XX:+UseG1GC
-XX:MaxGCPauseMillis=500 -XX:+UnlockExperimentalVMOptions
-XX:G1MaxNewSizePercent=30 -XX:G1NewSizePercent=5 -XX:G1HeapRegionSize=32M
-XX:InitiatingHeapOccupancyPercent=70"

I have tried various permutations of the start command by dropping / adding
other parameters but it doesn't work. However starts up just fine with
just "-Dsolr.solr.home= -Denable.slave=true
-Denable.master=false" and starts up with the default CMS collector

I don't get any useful error logs too. It waits for default 180 secs and
then prints

Warning: Available entropy is low. As a result, use of the UUIDField, SSL,
or any other features that require
RNG might not work properly. To check for the amount of available entropy,
use 'cat /proc/sys/kernel/random/entropy_avail'.

Waiting up to 180 seconds to see Solr running on port 25280 [|]  Still not
seeing Solr listening on 25280 after 180 seconds!
2020-07-15 07:07:52.042 INFO  (coreCloseExecutor-60-thread-6) [
x:coreName] o.a.s.c.SolrCore [coreName]  CLOSING SolrCore
org.apache.solr.core.SolrCore@7cc638d8
2020-07-15 07:07:52.099 INFO  (coreCloseExecutor-60-thread-6) [
x:coreName] o.a.s.m.SolrMetricManager Closing metric reporters for
registry=solr.core.coreName, tag=7cc638d8
2020-07-15 07:07:52.100 INFO  (coreCloseExecutor-60-thread-6) [
x:coreName] o.a.s.m.r.SolrJmxReporter Closing reporter
[org.apache.solr.metrics.reporters.SolrJmxReporter@5216981f: rootName =
null, domain = solr.core.coreName, service url = null, agent id = null] for
registry solr.core.coreName / com.codahale.metrics.MetricRegistry@32988ddf
2020-07-15 07:07:52.173 INFO  (ShutdownMonitor) [   ]
o.a.s.m.SolrMetricManager Closing metric reporters for registry=solr.node,
tag=null
2020-07-15 07:07:52.173 INFO  (ShutdownMonitor) [   ]
o.a.s.m.r.SolrJmxReporter Closing reporter
[org.apache.solr.metrics.reporters.SolrJmxReporter@28952dea: rootName =
null, domain = solr.node, service url = null, agent id = null] for registry
solr.node / com.codahale.metrics.MetricRegistry@655f4a3f
2020-07-15 07:07:52.175 INFO  (ShutdownMonitor) [   ]
o.a.s.m.SolrMetricManager Closing metric reporters for registry=solr.jvm,
tag=null
2020-07-15 07:07:52.175 INFO  (ShutdownMonitor) [   ]
o.a.s.m.r.SolrJmxReporter Closing reporter
[org.apache.solr.metrics.reporters.SolrJmxReporter@69c6161d: rootName =
null, domain = solr.jvm, service url = null, agent id = null] for registry
solr.jvm / com.codahale.metrics.MetricRegistry@1252ce77
2020-07-15 07:07:52.176 INFO  (ShutdownMonitor) [   ]
o.a.s.m.SolrMetricManager Closing metric reporters for registry=solr.jetty,
tag=null
2020-07-15 07:07:52.176 INFO  (ShutdownMonitor) [   ]
o.a.s.m.r.SolrJmxReporter Closing reporter
[org.apache.solr.metrics.reporters.SolrJmxReporter@3aefae67: rootName =
null, domain = solr.jetty, service url = null, agent id = null] for
registry solr.jetty / com.codahale.metrics.MetricRegistry@3a538ecd

SSL + Solr 8.5.1 in cloud mode + Java 8

[Natarajan, Rajeswari]

Here is the result. I removed the else block and tested . You are correct , the 
previous exception which I saw went away.

But I see bel.ow exception , not sure what is the reason for this NPE.

2020-07-15 10:28:14.453 INFO  (MetricsHistoryHandler-12-thread-1) [   ] 
o.a.s.c.s.i.SolrClientNodeStateProvider Error on getting remote info, trying 
again: IOException occurred when talking to server at: 
http://10-169-50-16.search-solrcloud-solrcloud.service:8983/solr
2020-07-15 10:28:14.956 INFO  (MetricsHistoryHandler-12-thread-1) [   ] 
o.a.s.c.s.i.SolrClientNodeStateProvider Error on getting remote info, trying 
again: IOException occurred when talking to server at: 
http://10-169-50-16.search-solrcloud-solrcloud.service:8983/solr
2020-07-15 10:28:15.459 INFO  (MetricsHistoryHandler-12-thread-1) [   ] 
o.a.s.c.s.i.SolrClientNodeStateProvider Error on getting remote info, trying 
again: IOException occurred when talking to server at: 
http://10-169-50-16.search-solrcloud-solrcloud.service:8983/solr
2020-07-15 10:28:15.960 WARN  (MetricsHistoryHandler-12-thread-1) [   ] 
o.a.s.c.s.i.SolrClientNodeStateProvider could not get tags from node 
10-169-50-16.search-solrcloud-solrcloud.service:8983_solr => 
java.lang.NullPointerException
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.lambda$fetchReplicaMetrics$7(SolrClientNodeStateProvider.java:226)
java.lang.NullPointerException: null
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.lambda$fetchReplicaMetrics$7(SolrClientNodeStateProvider.java:226)
 ~[solr-solrj-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera 
- 2020-04-08 09:01:44]
at java.util.HashMap.forEach(HashMap.java:1289) ~[?:1.8.0_211]
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchReplicaMetrics(SolrClientNodeStateProvider.java:225)
 ~[solr-solrj-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera 
- 2020-04-08 09:01:44]
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider$AutoScalingSnitch.getRemoteInfo(SolrClientNodeStateProvider.java:271)
 ~[solr-solrj-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera 
- 2020-04-08 09:01:44]
at 
org.apache.solr.common.cloud.rule.ImplicitSnitch.getTags(ImplicitSnitch.java:76)
 ~[solr-solrj-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera 
- 2020-04-08 09:01:44]
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.fetchTagValues(SolrClientNodeStateProvider.java:139)
 ~[solr-solrj-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera 
- 2020-04-08 09:01:44]
at 
org.apache.solr.client.solrj.impl.SolrClientNodeStateProvider.getNodeValues(SolrClientNodeStateProvider.java:128)
 ~[solr-solrj-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera 
- 2020-04-08 09:01:44]
at 
org.apache.solr.handler.admin.MetricsHistoryHandler.collectGlobalMetrics(MetricsHistoryHandler.java:506)
 ~[solr-core-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera - 
2020-04-08 09:01:41]
at 
org.apache.solr.handler.admin.MetricsHistoryHandler.collectMetrics(MetricsHistoryHandler.java:378)
 ~[solr-core-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera - 
2020-04-08 09:01:41]
at 
org.apache.solr.handler.admin.MetricsHistoryHandler.lambda$new$0(MetricsHistoryHandler.java:235)
 ~[solr-core-8.5.1.jar:8.5.1 edb9fc409398f2c3446883f9f80595c884d245d0 - ivera - 
2020-04-08 09:01:41]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[?:1.8.0_211]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
~[?:1.8.0_211]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
 ~[?:1.8.0_211]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
 ~[?:1.8.0_211]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
~[?:1.8.0_211]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
~[?:1.8.0_211]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_211]

Thanks,
Rajeswari

On 7/15/20, 2:53 AM, "Natarajan, Rajeswari"  
wrote:

Ok , I looked at the solr script , here is the logic , even if the  
SOLR_SSL_CLIENT_KEY_STORE_PASSWORD is not set , it sets the  
-Djavax.net.ssl.keyStore=$SOLR_SSL_KEY_STORE" . Let me remove the else part and 
test it . Thanks again for the pointer

if [ -n "$SOLR_SSL_CLIENT_KEY_STORE" ]; then
SOLR_SSL_OPTS+=" -Djavax.net.ssl.keyStore=$SOLR_SSL_CLIENT_KEY_STORE"

if [ -n "$SOLR_SSL_CLIENT_KEY_STORE_PASSWORD" ]; then
  export 
SOLR_SSL_CLIENT_KEY_STORE_PASSWORD=$SOLR_SSL_CLIENT_KEY_STORE_PASSWORD
fi
if [ -n "$SOLR_SSL_CLIENT_KEY_STORE_TYPE" ]; then
  SOLR_SSL_OPTS+=" 

SSL + Solr 8.5.1 in cloud mode + Java 8

[Natarajan, Rajeswari]

Ok , I looked at the solr script , here is the logic , even if the  
SOLR_SSL_CLIENT_KEY_STORE_PASSWORD is not set , it sets the  
-Djavax.net.ssl.keyStore=$SOLR_SSL_KEY_STORE" . Let me remove the else part and 
test it . Thanks again for the pointer

if [ -n "$SOLR_SSL_CLIENT_KEY_STORE" ]; then
SOLR_SSL_OPTS+=" -Djavax.net.ssl.keyStore=$SOLR_SSL_CLIENT_KEY_STORE"

if [ -n "$SOLR_SSL_CLIENT_KEY_STORE_PASSWORD" ]; then
  export 
SOLR_SSL_CLIENT_KEY_STORE_PASSWORD=$SOLR_SSL_CLIENT_KEY_STORE_PASSWORD
fi
if [ -n "$SOLR_SSL_CLIENT_KEY_STORE_TYPE" ]; then
  SOLR_SSL_OPTS+=" 
-Djavax.net.ssl.keyStoreType=$SOLR_SSL_CLIENT_KEY_STORE_TYPE"
fi
  else
if [ -n "$SOLR_SSL_KEY_STORE" ]; then
  SOLR_SSL_OPTS+=" -Djavax.net.ssl.keyStore=$SOLR_SSL_KEY_STORE"
fi
if [ -n "$SOLR_SSL_KEY_STORE_TYPE" ]; then
  SOLR_SSL_OPTS+=" -Djavax.net.ssl.keyStoreType=$SOLR_SSL_KEY_STORE_TYPE"
fi
  fi

Thanks,
Rajeswari

On 7/15/20, 1:49 AM, "Natarajan, Rajeswari"  
wrote:

From the /bin directory I did grep for SOLR_SSL_CLIENT_KEY_STORE 
, this is what I see . But somehow the option option -Djavax.net.ssl.keyStore 
is added 
grep SOLR_SSL_CLIENT_KEY_STORE *
grep: init.d: Is a directory
solr:  if [ -n "$SOLR_SSL_CLIENT_KEY_STORE" ]; then
solr:SOLR_SSL_OPTS+=" 
-Djavax.net.ssl.keyStore=$SOLR_SSL_CLIENT_KEY_STORE"
solr:if [ -n "$SOLR_SSL_CLIENT_KEY_STORE_PASSWORD" ]; then
solr:  export 
SOLR_SSL_CLIENT_KEY_STORE_PASSWORD=$SOLR_SSL_CLIENT_KEY_STORE_PASSWORD
solr:if [ -n "$SOLR_SSL_CLIENT_KEY_STORE_TYPE" ]; then
solr:  SOLR_SSL_OPTS+=" 
-Djavax.net.ssl.keyStoreType=$SOLR_SSL_CLIENT_KEY_STORE_TYPE"
solr.cmd:  IF DEFINED SOLR_SSL_CLIENT_KEY_STORE (
solr.cmd:set "SOLR_SSL_OPTS=!SOLR_SSL_OPTS! 
-Djavax.net.ssl.keyStore=%SOLR_SSL_CLIENT_KEY_STORE%"
solr.cmd:IF DEFINED SOLR_SSL_CLIENT_KEY_STORE_TYPE (
solr.cmd:  set "SOLR_SSL_OPTS=!SOLR_SSL_OPTS! 
-Djavax.net.ssl.keyStoreType=%SOLR_SSL_CLIENT_KEY_STORE_TYPE%"
solr.in.cmd:REM set SOLR_SSL_CLIENT_KEY_STORE=
solr.in.cmd:REM set SOLR_SSL_CLIENT_KEY_STORE_PASSWORD=
solr.in.cmd:REM set SOLR_SSL_CLIENT_KEY_STORE_TYPE=
solr.in.sh:#SOLR_SSL_CLIENT_KEY_STORE=
solr.in.sh:#SOLR_SSL_CLIENT_KEY_STORE_PASSWORD=
solr.in.sh:#SOLR_SSL_CLIENT_KEY_STORE_TYPE=

Thanks,
Rajeswari
On 7/15/20, 12:46 AM, "Natarajan, Rajeswari"  
wrote:

Thank you for your reply. I looked at solr.in.sh I see that  
SOLR_SSL_CLIENT_KEY_STORE  is already commented out by default. But you are 
right I looked at the running solr,  I see the option -Djavax.net.ssl.keyStore 
pointing to solr-ssl.keystore.p12 , not sure how it is getting that value. Let 
me dig more. Thanks for the pointer. Also if you have a pointer how it get's 
populated  other than SOLR_SSL_CLIENT_KEY_STORE config in solr.in.sh , please 
let me know

#SOLR_SSL_CLIENT_KEY_STORE=
#SOLR_SSL_CLIENT_KEY_STORE_PASSWORD=
#SOLR_SSL_CLIENT_KEY_STORE_TYPE=
#SOLR_SSL_CLIENT_TRUST_STORE=
#SOLR_SSL_CLIENT_TRUST_STORE_PASSWORD=
#SOLR_SSL_CLIENT_TRUST_STORE_TYPE=

Yes we are not using Solr client auth.

Thanks,
Rajeswari

On 7/14/20, 5:55 PM, "Kevin Risden"  wrote:

Hmmm so I looked closer - it looks like a side effect of the default
passthrough of the keystore being passed to the client keystore.

https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L229

Can you remove or commout the entire SOLR_SSL_CLIENT_KEY_STORE 
section from
bin/solr or bin/solr.cmd depending on which version you are using? 
The key
being to make sure to not set "-Djavax.net.ssl.keyStore".

This assumes that you aren't using Solr client auth (which based on 
your
config you aren't) and you aren't trying to use Solr to connect to 
anything
that is secured via clientAuth (most likely you aren't).

If you can try this and report back that would be awesome. I think 
this
will fix the issue and it would be possible to make client auth opt 
in
instead of default fall back.
Kevin Risden



On Tue, Jul 14, 2020 at 1:46 AM Natarajan, Rajeswari <
rajeswari.natara...@sap.com> wrote:

> Thank you so much for the response.  Below are the configs I have 
in
> solr.in.sh and I followed
> https://lucene.apache.org/solr/guide/8_5/enabling-ssl.html 
documentation
>
> # Enables HTTPS. It is implicitly true if you set 
SOLR_SSL_KEY_STORE. Use
> this config
> # to enable https module with custom jetty configuration.
> SOLR_SSL_ENABLED=true
> # Uncomment to set SSL-related system properties
> # Be sure to update the paths to the correct keystore for your 
environment
> 

Re: SOLR Exact phrase search issue

[Charlie Hull]

On 14/07/2020 12:48, Erick Erickson wrote:

 This is almost certainly a mismatch between what you think is happening 
and what you’ve actually told Solr to do ;).
That's a great one-line explanation of 90% of the issues people face 
with Solr :-)


Charlie


Best,
Erick


On Jul 14, 2020, at 7:05 AM, Villalba Sans, Raúl  wrote:

Hello,

We have an app that uses SOLR as search engine. We have detected incorrect behavior for which we find no explanation. 
If we perform a search with the phrase "Què t’hi jugues" we do not receive any results, although we know that 
there is a result that contains this phrase. However, if we search for "Què t’hi" or for "t’hi 
jugues" we do find results, including "Què t’hi jugues ". We attach screenshots of the search tool and 
the xml of the results. We would greatly appreciate it if you could lend a hand in trying to find a solution or 
identify the cause of the problem.
  
Search 1 – “Què t’hi jugues”


  
Search 2 – “Què t’hi”

 

Search 3 – “t’hi jugues”


Best regards,
  

  
Raül Villalba Sans

Delivery Centers – Centros de Producción
  
Parque de Gardeny, Edificio 28

25071 Lleida, España
T +34 973 193 580
  




--
Charlie Hull
OpenSource Connections, previously Flax

tel/fax: +44 (0)8700 118334
mobile:  +44 (0)7767 825828
web: www.o19s.com

[ANNOUNCE] Apache Solr 8.6.0 released

[Bruno Roustant]

The Lucene PMC is pleased to announce the release of Apache Solr 8.6.0.


Solr is the popular, blazing fast, open source NoSQL search platform from
the Apache Lucene project. Its major features include powerful full-text
search, hit highlighting, faceted search, dynamic clustering, database
integration, rich document handling, and geospatial search. Solr is highly
scalable, providing fault tolerant distributed search and indexing, and
powers the search and navigation features of many of the world's largest
internet sites.


Solr 8.6.0 is available for immediate download at:


  


### Solr 8.6.0 Release Highlights:


 * Cross-Collection Join Queries: Join queries can now work
cross-collection, even when shared or when spanning nodes.

 * Search: Performance improvement for some types of queries when exact hit
count isn't needed by using BlockMax WAND algorithm.

 * Streaming Expression: Percentiles and standard deviation aggregations
added to stats, facet and time series.  Streaming expressions added to
/export handler.  Drill Streaming Expression for efficient and accurate
high cardinality aggregation.

 * Package manager: Support for cluster (CoreContainer) level plugins.

 * Health Check: HealthCheckHandler can now require that all cores are
healthy before returning OK.

 * Zookeeper read API: A read API at /api/cluster/zk/* to fetch raw ZK data
and view contents of a ZK directory.

 * Admin UI: New panel with security info in admin UI's dashboard.

 * Query DSL: Support for {param:ref} and {bool: {excludeTags:""}}

 * Ref Guide: Major redesign of Solr's documentation.


Please read CHANGES.txt for a full list of new features and changes:


  


Solr 8.6.0 also includes features, optimizations  and bugfixes in the
corresponding Apache Lucene release:


  


Note: The Apache Software Foundation uses an extensive mirroring network for

distributing releases. It is possible that the mirror you are using may not
have

replicated the release yet. If that is the case, please try another mirror.

This also applies to Maven access.

Re: [CAUTION] Re: [CAUTION] SSL + Solr 8.5.1 in cloud mode + Java 8

[Natarajan, Rajeswari]

From the /bin directory I did grep for SOLR_SSL_CLIENT_KEY_STORE , 
this is what I see . But somehow the option option -Djavax.net.ssl.keyStore is 
added 
grep SOLR_SSL_CLIENT_KEY_STORE *
grep: init.d: Is a directory
solr:  if [ -n "$SOLR_SSL_CLIENT_KEY_STORE" ]; then
solr:SOLR_SSL_OPTS+=" -Djavax.net.ssl.keyStore=$SOLR_SSL_CLIENT_KEY_STORE"
solr:if [ -n "$SOLR_SSL_CLIENT_KEY_STORE_PASSWORD" ]; then
solr:  export 
SOLR_SSL_CLIENT_KEY_STORE_PASSWORD=$SOLR_SSL_CLIENT_KEY_STORE_PASSWORD
solr:if [ -n "$SOLR_SSL_CLIENT_KEY_STORE_TYPE" ]; then
solr:  SOLR_SSL_OPTS+=" 
-Djavax.net.ssl.keyStoreType=$SOLR_SSL_CLIENT_KEY_STORE_TYPE"
solr.cmd:  IF DEFINED SOLR_SSL_CLIENT_KEY_STORE (
solr.cmd:set "SOLR_SSL_OPTS=!SOLR_SSL_OPTS! 
-Djavax.net.ssl.keyStore=%SOLR_SSL_CLIENT_KEY_STORE%"
solr.cmd:IF DEFINED SOLR_SSL_CLIENT_KEY_STORE_TYPE (
solr.cmd:  set "SOLR_SSL_OPTS=!SOLR_SSL_OPTS! 
-Djavax.net.ssl.keyStoreType=%SOLR_SSL_CLIENT_KEY_STORE_TYPE%"
solr.in.cmd:REM set SOLR_SSL_CLIENT_KEY_STORE=
solr.in.cmd:REM set SOLR_SSL_CLIENT_KEY_STORE_PASSWORD=
solr.in.cmd:REM set SOLR_SSL_CLIENT_KEY_STORE_TYPE=
solr.in.sh:#SOLR_SSL_CLIENT_KEY_STORE=
solr.in.sh:#SOLR_SSL_CLIENT_KEY_STORE_PASSWORD=
solr.in.sh:#SOLR_SSL_CLIENT_KEY_STORE_TYPE=

Thanks,
Rajeswari
On 7/15/20, 12:46 AM, "Natarajan, Rajeswari"  
wrote:

Thank you for your reply. I looked at solr.in.sh I see that  
SOLR_SSL_CLIENT_KEY_STORE  is already commented out by default. But you are 
right I looked at the running solr,  I see the option -Djavax.net.ssl.keyStore 
pointing to solr-ssl.keystore.p12 , not sure how it is getting that value. Let 
me dig more. Thanks for the pointer. Also if you have a pointer how it get's 
populated  other than SOLR_SSL_CLIENT_KEY_STORE config in solr.in.sh , please 
let me know

#SOLR_SSL_CLIENT_KEY_STORE=
#SOLR_SSL_CLIENT_KEY_STORE_PASSWORD=
#SOLR_SSL_CLIENT_KEY_STORE_TYPE=
#SOLR_SSL_CLIENT_TRUST_STORE=
#SOLR_SSL_CLIENT_TRUST_STORE_PASSWORD=
#SOLR_SSL_CLIENT_TRUST_STORE_TYPE=

Yes we are not using Solr client auth.

Thanks,
Rajeswari

On 7/14/20, 5:55 PM, "Kevin Risden"  wrote:

Hmmm so I looked closer - it looks like a side effect of the default
passthrough of the keystore being passed to the client keystore.

https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L229

Can you remove or commout the entire SOLR_SSL_CLIENT_KEY_STORE section 
from
bin/solr or bin/solr.cmd depending on which version you are using? The 
key
being to make sure to not set "-Djavax.net.ssl.keyStore".

This assumes that you aren't using Solr client auth (which based on your
config you aren't) and you aren't trying to use Solr to connect to 
anything
that is secured via clientAuth (most likely you aren't).

If you can try this and report back that would be awesome. I think this
will fix the issue and it would be possible to make client auth opt in
instead of default fall back.
Kevin Risden



On Tue, Jul 14, 2020 at 1:46 AM Natarajan, Rajeswari <
rajeswari.natara...@sap.com> wrote:

> Thank you so much for the response.  Below are the configs I have in
> solr.in.sh and I followed
> https://lucene.apache.org/solr/guide/8_5/enabling-ssl.html 
documentation
>
> # Enables HTTPS. It is implicitly true if you set SOLR_SSL_KEY_STORE. 
Use
> this config
> # to enable https module with custom jetty configuration.
> SOLR_SSL_ENABLED=true
> # Uncomment to set SSL-related system properties
> # Be sure to update the paths to the correct keystore for your 
environment
> SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.p12
> SOLR_SSL_KEY_STORE_PASSWORD=secret
> SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.p12
> SOLR_SSL_TRUST_STORE_PASSWORD=secret
> # Require clients to authenticate
> SOLR_SSL_NEED_CLIENT_AUTH=false
> # Enable clients to authenticate (but not require)
> SOLR_SSL_WANT_CLIENT_AUTH=false
> # SSL Certificates contain host/ip "peer name" information that is
> validated by default. Setting
> # this to false can be useful to disable these checks when re-using a
> certificate on many hosts
> SOLR_SSL_CHECK_PEER_NAME=true
>
> In local , with the below certificate it works
> ---
>
> keytool -list -keystore solr-ssl.keystore.p12
> Enter keystore password:
> Keystore type: PKCS12
> Keystore provider: SUN
>
> Your keystore contains 1 entry
>
> solr-18, Jun 26, 2020, PrivateKeyEntry,
> Certificate fingerprint (SHA1):
> AB:F2:C8:84:E8:E7:A2:BF:2D:0D:2F:D3:95:4A:98:5B:2A:88:81:50
> C02W48C6HTD6:solr-8.5.1 i843100$ keytool -list -v -keystore
> 

Elevation with distributed search causes NPE

[Marc Linden]

Hi all,

I'm facing the problem that Solr is throwing a NullPointerException when 
performing a distributed search with multiple shards having elevation 
configured where one or more shards do have elevated results but others do not.

We are using Solr 8.2 and have the QueryElevationComponent configured with 
"last-components" of the default search handler "/select". But the problem also 
occurs when using the explicit "/elevate" search handler.
  
...

  elevator

  
  ...
  

string
elevate.xml
  

### Steps to reproduce:

(1) Add entries to the elevate.xml of each core to elevate a specific document 
for the text "searchTerm":

   core1:
   
 ...
 
   
   core2:
   
 ...
 
   

(2) Execute query (we use port 9983): 
http://localhost:9983/solr/web/select?q=elevatedTerm=false=text_en=edismax=lang:en=localhost:9983/solr/core1,localhost:9983/solr/core2=[elevated],[shard],area,id=10=0

Now as both shards have elevated documents for the requested "searchTerm" the 
search results are as expected:

response: {
numFound: 5192,
start: 0,
maxScore: 1.9032197,
docs: [{
area: "press",
id: "core1docId1",
[elevated]: true,
[shard]: "localhost:9983/solr/core1"
}, {
area: "products",
id: "core2docId1",
[elevated]: true,
[shard]: "localhost:9983/solr/core2"
}, {
area: "press",
id: "core1docId2",
[elevated]: false,
[shard]: "localhost:9983/solr/core1"
},
...

(3) Remove the elevation entry for that "searchTerm" from one of the cores, 
e.g. via comment

   core2:
   
 ...
 
   


(4) Reload the modified core: 
http://localhost:9983/solr/admin/cores?action=RELOAD=core2

(5) Request same query again and you get the NPE:

error: {
trace: "java.lang.NullPointerException
   at 
org.apache.solr.handler.component.QueryComponent.unmarshalSortValues(QueryComponent.java:1068)
   at 
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:917)
   at 
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:613)
   at 
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:592)
   at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:431)
   at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:2578)
   at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:780)
   at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:566)
   at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:423)
   at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:350)
   at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)
   at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)
   ...


I want to ask the community if I'm missing something or if this really is a bug.

Thanks in advance,
Marc
Marc Linden
Developer

Virtual Identity AG
Grünwälderstraße 10-14
79098 Freiburg

+49 761 20758-422
--

marc.lin...@virtual-identity.com
http://www.virtual-identity.com

Freiburg | München | Wien | Porto



Virtual Identity AG
Grünwälderstraße 10-14
79098 Freiburg
Amtsgericht Freiburg, HRB 6218
Vorstand: Ralf Heller
Vorsitzende des Aufsichtsrates: Kirsten Heller
Umsatzsteuer-ID: DE208002218

Re: [CAUTION] SSL + Solr 8.5.1 in cloud mode + Java 8

[Natarajan, Rajeswari]

Thank you for your reply. I looked at solr.in.sh I see that  
SOLR_SSL_CLIENT_KEY_STORE  is already commented out by default. But you are 
right I looked at the running solr,  I see the option -Djavax.net.ssl.keyStore 
pointing to solr-ssl.keystore.p12 , not sure how it is getting that value. Let 
me dig more. Thanks for the pointer. Also if you have a pointer how it get's 
populated  other than SOLR_SSL_CLIENT_KEY_STORE config in solr.in.sh , please 
let me know

#SOLR_SSL_CLIENT_KEY_STORE=
#SOLR_SSL_CLIENT_KEY_STORE_PASSWORD=
#SOLR_SSL_CLIENT_KEY_STORE_TYPE=
#SOLR_SSL_CLIENT_TRUST_STORE=
#SOLR_SSL_CLIENT_TRUST_STORE_PASSWORD=
#SOLR_SSL_CLIENT_TRUST_STORE_TYPE=

Yes we are not using Solr client auth.

Thanks,
Rajeswari

On 7/14/20, 5:55 PM, "Kevin Risden"  wrote:

Hmmm so I looked closer - it looks like a side effect of the default
passthrough of the keystore being passed to the client keystore.

https://github.com/apache/lucene-solr/blob/master/solr/bin/solr#L229

Can you remove or commout the entire SOLR_SSL_CLIENT_KEY_STORE section from
bin/solr or bin/solr.cmd depending on which version you are using? The key
being to make sure to not set "-Djavax.net.ssl.keyStore".

This assumes that you aren't using Solr client auth (which based on your
config you aren't) and you aren't trying to use Solr to connect to anything
that is secured via clientAuth (most likely you aren't).

If you can try this and report back that would be awesome. I think this
will fix the issue and it would be possible to make client auth opt in
instead of default fall back.
Kevin Risden



On Tue, Jul 14, 2020 at 1:46 AM Natarajan, Rajeswari <
rajeswari.natara...@sap.com> wrote:

> Thank you so much for the response.  Below are the configs I have in
> solr.in.sh and I followed
> https://lucene.apache.org/solr/guide/8_5/enabling-ssl.html documentation
>
> # Enables HTTPS. It is implicitly true if you set SOLR_SSL_KEY_STORE. Use
> this config
> # to enable https module with custom jetty configuration.
> SOLR_SSL_ENABLED=true
> # Uncomment to set SSL-related system properties
> # Be sure to update the paths to the correct keystore for your environment
> SOLR_SSL_KEY_STORE=etc/solr-ssl.keystore.p12
> SOLR_SSL_KEY_STORE_PASSWORD=secret
> SOLR_SSL_TRUST_STORE=etc/solr-ssl.keystore.p12
> SOLR_SSL_TRUST_STORE_PASSWORD=secret
> # Require clients to authenticate
> SOLR_SSL_NEED_CLIENT_AUTH=false
> # Enable clients to authenticate (but not require)
> SOLR_SSL_WANT_CLIENT_AUTH=false
> # SSL Certificates contain host/ip "peer name" information that is
> validated by default. Setting
> # this to false can be useful to disable these checks when re-using a
> certificate on many hosts
> SOLR_SSL_CHECK_PEER_NAME=true
>
> In local , with the below certificate it works
> ---
>
> keytool -list -keystore solr-ssl.keystore.p12
> Enter keystore password:
> Keystore type: PKCS12
> Keystore provider: SUN
>
> Your keystore contains 1 entry
>
> solr-18, Jun 26, 2020, PrivateKeyEntry,
> Certificate fingerprint (SHA1):
> AB:F2:C8:84:E8:E7:A2:BF:2D:0D:2F:D3:95:4A:98:5B:2A:88:81:50
> C02W48C6HTD6:solr-8.5.1 i843100$ keytool -list -v -keystore
> solr-ssl.keystore.p12
> Enter keystore password:
> Keystore type: PKCS12
> Keystore provider: SUN
>
> Your keystore contains 1 entry
>
> Alias name: solr-18
> Creation date: Jun 26, 2020
> Entry type: PrivateKeyEntry
> Certificate chain length: 1
> Certificate[1]:
> Owner: CN=localhost, OU=Organizational Unit, O=Organization, L=Location,
> ST=State, C=Country
> Issuer: CN=localhost, OU=Organizational Unit, O=Organization, L=Location,
> ST=State, C=Country
> Serial number: 45a822c8
> Valid from: Fri Jun 26 00:13:03 PDT 2020 until: Sun Nov 10 23:13:03 PST
> 2047
> Certificate fingerprints:
>  MD5:  0B:80:54:89:44:65:93:07:1F:81:88:8D:EC:BD:38:41
>  SHA1: AB:F2:C8:84:E8:E7:A2:BF:2D:0D:2F:D3:95:4A:98:5B:2A:88:81:50
>  SHA256:
> 
9D:65:A6:55:D7:22:B2:72:C2:20:55:66:F8:0C:9C:48:B1:F6:48:40:A4:FB:CB:26:77:DE:C4:97:34:69:25:42
> Signature algorithm name: SHA256withRSA
> Subject Public Key Algorithm: 2048-bit RSA key
> Version: 3
>
> Extensions:
>
> #1: ObjectId: 2.5.29.17 Criticality=false
> SubjectAlternativeName [
>   DNSName: localhost
>   IPAddress: 172.20.10.4
>   IPAddress: 127.0.0.1
> ]
>
> #2: ObjectId: 2.5.29.14 Criticality=false
> SubjectKeyIdentifier [
> KeyIdentifier [
> : 1B 6F BB 65 A4 3C 6A F4   C9 05 08 89 88 0E 9E 76  .o.e. 0010: A1 B7 28 BE..(.
> ]
>
> /
> In a