lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gus Heck (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-11739) Solr can accept duplicated async IDs
Date Thu, 01 Feb 2018 04:49:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-11739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16348004#comment-16348004
] 

Gus Heck commented on SOLR-11739:
---------------------------------

[~hossman], To me it seems that with your 3 command example things are a little worse than
you say... There would be a window where id 222 could be seen as the success of CREATESOMETHING,
and someone checking on DOWHATEVER might think DOWHATEVER had been done successfully (yay,
go home, throw a party... ) but then DOWHATEVER fails (Monday's gonna be less fun...), and
then some automated process checks on 222 to verify that it did actually CREATESOMETHING,
but sees a failure... (drat, do it again... and again and again.. continually failing because
SOMETHING now exists)..... 

Sure, it's their fault for not coordinating their ID's but... why help them make that mistake?

I think any ID that is not unique is more or less useless. I haven't used async requests and
haven't previously paid much attention to it, don't know the history, and I might be missing
something, but I find it shocking that Solr is not generating the id and ensuring it's uniqueness.
How about when the Overseer is elected, it establishes a source of entropy (Random initialized
from time) and uses that to issue UUID's. There's only one overseer at a time, and the cases
where 2 or more overseers are started at exactly the same time and coexist is a bug, right?
If there's no overseer, commands can't be run anyway...

> 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) 
>          Components: SolrCloud
>            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
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message