[
https://issues.apache.org/jira/browse/KAFKA-12766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17342123#comment-17342123
]
A. Sophie Blee-Goldman commented on KAFKA-12766:
------------------------------------------------
Personally I agree that throwing an exception may be too harsh, it's not my
impression that any of the wal-related options are "critical" enough that a
user would want or need to be informed if they were going to be ignored. We
should definitely log a warning at the least.
Can you clarify a bit more on the difference between the first two approaches,
ie disable vs ignore? AFAICT they are pretty much the same -- since all user
options pass through our adapter class, if we just don't pass through to the
method on the underlying Option then we've both ignored and disabled it.
{quote}I do not understand how we should disable the option since we do not
have control over the `Options` object
{quote}
Based on this sentence I'm wondering if you had something else in mind by
"disable"? I feel that "ignoring" it may be sufficient, for the reasons
described above, plus it's simple to implement
> Consider Disabling WAL-related Options in RocksDB
> -------------------------------------------------
>
> Key: KAFKA-12766
> URL: https://issues.apache.org/jira/browse/KAFKA-12766
> Project: Kafka
> Issue Type: Improvement
> Components: streams
> Reporter: Bruno Cadonna
> Priority: Minor
>
> Streams disables the write-ahead log (WAL) provided by RocksDB since it
> replicates the data in changelog topics. Hence, it does not make much sense
> to set WAL-related configs for RocksDB instances within Streams.
> Streams could:
> - disable WAL-related options
> - ignore WAL-related options
> - throw an exception when a WAL-related option is set.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
