[
https://issues.apache.org/jira/browse/SOLR-5944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Chattopadhyaya updated SOLR-5944:
---------------------------------------
Attachment: SOLR-5944.patch
bq. it is acquired by indexing threads who only want to read stuff from update
log
Ah, I see. That makes it clear for me; I've updated the patch now and have done
the wait loop as per your suggestion.
bq. 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.
Done, removed.
bq. I don't think the case of vinfo.lookupVersion returning a negative value
(for deletes) is handled here at all.
Indeed, I hadn't handled it! I've now handled it in this new patch.
bq. 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?
I think it should now be fixed: v2 update would be dropped since abs(v3) > v2
(earlier I was just checking v3 > v2, which didn't consider negative versions).
I'll add a test for this.
bq. 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.
I think as long as a particular update for the given version is present at the
leader's ulog/tlog, it will be returned. I will add a test for this scenario
specifically anyway.
> 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, 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
