Thanks Chathuri, I will test and let you know. Raman On May 21, 2013, at 4:55 PM, Chathuri Wimalasena wrote:
> 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 <[email protected]>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 <[email protected] >>> 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 >>>> <[email protected]>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 >>>>> >>>>> >>> >>> >>
