[
https://issues.apache.org/jira/browse/KAFKA-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749738#comment-13749738
]
Jay Kreps commented on KAFKA-1023:
----------------------------------
Yeah I would also be reticent to do this. The reason is just that each
interface that is "injectable" is something we need to plan compatibility
around. Currently we don't do this for internal interfaces.
With replication it is possible to hang onto data for a long time on the kafka
servers and have data replicated so it is likely to survive even server
failures. If you want more assurance still, since Kafka is easy to consume from
its easy enough to build a consumer that backs up the data elsewhere. If you
want something more low-tech I think you could just have a shell script or
background java thread that scps the kafka files without needing to inject it
into the actual log roll logic.
> Allow Injectable LogManager
> ---------------------------
>
> Key: KAFKA-1023
> URL: https://issues.apache.org/jira/browse/KAFKA-1023
> Project: Kafka
> Issue Type: Improvement
> Components: core
> Reporter: Micah Whitacre
>
> Currently the LogManager is responsible for deleting and cleaning up messages
> based on time or size. It'd be nice to be able enhance the LogManager to not
> only perform the cleanup but maybe also backup the messages eligible for
> deletion to a custom location (hdfs). This would allow a backup plan in the
> case of a consumer not able to keep up with the messages and data being lost
> due to log rolling.
> Currently LogManager is sealed so no one can extend it but additionally we'd
> need a way to inject the custom LogManager into the KafkaServer.
--
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
