[
https://issues.apache.org/jira/browse/SAMZA-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14555696#comment-14555696
]
Jakob Homan commented on SAMZA-658:
-----------------------------------
+1 on backport.
> Iterator.remove breaks caching layer
> ------------------------------------
>
> Key: SAMZA-658
> URL: https://issues.apache.org/jira/browse/SAMZA-658
> Project: Samza
> Issue Type: Bug
> Components: kv
> Affects Versions: 0.9.0
> Reporter: Naveen
> Assignee: Guozhang Wang
> Labels: newbie
> Fix For: 0.10.0, 0.9.1
>
> Attachments: SAMZA-658.v3.patch, SAMZA-658.v4.patch,
> samza-658.0.9.1.patch
>
>
> If you get an iterator from the underlying layer from any store (InMemory),
> we just return the underlying iterator. Upon invoking remove operation on the
> iterator, we just delete the value from the underlying store.
> InMemory:
> {code}
> override def remove(): Unit = iter.remove()
> {code}
> This removes it from the store, but the cache still has the value and returns
> a value when requested for the key in the subsequent calls for the key. When
> the iterator.remove() is invoked, we need make sure that all the layers
> remove the key before we remove it from the underlying store.
> RocksDB doesn't support remove on iterator, so it's probably only for
> inmemory store we have this issue.
> {code}
> def remove() = throw new UnsupportedOperationException("RocksDB iterator
> doesn't support remove")
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
