There is no locking at a higher level but it is not needed. The metrics thread
does not actually call the IMetrics implementations, but instead enqueues a
special message to the bolt on the Constants/METRICS_TICK_STREAM_ID stream.
The clojure code that calls into the bolts sees this message and instead of
sending it to the bolt to handle it calls the IMetrics implementations and gets
their metrics, and sends them off as messages to the Metrics consumer. Unless
the KafkaSpout is already multi-threaded you will not need to worry about
locking.
- Bobby
On Thursday, May 28, 2015 10:32 AM, Pete Prokopowicz
<[email protected]> wrote:
Hi Devs,
It looks to me like the method getMyManagedPartitions is not thread-safe
and is called from both KafkaSpout::nextTuple() and the anonymous internal
class method IMetric::getValueAndReset(). As far as I can tell these are
called from separate threads.
One outcome is that the method ZkCoordinator::refresh() can get called
twice when the 60 second refreshFreqSecs interval is reached, because the
attribute ZkCoordinator::_lastRefreshTime is not locked and is accessed in
multiple places. The internals of refresh() are not at all thread safe
either and manipulate the partition manager map _managers without locking.
I'm pretty new to the code base; I wasn't able to determine if there was
locking at a higher level, but I doubt it, because the timer-based metrics
thread has access only to the internal object implementing the IMetric
interface, not the KafkaSpout itself.
Does this seem like a problem?
--
*Pete Prokopowicz*Sr. Engineer - Automated Merchandising
600 W. Chicago Ave, Chicago, IL 60654
Mobile: 708-654-8137
Groupon
<http://www.google.com/url?q=http%3A%2F%2Fwww.groupon.com%2F&sa=D&sntz=1&usg=AFrqEzcC80FkwsjyolWTKAH1sZ9yU2t0xg>
II Grouponworks
<http://www.google.com/url?q=http%3A%2F%2Fwww.grouponworks.com%2F&sa=D&sntz=1&usg=AFrqEzdLBm3Dql75wz1BTY0mA30ov3RnWg>
