[ https://issues.apache.org/jira/browse/SOLR-9818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17075306#comment-17075306 ]
Gus Heck commented on SOLR-9818: -------------------------------- I've been running into this many times. I don't think it should be closed. Just today I got so irritated that I tracked down where it happens, and discovered that this is configurable on a per page basis (I think...) I don't have time to actually tweak it yet, but an example of this being turned off in the data import handler admin ui (I think) exists at [https://github.com/apache/lucene-solr/blob/master/solr/webapp/web/js/angular/services.js#L179] {code:javascript} "config": {params: {command: "show-config"}, headers: {doNotIntercept: "true"}, {code} The doNotIntercept seems to short ciruit before the retry here: [https://github.com/apache/lucene-solr/blob/master/solr/webapp/web/js/angular/app.js#L411] {code:javascript} if (rejection.config.headers.doNotIntercept) { return rejection; } if (rejection.status === 0) { $rootScope.$broadcast('connectionStatusActive'); if (!$rootScope.retryCount) $rootScope.retryCount=0; $rootScope.retryCount ++; var $http = $injector.get('$http'); var result = $http(rejection.config); return result; } else if (rejection.status === 401) { // Authentication redirect var headers = rejection.headers(); var wwwAuthHeader = headers['www-auth{code} > Solr admin UI rapidly retries any request(s) if it loses connection with the > server > ----------------------------------------------------------------------------------- > > Key: SOLR-9818 > URL: https://issues.apache.org/jira/browse/SOLR-9818 > Project: Solr > Issue Type: Bug > Components: Admin UI > Affects Versions: 6.3 > Reporter: Ere Maijala > Assignee: Shalin Shekhar Mangar > Priority: Major > > It seems that whenever the Solr admin UI loses connection with the server, be > the reason that the server is too slow to answer or that it's gone away > completely, it starts hammering the server with the previous request until it > gets a success response, it seems. That can be especially bad if the last > attempted action was something like collection reload with a SolrCloud > instance. The admin UI will quickly add hundreds of reload commands to > overseer/collection-queue-work, which may essentially cause the replicas to > get overloaded when they're trying to handle all the reload commands. > I believe the UI should never retry the previous command blindly when the > connection is lost, but instead just ping the server until it responds again. > Steps to reproduce: > 1.) Fire up Solr > 2.) Open the admin UI in browser > 3.) Open a web console in the browser to see the requests it sends > 4.) Stop solr > 5.) Try an action in the admin UI > 6.) Observe the web console in browser quickly fill up with repeats of the > originally attempted request -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org