[
https://issues.apache.org/jira/browse/SOLR-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15385215#comment-15385215
]
Shalin Shekhar Mangar commented on SOLR-5944:
---------------------------------------------
bq. Btw, I've surrounded only the lookupVersion() calls with the acquiring and
releasing of the lock, instead of surrounding the entire wait loop with the
acquiring/releasing of the lock: I reasoned that while we are waiting in that
wait loop, other threads need to have indexed the update that we're waiting on,
and hence I released the lock as soon as it was not needed, only to re-acquire
it after 100ms. Does that sound like a valid reason?
The read lock is for safe publication of fields in update log and it is
acquired by indexing threads who only want to read stuff from update log. Also
read locks can be held by multiple readers. Therefore, acquiring this lock does
not prevent other threads from indexing.
Also, please be very careful when changing the order of acquiring locks because
it can result in deadlocks. It is good practice to do them in the same sequence
as everywhere else in the code. So synchronizing on bucket before
vinfo.lockForUpdate for a small optimization doesn't seem worthwhile to me.
bq. Since this method enters the wait loop for every in-place update that has
arrived out of order at a replica (an event, that I think is frequent under
multithreaded load), I don't want every such update to be waiting for the full
timeout period (5s here), but instead check back from time to time. In most of
the cases, the dependent update would've been written (by another thread)
within the first 100ms, after which we can bail out. Do you think that makes
sense?
You misunderstand. A wait(5000) does not mean that you are waiting the full 5
seconds. Any notifyAll() will wake up the waiting thread and when it does, it
will check the lastFoundVersion and proceed accordingly. In practice wait(100)
may not be so bad but if an update doesn't arrive for more than 100ms the
thread will wake up and lookup the version needlessly with your current patch.
A few more comments:
# In your latest patch, acquiring the read lock to call versionAdd is not
necessary -- it will do that anyway. You can re-acquire it for reading the
version after the method call returns.
# I don't think the case of {{vinfo.lookupVersion}} returning a negative value
(for deletes) is handled here at all.
# What happens if the document has been deleted already (due to reordering on
the replica) when you enter waitForDependentUpdates? i.e. what if re-ordering
leads to new_doc (v1) -> del_doc (v3) -> dv_update (v2) on the replica?
# Similarly, how do we handle the case when the doc has been deleted on the
leader when you execute fetchMissingUpdateFromLeader. Does RTG return the
requested version even if the doc has been deleted already? I suspect it does
but be nice to confirm.
> Support updates of numeric DocValues
> ------------------------------------
>
> Key: SOLR-5944
> URL: https://issues.apache.org/jira/browse/SOLR-5944
> Project: Solr
> Issue Type: New Feature
> Reporter: Ishan Chattopadhyaya
> Assignee: Shalin Shekhar Mangar
> Attachments: DUP.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch, SOLR-5944.patch,
> SOLR-5944.patch,
> TestStressInPlaceUpdates.eb044ac71.beast-167-failure.stdout.txt,
> TestStressInPlaceUpdates.eb044ac71.beast-587-failure.stdout.txt,
> TestStressInPlaceUpdates.eb044ac71.failures.tar.gz,
> hoss.62D328FA1DEA57FD.fail.txt, hoss.62D328FA1DEA57FD.fail2.txt,
> hoss.62D328FA1DEA57FD.fail3.txt, hoss.D768DD9443A98DC.fail.txt,
> hoss.D768DD9443A98DC.pass.txt
>
>
> LUCENE-5189 introduced support for updates to numeric docvalues. It would be
> really nice to have Solr support this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
