[
https://issues.apache.org/jira/browse/SOLR-11739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16286346#comment-16286346
]
Hoss Man commented on SOLR-11739:
---------------------------------
My off the cuff, uneducated, impression w/o knowing much about the internals or
the history of how the existing code go to the state it's currently in is
that...
Either:
# Solr should assign the asyncIds and guarantee that they are unique
# The user should assign the asyncIds, and Solr should make no assumptions
about them, nor use them for *anything* other then reporting status.
#1 seems a lot harder since it's essentially a distributed unique key
generation problem, which IIUC is why asyncId wasn't implemented that way in
the first place.
For #2, from my perspective, It sounds like tomas is saying that there is
existing code in solr that tries to reject duplicate asyncIds -- and I would
argue (as a straw man) that Solr making any attempt at doing that is where the
real bug lies ... Solr should happily let you specify the same asyncId multiple
times, and that should have no affect at all on the reliability of the commands
being executed in the order recieved. the only thing it should affect is that
requesting status info on the commands may give unexpected results (depending
on what the client is expecting) ... i would expect that requesting status for
the id would return the status of the "1st" instance, until the "2nd" instance
finishes at which point the status info is overridden.
that way if a user wants to re-use the exact same asyncId for every request,
they are welcome to put that bullet in their foot as many times as they want --
it keeps things simpler for us internally, and we're not trying to coddle them
for doing something (very advanced) in a silly way.
----
If we're going to coddle them, then we should coddle them all the way -- isn't
the amount of work / zk writes needed to generate a universally unique asyncId
on the server side essentially the same as the amount needed to tell the client
that the asyncId they specified isn't unique?
> 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 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]