lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomás Fernández Löbbe (JIRA) <j...@apache.org>
Subject [jira] [Commented] (SOLR-11739) Solr can accept duplicated async IDs
Date Sun, 04 Feb 2018 02:13:00 GMT

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

Tomás Fernández Löbbe commented on SOLR-11739:
----------------------------------------------

Thanks for the thorough review Anshum.
{quote}We should add back the check in old places instead of leaving that as a TODO
{quote}
Yes, that was my plan. I'll upload a patch now with the back compat support.
{quote}L296: It would be good to log the reason for the failure to offer the request to the
OverseerCollectionQueue
{quote}
Note that the exception will be thrown in this case
{quote}Are the log4j.properties changes intentional ?
{quote}
For my testing, I'll revert before committing
{quote}SizeLimitedDistributedMap.OnChildDeleteObserver interface doesn’t need the keyword
static also can you add some javadoc there?
{quote}
Good catch. Changed.
{quote}As I understand, you would also want to override clear() and call onDeleteObserver.onChildDelete
in those cases too.
{quote}
Really, I was thinking on the observer to be called only in the case of overflow, not for
a regular delete (it's also not called on remove). I modified the name to {{OnOverflowObserver}}
of the observer to be clearer about this.
{quote}Javadocs for claim/clearAsyncId. It’d be good to mention that it returns false when
it tries to clear an ID that doesn’t exist any more.
{quote}
Added

Also added some more tests to the new code and to {{DistributedMap}} since I couldn't find
any.
{quote}...How about when the Overseer is elected, it establishes a source of entropy (Random
initialized from time) and uses that to issue UUID's...
{quote}
That is another option. Although note that there is a client option to call with an auto-generated
asyncId, which should prevent collisions. We could also switch to a model in which we don't
accept client-provided async IDs, but I guess that should be another Jira, there would be
much more changes for that, including an API change

> 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-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