Return-Path: X-Original-To: apmail-oodt-dev-archive@www.apache.org Delivered-To: apmail-oodt-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 4F3BF7C69 for ; Wed, 26 Oct 2011 22:50:10 +0000 (UTC) Received: (qmail 70935 invoked by uid 500); 26 Oct 2011 22:50:10 -0000 Delivered-To: apmail-oodt-dev-archive@oodt.apache.org Received: (qmail 70912 invoked by uid 500); 26 Oct 2011 22:50:10 -0000 Mailing-List: contact dev-help@oodt.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@oodt.apache.org Delivered-To: mailing list dev@oodt.apache.org Received: (qmail 70904 invoked by uid 99); 26 Oct 2011 22:50:10 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Oct 2011 22:50:10 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [128.149.139.105] (HELO mail.jpl.nasa.gov) (128.149.139.105) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Oct 2011 22:50:01 +0000 Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p9QMnc10023053 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO) for ; Wed, 26 Oct 2011 15:49:39 -0700 Received: from ALTPHYEMBEVSP20.RES.AD.JPL ([128.149.137.83]) by ALTVIREHTSTAP01.RES.AD.JPL ([128.149.137.72]) with mapi; Wed, 26 Oct 2011 15:49:38 -0700 From: "Verma, Rishi (388J)" To: "dev@oodt.apache.org" Date: Wed, 26 Oct 2011 15:49:37 -0700 Subject: Re: Sharing workflow task metadata when using a resource manager Thread-Topic: Sharing workflow task metadata when using a resource manager Thread-Index: AcyUMYpkaCCFgQdCS4O2TkRp7VoLng== Message-ID: <99205657-8327-42B0-825C-9752AF8C0BC3@jpl.nasa.gov> References:

<40A49A06-1D17-46CE-992D-150CE17EC72E@me.com> In-Reply-To: <40A49A06-1D17-46CE-992D-150CE17EC72E@me.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: Rishi.Verma@jpl.nasa.gov X-AUTH: Authorized X-Virus-Checked: Checked by ClamAV on apache.org Thanks for the heads up Brian, Actually, I am trying to pass workflow met from a WorkflowTaskInstance to a= PGETaskInstance, but I will keep this in mind for future cases! thanks, rishi On Oct 24, 2011, at 6:17 PM, Brian Foster wrote: > if you are using CAS-PGE then in your pgeconfig.xml file you can specify = on a any custom metadata element the attribute workflowMet=3D'true' and it = will pass through to all the following tasks in the workflow... for example= : >=20 > -Brian >=20 > On Oct 24, 2011, at 5:45 PM, "Verma, Rishi (388J)" wrote: >=20 >> Hey Sheryl, >>=20 >> Thanks for the response! >>=20 >> Yeah, the workflow-manager log actually already spits out a lot of workf= low task instance info whenever it submits a task to a resource manager nod= e. >> It shows (for each task invoked): >> * 'task.intance.class' name >> * 'task.config' parameters >> * 'task.metadata' contents >>=20 >> I did some tests, and concluded (from viewing task.metadata) that all ta= sk metadata fed into the first task of my workflow (ie. when passing in met= via: wmgr-client ... --key name value...) showed up in the 'task.metadata'= for all tasks in my workflow. However, if my first task added new generate= d metadata, it would not show up in the 'task.metadata' of subsequent tasks= being called. The latter issue only occurs when using a resource manager f= or task execution. >>=20 >> Thanks for the tip though, I will keep this in mind while trying out som= e new strategies. >>=20 >> rishi >>=20 >> On Oct 24, 2011, at 5:18 PM, Sheryl John wrote: >>=20 >>> Hi Rishi, >>>=20 >>> Would getting workflowInstance metadata help you debug this problem ( u= sing >>> command-line option for the wmgr-client)? This will not give you the jo= b >>> metadata of course, but it gives out the job ids. >>> And you could probably use the job id for checking out the metadata for >>> that respective job. I'm not sure if there is code for this. >>>=20 >>> On Mon, Oct 24, 2011 at 4:52 PM, Verma, Rishi (388J) < >>> Rishi.Verma@jpl.nasa.gov> wrote: >>>=20 >>>> Hi all, >>>>=20 >>>> I'm trying to pass generated metadata from a workflow task to another >>>> workflow task (both in the same workflow) when using a resource manage= r to >>>> execute workflow task jobs. >>>>=20 >>>> I've done this before successfully when workflow tasks within a given >>>> workflow are run locally (by the workflow manager itself) but when I p= oint >>>> workflow manager to have tasks execute through a resource manager, my >>>> generated metadata does not seem to transfer from one task to the next= . >>>>=20 >>>> By "generated" metadata, I mean metadata that is added within the "run= " >>>> method of an implemented WorkflowTaskInstance. It's worth noting thoug= h, >>>> that metadata passed into the initial XmlRpc call of a workflow task s= eems >>>> to be passed to all subsequent tasks just fine. Just not generated met= adata >>>> - which passes only when not using a resource manager. >>>>=20 >>>> I'm trying to ascertain if this issue is a bug or not. To find out, co= uld >>>> someone elaborate a bit on which resmgr (or other) classes would inclu= de >>>> code that actually shows metadata for a job being passed through a rem= otely >>>> running job? I've been trying to find such code within the codebase bu= t have >>>> not come across it yet. >>>>=20 >>>> Thanks! >>>> rishi >>>>=20 >>>>=20 >>>=20 >>>=20 >>> --=20 >>> -Sheryl >>=20