[jira] [Commented] (SOLR-9818) Solr admin UI rapidly retries any request(s) if it loses connection with the server

2020-05-20 Thread Jira


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

Jan Høydahl commented on SOLR-9818:
---

Can we please fully get rid of the retry buffer? Instead just display the 
errors and not retry the original request? Will this patch [^SOLR-9818.patch] 
work?

> 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
> Attachments: SOLR-9818.patch
>
>
> 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



[jira] [Commented] (SOLR-9818) Solr admin UI rapidly retries any request(s) if it loses connection with the server

2020-04-04 Thread Gus Heck (Jira)


[ 
https://issues.apache.org/jira/browse/SOLR-9818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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