airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chathuri Wimalasena <kamalas...@gmail.com>
Subject Re: Updates to Airavata API version 0.8
Date Tue, 21 May 2013 20:55:11 GMT
Hi Raman,

The method Saminda mentioned will work for your case. I tested with your
test class. I fixed deserialization issues from REST service side. You will
probably have to update both server and client.

Regards,
Chathuri


On Tue, May 21, 2013 at 3:04 PM, Saminda Wijeratne <samindaw@gmail.com>wrote:

> 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