Re: Solr multi core query too slow

[Anshuman Singh]

Thanks for your reply, Erick. You helped me in improving my understanding
of how Solr distributed requests work internally.

Actually my ultimate goal is to improve search performance in one of our
test environment where the queries are taking upto 60 seconds to execute.
*We want to fetch at least the first top 100 rows in seconds (< 5 seconds).
*

Right now, we have 7 Collections across 10 Solr nodes, each Collection
having approx 2B records equally distributed across 20 shards with rf 2.
Each replica/core is ~40GB in size . The number of users are very few
(<10). We are using HDDs and each host has 128 GB RAM. Solr JVM Heap size
is 24GB. In the actual production environment, we are planning for 100 such
machines and we will be ingesting ~2B records on daily basis. We will
retain data of upto 3 months.

I followed your suggestion of not querying more than 100 rows and this is
my observation. I ran queries with the debugQuery param and found that the
query response time depends on the worst performing shard as some of the
shards take longer to execute the query than other shards.

Here are my questions:

   1.  Is decreasing number of shards going to help us as there will be
   lesser number of shards to be queried?
   2.  Is increasing number of replicas going to help us as there will be
   load balancing?
   3.  How many records should we keep in each Collection or in each
   replica/core? Will we face performance issues if the core size becomes too
   big?

Any other suggestions are appreciated.

On Wed, May 27, 2020 at 9:23 PM Erick Erickson 
wrote:

> First of all, asking for that many rows will spend a lot of time
> gathering the document fields. Assuming you have stored fields,
> each doc requires
> 1> the aggregator node getting the candidate 10 docs from each shard
>
> 2> The aggregator node sorting those 10 docs from each shard into the
> true top 10 based on the sort criteria (score by default)
>
> 3> the aggregator node going back to the shards and asking them for those
> docs of that 10 that are resident on that shard
>
> 4> the aggregator node assembling the final docs to be sent to the client
> and sending them.
>
> So my guess is that when you fire requests at a particular replica that
> has to get them from the other shard’s replica on another host, the network
> back-and-forth is killing your perf. It’s not that your network is having
> problems, just that you’re pushing a lot of data back and forth in your
> poorly-performing cases.
>
> So first of all, specifying 100K rows is an anti-pattern. Outside of
> streaming, Solr is built on the presumption that you’re after the top few
> rows (< 100, say). The times vary a lot depending on whether you need to
> read stored fields BTW.
>
> Second, I suspect your test is bogus. If you run the tests in the order
> you gave, the first one will read the necessary data from disk and probably
> have it in the OS disk cache for the second and subsequent. And/or you’re
> getting results from your queryResultCache (although you’d have to have a
> big one). Specifying the exact same query when trying to time things is
> usually a mistake.
>
> If your use-case requires 100K rows, you should be using streaming or
> cursorMark. While that won’t make the end-to-end time shorter, but won’t
> put such a strain on the system.
>
> Best,
> Erick
>
> > On May 27, 2020, at 10:38 AM, Anshuman Singh 
> wrote:
> >
> > I have a Solr cloud setup (Solr 7.4) with a collection "test" having two
> > shards on two different nodes. There are 4M records equally distributed
> > across the shards.
> >
> > If I query the collection like below, it is slow.
> > http://localhost:8983/solr/*test*/select?q=*:*&rows=10
> > QTime: 6930
> >
> > If I query a particular shard like below, it is also slow.
> > http://localhost:8983/solr/*test_shard1_replica_n2*
> > /select?q=*:*&rows=10&shards=*shard2*
> > QTime: 5494
> > *Notice shard2 in shards parameter and shard1 in the core being queried.*
> >
> > But this is faster:
> > http://localhost:8983/solr/*test_shard1_replica_n2*
> > /select?q=*:*&rows=10&shards=*shard1*
> > QTime: 57
> >
> > This is also faster:
> > http://localhost:8983/solr/*test_shard2_replica_n4*
> > /select?q=*:*&rows=10&shards=*shard2*
> > QTime: 71
> >
> > I don't think it is the network as I performed similar tests with a
> single
> > node setup as well. If you query a particular core and the corresponding
> > logical shard, it is much faster than querying a different shard or core.
> >
> > Why is this behaviour? How to make the first two queries work as fast as
> > the last two queries?
>
>

TolerantUpdateProcessorFactory not functioning

[Hup Chen]

Hi,

