I believe the long term plan was to move to Guava, as Jarcec pointed out. This is probably better than trying to fix and improve the current lifecycle management system. As it is, there are a bunch of issues with our current system, which have noticed and fixed. I am not quite satisfied with the fixes we have made though, most are tacky and break-fix.
Also, none of our components really check for interrupts and many(most?) don'g have clean shutdown semantics. Maybe this should be discussed and we should come up with a detailed analysis of the situation. I am willing to look at the migration to Guava if no one else has already looked at it or is looking into it. Thanks Hari -- Hari Shreedharan On Tuesday, June 5, 2012 at 11:13 PM, Jarek Jarcec Cecho wrote: > Just a quick question to the idea of adding more lifecycle states - are we > still planning to move from our "homemade" lifecycle management to Guava as > is describe in FLUME-966? > > Jarcec > > On Jun 6, 2012, at 8:06 AM, Juhani Connolly wrote: > > > I've been burrowing into the lifecycle code recently and posted > > https://issues.apache.org/jira/browse/FLUME-1257 regarding it(more > > specifically, regarding inability to shutdown after a component gets stuck > > in a starting loop). > > > > Right now, to put it bluntly, the shutdown model feels incorrect, there are > > a lot of places with a loop waiting for changes in state, that have an > > exception handler for InterruptedException, but nothing will ever trigger > > that interrupt. SIGINT is handled by the shutdown hook, which requests a > > clean shutdown. If a clean shutdown doesn't succeed, everything just hangs > > in limbo until you forcibly kill it. > > > > I'd like to start some kind of discussion on how to go about handling this. > > One argument may be that it's just not a problem... so long as everything > > starts and stops in a timely manner. Other simple kludges would be setting > > a limit to number of times through each loop. Or we could just start > > sending interrupts after a predetermined delay. > > > > Another possibility is adding more lifecycle states to better communicate > > state(starting/stopping?) so that actions can be aborted as necessary. This > > would likely require all existing components to communicate these new > > states. > > > > Feedback/opinions would be appreciated
