I guess I don't see completely how that can work. In OG the event contained getTimestamp(), getNanos() and getHost(). The Event in OG does not have these fields. We have an application that is reading legacy log data, creating an OG event and passing it through Flume to a custom Sink to write to Cassandra. In addition, we will have a bunch of apps that use an Appender to create an OG Event which will pass it to an agent to forward to the same Cassandra sink. I'm trying to figure out how we can do the upgrade to NG in a sane fashion.
Ralph On Dec 31, 2011, at 1:30 AM, Eric Sammer wrote: > I've been running through some of the compatibility scenarios and while I > haven't spent a ton of time on it, I think there's a solution. It's true > that the event object isn't the same as OG. That would have been bulky as > we would have had to include thrift just to accommodate it (NG's event is > just a pojo to prevent RPC bleed throughout the codebase). Since users can > only upgrade an entire agent at once - that is, run an OG agent and connect > it to an NG agent or vice versa - we could introduce a compatibility source > and sink for NG and handle the marshaling from OG events to NG events. > > I don't know if that fully allays your concern, but it should get us to > where we need to be. > > On Sat, Dec 31, 2011 at 12:04 AM, Ralph Goers > <[email protected]>wrote: > >> Was it really necessary to make the Event object in NG backward >> incompatible. This will make upgrading systems very painful as everything >> needs to be upgraded at once. >> >> Ralph > > > > > -- > Eric Sammer > twitter: esammer > data: www.cloudera.com
