[
https://issues.apache.org/jira/browse/SOLR-5374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13804391#comment-13804391
]
Hoss Man commented on SOLR-5374:
--------------------------------
bq. It seems like concurrency is not yet handled? Under concurrent updates, the
patch won't guarantee the correct ordering.
You're right ... i hadn't considered that.
bq. Also, it looks like the current code assumes it's running on the leader?
The realtime-get done is local only, ...
It is?!?! ... I didn't realize that. (but i also hadn't had a chance to add a
test for it)
That must just be because of the convenience method i used correct? Obviously
the RTG Component has a way to fetch the document even if you don't hit the
correct shard (I hope! for bigger reasons then this patch).
The only way i can think of to address your concurrency concern is by forcing
this logic to run on hte leader (not sure if you have an alternative idea: I'm
not following your "or optimistic concurrency." suggestion) in which case if we
solve that problem, we should automatically solve the "current code assumes
it's running on the leader?" correct?
Unless i'm missing something, we still don't have an easy generic way to say
"run this code _only_ on the leader" -- not w/o modifying
DistributedUpdateProcessor i don't think -- but IIUC the distributed update
code first ensures that the update succeeds on the leader before forwarding to
the replicas, correct?
Perhaps we couldtweak the logic of DocBasedVersionConstraintsProcessor so it's
configured to run _after_ DistributedUpdateProcessor. On the leader it would
use uniqueKey based locking around the existing logic, and throw an error if
the constrain wasn't satisfied - preventing the leader from ever forwarding to
the replicas. On the replicas it would just be a no-op.
The "ignoreOldUpdates" would have to be rippped out, but it could easily be
refactored into a little convenience processor that could run _before_
DistributedUpdateProcessor so that if enabled it would catch all 409 errors and
swallow them. (which could be geenrally re-usable with the existing optimisitc
concurrency feature as well if people want to ignore those conflicts as well)
The only thing i'm not sure about how to deal with if we go this direction is
supporting the DeleteUpdateCommand -> AddUpdateCommand logic. Because if that
happens on the leader _after_ DistributedUpdateProcessor I don't think it will
affect the commands that get forwarded to the replicas. (will it?)
> Support user configured doc-centric versioning rules
> ----------------------------------------------------
>
> Key: SOLR-5374
> URL: https://issues.apache.org/jira/browse/SOLR-5374
> Project: Solr
> Issue Type: Improvement
> Reporter: Hoss Man
> Assignee: Hoss Man
> Attachments: SOLR-5374.patch
>
>
> The existing optimistic concurrency features of Solr can be very handy for
> ensuring that you are only updating/replacing the version of the doc you
> think you are updating/replacing, w/o the risk of someone else
> adding/removing the doc in the mean time -- but I've recently encountered
> some situations where I really wanted to be able to let the client specify an
> arbitrary version, on a per document basis, (ie: generated by an external
> system, or perhaps a timestamp of when a file was last modified) and ensure
> that the corresponding document update was processed only if the "new"
> version is greater then the "old" version -- w/o needing to check exactly
> which version is currently in Solr. (ie: If a client wants to index version
> 101 of a doc, that update should fail if version 102 is already in the index,
> but succeed if the currently indexed version is 99 -- w/o the client needing
> to ask Solr what the current version)
> The idea Yonik brought up in SOLR-5298 (letting the client specify a
> {{\_new\_version\_}} that would be used by the existing optimistic
> concurrency code to control the assignment of the {{\_version\_}} field for
> documents) looked like a good direction to go -- but after digging into the
> way {{\_version\_}} is used internally I realized it requires a uniqueness
> constraint across all update commands, that would make it impossible to allow
> multiple independent documents to have the same {{\_version\_}}.
> So instead I've tackled the problem in a different way, using an
> UpdateProcessor that is configured with user defined field to track a
> "DocBasedVersion" and uses the RTG logic to figure out if the update is
> allowed.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
