[ 
https://issues.apache.org/jira/browse/SOLR-10211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752438#comment-16752438
 ] 

Gus Heck edited comment on SOLR-10211 at 1/25/19 5:00 PM:
----------------------------------------------------------

I just hit this again this time with the autoscaling suggestions UI (wound up 
with multiple copies of a core on a movereplica suggestion). It seems that all 
non idempotent UI commands are very dangerous to use because of this tendency 
to repeat timed out requests.


was (Author: gus_heck):
I just hit this again this time with the autoscaling suggestions UI. It seems 
that all non idempotent UI commands are very dangerous to use because of this 
tendency to repeat timed out requests.

> Solr UI crashes Solr server somtimes by repeating long requests
> ---------------------------------------------------------------
>
>                 Key: SOLR-10211
>                 URL: https://issues.apache.org/jira/browse/SOLR-10211
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: Admin UI
>    Affects Versions: 6.3
>         Environment: Linux Debian7, Firefox 51.0.1
>            Reporter: Tomasz Czarnecki
>            Priority: Critical
>              Labels: blocker
>             Fix For: 7.0
>
>         Attachments: Connection to Solr lost message.png, repeated optimize 
> requests.png
>
>
> I can observe the following behavior in the new UI:
> - If request takes to long
> - Pop up red "Connection to Solr lost" message.
> - Try to repeat last request every few seconds to recover.
> As this tactic may seem OK for real connection problems it may do a lot of 
> harm if request takes long because it's heavy.
> I have had two such scenarios.
> 1. Loading Schema (e.g. /#/collection1/schema). For big index this can 
> require a a lot of memory initially. And it can take 20-30 seconds. But if 
> such operation is repeated several times in a series is short time frame, 
> resource requirements add up and this results in OOM exception on server side.
> The workaround is to:
> - Try to load schema
> - If red red "Connection to Solr lost" message pops up close Solr UI browser 
> tab.
> - Wait a about minute for server to warm up.
> - Open a new Solr UI tab and load schema again, this time it works fast 
> enough, probably to next index update.
> 2. "optimize now" functionality we occasionally use. It can take a while for 
> some collections (~100GB, 10M docs). If such request is repeated over longer 
> period of time a whole Jetty thread pool can be exhausted leaving Solr 
> unresponsive to any requests.
> It's as easy as starting optimize and leaving your screen for 15 minutes with 
> "Connection to Solr lost" message present.
> Observed on our few Solr instances after migration from 5.3 to 6.3.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to