[
https://issues.apache.org/jira/browse/SOLR-11739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16298901#comment-16298901
]
Tomás Fernández Löbbe commented on SOLR-11739:
----------------------------------------------
bq. feel like my suggestion was orthognal to to the concern you suggested in
response.
No, I meant "Solr won't re-execute the same request twice" *even if it receives
it twice*. What I say is that, by Solr rejecting the duplicate async ID it
makes the admin request idempotent, you could do something like:
{code}
while (!success) {
try {
performRequest(asyncId=1&cmd=CREATESOMETHING)
success = true
} catch (e) {
//backoff
}
}
{code}
If there is some error back from {{performRequest}}, you don’t know if the
request was scheduled or not, but you don’t care if you know Solr won’t
re-schedule it, you can just send it again. Another use case could be workers
watching a queue and executing actions, if the queue delivers a message more
than once, you don’t have to worry about sending the command to Solr multiple
times, and can assume a “request already exists” response from Solr to be a
success.
> Solr can accept duplicated async IDs
> ------------------------------------
>
> Key: SOLR-11739
> URL: https://issues.apache.org/jira/browse/SOLR-11739
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Tomás Fernández Löbbe
> Assignee: Tomás Fernández Löbbe
> Priority: Minor
> Attachments: SOLR-11739.patch, SOLR-11739.patch
>
>
> Solr is supposed to reject duplicated async IDs, however, if the repeated IDs
> are sent fast enough, a race condition in Solr will let the repeated IDs
> through. The duplicated task is ran and and then silently fails to report as
> completed because the same async ID is already in the completed map.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
