airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Wijeratne <samin...@gmail.com>
Subject Re: Updates to Airavata API version 0.8
Date Tue, 21 May 2013 19:04:43 GMT
So far what you are saying is true. If the client knows which node failed
he/she can get the list of errors for that node using the
getExecutionError(...) function. Use the "type" as ALL and leave the
gfacJobId as null. I couldn;t think of doing this any other better way than
introducing a whole lot of functions which could be more annoying/confusing
to figure-out. I'm welcome for suggestions for improvements.

Saminda


On Tue, May 21, 2013 at 2:36 PM, Raminder Singh <raminderjsingh@gmail.com>wrote:

> Thanks Chathuri, the WorkflowExecutionError works.  Integrating to Error
> API brought few questions. We have ErrorTypes as : WorkflowExecutionError,
> ExperimentExecutionError, NodeExecutionError, GFacJobExecutionError,
> ExecutionError . How do we want clients to know which error type to query?
> I ran a job and it failed, now i want to get error. Error occurred at  GFac
> provider level and client does not have any information. Do we expect
> client to query all different types?
>
> I thing we can have is a method to get all error and return the Error type
> part of the object to help the client to classify the error location.
>  Other suggestions?
>
> Raminder
>
> On May 21, 2013, at 10:57 AM, Chathuri Wimalasena wrote:
>
> > Hi Raman,
> >
> > WorkflowExecutionError method not returning any data issue should be
> fixed
> > now. Can you get an update and check.
> >
> > Regards,
> > Chathuri
> >
> >
> > On Tue, May 21, 2013 at 10:02 AM, Raminder Singh
> > <raminderjsingh@gmail.com>wrote:
> >
> >> Thank, these are very useful for API users. Only thing i found confusing
> >> for the user is API managers.  ProvenanceManager is the one used to get
> >> experiment status. Users will get FINISHED or FAILED status from the
> data
> >> object. On failure, i was trying to find a method to get the error data
> but
> >> i was not able to find as those methods exist in ExecutionManager.
> >> According to me, experiment status and in case of failures get error
> need
> >> to be part of one manager. May be a ExperimentManager?  Getting output
> data
> >> can be left as part of provenance manages as only few client may want to
> >> get the data in few cases. Getting error detail in case of error is
> obvious
> >> step.
> >>
> >> Other thing can you please explain the difference between
> >> WorkflowExecutionError, ExperimentExecutionError, NodeExecutionError,
> >> GFacExecutionError on a Wiki page for the users. Also add a method to
> get
> >> JobID as that is required to get GFacExecutionError.
> >>
> >> I tested the WorkflowExecutionError method and its not returning any
> data.
> >> Can you please test that as well?
> >>
> >> ExperimentData data =
> >> airavataAPI.getProvenanceManager().getExperimentData(experimentID);
> >> List<WorkflowExecutionError> experimentExecutionErrors =
> >>
> airavataAPI.getExecutionManager().getWorkflowExecutionErrors(experimentID,
> >> experimentID);
> >>
> >> Thanks
> >> Raminder
> >>
> >>
> >> On May 20, 2013, at 5:05 PM, Saminda Wijeratne wrote:
> >>
> >>> Following updates will be present Airavata API from 0.8 release.
> >>>
> >>>
> >>>  1. *Error message from the immediate exception used as the error
> >> message
> >>>  for the AiravataAPInvocationException*. Earlier it was just "Error
> >>>  invoking API". *This change was made so that the users of the API can
> >>>  show the error from the exception without having to dig in to the
> inner
> >>>  exception to get a better error message.*
> >>>  2. *Saving and retrieving experiment execution error details*. Earlier
> >>>  we were not persisting any execution error details of the workflow.
> >> Error
> >>>  details are only available only if the developers are monitoring
> >> experiment
> >>>  at the time of error occurs. *This is not feasible if users would only
> >>>  want to go through the error details later without doing monitoring
> >> from
> >>>  the beginning. Therefore we are now persisting the error details (not
> >> as
> >>>  part of provenance data) of executing workflows (i.e. experiments)* in
> >>>  to the registry and also retrieving from registry through Airavata API
> >>>  (which calls the Registry API).
> >>>
> >>> For now we have the functions for saving and retrieving errors in the
> >>> ExecutionManager[1]. We need to decide if this is the correct place to
> >> put
> >>> these functions. Your thoughts in this matter are most welcome...
> >>>
> >>>
> >>> Thanks,
> >>> Saminda
> >>>
> >>> 1.
> >>>
> >>
> https://svn.apache.org/repos/asf/airavata/trunk/modules/airavata-client/src/main/java/org/apache/airavata/client/api/ExecutionManager.java
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message