[ 
https://issues.apache.org/jira/browse/KAFKA-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477973#comment-13477973
 ] 

Jun Rao commented on KAFKA-566:
-------------------------------

Madhusudan,

Your understanding is correct. However, there is a bigger issue. The problem is 
that TopicMetadataRequest is designed to be served on any broker since it just 
gets all topic and partition info from ZK. To get log specific information such 
as lastModified time, the request has to be served on the broker to which a 
partition is assigned. So, it's likely that we will need a separate request 
type, something like getReplicaInforRequest. The client will first issue the 
getMetedataRequest to figure out which broker is hosting a partition and then 
issue the getReplicaInforRequest directly to the broker to get the physical 
information related to the replica.
                
> Add last modified time to the TopicMetadataRequest
> --------------------------------------------------
>
>                 Key: KAFKA-566
>                 URL: https://issues.apache.org/jira/browse/KAFKA-566
>             Project: Kafka
>          Issue Type: Bug
>    Affects Versions: 0.8
>            Reporter: Jay Kreps
>            Priority: Blocker
>             Fix For: 0.8
>
>
> To support KAFKA-560 it would be nice to have a last modified time in the 
> TopicMetadataRequest. This would be the timestamp of the last append to the 
> log as taken from stat on the final log segment.
> Implementation would involve
> 1. Adding a new field to TopicMetadataRequest
> 2. Adding a method Log.lastModified: Long to get the last modified time from 
> a log
> This timestamp would, of course, be subject to error in the event that the 
> file was touched without modification, but I think that is actually okay 
> since it provides a manual way to avoid gc'ing a topic that you  know you 
> will want.
> It is debatable whether this should go in 0.8. It would be nice to add the 
> field to the metadata request, at least, as that change should be easy and 
> would avoid needing to bump the version in the future.

--
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

Reply via email to