[
https://issues.apache.org/jira/browse/HDFS-7446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14225571#comment-14225571
]
Colin Patrick McCabe commented on HDFS-7446:
--------------------------------------------
This patch adds a txid field to all {{Event}} objects. We have to send this
over the wire, since the existing information (start txid and stop txid for a
group of txids we got in an RPC) is not enough. Not every edit log txid maps
to an event.
Another complication is the fact that some txids map to more than one event.
This makes it somewhat difficult for clients to know what they've read up to
when using a one-event-at-a-time interface. This patch solves that by having
the {{DFSInotifyEventInputStream}} return an array of events. In the cases
where a single txid maps to multiple events, we return an array of all those
events. So the client knows that after it has finished processing this batch,
it is done with that transaction id. This interface is marked as unstable, so
changing it is not a problem.
Miscellaneous cleanups: I made all some fields final in the {{Event}}
structures. In cases where I modified a unit test, I replaced assertTrue(1 ==
foo) with assertEquals(1, foo). The latter gives nicer error messages when the
test fails.
> HDFS inotify should have the ability to determine what txid it has read up to
> -----------------------------------------------------------------------------
>
> Key: HDFS-7446
> URL: https://issues.apache.org/jira/browse/HDFS-7446
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: dfsclient
> Affects Versions: 2.6.0
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
>
> HDFS inotify should have the ability to determine what txid it has read up
> to. This will allow users who want to avoid missing any events to record
> this txid and use it to resume reading events at the spot they left off.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
