> 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
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? - Sid ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/36587/#review92148 ----------------------------------------------------------- On July 17, 2015, 11:45 p.m., Sid Wagle wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/36587/ > ----------------------------------------------------------- > > (Updated July 17, 2015, 11:45 p.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 > >