My solr indexing did not tolerate bad record but simply exited even I have 
configured TolerantUpdateProcessorFactory  in solrconfig.xml.
Please advise how could I get TolerantUpdateProcessorFactory  to be working?

solrconfig.xml:

 
   
 100
   
   
 

restarted solr before indexing:
service solr stop
service solr start

curl 
"http://localhost:7070/solr/mycore/update?update.chain=tolerant-chain&maxErrors=100";
 -d @test.json

The first record is a bad record in test.json, the rest were not indexed.

{
  "responseHeader":{
"errors":[{
"type":"ADD",
"id":"0007264097",
"message":"ERROR: [doc=0007264097] Error adding field 'usedshipping'='' 
msg=empty String"}],
"maxErrors":100,
"status":400,
"QTime":0},
  "error":{
"metadata":[
  "error-class","org.apache.solr.common.SolrException",
  "root-error-class","org.apache.solr.common.SolrException"],
"msg":"Cannot parse provided JSON: Expected key,value separator ':': 
char=\",position=1240 AFTER='isbn\":\"4032171203\", \"sku\":\"\", 
\"title\":\"ãã³ãã¡ã¡ããã³ã \"author\"' BEFORE=':\"Sachiko OÃtomo\", 
ãã, \"ima'",
"code":400}}

Re: Solr multi core query too slow

[Erick Erickson]

Right, you’re running into the “laggard” problem, you can’t get the overall
result back until every shard has responded. There’s an interesting
parameter “shards.info=true” will give you some information about
the time taken by the sub-search on each shard.

But given your numbers, I think your root problem is that 
your hardware is overmatched. In total, you have 14B documents, correct?
and a replication factor of 2. Meaning each of your 10 machines has 2.8
billion docs in 128G total memory. Another way to look at it is that you
have 7 x 20 x 2 = 280 replicas each with a 40G index. So each node has
28 replicas/node and handles over a terabyte of index in aggregate. At first
blush, you’ve overloaded your hardware. My guess here is that one node or
the other has to do a lot of swapping/gc/whatever quite regularly when
you query. Given that you’re on HDDs, this can be quite expensive. 

I think you can simplify your analysis problem a lot by concentrating on
a single machine, load it up and analyze it heavily. Monitor I/O, analyze
GC and CPU utilization. My first guess is you’ll see heavy I/O. Once the index
is read into memory, a well-sized Solr installation won’t see much I/O,
_especially_ if you simplify the query to only ask for, say, some docValues
field or rows=0. I think that your OS is swapping significant segments of the
Lucene index in and out to satisfy your queries.

GC is always a place to look. You should have GC logs available to see if
you spend lots of CPU cycles in GC. I doubt that GC tuning will fix your
performance issues, but it’s something to look at.

A quick-n-dirty way to see if it’s swapping as I suspect is to monitor
CPU utilization. A red flag is if it’s low and your queries _still_ take
a long time. That’s a “smoking gun” that you’re swapping. While
indicative, that’s not definitive since I’ve also seen CPU pegged because
of GC, so if CPUs are running hot, you have to dig deeper...


So to answer your questions:

1> I doubt decreasing the number of shards will help.. I think you
 simply have too many docs per node, changing the number of 
 shards isn’t going to change that.

2> A strongly suspect that increasing replicas will make the 
 problem _worse_ since it’ll just add more docs per node.

3> It Depends (tm). I wrote “the sizing blog” a long time ago because
 this question comes up so often and is impossible to answer in the
 abstract. Well, it’s possible in theory, but in practice there are just
 too many variables. What you need to do to fully answer this in your
 situation with your data is set up a node and “test it to destruction”.

 
https://lucidworks.com/post/sizing-hardware-in-the-abstract-why-we-dont-have-a-definitive-answer/

I want to emphasize that you _must_ have realistic queries when
you test as in that blog, and you _must_ have a bunch of them
in order to not get fooled by hitting, say, your queryResultCache. I
had one client who “stress tested” with the same query and was
getting 3ms response times because, after the first one, they never
needed to do any searching at all, everything was in caches. Needless
to say that didn’t hold up when they used a realistic query mix.

Best,
Erick

> On May 29, 2020, at 4:53 AM, Anshuman Singh  wrote:
> 
> Thanks for your reply, Erick. You helped me in improving my understanding
> of how Solr distributed requests work internally.
> 
> Actually my ultimate goal is to improve search performance in one of our
> test environment where the queries are taking upto 60 seconds to execute.
> *We want to fetch at least the first top 100 rows in seconds (< 5 seconds).
> *
> 
> Right now, we have 7 Collections across 10 Solr nodes, each Collection
> having approx 2B records equally distributed across 20 shards with rf 2.
> Each replica/core is ~40GB in size . The number of users are very few
> (<10). We are using HDDs and each host has 128 GB RAM. Solr JVM Heap size
> is 24GB. In the actual production environment, we are planning for 100 such
> machines and we will be ingesting ~2B records on daily basis. We will
> retain data of upto 3 months.
> 
> I followed your suggestion of not querying more than 100 rows and this is
> my observation. I ran queries with the debugQuery param and found that the
> query response time depends on the worst performing shard as some of the
> shards take longer to execute the query than other shards.
> 
> Here are my questions:
> 
>   1.  Is decreasing number of shards going to help us as there will be
>   lesser number of shards to be queried?
>   2.  Is increasing number of replicas going to help us as there will be
>   load balancing?
>   3.  How many records should we keep in each Collection or in each
>   replica/core? Will we face performance issues if the core size becomes too
>   big?
> 
> Any other suggestions are appreciated.
> 
> On Wed, May 27, 2020 at 9:23 PM Erick Erickson 
> wrote:
> 
>> First of all, asking for that many rows wi

Solr Admin UI with restricted authorization

[Yang, Ya Lan]

Dear Solr support team,

Hope you are doing well in this difficult time! I have 2 quick questions:

  1.  Are we able to restrict Admin UI's functions? For example, blocking the 
update (insert/delete/edit) functions on the Admin UI. My colleagues would like 
to open this Admin UI to users, but I think this is too risky because accessing 
Admin UI can edit the data and even bring down the Solr instance. Please 
correct me if I am wrong.
  2.  I implemented the Authentication and Authorization 
Plugins
 to our solr instance using your super helpful guide. I wonder is there any UI 
we can manage/configure the users' accounts and permissions instead of using 
the 
commands?

Thank you!

Ya-Lan Yang
Software Engineer
Cline Center for Advanced Social Research
University of Illinois Urbana-Champaign
217.244.6641
yly...@illinois.edu

Cline Center for Advanced Social Research
2001 S. First St. Suite 207, MC-689
Champaign, IL  61820-7478
www.clinecenter.illinois.edu

[cid:ed581ada-5689-4864-9d85-ae6b10e2ee0b]

Re: Solr Deletes

[Cassandra Targett]

I’m coming in a little late, but as of 8.5 there is a new streaming expression 
designed for DBQ situations which basically does what Erick was suggesting - 
gets a list of IDs for a query then does a delete by ID: 
https://lucene.apache.org/solr/guide/8_5/stream-decorator-reference.html#delete.

It won’t help if you’re not on 8.5, but going forward will be a good option for 
large delete sets.
On May 26, 2020, 8:09 PM -0500, Dwane Hall , wrote:
> Thank you very much Erick, Emir, and Bram this is extremly useful advice I 
> sincerely appreciate everyone’s input!
>
>
> Before I received your responses I ran a controlled DBQ test in our DR 
> environment and exactly what you said occurred. It was like reading a step by 
> step playbook of events with heavy blocking occurring on the Solr nodes and 
> lots of threads going into a TIMED_WAITING state. Several shards were pushed 
> into recovery mode and things were starting to get ugly, fast!
>
>
> I'd read snippets in blog posts and JIRA tickets on DBQ being a blocking 
> operation but I did not expect having such a specific DBQ (i.e. by ID's) 
> would operate very differently from the DBID (which I expected block as 
> well). Boy was I wrong! They're used interchangeably in the Solr ref guide 
> examples so it’s very useful to understand the performance implications of 
> each. Additionally all of the information I found on delete operations never 
> mentioned query performance so I was unsure of its impact in this dimension.
>
>
> Erik thanks again for your comprehensive response your blogs and user group 
> responses are always a pleasure to read I'm constantly picking useful pieces 
> of information that I use on a daily basis in managing our Solr/Fusion 
> clusters. Additionally, I've been looking for an excuse to use streaming 
> expressions and I did not think to use them the way you suggested. I've 
> watched quite a few of Joel's presentations on youtube and his blog is 
> brilliant. Streaming expressions are expanding with every Solr release they 
> really are a very exciting part of Solr's evolution. Your final point on 
> searcher state while streaming expressions are running and its relationship 
> with new searchers is a very interesting additional piece of information I’ll 
> add to the toolbox. Thank you.
>
>
>
> At the moment we're fortunate to have all the ID's of the documents to remove 
> in a DB so I'll be able to construct batches of DBID requests relatively 
> easily and store them in a backlog table for processing without needing to 
> traverse Solr with cursors, streaming (or other means) to identify them. We 
> follow a similar approach for updates in batches of around ~1000 docs/batch. 
> Inspiration for that sweet spot was once again determined after reading one 
> of Erik's Lucidworks blog posts and testing 
> (https://lucidworks.com/post/really-batch-updates-solr-2/).
>
>
>
> Again thanks to the community and users for everyone’s contribution on the 
> issue it is very much appreciated.
>
>
> Successful Solr-ing to all,
>
>
> Dwane
>
> 
> From: Bram Van Dam 
> Sent: Wednesday, 27 May 2020 5:34 AM
> To: solr-user@lucene.apache.org 
> Subject: Re: Solr Deletes
>
> On 26/05/2020 14:07, Erick Erickson wrote:
> > So best practice is to go ahead and use delete-by-id.
>
>
> I've noticed that this can cause issues when using implicit routing, at
> least on 7.x. Though I can't quite remember whether the issue was a
> performance issue, or whether documents would sometimes not get deleted.
>
> In either case, I worked it around it by doing something like this:
>
> UpdateRequest req = new UpdateRequest();
> req.deleteById(id);
> req.setCommitWithin(-1);
> req.setParam(ShardParams._ROUTE_, shard);
>
> Maybe that'll help if you run into either of those issues.
>
> - Bram

Re: Why Did It Match?

[David Smiley]

I've used the highlighter in the past for this but it has to do a lot more
work than "explain".  Typically that extra work is analysis of the fields'
text again.  Still; the highlighter can make sense when the individual
fields aren't otherwise searchable because you are searching on an
aggregate catch-all field.

~ David


On Thu, May 28, 2020 at 6:40 PM Walter Underwood 
wrote:

> Are you sure they will wonder? I’d try it without that and see if the
> simpler UI is easier to use. Simple almost always wins the A/B test.
>
> You can use the highlighter to see if a field matched a term. Only use
> explain if you need all the scores.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> > On May 28, 2020, at 3:37 PM, Webster Homer <
> webster.ho...@milliporesigma.com> wrote:
> >
> > Thank you.
> >
> > The problem is that Endeca just provided this information. The website
> users see how each search result matched the query.
> > For example this is displayed for a hit:
> > 1 Product Result
> >
> > |  Match Criteria: Material, Product Number
> >
> > The business users will wonder why we cannot provide this information
> with the new system.
> >
> > -Original Message-
> > From: Erick Erickson 
> > Sent: Thursday, May 28, 2020 4:38 PM
> > To: solr-user@lucene.apache.org
> > Subject: Re: Why Did It Match?
> >
> > Yes, debug=explain is expensive. Expensive in the sense that I’d never
> add it to every query. But if your business users are trying to understand
> why query X came back the way it did by examining individual queries, then
> I wouldn’t worry.
> >
> > You can easily see how expensive it is in your situation by looking at
> the timings returned. Debug is just a component just like facet etc and the
> time it takes is listed separately in the timings section of debug output…
> >
> > Best,
> > Erick
> >
> >> On May 28, 2020, at 4:52 PM, Webster Homer <
> webster.ho...@milliporesigma.com> wrote:
> >>
> >> My concern was that I thought that explain is resource heavy, and was
> only used for debugging queries.
> >>
> >> -Original Message-
> >> From: Doug Turnbull 
> >> Sent: Thursday, May 21, 2020 4:06 PM
> >> To: solr-user@lucene.apache.org
> >> Subject: Re: Why Did It Match?
> >>
> >> Is your concern that the Solr explain functionality is slower than
> Endecas?
> >> Or harder to understand/interpret?
> >>
> >> If the latter, I might recommend http://splainer.io as one solution
> >>
> >> On Thu, May 21, 2020 at 4:52 PM Webster Homer <
> webster.ho...@milliporesigma.com> wrote:
> >>
> >>> My company is working on a new website. The old/current site is
> >>> powered by Endeca. The site under development is powered by Solr
> >>> (currently 7.7.2)
> >>>
> >>> Out of the box, Endeca provides the capability to show how a query
> >>> was matched in the search. The business users like this
> >>> functionality, in solr this functionality is an expensive debug
> >>> option. Is there another way to get this information from a query?
> >>>
> >>> Webster Homer
> >>>
> >>>
> >>>
> >>> This message and any attachment are confidential and may be
> >>> privileged or otherwise protected from disclosure. If you are not the
> >>> intended recipient, you must not copy this message or attachment or
> >>> disclose the contents to any other person. If you have received this
> >>> transmission in error, please notify the sender immediately and
> >>> delete the message and any attachment from your system. Merck KGaA,
> >>> Darmstadt, Germany and any of its subsidiaries do not accept
> >>> liability for any omissions or errors in this message which may arise
> >>> as a result of E-Mail-transmission or for damages resulting from any
> >>> unauthorized changes of the content of this message and any
> >>> attachment thereto. Merck KGaA, Darmstadt, Germany and any of its
> >>> subsidiaries do not guarantee that this message is free of viruses
> >>> and does not accept liability for any damages caused by any virus
> transmitted therewith.
> >>>
> >>>
> >>>
> >>> Click http://www.merckgroup.com/disclaimer to access the German,
> >>> French, Spanish and Portuguese versions of this disclaimer.
> >>>
> >>
> >>
> >> --
> >> *Doug Turnbull **| CTO* | OpenSource Connections
> >> , LLC | 240.476.9983
> >> Author: Relevant Search ; Contributor:
> *AI Powered Search * This e-mail and all
> contents, including attachments, is considered to be Company Confidential
> unless explicitly stated otherwise, regardless of whether attachments are
> marked as such.
> >>
> >>
> >> This message and any attachment are confidential and may be privileged
> or otherwise protected from disclosure. If you are not the intended
> recipient, you must not copy this message or attachment or disclose the
> contents to any other person. If you have received this transmission in
> error, please notify the sender immediatel

Re: SolrCloud upgrade concern

[gnandre]

Thanks for all this information. It clears lot of confusion surrounding
CDCR feature. Although, I should say that if CDCR functionality is so
fragile in SolrCloud and not worth pursuing much, does it make sense to add
some warning about its possible shortcomings in the documentation?

On Thu, May 28, 2020 at 9:02 AM Jan Høydahl  wrote:

> I had a client who asked a lot about CDCR a few years ago, but I kept
> recommending
> aginst it and recommended them to go for Ericks’s alternative (2), since
> they anyway
> needed to replicate their Oracle DBs in each DC as well. Much cleaner
> design to let
> each cluster have a local datasource and always stay in sync with local DB
> than to
> replicate both DB and index.
>
> There are of course use cases where you want to sync a read-only copy of
> indices
> to multiple DCs. I hope we’ll see a 3rd party tool for that some day,
> something that
> can sit outside your Solr clusters, monitor ZK of each cluster, and do
> some magic :)
>
> Jan
>
> > 28. mai 2020 kl. 01:17 skrev Erick Erickson :
> >
> > The biggest issue with CDCR is it’s rather fragile and requires
> monitoring,
> > it’s not a “fire and forget” type of functionality. For instance, the
> use of the
> > tlogs as a queueing mechanism means that if, for any reason, the
> communications
> > between DCs is broken, the tlogs will grow forever until the connection
> is
> > re-established. Plus the other issues Jason pointed out.
> >
> > So yes, some companies do use CDCR to communicate between separate
> > DCs. But they also put in some “roll your own” type of monitoring to
> insure
> > things don’t go haywire.
> >
> > Alternatives:
> > 1> use something that’s built from the ground up to provide reliable
> > messaging between DCs. Kafka or similar has been mentioned. Write
> > your updates to the Kafka queue and consume them in both DCs.
> > These kinds of solutions have a lot more robustness.
> >
> > 2> reproduce your system-of-record rather than Solr in the DCs and
> >   treat the DCs as separate installations. If you adopt this approach,
> >  some of the streaming capabilities can be used to monitor that they stay
> >  in sync. For instance have a background or periodic task that’ll take a
> while
> >  for a complete run wrap two "search" streams in a "unique” decorator,
> >  anything except an empty result identifies docs not on both DCs.
> >
> > 3> Oh Dear. This one is “interesting”. Wrap a “topic" stream on DC1 in
> >an update decorator for DC2 and wrap both of those in a daemon
> decorator.
> >   That’s gobbledygook, and you’ll have to dig through the docs a bit for
> >   that to make sense. Essentially the topic stream is one of the very
> few
> >   streams that does not (IIRC) require all values in the fl list be
> docValues.
> >   It fires the first time and establishes a checkpoint, finding all docs
> up to that point.
> >   Thereafter, it’ll get docs that have changed since the last time it
> ran. It uses a tiny
> >   collection for record keeping. Each time the topic stream finds new
> docs, it passes
> >  them to the update stream which sends them to another DC. Wrapping the
> whole
> >  thing in a daemon decorator means it periodically runs in the
> background. The one
> >  shortcoming is that this approach doesn’t propagate deletes. That’s
> enough of that
> >  until you tell us whether it sounds worth pursuing ;)
> >
> > So overall, you _can_ use CDCR to connect remote DCs, but it takes time
> and energy
> > to make it robust. Its advantage is that it’s entirely contained within
> Solr. But it’s not
> > getting much attention lately, meaning nobody has decided the
> functionality is important
> > enough to them to donate the time/resources to make it more robust. Were
> someone
> > to take an active interest in it, likely it could be kept around as a
> plugin that core Solr
> > is not responsible for.
> >
> > Best,
> > Erick
> >
> >> On May 27, 2020, at 4:43 PM, gnandre  wrote:
> >>
> >> Thanks, Jason. This is very helpful.
> >>
> >> I should clarify though that I am not using CDCR currently with my
> >> existing master-slave architecture. What I meant to say earlier was
> that we
> >> will be relying heavily on the CDCR feature if we migrate from solr
> >> master-slave architecture to solrcloud architecture. Are there any
> >> alternatives to CDCR? AFAIK, if you want to replicate between different
> >> data centers then CDCR is the only option. Also, when you say lot of
> >> customers are using SolrCloud successfully, how are they working around
> the
> >> CDCR situation? Do they not have any data center use cases? Is there
> some
> >> list maintained somewhere where one can find which companies are using
> >> SolrCloud successfully?
> >>
> >>
> >>
> >> On Wed, May 27, 2020 at 9:27 AM Jason Gerlowski 
> >> wrote:
> >>
> >>> Hi Arnold,
> >>>
> >>> From what I saw in the community, CDCR saw an initial burst of
> >>> development around when it was contributed, but hasn't seen much

Does Learning To Rank feature require SolrCloud?

[gnandre]

Hi,

Do following features require SolrCloud? Or do they work in master-slave
mode just fine?

1. Learning to rank (LTR)
2. Distributed IDF

Lucene query to Solr query

[gnandre]

Hi,

I have following query which works fine as a lucene query:
+(topics:132)^0.02607211 (topics:146)^0.008187325
-asset_id:doc:en:index.html

But, it does not work if I use it as a solr query with lucene as defType.

For it to work, I need to convert it like following:
q=+((topics:132)^0.02607211 (topics:146)^0.008187325
+(-(asset_id:doc\:en\:index.html))&defType=edismax&q.op=OR

Why does it not work as is? AFAIK syntax given in the first query is
supported by edismax.

Re: Solr Admin UI with restricted authorization

[Jörn Franke]

You can restrict the admin UI by limiting access using the authorization 
plugin. I would though not give access to end users for the admin UI.  A good 
practice is to create your own web application running on a dedicated server 
that manages all the authentication / authorization and provides a UI for the 
end users. Then you can manage access in a dedicated enterprise directory and 
also implement single sign-on etc.


You cannot manage users in the admin UI and you will see it gets very 
cumbersome with many different users.

Also from a usability point of view the admin UI does not make sense for end 
users.



> Am 29.05.2020 um 22:08 schrieb Yang, Ya Lan :
> 
> 
> Dear Solr support team,
> 
> Hope you are doing well in this difficult time! I have 2 quick questions:
> Are we able to restrict Admin UI's functions? For example, blocking the 
> update (insert/delete/edit) functions on the Admin UI. My colleagues would 
> like to open this Admin UI to users, but I think this is too risky because 
> accessing Admin UI can edit the data and even bring down the Solr instance. 
> Please correct me if I am wrong.
> I implemented the Authentication and Authorization Plugins to our solr 
> instance using your super helpful guide. I wonder is there any UI we can 
> manage/configure the users' accounts and permissions instead of using the 
> commands? 
> Thank you!
> 
> Ya-Lan Yang
> Software Engineer
> Cline Center for Advanced Social Research
> University of Illinois Urbana-Champaign
> 217.244.6641
> yly...@illinois.edu
> 
> Cline Center for Advanced Social Research
> 2001 S. First St. Suite 207, MC-689
> Champaign, IL  61820-7478
> www.clinecenter.illinois.edu
> 
>