> On July 18, 2015, 1:22 a.m., Sumit Mohanty wrote: > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/AbstractProviderModule.java, > > line 705 > > <https://reviews.apache.org/r/36587/diff/1/?file=1015041#file1015041line705> > > > > Wont it allow multiple threads to get in? > > Sid Wagle wrote: > Not sure I follow the question. Only the lock owner can proceed with > initProviderMaps() other would wait on it, all waiting ones will see the > first one has set initialized to true and exit after acquiring the lock. > Subsequent threads will never as for lock since initialized will be true from > then on until next reset. > > Sumit Mohanty wrote: > I thought the read lock may be held simultaneously by multiple reader > threads > > Sid Wagle wrote: > Yes, that is right multiple readers can hOld the lock which still solves > deadlock problem But we could have multiple threads updating provider maps. > Alternative is to use compareAnsSet on automiC boolean which means only 1 > thread performs init however if that init fails other reader might miss a > chance, i gUess that might be ok too, thoughts?
Actually, multiple calls to init is OK as they simply overwrite the old value in the maps. Your choice. - Sumit ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/36587/#review92148 ----------------------------------------------------------- On July 18, 2015, 4:44 a.m., Sid Wagle wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/36587/ > ----------------------------------------------------------- > > (Updated July 18, 2015, 4:44 a.m.) > > > Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Mahadev > Konar, Myroslav Papirkovskyy, and Sumit Mohanty. > > > Bugs: AMBARI-12453 > https://issues.apache.org/jira/browse/AMBARI-12453 > > > Repository: ambari > > > Description > ------- > > The high level picture seems to be: Requests made from the UI for host > metrics trying to figure out the actual metrics service and the code that > updates in-memory maps which hold information of where that service is and > what ports to use to connect to it etc. These property maps are update by > Observers on important events like Cluster/Service/Host CRUD by resetting a > volatile variable. > > The contention occurs due the thread that actually enters the monitor > protecting the volatile var and asks for another lock on the cluster which is > held by some other thread which also needs a value from the in-memory maps > and waits on the object monitor that it cannot enter. > > Note: Web based deployments get away because not a lot of CRUD ops happen in > parallel to Reads like the use case of monitoring the Blueprint deploy as the > cluster is being provisioned. > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/AbstractProviderModule.java > 380a0fe > > Diff: https://reviews.apache.org/r/36587/diff/ > > > Testing > ------- > > All unit test passed. > > > Thanks, > > Sid Wagle > >
