[
https://issues.apache.org/jira/browse/SOLR-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-10121:
--------------------------------
Attachment: SOLR-10121.patch
Here's a draft patch to fix the currently identified concurrency issues in
BlockCache.
- fetch() checked isRemoved() before the read from the block, but the block
could be reused after that point (i.e. before or during the read), causing the
wrong data to be returned.
- store() allowed existing blocks to be updated, but resulted in corruption.
The reason is that if one retrieves an existing block, one does not know when
that block may stop being used for one key and start being used for another
key. To safely do this, one would require write locks. Since we don't need
the functionality, I simply failed the case of trying to cache/update a block
already in the cache.
> BlockCache corruption with high concurrency
> -------------------------------------------
>
> Key: SOLR-10121
> URL: https://issues.apache.org/jira/browse/SOLR-10121
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Yonik Seeley
> Assignee: Yonik Seeley
> Attachments: SOLR-10121.patch
>
>
> Improving the tests of the BlockCache in SOLR-10116 uncovered a corruption
> bug (either that or the test is flawed... TBD).
> The failing test is TestBlockCache.testBlockCacheConcurrent()
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
