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


Ship it!




Ship It!

- Robert Levas


On July 30, 2016, 9:04 p.m., Jonathan Hurley wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50636/
> -----------------------------------------------------------
> 
> (Updated July 30, 2016, 9:04 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Nate Cole, Robert Levas, and 
> Sid Wagle.
> 
> 
> Bugs: AMBARI-17970
>     https://issues.apache.org/jira/browse/AMBARI-17970
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> This was an EclipseLink cache problem discovered on downgrade testing. When 
> downgrading Ranger Admin from HDP 2.5 to HDP 2.4, the python code correctly 
> detects HDP 2.4 is the version it should use for "stack feature" checking. On 
> HDP 2.4, Ranger used the audit DB and therefore looks at the configs for 
> audit DB related data.
> 
> However, the data was not there. The problem is complex, yet subtle: 
> - The client thread creating the downgrade changes the desired configurations 
> of the cluster (that's good!)
> - The action scheduler picks up the first task to run during downgrade and 
> sees that configs need to be refresh (that's good!)
> - The ClusterEntity that the action scheduler sees from its entity manager 
> doesn't have the updates applied by the client thread (that's bad!)
> 
> It takes EclipseLink up to 1000ms to invalidate the L1 persistence context 
> cache of the action scheduler's EntityManager. As a result, there's a 
> fraction of a second where the scheduler could see the first downgrade task 
> and try to schedule it using stale configurations. In this case, the 
> configurations from HDP 2.5.
> 
> The solution I chose was to use a synchronous event bus to instruct 
> interested DAOs to invalidate particular entities. The entity manager bound 
> to the action scheduler thread was the problem, but since that thread uses so 
> many DAOs indirectly, it was easier to broadcast an event to interested DAOs, 
> keeping the scheduler thread out of it.
> 
> 
> Diffs
> -----
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/actionmanager/ExecutionCommandWrapper.java
>  2f6ab02 
>   
> ambari-server/src/main/java/org/apache/ambari/server/events/jpa/EntityManagerCacheInvalidationEvent.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/events/jpa/JPAEvent.java 
> PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/events/publishers/JPAEventPublisher.java
>  PRE-CREATION 
>   
> ambari-server/src/main/java/org/apache/ambari/server/orm/dao/ClusterDAO.java 
> 7f499f0 
>   
> ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
>  53059dc 
>   
> ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterTest.java
>  7c0e17c 
> 
> Diff: https://reviews.apache.org/r/50636/diff/
> 
> 
> Testing
> -------
> 
> PENDING UNIT TESTS
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>

Reply via email to