[
https://issues.apache.org/jira/browse/SOLR-9818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15884841#comment-15884841
]
Amrit Sarkar edited comment on SOLR-9818 at 2/26/17 6:02 PM:
-------------------------------------------------------------
Erick,
Spot on!
1. Yes, we will introduce an progress bar, or any other suitable icon/gif which
will display request-id and its current status.
2. {noformat}if (the initial call failed or there was no status to be found)
{ report an error and suggest the user look check their system before
resubmitting the request. Bail out in this case, no retries, no attempt to
drive on. }{noformat}
Positively, if it fails, we will receive an error report which can be displayed
on progress bar or red colored box we have right now. For not-found, it was
simply never registered, never received by ZK and we can get out. Though we
need to decide how much to wait until we receive a status; patch uploaded on
SOLR-10201, I set the timer to 15 sec, should be lower I guess.
{noformat}else
{ put up a progress indicator while periodically checking the status, Continue
spinning until we can report the final status. }{noformat}
We have to decide an upper limit for the request processing time before we tell
the user, _the request is taking long time to process, go check your logs_.
3. Yes, the request status stays around forever and X number of entries are
allowed in zookeeper. We can have a range for generated ids something like
_0-9999_ etc for it; don't want to burden zk with extra memory. There is a
chance for collision, especially when more than one user are using these APIs,
but what are the odds there? Also we really want to re-submit any calls when
the status is not good news (running/completed)? I am inclined towards
reporting to user if there is a hint of bad news, let him/her decide what to do
next.
was (Author: [email protected]):
Erick,
Spot on!
1. Yes, we will introduce an progress bar, or any other suitable icon/gif which
will display request-id and its current status.
2. {noformat}if (the initial call failed or there was no status to be found)
{ report an error and suggest the user look check their system before
resubmitting the request. Bail out in this case, no retries, no attempt to
drive on. }{noformat}
Positively, if it fails, we will receive an error report which can be displayed
on progress bar or red colored box we have right now. For not-found, it was
simply never registered, never received by ZK and we can get out. Though we
need to decide how much to wait until we receive a status; patch uploaded on
SOLR-10201, I set the timer to 15 sec, should be lower I guess.
{noformat}else
{ put up a progress indicator while periodically checking the status, Continue
spinning until we can report the final status. }{noformat}
We have to decide an upper limit for the request processing time before we tell
the user, _the request is taking long time to process, go check your logs_.
3. Yes, the request status stays around forever and X number of entries are
allowed only in zookeeper. We can have a range for generated ids something like
_0-9999_ etc for it; don't want to burden zk with extra memory. There is a
chance for collision, especially when more than one user are using these APIs,
but what are the odds there? Also we really want to re-submit any calls when
the status is not good news (running/completed)? I am inclined towards
reporting to user if there is a hint of bad news, let him/her decide what to do
next.
> 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
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
> Affects Versions: 6.3
> Reporter: Ere Maijala
>
> 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
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
