Re: Three questions about huge tlog problem and CDCR

[damienk]

Did you run /cdcr?action=DISABLEBUFFER on both sides?


On Fri, 20 Dec 2019 at 05:22, alwaysbluesky 
wrote:

> Thank you for the advice.
>
> By the way, when I upload a new collectin configuration to zookeepr and
> enable bidirectional CDCR for the collections on both prod and dr
> side(/cdcr?action=START), and reload the collections, CDCR
> usually didn't work. So if I restarted entire nodes in the cluster on both
> prod and dr, CDCR started working.
>
> Should I normally restart Solr after enabling/disabling the CDCR? Reloading
> the collections without Solr restart is not enough to apply the CDCR
> change?
>
>
>
> --
> Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
>

Re: Synonym expansions w/ phrase slop exhausting memory after upgrading to SOLR 7

[Michael Gibney]

Solution 2 (downgrade to 7.5) fixes the problem by reverting to
building proximity (SpanNear) queries that do not explode
exponentially like MultiPhraseQuery does; but note that
SpanNearQueries in 7.5 are dropped (SOLR-12243), so they have
literally no effect whatsoever (aside from the minimal cost of
building them before they get GC'd).

You are correct that there's still a problem wrt exponential graph
query expansion (a case often associated with multi-term synonyms and
WordDelimiterGraphFilter). In 8.1 and later, the parser still
*attempts* to build the exact same queries, but will be prevented from
doing so (and return an error response code) when expansion hits the
effective maxBooleanClauses threshold. So individual requests will
(for certain analysis/input combinations) still error out, but the
entire system is no longer affected. Some related issues (having to do
with graph token streams) that might be of interest:
https://issues.apache.org/jira/browse/LUCENE-8544
https://issues.apache.org/jira/browse/LUCENE-7398
https://issues.apache.org/jira/browse/LUCENE-4312


I interpret the documentation
(https://lucene.apache.org/solr/guide/8_3/query-settings-in-solrconfig.html#maxbooleanclauses)
to indicate that the maxBooleanClauses setting in solr.xml takes
priority as a hard upper bound; so the individual settings in
solrconfig.xml may be used per-collection to *decrease* the global
limit. If you attempt to set maxBooleanClauses larger in
solrconfig.xml than the systemwide setting (configured via solr.xml),
a warning message will be logged, but the attempted configuration will
otherwise have no affect (the lower systemwide value will still be the
effective limit).

Michael


On Wed, Dec 18, 2019 at 9:48 PM Nick D  wrote:
>
> Michael,
>
> Thank you so much, that was extremely helpful. My googlefu wasn't good
> enough I guess.
>
> 1. Was my initial fix just to stop it from exploding.
>
> 2. Will be the perm solutions for now until we can get some things squared
> away for 8.0.
>
> Sounds like even in 8 there is a problem with any graph query expansion
> potential still growing rather large but it just won't consume all
> available memory, is that correct?
>
> One final question, why would the maxbooleanqueries value in the solrconfig
> still apply? Reading through all the jiras I thought that was supposed to
> still be a fail safe, did I miss something?
>
> Thanks again for your help,
>
> Nick
>
> On Wed, Dec 18, 2019, 8:10 AM Michael Gibney 
> wrote:
>
> > This is related to this issue:
> > https://issues.apache.org/jira/browse/SOLR-13336
> >
> > Also tangentially relevant:
> > https://issues.apache.org/jira/browse/LUCENE-8531
> > https://issues.apache.org/jira/browse/SOLR-12243
> >
> > I think your options include:
> > 1. setting slop=0, which restores SpanNearQuery as the graph phrase
> > query implementation (see LUCENE-8531)
> > 2. downgrading to 7.5 would avoid the OOM, but would cause graph
> > phrase queries to be effectively ignored (see SOLR-12243)
> > 3. upgrade to 8.0, which will restore the failsafe maxBooleanClauses,
> > avoiding OOM but returning an error code for affected queries (which
> > in your case sounds like most queries?) (see SOLR-13336)
> >
> > Michael
> >
> > On Tue, Dec 17, 2019 at 4:16 PM Nick D  wrote:
> > >
> > > Hello All,
> > >
> > > We recently upgraded from Solr 6.6 to Solr 7.7.2 and recently had spikes
> > in
> > > memory that eventually caused either an OOM or almost 100% utilization of
> > > the available memory. After trying a few things, increasing the JVM heap,
> > > making sure docValues were set for all Sort, facet fields (thought maybe
> > > the fieldCache was blowing up), I was able to isolate a single query that
> > > would cause the used memory to become fully exhausted and effectively
> > > render the instance dead. After applying a timeAllowed  value to the
> > query
> > > and reducing the query phrase (system would crash on without throwing the
> > > warning on longer queries containing synonyms). I was able to idenitify
> > the
> > > following warning in the logs:
> > >
> > > o.a.s.s.SolrIndexSearcher Query: 
> > >
> > > the request took too long to iterate over terms. Timeout: timeoutAt:
> > > 812182664173653 (System.nanoTime(): 812182715745553),
> > > TermsEnum=org.apache.lucene.codecs.blocktree.SegmentTermsEnum@7a0db441
> > >
> > > I have narrowed the problem down to the following:
> > > the way synonyms are being expaneded along with phrase slop.
> > >
> > > With a ps=5 I get 4096 possible permutations of the phrase being searched
> > > with because of synonyms, looking similar to:
> > > ngs_title:"bereavement leave type build bereavement leave type data p"~5
> > >  ngs_title:"bereavement leave type build bereavement bereavement type
> > data
> > > p"~5
> > >  ngs_title:"bereavement leave type build bereavement jury duty type data
> > > p"~5
> > >  ngs_title:"bereavement leave type build bereavement maternity 

Re: Three questions about huge tlog problem and CDCR

[alwaysbluesky]

Thank you for the advice.

By the way, when I upload a new collectin configuration to zookeepr and
enable bidirectional CDCR for the collections on both prod and dr
side(/cdcr?action=START), and reload the collections, CDCR
usually didn't work. So if I restarted entire nodes in the cluster on both
prod and dr, CDCR started working.

Should I normally restart Solr after enabling/disabling the CDCR? Reloading
the collections without Solr restart is not enough to apply the CDCR change?



--
Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: Three questions about huge tlog problem and CDCR

[Erick Erickson]

This usually indicates that the connection between DCs is broken and one or the 
other is falling behind.

Note: “bidirectional” does _not_ mean that you can index to both DCs 
simultaneously, rather than you can switch from indexing in one DC to the 
other….

Best,
Erick

> On Dec 19, 2019, at 1:01 AM, alwaysbluesky  wrote:
> 
> found a typo. correcting "updateLogSynchronizer" is set to 6(1 min), not
> 1 hour
> 
> 
> 
> --
> Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html

Re: CVE-2017-7525 fix for Solr 7.7.x

[Mehai, Lotfi]

Kevin & Colvin
Thanks for this details response.

Lotfi



On Thu, Dec 19, 2019 at 11:59 AM Colvin Cowie 
wrote:

> Sorry, in Solr 8 and master there are some additional users of Jackson. But
> they still don't appear to use default typing or unrestricted subtypes.
>
>
> On Thu, 19 Dec 2019 at 16:50, Colvin Cowie 
> wrote:
>
> > Hi,
> >
> > We've got users on Solr 6 (and use Jackson ourselves), so I had a look at
> > this CVE and related Jackson exploits, to see whether they are actually
> > exploitable in Solr.
> >
> >- What parts of Solr actually use Jackson (I thought noggit was used
> >for the JSON de/serialization)?
> >- Do any of the object mappers used enable default typing? (which is
> >necessary to exploit CVE-2017-7525
> >
> https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/
> >)
> >- Is polymorphism used with Jackson without restricting subtypes (e.g.
> >@JsonTypeInfo with JsonTypeInfo.Id.CLASS, which allows other exploits
> like
> >CVE-2017-15095
> >
> https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062
> >)
> >
> > Aside from test classes, the only users of Jackson appear to be
> >
> >- org.apache.solr.analytics.AnalyticsRequestParser
> >- org.apache.solr.prometheus.scraper.SolrScraper
> >
> > From what I can see in the source on master and the 7_7 branch default
> > typing isn't ever enabled, and @JsonTypeInfo is restricted to named
> > subtypes.
> >
> > In the 6_6 branch source it seems Jackson is only used in a handful of
> > tests.
> > Prior to Solr 6.3 (https://issues.apache.org/jira/browse/SOLR-9589)
> >
> org.apache.solr.client.solrj.response.DelegationTokenResponse.JsonMapResponseParser
> > constructed an ObjectMapper without configuration.
> >
> > So, as far as I can see, the polymorphic deserialization Remote Code
> > Execution vulnerabilities on (older versions of) Jackson shouldn't
> actually
> > be exploitable in Solr 7.7... but I could be wrong, and new
> vulnerabilities
> > may still be discovered.
> >
> > Colvin
> >
> >
> > On Wed, 18 Dec 2019 at 18:16, Kevin Risden  wrote:
> >
> >> There are no specific plans for any 7.x branch releases that I'm aware
> of.
> >> Specifically for SOLR-13110, that required upgrading Hadoop 2.x to 3.x
> for
> >> specifically jackson-mapper-asl and there are no plans to backport that
> to
> >> 7.x even if there was a future 7.x release.
> >>
> >> Kevin Risden
> >>
> >>
> >> On Wed, Dec 18, 2019 at 8:44 AM Mehai, Lotfi 
> >> wrote:
> >>
> >> > Hello;
> >> >
> >> > We are using Solr 7.7.0. The CVE-2017-7525 have been fixed for Solr
> 8.x.
> >> > https://issues.apache.org/jira/browse/SOLR-13110
> >> >
> >> > When the fix will be available for Solr 7.7.x
> >> >
> >> > Lotfi
> >> >
> >>
> >
>

Re: CVE-2017-7525 fix for Solr 7.7.x

[Colvin Cowie]

Sorry, in Solr 8 and master there are some additional users of Jackson. But
they still don't appear to use default typing or unrestricted subtypes.


On Thu, 19 Dec 2019 at 16:50, Colvin Cowie 
wrote:

> Hi,
>
> We've got users on Solr 6 (and use Jackson ourselves), so I had a look at
> this CVE and related Jackson exploits, to see whether they are actually
> exploitable in Solr.
>
>- What parts of Solr actually use Jackson (I thought noggit was used
>for the JSON de/serialization)?
>- Do any of the object mappers used enable default typing? (which is
>necessary to exploit CVE-2017-7525
>https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/
>)
>- Is polymorphism used with Jackson without restricting subtypes (e.g.
>@JsonTypeInfo with JsonTypeInfo.Id.CLASS, which allows other exploits like
>CVE-2017-15095
>
> https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062
>)
>
> Aside from test classes, the only users of Jackson appear to be
>
>- org.apache.solr.analytics.AnalyticsRequestParser
>- org.apache.solr.prometheus.scraper.SolrScraper
>
> From what I can see in the source on master and the 7_7 branch default
> typing isn't ever enabled, and @JsonTypeInfo is restricted to named
> subtypes.
>
> In the 6_6 branch source it seems Jackson is only used in a handful of
> tests.
> Prior to Solr 6.3 (https://issues.apache.org/jira/browse/SOLR-9589)
> org.apache.solr.client.solrj.response.DelegationTokenResponse.JsonMapResponseParser
> constructed an ObjectMapper without configuration.
>
> So, as far as I can see, the polymorphic deserialization Remote Code
> Execution vulnerabilities on (older versions of) Jackson shouldn't actually
> be exploitable in Solr 7.7... but I could be wrong, and new vulnerabilities
> may still be discovered.
>
> Colvin
>
>
> On Wed, 18 Dec 2019 at 18:16, Kevin Risden  wrote:
>
>> There are no specific plans for any 7.x branch releases that I'm aware of.
>> Specifically for SOLR-13110, that required upgrading Hadoop 2.x to 3.x for
>> specifically jackson-mapper-asl and there are no plans to backport that to
>> 7.x even if there was a future 7.x release.
>>
>> Kevin Risden
>>
>>
>> On Wed, Dec 18, 2019 at 8:44 AM Mehai, Lotfi 
>> wrote:
>>
>> > Hello;
>> >
>> > We are using Solr 7.7.0. The CVE-2017-7525 have been fixed for Solr 8.x.
>> > https://issues.apache.org/jira/browse/SOLR-13110
>> >
>> > When the fix will be available for Solr 7.7.x
>> >
>> > Lotfi
>> >
>>
>

Re: Client Cert Broken in Solr 8.2.0 because of a Jetty Issue (workaround included)

[Kevin Risden]

Thanks for the report Ryan. It looks like this fell through the cracks and
was reported a second time in Jira.

https://issues.apache.org/jira/browse/SOLR-14106

I have a patch up there that should help with some comments about multiple
clientAuth certificates.

Kevin Risden


On Fri, Sep 27, 2019 at 1:04 PM Ryan Rockenbaugh
 wrote:

> All,
> If you are using client authentication with SSL in Solr
> (SOLR_SSL_NEED_CLIENT_AUTH=true or  SOLR_SSL_WANT_CLIENT_AUTH=true), be
> advised that Jetty made a change that will break Solr 8.2.0
> The version of Jetty packaged with Solr 8.2.0 changed to 9.4.19.v20190610
> (see
> https://lucene.apache.org/solr/8_2_0/changes/Changes.html#v8.2.0.versions_of_major_components
> )
> The official Jetty issue is here:
> https://github.com/eclipse/jetty.project/issues/3554
> The stated fix is:
> Set endpointIdentificationAlgorithm=null or better yet use
> SslContextFactory.Server instead of a plain SslContextFactory.
> I found I couldn't change the class from SslContextFactory to
> SslContextFactory.Server
> My workaround was to update the file server/etc/jetty-ssl.xml, adding the
> following entry to the  element:
>
> 
> Thanks,
> Ryan Rockenbaugh
>
>
>
>
>
> "Do all the good you can, By all the means you can, In all the ways
> you can, In all the places you can, At all the times you can, To all
> the people you can, As long as ever you can."
>
>  - John Wesley

Re: CVE-2017-7525 fix for Solr 7.7.x

[Colvin Cowie]

Hi,

We've got users on Solr 6 (and use Jackson ourselves), so I had a look at
this CVE and related Jackson exploits, to see whether they are actually
exploitable in Solr.

   - What parts of Solr actually use Jackson (I thought noggit was used for
   the JSON de/serialization)?
   - Do any of the object mappers used enable default typing? (which is
   necessary to exploit CVE-2017-7525
   https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/
   )
   - Is polymorphism used with Jackson without restricting subtypes (e.g.
   @JsonTypeInfo with JsonTypeInfo.Id.CLASS, which allows other exploits like
   CVE-2017-15095
   
https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062
   )

Aside from test classes, the only users of Jackson appear to be

   - org.apache.solr.analytics.AnalyticsRequestParser
   - org.apache.solr.prometheus.scraper.SolrScraper

>From what I can see in the source on master and the 7_7 branch default
typing isn't ever enabled, and @JsonTypeInfo is restricted to named
subtypes.

In the 6_6 branch source it seems Jackson is only used in a handful of
tests.
Prior to Solr 6.3 (https://issues.apache.org/jira/browse/SOLR-9589)
org.apache.solr.client.solrj.response.DelegationTokenResponse.JsonMapResponseParser
constructed an ObjectMapper without configuration.

So, as far as I can see, the polymorphic deserialization Remote Code
Execution vulnerabilities on (older versions of) Jackson shouldn't actually
be exploitable in Solr 7.7... but I could be wrong, and new vulnerabilities
may still be discovered.

Colvin


On Wed, 18 Dec 2019 at 18:16, Kevin Risden  wrote:

> There are no specific plans for any 7.x branch releases that I'm aware of.
> Specifically for SOLR-13110, that required upgrading Hadoop 2.x to 3.x for
> specifically jackson-mapper-asl and there are no plans to backport that to
> 7.x even if there was a future 7.x release.
>
> Kevin Risden
>
>
> On Wed, Dec 18, 2019 at 8:44 AM Mehai, Lotfi 
> wrote:
>
> > Hello;
> >
> > We are using Solr 7.7.0. The CVE-2017-7525 have been fixed for Solr 8.x.
> > https://issues.apache.org/jira/browse/SOLR-13110
> >
> > When the fix will be available for Solr 7.7.x
> >
> > Lotfi
> >
>

Re: [EXTERNAL] Autoscaling simulation error

[Andrzej Białecki]

Hi,

Thanks for the data. I see the problem now - it’s a bug in the simulator. I 
filed a Jira issue to track and fix it: SOLR-14122.

> On 16 Dec 2019, at 19:13, Cao, Li  wrote:
> 
>> I am using solr 8.3.0 in cloud mode. I have collection level autoscaling 
>> policy and the collection name is “entity”. But when I run autoscaling 
>> simulation all the steps failed with this message:
>> 
>>   "error":{
>> "exception":"java.io.IOException: 
>> java.util.concurrent.ExecutionException: 
>> org.apache.solr.common.SolrException: org.apache.solr.common.SolrException: 
>> Could not find collection : entity/shards",
>> "suggestion":{
>>   "type":"repair",
>>   "operation":{
>> "method":"POST",
>> "path":"/c/entity/shards",
>> "command":{"add-replica":{
>> "shard":"shard2",
>> "node":"my_node:8983_solr",
>> "type":"TLOG",
>> "replicaInfo":null}}},

Re: "No value present" when set cluster policy for autoscaling in solr cloud mode

[Andrzej Białecki]

Hi,

For some strange reason global tags (such as “cores”) don’t support the 
“nodeset” syntax. For “cores” the only supported attribute is “node”, and then 
you’re only allowed to use #ANY or a single specific node name (with optional 
“!" NOT operand), or a JSON array containing node names to indicate the IN 
operand.

The Ref Guide indeed is not very clear on that…


> On 17 Dec 2019, at 21:20, Cao, Li  wrote:
> 
> Hi!
> 
> I am trying to add a cluster policy to a freshly built 8.3.0 cluster (no 
> collection added). I got this error when adding such a cluster policy
> 
> { 
> "set-cluster-policy":[{"cores":"<3","nodeset":{"sysprop.rex.node.type":"tlog"}}]}
> 
> Basically I want to limit the number of cores for certain machines with a 
> special environmental variable value.
> 
> But I got this error response:
> 
> {
>  "responseHeader":{
>"status":400,
>"QTime":144},
>  "result":"failure",
>  "WARNING":"This response format is experimental.  It is likely to change in 
> the future.",
>  "error":{
>"metadata":[
>  "error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject",
>  "root-error-class","org.apache.solr.api.ApiBag$ExceptionWithErrObject"],
>"details":[{
>"set-cluster-policy":[{
>"cores":"<3",
>"nodeset":{"sysprop.rex.node.type":"tlog"}}],
>"errorMessages":["No value present"]}],
>"msg":"Error in command payload",
>"code":400}}
> 
> However, this works:
> 
> { "set-cluster-policy":[{"cores":"<3","node":"#ANY"}]}
> 
> I read the autoscaling policy documentations and cannot figure out why. Could 
> someone help me on this?
> 
> Thanks!
> 
> Li

Re: Move SOLR from cloudera HDFS to SOLR on Docker

[Jason Gerlowski]

Hi Wael,

Getting configs and data out of Cloudera's HDP is about the same as
moving data between any 2 Solr clusters.

Moving configs is going to be the easy part.

If you're currently using Solr in SolrCloud mode, then your configs
all live in ZooKeeper.  Recent versions of Solr have a utility for
downloading and uploading collection configs from ZooKeeper: run
"bin/solr zk" for more details.  Without checking, I'm not sure
whether this tool is available as far back as 4.10.3.  But the way
that the tool works, I believe the current version would work against
an older SolrCloud install, so you can download a more recent version
and use the tool to extract and reupload your configs where you need
them.

If you're _not_ using SolrCloud, your collection configs will be on
disk, and moving them between installs is as simple as moving them on
disk.

Much more complicated is getting your index data into your new
install.  If you stay on the same Solr version, you should be able to
re-use your existing index files.  That said, recent releases have
seen Solr make strides in becoming cloud/docker aware, or at least
tolerant.  8.3.1 or 7.7.2 will likely be easier to manage on docker
than 4.10.3.  Additionally, 4.10.3 no longer receives any security
backports from the community, and hasn't for some time.  It's worth
considering whether that offers enough benefits to be worth the pain
of reindexing.

Best,

Jason

On Wed, Dec 18, 2019 at 9:26 AM Wael Kader  wrote:
>
> Hello,
>
> I want to move data from my SOLR setup on Cloudera Hadoop to a docker SOLR
> container.
> I don't need to run all the hadoop services in my setup as I am only
> currently using SOLR from the cloudera HDP.
>
> My concern now is to know what's the best way to move the data and schema
> to Docker container.
> I don't mind moving data to an older version of SOLR Container to match the
> 4.10.3 SOLR Version I have on Cloudera.
>
> Much help is appreciated.
>
> --
> Regards,
> Wael

Clustering always return labels":["Other Topics"]

[Nehemia Litterat]

Hi,
I am using stand alone solr 8.2 server.
Used this guide to define Clustering
https://carrot2.github.io/solr-integration-strategies/carrot2-3.6.3/index.html


(Attached the config file)

When running a query no real results are returned
Included the file with the query and return results as seen in the admin GUI

I will appreciate any suggestions.

Thanks,

[image: photo]
*Nehemia Litterat*
Our story

+972-54-6609351 | nlitte...@gmail.com

Skype: nlitterat <#SignatureSanitizer_SafeHtmlFilter_>

Please consider your environmental responsibility. Before printing this
e-mail message, ask yourself whether you really need a hard copy.
Create your own email signature

{
  "responseHeader":{
"status":0,
"QTime":2},
  "response":{"numFound":2,"start":0,"maxScore":2.2009814,"docs":[
  {
"sid":[656821518625792000],
"firstName":["Kathie's"],
"lastName":["sorters"],
"birthYear":[1977.0],
"birthMonth":[11.0],
"birthDay":[19.0],
"deathYear":[1991.0],
"deathMonth":[6.0],
"deathDay":[4.0],
"gender":["FEMALE"],
"shortDesc":["Columbus knacker Flo's Mario's sportswoman's 
controversies reciprocation waterfowls grans menstruate fiddler implacable 
katydid defrosting weakened occluding Matisse's pontoons excels roadways 
towpaths squabs Guatemala's watercraft's muscly glimpsed animators rainmaking's 
Hainan's benzine's heat's hatches inviolability's mu's Cebu's removable 
Cartersville brook sitter's plagiarizers philandering's tamperers labored 
township's itchiness's functionally onerousness racers bathos's decoder's 
solitaries frizzled critters Kevin's reemployed lampposts prawning frozen 
fatalities Weinberg's apostle incestuousness accounting zing perkiness 
veterinary coco's Wendell saintlike beryl Murillo Lahore visualization 
radicalization's Chileans rathskeller's dehydrated perplex musician's unpacking 
haggardly ascertainable uncooked rotary's derangement's glares desertion 
bellyfuls cockfight Pliny blow tamer morsel midyears donation's glows 
microgroove nonactive jangles Fraser's "],
"resourceVisibility":["SHARED"],
"id":"2974e283-9a84-4c50-87e1-9480370e4d98",
"_version_":1653164745593716736,
"score":2.2009814},
  {
"sid":[656822798601543680],
"firstName":["Name955"],
"lastName":["Name562"],
"birthYear":[1968.0],
"birthMonth":[8.0],
"birthDay":[1.0],
"deathYear":[1986.0],
"deathMonth":[4.0],
"deathDay":[6.0],
"gender":["FEMALE"],
"shortDesc":["tropic riveted ttys mischances dimness bliss archfiends 
cagiest Sheri rte speechless womanize delinquencies recasting's updraft Hendrix 
reprocessing sneakily biliousness mollycoddle's sexpot's umber's moonwalk 
iceboat's snippet's Como Fujian's lubricity's minimalism concoctions chirped 
bicentenaries president's flatboats planting chilies ketch Bushido reimpose 
crevice Sayers owed somebodies ordinations botany toastmasters briniest Jake's 
faint's dermis's multiplexes floodwaters bohemianism's Cardin nimbi Cb 
freighter's work realigning restudy babel's chummily Revlon's brougham's 
evictions ululate allowably Barnett consultative haughtiness's unable refolds 
reechoing pimp's keenness's breaded spendthrift's composite recap tracheotomies 
seagull Kit's epiphany bioethics's Alighieri's cowries lines knacker knew 
wheezes lawgivers Stella's pestled bass's antilogarithms fund's elk shockers 
greetings coworkers "],
"resourceVisibility":["SHARED"],
"id":"3aa3dc89-f642-4035-a515-1de6640b981a",
"_version_":1653165065549905920,
"score":2.2009814}]
  },
  "clusters":[{
  "labels":["Other Topics"],
  "score":0.0,
  "other-topics":true,
  "docs":["2974e283-9a84-4c50-87e1-9480370e4d98",
"3aa3dc89-f642-4035-a515-1de6640b981a"]}]}




  

  
  8.2.0

  

  
  
  

  
  

  
  

  
  
  

  
  

  
  ${solr.data.dir:}


  
  

  
  

  
  





















${solr.lock.type:native}













  


  
  
  
  
  
  

  
  



  ${solr.ulog.dir:}
  ${solr.ulog.numVersionBuckets:65536}




  ${solr.autoCommit.maxTime:15000}
  false





  ${solr.autoSoftCommit.maxTime:-1}




  

  
  

  
  


${solr.max.booleanClauses:1024}























true





20


200




  

  


  

  



false

  


  
  








  

  
  
  


  explicit
  10