[
https://issues.apache.org/jira/browse/SOLR-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-4085:
-----------------------------------
Attachment: SOLR-4085.patch
by following [~ysee...@gmail.com] advice I solved atomicity problem by using
SolrRequestInfo <<ThreadLocal>>: have a look to new
testSearchSortAtomicityVsReload and testSearchAtomicityVsReload
I moved TestExternalFileFieldReload to schema-eff.xml, unfortunately I needed
to amend its' present usage ExternalFileFieldSortTest
The evil is in FileFloatSource.Cache.resetAllReaders(Objectkey) right now it
warns when detects the race:
# one thread are loading the file version 333 lazily
# new file version 334 is created (333 is still being loading)
# reload request submitted, it places _loading placeholder_ in cache and
responses Ok. (333 is still being loading)
# 333 load is over, it substitutes palceholder which was purposed for picking
334
# new search see 333 not 334
I don't think it's a blocker, for someone. Surprisingly right after clicking
Attach, I realized that it's possible to address this race. Obviously efforts
will payed for testing rather than impl itself.
Stay tuned. Looking forward for your feedback.
> Commit-free ExternalFileField
> -----------------------------
>
> Key: SOLR-4085
> URL: https://issues.apache.org/jira/browse/SOLR-4085
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
> Affects Versions: 4.1
> Reporter: Mikhail Khludnev
> Labels: externalfilefield
> Attachments: SOLR-4085.patch, SOLR-4085.patch
>
>
> Let's reload ExternalFileFields without commit!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
