Return-Path: X-Original-To: apmail-ambari-user-archive@www.apache.org Delivered-To: apmail-ambari-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 97B16184C8 for ; Mon, 7 Dec 2015 17:43:41 +0000 (UTC) Received: (qmail 59766 invoked by uid 500); 7 Dec 2015 17:43:41 -0000 Delivered-To: apmail-ambari-user-archive@ambari.apache.org Received: (qmail 59722 invoked by uid 500); 7 Dec 2015 17:43:41 -0000 Mailing-List: contact user-help@ambari.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@ambari.apache.org Delivered-To: mailing list user@ambari.apache.org Received: (qmail 59712 invoked by uid 99); 7 Dec 2015 17:43:41 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Dec 2015 17:43:41 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 6085F1A0B61 for ; Mon, 7 Dec 2015 17:43:40 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.446 X-Spam-Level: ** X-Spam-Status: No, score=2.446 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=3, RP_MATCHES_RCVD=-0.554, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id dVsmHhDMUUe9 for ; Mon, 7 Dec 2015 17:43:29 +0000 (UTC) Received: from esg01.rackspace.com (esg04.rackspace.com [104.130.178.9]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 9A3D720ECF for ; Mon, 7 Dec 2015 17:43:28 +0000 (UTC) Received: from smtpout.rackspace.com (unknown [10.13.196.92]) by Websense Email Security Gateway with ESMTPS id A61033EE4A364 for ; Mon, 7 Dec 2015 17:43:30 +0000 (UTC) Received: from 543818-OEXCH01.ror-uc.rackspace.com (10.13.196.91) by 544124-OEXCH02.ror-uc.rackspace.com (10.13.196.92) with Microsoft SMTP Server (TLS) id 15.0.1130.6; Mon, 7 Dec 2015 11:43:27 -0600 Received: from 543818-OEXCH01.ror-uc.rackspace.com ([fe80::5c15:c66b:3251:9f85]) by 543818-OEXCH01.ror-uc.rackspace.com ([fe80::5c15:c66b:3251:9f85%17]) with mapi id 15.00.1130.005; Mon, 7 Dec 2015 11:43:27 -0600 From: Greg Hill To: "user@ambari.apache.org" Subject: Re: NullPointerException when posting a Request Thread-Topic: NullPointerException when posting a Request Thread-Index: AQHRMRSvNH8NiZdS1E2J6UbN0mX18J6/y2EA Date: Mon, 7 Dec 2015 17:43:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [72.3.161.24] Content-Type: multipart/alternative; boundary="_000_D28B20B221C0Cgreghillrackspacecom_" MIME-Version: 1.0 --_000_D28B20B221C0Cgreghillrackspacecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So, looking at our code a bit more, we submit multiple requests in parallel= , and only one of them failed with the 500 error. Perhaps a locking (or la= ck thereof) issue? I can adjust our workflow to prevent the parallel submi= ssion as a workaround, but seems like Ambari should be able to handle it. Greg From: Greg > Reply-To: "user@ambari.apache.org" > Date: Monday, December 7, 2015 at 11:28 AM To: "user@ambari.apache.org" > Subject: COMMERCIAL:NullPointerException when posting a Request Our product provisions clusters in an automated way using Ambari. About 1 = in 50 clusters gets this error, so we're not sure exactly how to reproduce = it. It might be a race condition of some sort. One of the first things we= do is run a set of custom actions on all the nodes in the cluster. We do = that by POST'ing a request to the cluster. Randomly that request will thro= w a 500 error with this NullPointerException: https://gist.githubusercontent.com/jimbobhickville/62176c2053827a90efab/raw= /34fec22ff0fda2056090377ca432b18f58073d9a/gistfile1.txt This is on Ambari 2.1.1 The code path looks pretty normal, but I'm not much of a Java dev so there = could be something that isn't obvious to me. It's just looking up the curr= ent cluster in the database by name. Doing a GET /clusters/ wo= rks fine at the same point in the process, afaict, so I don't see how it's = getting a NullPointerException when doing it internally. Is this a known issue? Is there a workaround or way to tell when it's safe= to issue the request? Greg --_000_D28B20B221C0Cgreghillrackspacecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <29B8A6BD7333FC4AA2196059284C4140@rackspace.com> Content-Transfer-Encoding: quoted-printable
So, looking at our code a bit more, we submit multiple requests in par= allel, and only one of them failed with the 500 error.  Perhaps a lock= ing (or lack thereof) issue?  I can adjust our workflow to prevent the= parallel submission as a workaround, but seems like Ambari should be able to handle it.

Greg

From: Greg <greg.hill@rackspace.com>
Reply-To: "user@ambari.apache.org" <user@ambari.apache.org>
Date: Monday, December 7, 2015 at 1= 1:28 AM
To: "user@ambari.apache.org" <user@ambari.apache.org>
Subject: COMMERCIAL:NullPointerExce= ption when posting a Request

Our product provisions clusters in an automated way using Ambari. &nbs= p;About 1 in 50 clusters gets this error, so we're not sure exactly how to = reproduce it.  It might be a race condition of some sort.  One of= the first things we do is run a set of custom actions on all the nodes in the cluster.  We do that by POST'ing a re= quest to the cluster.  Randomly that request will throw a 500 error wi= th this NullPointerException:


This is on Ambari 2.1.1

The code path looks pretty normal, but I'm not much of a Java dev so t= here could be something that isn't obvious to me.  It's just looking u= p the current cluster in the database by name.  Doing a GET /clusters/= <cluster-id> works fine at the same point in the process, afaict, so I don't see how it's getting a NullPointerExcep= tion when doing it internally.

Is this a known issue?  Is there a workaround or way to tell when= it's safe to issue the request?

Greg
 --_000_D28B20B221C0Cgreghillrackspacecom_--