Mailing-List: contact dev-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Content-Type: multipart/alternative;
 boundary="===============6274826070158293233=="
MIME-Version: 1.0
Subject: Re: Review Request 41477: Fix stale cluster entity reference which
 results in merge issues
From: "Sid Wagle" <swagle@hortonworks.com>
To: "Myroslav Papirkovskyy" <mpapyrkovskyy@hortonworks.com>,
 "Nate Cole" <ncole@hortonworks.com>,
 "Sumit Mohanty" <smohanty@hortonworks.com>,
 "Jonathan Hurley" <jhurley@hortonworks.com>
Cc: "Sid Wagle" <swagle@hortonworks.com>,
 "Ajit Kumar" <ajit.kumar@hortonworks.com>, "Ambari" <dev@ambari.apache.org>
Date: Wed, 06 Jan 2016 22:15:06 -0000
Message-ID: <20160106221506.26044.69554@reviews.apache.org>
Auto-Submitted: auto-generated
Sender: "Sid Wagle" <noreply@reviews.apache.org>
References: <20160106053122.26043.1018@reviews.apache.org>
In-Reply-To: <20160106053122.26043.1018@reviews.apache.org>
Reply-To: "Sid Wagle" <swagle@hortonworks.com>

--===============6274826070158293233==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


> On Jan. 6, 2016, 5:31 a.m., Ajit Kumar wrote:
> > ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java, line 838
> > <https://reviews.apache.org/r/41477/diff/3/?file=1183400#file1183400line838>
> >
> >     why clusterId is declared as Long instead of long?
> 
> Sid Wagle wrote:
>     It could technically be null. The clusterId management is pretty much left upto the calling code, for Cluster object not persisted, the id could be null and thereby a valid value, IMO.
> 
> Ajit Kumar wrote:
>     If this is null then get method will throw NullPointerException as it is returning long instead of Long. You will also have to check all methods where you are passing clusterId  to make sure it doesn't throw NullPointerException while converting from Long to long.

Good point, I getter should return Long instead. Will make that change as a separate commit.


- Sid


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


On Jan. 6, 2016, 1:43 a.m., Sid Wagle wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41477/
> -----------------------------------------------------------
> 
> (Updated Jan. 6, 2016, 1:43 a.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Myroslav Papirkovskyy, Nate Cole, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-14411
>     https://issues.apache.org/jira/browse/AMBARI-14411
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> *Preliminary patch*
> 
> Symptom:
> 
> {code}
> Local Exception Stack: 
> Exception [EclipseLink-6004] (Eclipse Persistence Services - 2.5.2.v20140319-9ad6abd): org.eclipse.persistence.exceptions.QueryException
> Exception Description: The object [org.apache.ambari.server.orm.entities.ClusterConfigEntity@3646b3a8], of class [class org.apache.ambari.server.orm.entities.ClusterConfigEntity], with identity hashcode (System.identityHashCode()) [364,075,546], 
> is not from this UnitOfWork object space, but the parent session's.  The object was never registered in this UnitOfWork, 
> but read from the parent session and related to an object registered in the UnitOfWork.  Ensure that you are correctly
> registering your objects.  If you are still having problems, you can use the UnitOfWork.validateObjectSpace() method to 
> help debug where the error occurred.  For more information, see the manual or FAQ.
> 	at org.eclipse.persistence.exceptions.QueryException.backupCloneIsOriginalFromParent(QueryException.java:298)
> 	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.getBackupClone(UnitOfWorkImpl.java:1995)
> 	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3976)
> 	at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerExistingObject(UnitOfWorkImpl.java:3894)
> 	at org.eclipse.persistence.mappings.CollectionMapping.buildElementUnitOfWorkClone(CollectionMapping.java:308)
> 	at org.eclipse.persistence.mappings.CollectionMapping.buildElementClone(CollectionMapping.java:321)
> 	at org.eclipse.persistence.internal.queries.ContainerPolicy.addNextValueFromIteratorInto(ContainerPolicy.java:217)
> {code}
> 
> Likely Cause:
> Stale clusterEntity reference points to a detached entity which gets tried to be merged, the Cascaded relationship throws the error on persist.
> 
> 
> Diffs
> -----
> 
>   ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java 3358e8c 
>   ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterTest.java 3998f1c 
> 
> Diff: https://reviews.apache.org/r/41477/diff/
> 
> 
> Testing
> -------
> 
> Unit testing in progress.
> 
> 
> Thanks,
> 
> Sid Wagle
> 
>


--===============6274826070158293233==--