On Fri, May 31, 2013 at 11:26 AM, Saminda Wijeratne <[email protected]>wrote:
> Latest update on AiravataAPI updates for 0.8 version > > 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). These functions are available in the > "ExecutionManager" of the AiravataAPI and "ProvenanceRegistry" in the > RegistryAPI. > * > 3. Persisting & retrieving GFac job data. There are many benefits of > saving the GRAM data, EC2 data etc. such as for debugging, analysis etc. > Currently these data are available only through the message > notifications. > *It is not feasible for the same reasons mentioned for API change for > saving error data. Hence the introduction of functions in the API to > save & > retrieve GFac job data.** These functions are available as > get/setApplicationJob***(...) functions in the "ProvenanceManager" of > the > AiravataAPI and "ProvenanceRegistry" in the RegistryAPI.* > May I ask why we need setApplicationJob****() methods in the API ? As far as I understood job information is populated by GFac and other internal components. So why do we need API methods to set those data ? (OR am I missing something ?) Thanks Amila > > > Regards, > > Saminda > > > On Tue, May 21, 2013 at 4:59 PM, Raminder Singh <[email protected] > >wrote: > > > 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 > > >>>>> > > >>>>> > > >>> > > >>> > > >> > > > > >
