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 > > >> > > >> > > > > >
