Return-Path: 
 <dev-return-9722-apmail-airavata-dev-archive=airavata.apache.org@airavata.apache.org>
X-Original-To: apmail-airavata-dev-archive@www.apache.org
Delivered-To: apmail-airavata-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id E064610072
	for <apmail-airavata-dev-archive@www.apache.org>;
 Fri, 17 Jan 2014 02:40:55 +0000 (UTC)
Received: (qmail 63103 invoked by uid 500); 17 Jan 2014 02:40:54 -0000
Delivered-To: apmail-airavata-dev-archive@airavata.apache.org
Received: (qmail 62994 invoked by uid 500); 17 Jan 2014 02:40:54 -0000
Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@airavata.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@airavata.apache.org>
List-Post: <mailto:dev@airavata.apache.org>
List-Id: <dev.airavata.apache.org>
Reply-To: dev@airavata.apache.org
Delivered-To: mailing list dev@airavata.apache.org
Received: (qmail 62986 invoked by uid 99); 17 Jan 2014 02:40:53 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Jan 2014 02:40:53 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
	tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of swsachith@gmail.com
 designates 74.125.82.48 as permitted sender)
Received: from [74.125.82.48] (HELO mail-wg0-f48.google.com) (74.125.82.48)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Jan 2014 02:40:48 +0000
Received: by mail-wg0-f48.google.com with SMTP id x13so3902988wgg.3
        for <dev@airavata.apache.org>; Thu, 16 Jan 2014 18:40:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:date:message-id:subject:from:to:content-type;
        bh=7pxArOnBGOGvQc76aiMPmOe7sFYhWzNyAOhH45zJKw4=;
        b=FtXM6R7/dKfwGkCoev+XNMZTvfpS1LAzND4wwXWv1c+E2gNZUkADqvN/moig3jSyMp
         HuihI1lS0L4TvSLnGBAoAjjRYjJs6ddxS64LftoPAPOHCTJYKeEaEppCqE2ZzTtlx8oJ
         kaQoGpr7UGASR1UOlfpltYVP8ZkBBakO5xBGcgABGmOwEzcYujoSmV9VCHRnL1HYPuPu
         ia2Xt6VyQTkYzaqKo3aGLheyEnhn69G6QTTX2izB7H1gEt+cnR1P8znBZv45rnPbwbyn
         z3XHvBB0w3l6SgZt9zzdjNB5/ObDC3tnt4C3qWPbqmXX1W6yRqxnPubXpgIAwVbdMkIY
         +fhQ==
MIME-Version: 1.0
X-Received: by 10.180.14.37 with SMTP id m5mr34333wic.46.1389926427406; Thu,
 16 Jan 2014 18:40:27 -0800 (PST)
Received: by 10.217.93.129 with HTTP; Thu, 16 Jan 2014 18:40:27 -0800 (PST)
Date: Thu, 16 Jan 2014 21:40:27 -0500
Message-ID: 
 <CAOpPrj9f+6Np1_VObfKy=Gtk7aQ+_m3HBFVSBhOJMrS96XFagQ@mail.gmail.com>
Subject: Update the Gfac job status in the Orchestrator table.
From: Sachith Withana <swsachith@gmail.com>
To: dev@airavata.apache.org
Content-Type: multipart/alternative; boundary=f46d04138ca7f8390704f0217698
X-Virus-Checked: Checked by ClamAV on apache.org

--f46d04138ca7f8390704f0217698
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

Currently Gfac job status updates are not reflected in the Orchestrator
table. We need to have the status updates in the Orchestrator table for it
to function properly.

Currently the suggestion is:

Update the Orchestrator table when the Gfac is updating its status in the
registry.This will take place in the Registry method itself, since
Orchestrator is using the registry directly rather than going through the
API like the Gfac does.We will have to check whether the Gfac Job_id is
connected to an experiment in the Orchestrator table, and if it is, update
the Orchestrator table as well

Any better ways of doing this? I'm not sure about the overhead involved
with looking up two tables when updating the status.

-- 
Thanks,
Sachith Withana

--f46d04138ca7f8390704f0217698
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br></div><div>Currently Gfac job status updat=
es are not reflected in the Orchestrator table. We need to have the status =
updates in the Orchestrator table for it to function properly.</div><div><b=
r>

</div><div>Currently the suggestion is:</div><div><br></div><div>Update the=
 Orchestrator table when the Gfac is updating its status in the registry.Th=
is will take place in the Registry method itself, since Orchestrator is usi=
ng the registry directly rather than going through the API like the Gfac do=
es.We will have to check whether the Gfac Job_id is connected to an experim=
ent in the Orchestrator table, and if it is, update the Orchestrator table =
as well</div>
<div><br></div><div>Any better ways of doing this? I&#39;m not sure about t=
he overhead involved with looking up two tables when updating the status.=
=A0</div><div><div><br></div>-- <br>
<div dir=3D"ltr"><div><font style=3D"font-family:garamond,serif">Thanks,</f=
ont></div><font style=3D"font-family:garamond,serif"></font><font style=3D"=
font-family:garamond,serif"></font><div style>
<font face=3D"garamond, serif">Sachith Withana<br></font><br></div></div>
</div></div>

--f46d04138ca7f8390704f0217698--