Flume-1026: Document thread safety expectations of interfaces
Review Request #4400 - Created March 19, 2012 and submitted
I went over the basic interfaces and added some javadoc for developers of new components. I am pretty concerned about the fact that pretty much everything is not thread safe because off the lack of guarantees provided by some of the interfaces(Configurable in particular). A lot of existing components assume thread safety(which is somewhat given by isolation of process() type methods to a single runner thread). Should we be fixing these components, or making some more guarantees about when and how configuration calls should be called(e.g. only callable on a stopped component?)
Doc only patch
Posted (March 20, 2012, 11:24 p.m.)
Juhani, looks great. I added a few suggestions around wording. I agree with the general concerns. I'm not yet sure what I think we should do about it though.
"...they may be simultaneously accessed by" (missing "by")
How about: "guaranteed to be called only by a single thread at a time, with no concurrency. Any other mechanism driving a pollable source must follow the same semantics." This sounds a lot like a synchronized call and I wonder if it makes sense to call this out as required by PollableSource implementations.
How about switching a couple words around: "While the Sink process call is guaranteed to only be accessed by a single thread, other calls may be concurrently accessed and should thus be protected."
Posted (March 20, 2012, 11:37 p.m.)
I too am concerned about the thread safety. I'll take a look at some of the classes tonight or tomorrow, and will offer some suggestions. I'll be considering atomicity, visibility, and HB relationships per JCIP.