The "updateApplicationJobStatusUpdateTime" method is called from GramJobSubmissionListener.waitFor method. I dont understand why that method is called from waitFor method.
Could you please explain ? Thanks Amila On Tue, Jul 2, 2013 at 5:26 PM, Saminda Wijeratne <[email protected]>wrote: > Hi Amila, > > These are my additions. Basically we are recording the status of the > application execution with the time which it was observed. However > sometimes the same status is observed continuously by the > observers/listeners defined in the provider for that job. In those times we > update only the time which that same status was observed last. > > If you think that the name of the function is confusing shall we change it? > These are util functions which the providers may or may not use for their > convenience. > > Saminda > > > On Tue, Jul 2, 2013 at 4:57 PM, Amila Jayasekara <[email protected] > >wrote: > > > Hi Lahiru, > > > > I have few more questions related to this. > > In GFacUtils class I see following 2 methods; > > > > public static void > > updateApplicationJobStatusUpdateTime(JobExecutionContext context, String > > jobId, Date statusUpdateTime) > > public static void updateApplicationJobStatus(JobExecutionContext > > context, String jobId, ApplicationJobStatus status, Date > statusUpdateTime) > > > > What is the difference between about 2 methods ? More precisely I am > having > > difficulty understanding the need for 1st method. > > > > Thanks > > Amila > > > > > > > > On Tue, Jul 2, 2013 at 3:13 PM, Suresh Marru <[email protected]> wrote: > > > > > On Jul 2, 2013, at 2:19 PM, Saminda Wijeratne <[email protected]> > > wrote: > > > > > > > Are we not going to allow using the GFac libraries as standalone > tool? > > It > > > > could be useful for devs who dont want to use the workflow context to > > run > > > > applications. > > > > > > I would vote against direct use of GFac API from clients. We need to > > > brainstorm and decide on the component level API's and their > implications > > > once we discuss Airavata 1.0( may be also 2.0) roadmaps. > > > > > > In short, I see the need for GFac API's to evolve to facilitate more > > > dynamism and multi-phased interactions between workflow interpreter and > > > GFac. I think we should limit all client integrations to Airavata API > so > > we > > > can put in extra effort to ensure backward compatibility is maintained > > > within major versions. > > > > > > Suresh > > > > > > > On Tue, Jul 2, 2013 at 9:53 AM, Lahiru Gunathilake < > [email protected] > > > >wrote: > > > > > > > >> It's not required now. Please remove it. > > > >> > > > >> > > > >> Lahiru > > > >> > > > >> On Tuesday, July 2, 2013, Amila Jayasekara wrote: > > > >> > > > >>> Hi All, > > > >>> > > > >>> In GFacUtils I see methods like follows; > > > >>> > > > >>> public static void > > > >> updateApplicationJobStatusUpdateTime(JobExecutionContext > > > >>> context, String jobId, Date statusUpdateTime){ > > > >>> AiravataAPI airavataAPI = > > > >>> context.getGFacConfiguration().getAiravataAPI(); > > > >>> if(airavataAPI != null){ > > > >>> try { > > > >>> > > > >>> > > > >> > > > > > > airavataAPI.getProvenanceManager().updateApplicationJobStatusUpdateTime(jobId, > > > >>> statusUpdateTime); > > > >>> } catch (AiravataAPIInvocationException e) { > > > >>> log.error("Error in updating application job status time > > > >>> "+statusUpdateTime.toString()+" for job Id "+jobId+"!!!", e); > > > >>> } > > > >>> } > > > >>> } > > > >>> > > > >>> Any particular reason to have "if(airavataAPI != null)" condition ? > > > >>> > > > >>> Thanks > > > >>> Amila > > > >>> > > > >> > > > >> > > > >> -- > > > >> System Analyst Programmer > > > >> PTI Lab > > > >> Indiana University > > > >> > > > > > > > > >
