ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sumit Mohanty" <smoha...@hortonworks.com>
Subject Re: Review Request 36895: Cluster creates stuck at 9x% (deadlock sql exception)
Date Mon, 03 Aug 2015 20:11:30 GMT

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


Changes look good. Will wait for the upgrade related changes.

- Sumit Mohanty


On Aug. 3, 2015, 6:39 p.m., Jonathan Hurley wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/36895/
> -----------------------------------------------------------
> 
> (Updated Aug. 3, 2015, 6:39 p.m.)
> 
> 
> Review request for Ambari, Alejandro Fernandez, Nate Cole, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-12570
>     https://issues.apache.org/jira/browse/AMBARI-12570
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> Similar to AMBARI-12526, Ambari installation via a blueprint on SQL Azure gets stuck
somewhere between 90% and 100% because of a SQL Database deadlock.
> 
> - We have dual X-locks on hostcomponentstate asking for U-locks when updating the CLUSTERED
INDEX.
> - Both dual X-locks, from different transactions and different processes, are on the
same row (technically impossible) - based on the XML execution plan, we can see that the concurrent
UPDATE statements are executing on different rows due to their CLUSTERED INDEX predicate.
> - In Java, Ambari has locks which prevent concurrent U- or X-locks on the same row
> - Only happens on SQL Server
> 
> My best suspicion right now is that we have a key hash collision happening on this table.
That's why two processes appear to have the same lock even though they are on different rows.
> 
> Restricting row-level locking on this table will prevent locking on hash keys which could
collide.
> 
> 
> Diffs
> -----
> 
>   ambari-server/src/main/java/org/apache/ambari/server/orm/dao/HostComponentStateDAO.java
fb585fd 
>   ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostComponentStateEntity.java
45e036b 
>   ambari-server/src/main/java/org/apache/ambari/server/orm/entities/HostComponentStateEntityPK.java
86e0dee 
>   ambari-server/src/main/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostImpl.java
0850a79 
>   ambari-server/src/main/resources/Ambari-DDL-MySQL-CREATE.sql 1b67b24 
>   ambari-server/src/main/resources/Ambari-DDL-Oracle-CREATE.sql 16f6a0a 
>   ambari-server/src/main/resources/Ambari-DDL-Postgres-CREATE.sql cd6e27a 
>   ambari-server/src/main/resources/Ambari-DDL-Postgres-EMBEDDED-CREATE.sql c7138be 
>   ambari-server/src/main/resources/Ambari-DDL-SQLServer-CREATE.sql 0ff1aff 
>   ambari-server/src/test/java/org/apache/ambari/server/state/ServiceComponentTest.java
96bbb1d 
>   ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClustersTest.java
ce1fd34 
>   ambari-server/src/test/java/org/apache/ambari/server/state/svccomphost/ServiceComponentHostTest.java
f6ab0ec 
>   ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog170Test.java
93f7f8c 
>   ambari-server/src/test/java/org/apache/ambari/server/upgrade/UpgradeCatalog200Test.java
484c18d 
> 
> Diff: https://reviews.apache.org/r/36895/diff/
> 
> 
> Testing
> -------
> 
> Deployed a clean cluster on SQL Server and then ran 10+ deployments on SQL Azure without
seeing a deadlock.
> 
> 
> Thanks,
> 
> Jonathan Hurley
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message