[
https://issues.apache.org/jira/browse/SOLR-11739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16297890#comment-16297890
]
Hoss Man commented on SOLR-11739:
---------------------------------
i have no strong opinions ... at a high level i think the approach you describe
(i didn't review the patch) is fine from a stability/reliability and back
compat standpoint, but I have no idea how it affects performance (although it
should go w/o saying that i favor stability/reliability over performance when
discussing "admin" actions)
To clarify one comment where i suspect we may have been misscommunicating...
{quote}
bq. Solr should happily let you specify the same asyncId multiple times
hmm I'm not sure. I think the fact that Solr won't re-execute the same request
twice makes it much easier to write workflows that do collection operations.
{quote}
I feel like my suggestion was orthoginal to to the concern you suggested in
response. What i was suggesting is that, in theory: Solr could be agnostic to
the asyncId and *only* use them for tracking results. Example: if these 4
commands come in...
* asyncId=222&cmd=CREATESOMETHING
* asyncId=1&cmd=DOSOMETHINGELSE
* asyncId=222&cmd=DOWHATEVER
...then Solr could in fact execute those 3 commands, in that sequence,
reliably, and w/o any risk of any of them being executed more or less then
exactly 1 time. The fact that 2 of them have the same asyncId should in no way
impact Solr's execution of those commands. The only impact that the duplicated
asyncId should have is that once the DOWHATEVER cmd is executed, it will no
longer be possible for a client to ever check the status of the
CREATESOMETHING, because the results of the DOWHATEVER command should overwrite
the results of the CREATESOMETHING ... that could be solr's *sole* internal use
of the asyncId
(ie: only track all commands to process in an ordered queue, use the asyncId
only in a map we don't care about internally, other then if a user asks for
status info)
that was the crux of my suggestion ... assuming we want a policy of solr being
"agnostic" to duplicate asyncIds in order to reduce the zk overhead of
tracking/rejecting dups. (BUt i don't feel strongly about it)
> 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]
