[ 
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to