> On Sept. 28, 2016, 9:54 a.m., Robert Levas wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/events/listeners/alerts/AlertServiceStateListener.java,
> >  line 100
> > <https://reviews.apache.org/r/52345/diff/1/?file=1512284#file1512284line100>
> >
> >     Was adding `m_` a mistake, an old habit, or a new trend?  
> >     
> >     Personally I like the `m_` prefix, but most code in Ambari does not 
> > follow that convention.
> 
> Jonathan Hurley wrote:
>     When I create classes from scratch or work with classes which have their 
> field names matching the method args, I always try to use `m_`. It's a 
> throwback from my old Hungarian notation days. I'd love it if we used full 
> Hungarian especially since Ambari loves to use Long/Integer/Boolean alonside 
> long/int/boolean. Something like m_lVersionId tells you in the name that it's 
> a field, non-static, and a primitive long. People argue that modern day IDEs 
> alleviate the need for this, but we've had our fair share of NPEs casting 
> Long to long and mistakes in losing scope of a variable in a large method.
>     
>     Anywho, we'd never get consensus on it, so I never tried to get it 
> officially added to our coding style wiki.

+1 on Hungarian notation. :)


- Robert


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/52345/#review150714
-----------------------------------------------------------


On Sept. 28, 2016, 8:50 a.m., Jonathan Hurley wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52345/
> -----------------------------------------------------------
> 
> (Updated Sept. 28, 2016, 8:50 a.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Nate Cole, and Robert Levas.
> 
> 
> Bugs: AMBARI-18456
>     https://issues.apache.org/jira/browse/AMBARI-18456
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> Remove shared instances of the shared {{ReadWriteLock}} found in 
> {{ClusterImpl}}. For now, the lock can remain private and full encapsulated 
> inside of {{ClusterImpl}}, but it's use and reference across the rest of 
> Ambari should be removed.
> 
> This is part of the effort to refactor/remove the (mostly) unnecessary locks 
> in memory. The shared instance of this lock is the number one reason that 
> Ambari "deadlocks" when under load.
> 
> 
> Diffs
> -----
> 
>   
> ambari-server/src/main/java/org/apache/ambari/annotations/ExperimentalFeature.java
>  1d5ba0e 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
>  1fc9dbf 
>   
> ambari-server/src/main/java/org/apache/ambari/server/events/listeners/alerts/AlertServiceStateListener.java
>  da4cbf5 
>   ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java 
> 2452df6 
>   ambari-server/src/main/java/org/apache/ambari/server/state/ConfigImpl.java 
> 7b7a60b 
>   ambari-server/src/main/java/org/apache/ambari/server/state/Service.java 
> 7000574 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/ServiceComponent.java
>  983cbdf 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/ServiceComponentImpl.java
>  3e805a0 
>   ambari-server/src/main/java/org/apache/ambari/server/state/ServiceImpl.java 
> 3120b86 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
>  2f7d6b9 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/configgroup/ConfigGroupImpl.java
>  1d6b1e8 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java
>  3b5ed28 
>   
> ambari-server/src/test/java/org/apache/ambari/server/update/HostUpdateHelperTest.java
>  387205d 
> 
> Diff: https://reviews.apache.org/r/52345/diff/
> 
> 
> Testing
> -------
> 
> Tests run: 4679, Failures: 0, Errors: 0, Skipped: 35
> 
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] 
> ------------------------------------------------------------------------
> [INFO] Total time: 41:36 min
> [INFO] Finished at: 2016-09-27T14:21:22-04:00
> [INFO] Final Memory: 40M/739M
> [INFO] 
> ------------------------------------------------------------------------
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

Reply via email to