Return-Path: 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 406A9EA73 for ; Tue, 5 Feb 2013 22:17:51 +0000 (UTC) Received: (qmail 16288 invoked by uid 500); 5 Feb 2013 22:17:51 -0000 Delivered-To: apmail-airavata-dev-archive@airavata.apache.org Received: (qmail 16252 invoked by uid 500); 5 Feb 2013 22:17:51 -0000 Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@airavata.apache.org Delivered-To: mailing list dev@airavata.apache.org Received: (qmail 16239 invoked by uid 99); 5 Feb 2013 22:17:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Feb 2013 22:17:51 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of samindaw@gmail.com designates 209.85.215.45 as permitted sender) Received: from [209.85.215.45] (HELO mail-la0-f45.google.com) (209.85.215.45) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Feb 2013 22:17:44 +0000 Received: by mail-la0-f45.google.com with SMTP id er20so738060lab.32 for ; Tue, 05 Feb 2013 14:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=DPwBtURvC/dUHdyy+JuEBIU1P1yzEQUQVeGEMSCE89Q=; b=p4NZJX23LoBV8frwn1GSzC+U2CGPBnL3oUXmTjoIkIWmFvHLdPuVY8Go+GZ4H+BLi4 XBGrWWTefUTPQPuylK6s5FZ4irJJBTqVt5L9W5QtYH5TLHsF63avp+NvT0Wz0ROPRBuG /oZbqXV6UI6SHWIDrmGBrG1bTAN1ya6kM7xi8TFYTwN9B3EqtMoJxgSKh+SeVmSE2A8I YSSDOl4mIwMNSyWh2uRH7Kv19uiM4adqWm30M4jH17akxVVsWlUisw6OR1/bbTjKQCnL mB5Oiy8LkLI1f7uMVmP93RUYvQKEFjgsnu0dvdGJ+1ITnAAg8TJqHpuoBbPyv0GsR3B5 5D5w== X-Received: by 10.112.38.228 with SMTP id j4mr10503865lbk.1.1360102642672; Tue, 05 Feb 2013 14:17:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.76.136 with HTTP; Tue, 5 Feb 2013 14:17:02 -0800 (PST) In-Reply-To: References: From: Saminda Wijeratne Date: Tue, 5 Feb 2013 17:17:02 -0500 Message-ID: Subject: Re: API Client questions To: dev@airavata.apache.org Content-Type: multipart/alternative; boundary=e0cb4efe2f12dfe5d904d5019205 X-Virus-Checked: Checked by ClamAV on apache.org --e0cb4efe2f12dfe5d904d5019205 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 5, 2013 at 4:46 PM, Pedro da Silveira wrote: > Saminda, > > > On Tue, Feb 5, 2013 at 2:18 PM, Saminda Wijeratne >wrote: > > > Hi Pedro, > > > > see my comments in-line, > > > > On Tue, Feb 5, 2013 at 1:42 PM, Pedro da Silveira > >wrote: > > > > > Hi Dev, > >> > > >> > I have a few question regarding to Airavata API Client. > >> > I tested both 2 samples from the directory > >> > "apache-airavata-client-0.7-SNAPSHOT/samples". They all ran the echo > >> > example successfully. > >> > I modified the sample "workflow-run" to submit my pre-defined > workflow, > >> > which has 4 inputs file "URI", 2 Application Services and total wall > >> time > >> > 20 minutes. My workflow ran successfully using API Client as it did on > >> > Xbaya. > >> > > >> > 1 - One part of the code that got my attention was a call to the > method > >> > "getWorkflowComposeContent()", which reads my workflow saved file with > >> > extension ".xwf". I didn't understand the call for this method. Can > >> someone > >> > help me? > >> > > >> > > >> > airavataAPI.getWorkflowManager().saveWorkflow(getWorkflowComposeContent()); > >> > > >> There are two ways to specify what the workflow that needs to be > >> executed. > >> 1. Pass the name of the workflow - then the workflow should already > be > >> saved in the registry > >> 2. Pass the workflow xml as a string > >> The above command tries to save the workflow to the registry. API user > has > >> to pass the workflow xml as a string to the "saveWorkflow" function. The > >> API will extract the name of the workflow from the xml string & save the > >> workflow to the registry under that name. This should be a one time > thing. > >> That's all it does and has nothing to do with running the workflow at > this > >> point. > >> Then the users can use the 1st way mentioned above to run the workflow > >> many > >> times as he/she wants by just passing only the name of the workflow to > the > >> runExperiment(...) method. > > > > > > If I understood it correctly, If my workflow is already saved in my > > register I don't need to run this command again, right? > > > Yep. > > > > > > > >> > 2 - The API client transfered my input correctly from my desktop to > >> > Lonestar, How can I get one output file back from Lonestar to my > desktop > >> > using the API? In general, my outputs are just text file and less than > >> > 500MB. > >> > > >> The API client could not have transfered any file from your desktop. I > >> assume that the Airavata server is running in your machine & the input > >> paths you may have passed to the experiment are local. The workflow > >> execution may have taken care of transfering the file in your desktop to > >> Lonestar. If you require files downloaded back to your desktop then you > >> need to update your workflow in order to do that. > > > > > > > Based on your answer "If you require files downloaded back to your desktop > then you need to update your workflow in order to do that." > > What kind of update do I need to do on my workflow? Do I have to add > anything in my script that runs on Lonestar? > My basic understating is that I can setup in my Application Service add > another Application parameter Output and then provide the type "URI". What > is next? Where is the location my output will be saved on my desktop? > Well its a little tricky. As far as I know we have grid-ftp capability to transfer files so as to stage them as input for the next application. Airavata has no notion of returning files at the end of workflow execution (to be exact Airavata would not know what files are to transfer anyway unless the application returns a URI pointing to the file). Theoretically speaking, if the final result is a file after running a workflow, the user should manually retrieve the file (using scp/ftp etc.). Having said that what you could do is to have a new application service defined in Airavata which points to an application that is in your machine which accepts a URI as an input (& may or may not have an output). And have your Lonestar application service output a URI to the file which you want to be downloaded to your machine & connect that output to the input of your new application service. (if you are in linux your new application service could just point to "/bin/echo"). In this way we can trick Airavata to bring a file back to your machine. Hope I was clear enough... if not please don't hesitate to ask questions to clarify further. > > > > > > > >> > 3 - I noticed in the monitoring part of the code that a Java Thread is > >> > created and keep the application hanging until the end of the > monitoring > >> > execution. Is that possible to create the thread, check the monitor > >> status > >> > and kill thread to check the status later in about N minutes? Or Do I > >> have > >> > to keep the thread alive during the job execution? > >> > > >> Monitoring is used to track the progress of the workflow experiment in > >> real > >> time... you can always *not monitor* and check the status at your > leisure. > >> Thus the lines, > >> MonitorWorkflow.monitor(result); > >> airavataAPI.getExecutionManager().waitForExperimentTermination(result); > >> are not needed. Important thing to note here is that the command, > >> airavataAPI.getExecutionManager().runExperiment(workflowName, > >> workflowInputs) > >> launches the experiment and returns without waiting for the experiment > to > >> finish. Thus the API users should not expect the results to be available > >> when it tries to read provenance data. Infact it'll take little bit of > >> time > >> for the experiment to be registered to the system & initial status of > the > >> workflow executions be updated correctly. API users should anticipate > such > >> scenarios if they are planning not to use default monitoring or > >> "waitForExperimentTermination(...)" functionalities. > > > > > > > My plan is to connect to Airavata-Server to check the status of the job > every 5 minutes and not keep the socket connection alive until the job > finishes. Is there any problem doing that? > nop.. no problems at all... > I want to submit more tasks to Lonestar, but now using my Xsede account, > instead of "ogce". > > Thank you for your help Saminda. > > > Please feel free to further ask questions if anything is unclear or if you > > have any other issues. > > > > Regards, > > Saminda > > > > > > > Thank you, > > > > > > Pedro da Silveira > > > > > > --e0cb4efe2f12dfe5d904d5019205--