Uploaded image for project: 'Airavata'
  1. Airavata
  2. AIRAVATA-343

[GSoC] Workflow Debugging Framework for Airavata

    Details

      Description

      The backend of Airavata should support workflow debugging. It should expose some API that will enable users to connect &
      1. Receive workflow execution data, current state data
      2. Send commands to manipulate execution life cycle (pause/resume/restart/stop etc.)
      3. Modify workflow data on the fly

      The API should be intuitive, language independent & supports remote debugging.

      The specifics for the task & the level of debugging is open for discussion.

      1. debuggerModule_midterm_eval.patch
        67 kB
        Hasitha Aravinda
      2. Xbaya_debugger_support_20_08_2012.patch
        218 kB
        Hasitha Aravinda

        Activity

        Hide
        samindaw Saminda Wijeratne added a comment -

        If you've ever used a debugger before the required features should be pretty straightforward to think of. If we start looking at the debugger client perspective the most common features would be,

        • A way to connect with the workflow debugging server/service: given some url, in certain cases prehaps credentials etc.
        • Exchanging debugging configuration with the server/service
          listing workflows are currently being executed/running
          specifying what workflows the client is interested in debugging
          eg: workflow topic id (usually unique at the execution of a workflow)
          breakpoint nodes & their properties
        • Listening to workflow events
          eg: workflow execution started, terminated, suspended, resumed, error, breakpoint_not_found etc.
        • Issuing debug commands while workflow execution
          eg:
          add breakpoint
          edit breakpoint properties
          clear breakpoint
          get/set node data, state, stack etc.
          step
          restart
          run
          stop

        As far as I can remember the workflow model is not transformed in to some compiled object when it is executed. Which means unlike many compiled programming languages we should be able to treat the workflow being executed as being executed by an interpreter. i.e. while the workflow is being executed we could allow changes of the workflow model to have immediate effect from the current execution point onwards (with some proper validation onwards). Which would be a cool feature to have.

        Please buzz if anything's unclear.

        I'll add more details on where to jump-in in Airavata code to start investigating.

        Show
        samindaw Saminda Wijeratne added a comment - If you've ever used a debugger before the required features should be pretty straightforward to think of. If we start looking at the debugger client perspective the most common features would be, A way to connect with the workflow debugging server/service: given some url, in certain cases prehaps credentials etc. Exchanging debugging configuration with the server/service listing workflows are currently being executed/running specifying what workflows the client is interested in debugging eg: workflow topic id (usually unique at the execution of a workflow) breakpoint nodes & their properties Listening to workflow events eg: workflow execution started, terminated, suspended, resumed, error, breakpoint_not_found etc. Issuing debug commands while workflow execution eg: add breakpoint edit breakpoint properties clear breakpoint get/set node data, state, stack etc. step restart run stop As far as I can remember the workflow model is not transformed in to some compiled object when it is executed. Which means unlike many compiled programming languages we should be able to treat the workflow being executed as being executed by an interpreter. i.e. while the workflow is being executed we could allow changes of the workflow model to have immediate effect from the current execution point onwards (with some proper validation onwards). Which would be a cool feature to have. Please buzz if anything's unclear. I'll add more details on where to jump-in in Airavata code to start investigating.
        Hide
        hasitha.aravinda Hasitha Aravinda added a comment -

        I went through your description and things mentioned by Surresh in mailing list. I have couple of questions regarding the scope of this feature.

        1) is this feature targeting on a debugging module that integrated in backend of Airavata ( in Workflow Interpreter) or debugging module in XBaya GUI ?
        According to my understanding it should contains both of them to provide better debugging framework.

        2) This feature covers lots of debugging functionalities and I feel, time constraints will be a problem to address all these things. So what would be the initial requirements that fit for a GSOC project? So we can set a milestone plan.

        Any suggestions are very much appreciated.

        Show
        hasitha.aravinda Hasitha Aravinda added a comment - I went through your description and things mentioned by Surresh in mailing list. I have couple of questions regarding the scope of this feature. 1) is this feature targeting on a debugging module that integrated in backend of Airavata ( in Workflow Interpreter) or debugging module in XBaya GUI ? According to my understanding it should contains both of them to provide better debugging framework. 2) This feature covers lots of debugging functionalities and I feel, time constraints will be a problem to address all these things. So what would be the initial requirements that fit for a GSOC project? So we can set a milestone plan. Any suggestions are very much appreciated.
        Hide
        samindaw Saminda Wijeratne added a comment -

        Sorry I could not get back to responding to your comment (or my promise) much earlier.

        1. Currently we already have a debugging feature at XBaya side. But this is limited to executing the workflow at the XBaya only. If the workflow was executed at the server XBaya cannot debug that execution. So the debugging module should be implemented at the backend Airavata & the XBaya GUI should be able to connect with it.

        2. Lets have a priority set of features listed. I feel following are MUST HAVE.

        • The debugging client (eg: XBaya GUI) should be able to connect with the backend debugging module in Airavata server.
        • The debugging client will provide a topic id & the breakpoint nodes to the backend.
        • Backend will pause and notify the debugging client whenever it reaches the breakpoint node of the workflow instance (that's being executed at the server) which corresponds to the topic id
        • Client should be able to retrieve & expose the current status & data of the workflow execution (eg: what are the inputs to the breakpoint node)
        • Client should be able to tell the server to execute next node & pause again (step)
        • Client should be able to tell the server to continue execution (resume)
        • Client should be able to tell the server to stop the execution of the workflow (terminate)

        Allowing modification of data on the stack while debugging is something that is common in debugging frameworks. But we'll leave it for now if it is not going to fit in to the time span.
        There is

        Show
        samindaw Saminda Wijeratne added a comment - Sorry I could not get back to responding to your comment (or my promise) much earlier. 1. Currently we already have a debugging feature at XBaya side. But this is limited to executing the workflow at the XBaya only. If the workflow was executed at the server XBaya cannot debug that execution. So the debugging module should be implemented at the backend Airavata & the XBaya GUI should be able to connect with it. 2. Lets have a priority set of features listed. I feel following are MUST HAVE. The debugging client (eg: XBaya GUI) should be able to connect with the backend debugging module in Airavata server. The debugging client will provide a topic id & the breakpoint nodes to the backend. Backend will pause and notify the debugging client whenever it reaches the breakpoint node of the workflow instance (that's being executed at the server) which corresponds to the topic id Client should be able to retrieve & expose the current status & data of the workflow execution (eg: what are the inputs to the breakpoint node) Client should be able to tell the server to execute next node & pause again (step) Client should be able to tell the server to continue execution (resume) Client should be able to tell the server to stop the execution of the workflow (terminate) Allowing modification of data on the stack while debugging is something that is common in debugging frameworks. But we'll leave it for now if it is not going to fit in to the time span. There is
        Hide
        samindaw Saminda Wijeratne added a comment -

        Hasitha,

        Until my request for becoming a mentor for ASF was approved through GSoC Melange site please consider the following as few comments on the proposal [1] you've submitted.

        i. There are a few spelling & grammar mistakes
        ii. While I know what you meant, I feel some of the following areas are a little unclear. Perhaps consider revising those a little?
        a. it is not clear why current XBaya debugging cannot be directly associated with a backend execution of the workflow with a simple RMI mechanism.
        b. Might be a good idea to mention what you plan do to if you do not have enough time to implement the all the tasks you've mentioned. (Note that it's not crucial for all the tasks you've mentioned to be implemented)
        c. How do you plan to carry out the testing phase. A brief description would do.
        d. When reading the proposal I see several paragraphs that could have a subheading (for clarity purposes).
        iii. If you have time, a simple box diagram would be helpful to others to understand the architecture you are proposing.

        Overall I think the proposal looks good.

        Saminda

        1. http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/hasithaaravinda/1

        Show
        samindaw Saminda Wijeratne added a comment - Hasitha, Until my request for becoming a mentor for ASF was approved through GSoC Melange site please consider the following as few comments on the proposal [1] you've submitted. i. There are a few spelling & grammar mistakes ii. While I know what you meant, I feel some of the following areas are a little unclear. Perhaps consider revising those a little? a. it is not clear why current XBaya debugging cannot be directly associated with a backend execution of the workflow with a simple RMI mechanism. b. Might be a good idea to mention what you plan do to if you do not have enough time to implement the all the tasks you've mentioned. (Note that it's not crucial for all the tasks you've mentioned to be implemented) c. How do you plan to carry out the testing phase. A brief description would do. d. When reading the proposal I see several paragraphs that could have a subheading (for clarity purposes). iii. If you have time, a simple box diagram would be helpful to others to understand the architecture you are proposing. Overall I think the proposal looks good. Saminda 1. http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/hasithaaravinda/1
        Hide
        hasitha.aravinda Hasitha Aravinda added a comment -

        Saminda,

        I have updated the proposal according to your feedback.

        Hasitha Aravinda.

        Show
        hasitha.aravinda Hasitha Aravinda added a comment - Saminda, I have updated the proposal according to your feedback. Hasitha Aravinda.
        Hide
        smarru Suresh Marru added a comment -

        Suresh April 6, 2012, 12:23 p.m.
        Hi Hasitha,

        I echo with Chris, great proposal but a bit ambitious. If you are motivated enough and have good time, you will be able to do all of it, but as you can see from the OODT jira, these can easliy result in half a dozen significant sub-tasks. I do not want to discourage you, but caution you to scope your project well enough. Even you can finish the phase 1, that by itself will be very helpful for the airavata user community. Airavata workflows are typically very long running in nature and tapping into existing executions not only assit the workflow debugging but opens up venue for other exhilerating opportunities like providing deferred (or just in time binding) of workflow inputs, provide workflow adaptability and so on. Very encouraging to see you are thinking beyond the current project.

        Few questions and comments:

        Why do you propose new debugging server as opposed to enhancing the workflow interpreter itself?

        You have a very elaborative development plan but a week testing plan, please try and elaborate on your test cases as well.

        You have a good granular details in the implementation section, but your schedule section is very course grained. Can you submit a more fine grained schedule?

        Over all, good proposal and an important topic. These capabilities not only improve airavata, but also saves valuable computational time on lage super computers and should have a very broad impact. Me and others in airavata community will be happy to guide you through out the project.

        Good luck with the proposal,

        Suresh

        Show
        smarru Suresh Marru added a comment - Suresh April 6, 2012, 12:23 p.m. Hi Hasitha, I echo with Chris, great proposal but a bit ambitious. If you are motivated enough and have good time, you will be able to do all of it, but as you can see from the OODT jira, these can easliy result in half a dozen significant sub-tasks. I do not want to discourage you, but caution you to scope your project well enough. Even you can finish the phase 1, that by itself will be very helpful for the airavata user community. Airavata workflows are typically very long running in nature and tapping into existing executions not only assit the workflow debugging but opens up venue for other exhilerating opportunities like providing deferred (or just in time binding) of workflow inputs, provide workflow adaptability and so on. Very encouraging to see you are thinking beyond the current project. Few questions and comments: Why do you propose new debugging server as opposed to enhancing the workflow interpreter itself? You have a very elaborative development plan but a week testing plan, please try and elaborate on your test cases as well. You have a good granular details in the implementation section, but your schedule section is very course grained. Can you submit a more fine grained schedule? Over all, good proposal and an important topic. These capabilities not only improve airavata, but also saves valuable computational time on lage super computers and should have a very broad impact. Me and others in airavata community will be happy to guide you through out the project. Good luck with the proposal, Suresh
        Hide
        samindaw Saminda Wijeratne added a comment -

        Looks really great Hasitha. Nice job.

        Few more tips from my side.

        i. a few formatting tips to improve the look n feel more,

        • try to see if you can justify alignments of a paragraph
        • see if you can indent bullet points
        • get rid of redundant sentences (eg: Backend debugging module will be implemented in Airavata Server and will capable to do following task.)

        ii. for the purpose of newbies to the Airavata architecture perhaps it would be useful to add a simple terminology index at the end of the proposal that explains (very briefly) some words used in Airavata domain,
        eg:
        topic id - represents <something>
        backend/airavata server - <something> which does <something>
        ...

        Show
        samindaw Saminda Wijeratne added a comment - Looks really great Hasitha. Nice job. Few more tips from my side. i. a few formatting tips to improve the look n feel more, try to see if you can justify alignments of a paragraph see if you can indent bullet points get rid of redundant sentences (eg: Backend debugging module will be implemented in Airavata Server and will capable to do following task.) ii. for the purpose of newbies to the Airavata architecture perhaps it would be useful to add a simple terminology index at the end of the proposal that explains (very briefly) some words used in Airavata domain, eg: topic id - represents <something> backend/airavata server - <something> which does <something> ...
        Hide
        samindaw Saminda Wijeratne added a comment -

        Only just saw Sureshs' response. I have to agree with Suresh. The testing plan does seem to be localized to only phase 2 & seems to only cover integration testing.

        I'm not so sure about having further fine-grained schedule. Perhaps subtask schedules for phase 1 & phase 2 with rough durations would make more sense?

        Saminda

        Show
        samindaw Saminda Wijeratne added a comment - Only just saw Sureshs' response. I have to agree with Suresh. The testing plan does seem to be localized to only phase 2 & seems to only cover integration testing. I'm not so sure about having further fine-grained schedule. Perhaps subtask schedules for phase 1 & phase 2 with rough durations would make more sense? Saminda
        Hide
        hasitha.aravinda Hasitha Aravinda added a comment -

        Chris, Surresh, and Saminda,

        Thank you for your feedback and i am really appreciate your feedback and they really helped me to improve my proposal.

        I agreed with you, proposal seems a bit ambitious. So I came with Development Plan to address that problem. I improved the testing plan, and schedule. Also improved the formatting of the proposal.

        Hasitha Aravinda.

        Show
        hasitha.aravinda Hasitha Aravinda added a comment - Chris, Surresh, and Saminda, Thank you for your feedback and i am really appreciate your feedback and they really helped me to improve my proposal. I agreed with you, proposal seems a bit ambitious. So I came with Development Plan to address that problem. I improved the testing plan, and schedule. Also improved the formatting of the proposal. Hasitha Aravinda.
        Hide
        hasitha.aravinda Hasitha Aravinda added a comment - - edited

        This is the development Road Map for Debugger module.

        Mile Stone 1
        =========

        This milestone divided into two subtasks.

        1) Develop a POC to cover basic debugger functionalities at workflow Interpreter Level.

        Implement a Debugger class and an API class to connect with the debugger.
        (ii) Implement Debugging functions for Input Nodes.
        (iii) Add support for Workflow termination, pause, continue, step.
        (iv) Add support for notify debugger events.
        (v) Add support for capture debugging related data.
        (vi) Implement debugger support for intermediates nodes. (Debugging Intermediate nodes can be done, before and after a service invoke.) Following components can be listed under Intermediates Nodes,

        • WS Components
        • Dynamic Components
        • DoWhile Components *
        • IF Components *
        • For Each Components *
        • SubWorkflow Component *
        • Instance Component *

        (vii) Add support for to modify data on fly for Input Nodes. *
        (viii) Add support for to modify data on fly for Intermediate Nodes. *

        2) Develop a sample GUI application to test implemented functionalities.

        Read a workflow file and load its nodes.
        (ii) Add a mechanism to set break points for nodes.
        (iii) Provide a mechanism to run a selected Workflow.
        (iv) Provide a mechanism to manipulate Workflow Execution. (Pause, Continue, Step, Terminate)
        (v) Listing and Monitoring debugger events. (Both Info and Debug Events)
        (vi) Add a mechanism to show debugger event details.
        (vii) Add a mechanism to show Input variables, Input Message, Output Message, Fault Message.
        (viii) Add a Object Navigator panel to browse objects which are captured during a node execution.
        (ix) Add support for modify data on fly. *

        (Note: marked as * functions will added soon.)

        Mile Stone 2 - (To be defined with more details.)
        ==========
        1) Implementing Debugger support for Airavata Client.
        2) Implementing Debugger support for XBaya.
        3) Implementing Remote Debugger Support.

        Show
        hasitha.aravinda Hasitha Aravinda added a comment - - edited This is the development Road Map for Debugger module. Mile Stone 1 ========= This milestone divided into two subtasks. 1) Develop a POC to cover basic debugger functionalities at workflow Interpreter Level. Implement a Debugger class and an API class to connect with the debugger. (ii) Implement Debugging functions for Input Nodes. (iii) Add support for Workflow termination, pause, continue, step. (iv) Add support for notify debugger events. (v) Add support for capture debugging related data. (vi) Implement debugger support for intermediates nodes. (Debugging Intermediate nodes can be done, before and after a service invoke.) Following components can be listed under Intermediates Nodes, WS Components Dynamic Components DoWhile Components * IF Components * For Each Components * SubWorkflow Component * Instance Component * (vii) Add support for to modify data on fly for Input Nodes. * (viii) Add support for to modify data on fly for Intermediate Nodes. * 2) Develop a sample GUI application to test implemented functionalities. Read a workflow file and load its nodes. (ii) Add a mechanism to set break points for nodes. (iii) Provide a mechanism to run a selected Workflow. (iv) Provide a mechanism to manipulate Workflow Execution. (Pause, Continue, Step, Terminate) (v) Listing and Monitoring debugger events. (Both Info and Debug Events) (vi) Add a mechanism to show debugger event details. (vii) Add a mechanism to show Input variables, Input Message, Output Message, Fault Message. (viii) Add a Object Navigator panel to browse objects which are captured during a node execution. (ix) Add support for modify data on fly. * (Note: marked as * functions will added soon.) Mile Stone 2 - (To be defined with more details.) ========== 1) Implementing Debugger support for Airavata Client. 2) Implementing Debugger support for XBaya. 3) Implementing Remote Debugger Support.
        Hide
        hasitha.aravinda Hasitha Aravinda added a comment -

        I have attached a patch, which contains the current version of the debugger POC module. It is less on features and not finalized module. I am attaching it here to give you an idea about my current progress.

        Note: this POC only supports for debugging input Nodes, WS Components and Dynamic Components. Debugging functions for other components (like IF, Dowhile, For Each, etc.) will be added soon. Also currently it doesn’t support to modify node data on fly.

        Show
        hasitha.aravinda Hasitha Aravinda added a comment - I have attached a patch, which contains the current version of the debugger POC module. It is less on features and not finalized module. I am attaching it here to give you an idea about my current progress. Note: this POC only supports for debugging input Nodes, WS Components and Dynamic Components. Debugging functions for other components (like IF, Dowhile, For Each, etc.) will be added soon. Also currently it doesn’t support to modify node data on fly.
        Hide
        hasitha.aravinda Hasitha Aravinda added a comment -

        Please follow the following steps to apply the patch and to debug a workflow using currently implemented functionalities.

        Applying Patches and Building the xbaya-gui with new Changes
        ==============================================
        1) First Apply above patch to xbaya-gui module.

        2) Then apply the GenericInvoker.patch attached at AIRAVATA-512 [1] JIRA. It allows to capture Input Message and Fault Messages during WSComponent execution.

        3) Then Build xbaya-gui module using maven.

        Debugging ComplexMath.xwf using TestCase
        =================================

        I have created a test-case called WorkflowDebuggingTest to test debugger module functionalities. It demonstrates how debugger API can be used to debug a workflow.

        In this test case, it sets all nodes of the ComplexMath.xwf as break points and then starts workflow execution. Since all node are break points, workflow execution will pause at every node. A separate thread watches this workflow execution and when workflow execution is paused at a break point, the thread notifys debugger to continue the workflow execution. In parallel to that, some of the event data which are captured during node execution will log runtime.

        This test-case only shows some of the basic functions of the debugger module. I have created a sample Debugger GUI and It can be used to test other functionalities of the debugger module.

        Debugging using sample GUI debugger
        =============================

        1) Check out sample GUI debugger from [2] and build it using maven.

        2) Run sampleDebuggerClient-1.0.jar which created at target directory.

        3) After the opening Debugger window, Click on “select” button which located at right top corner -> then select a XBaya workflow file from file browswe (ex: ComplexMath.xwf) -> then click Open.

        4) Click on “Load workflow” button to load workflow nodes. It will show all available nodes of the selected workflow in "Available Nodes .. " list.

        5) Add a node into break points list by double clicking on a node in "available nodes .." list.

        6) Also you can remove break point nodes by double clicking on a node on break point list.
        (Note: Also you can add and remove break points during the workflow execution)

        5) Click on “Debug <your_workflow_name>” button to start debugging.

        6) Manipulate workflow execution using Continue, Step, Pause and Terminate buttons.

        7) Click on an event in “Workflow Debug process monitor” table to display more details about the selected event.

        8) If you select a “DEBUG” event you can see some other options will enable like "Input, Input messages, output message, fault message, Advance object navigation" depending on captured data and the event.

        9) You can use “Advance object navigation ” tab to explore objects which are captured during corresponding node execution. To explore an object details, right click on corresponding tree node and select "explore object".

        Please let me know if you have any questions.

        [1] https://issues.apache.org/jira/browse/AIRAVATA-512
        [2] http://svn.codespot.com/a/apache-extras.org/airavata-gsoc-sandbox/trunk/hasitha/sampleDebuggerClient/

        Show
        hasitha.aravinda Hasitha Aravinda added a comment - Please follow the following steps to apply the patch and to debug a workflow using currently implemented functionalities. Applying Patches and Building the xbaya-gui with new Changes ============================================== 1) First Apply above patch to xbaya-gui module. 2) Then apply the GenericInvoker.patch attached at AIRAVATA-512 [1] JIRA. It allows to capture Input Message and Fault Messages during WSComponent execution. 3) Then Build xbaya-gui module using maven. Debugging ComplexMath.xwf using TestCase ================================= I have created a test-case called WorkflowDebuggingTest to test debugger module functionalities. It demonstrates how debugger API can be used to debug a workflow. In this test case, it sets all nodes of the ComplexMath.xwf as break points and then starts workflow execution. Since all node are break points, workflow execution will pause at every node. A separate thread watches this workflow execution and when workflow execution is paused at a break point, the thread notifys debugger to continue the workflow execution. In parallel to that, some of the event data which are captured during node execution will log runtime. This test-case only shows some of the basic functions of the debugger module. I have created a sample Debugger GUI and It can be used to test other functionalities of the debugger module. Debugging using sample GUI debugger ============================= 1) Check out sample GUI debugger from [2] and build it using maven. 2) Run sampleDebuggerClient-1.0.jar which created at target directory. 3) After the opening Debugger window, Click on “select” button which located at right top corner -> then select a XBaya workflow file from file browswe (ex: ComplexMath.xwf) -> then click Open. 4) Click on “Load workflow” button to load workflow nodes. It will show all available nodes of the selected workflow in "Available Nodes .. " list. 5) Add a node into break points list by double clicking on a node in "available nodes .." list. 6) Also you can remove break point nodes by double clicking on a node on break point list. (Note: Also you can add and remove break points during the workflow execution) 5) Click on “Debug <your_workflow_name>” button to start debugging. 6) Manipulate workflow execution using Continue, Step, Pause and Terminate buttons. 7) Click on an event in “Workflow Debug process monitor” table to display more details about the selected event. 8) If you select a “DEBUG” event you can see some other options will enable like "Input, Input messages, output message, fault message, Advance object navigation" depending on captured data and the event. 9) You can use “Advance object navigation ” tab to explore objects which are captured during corresponding node execution. To explore an object details, right click on corresponding tree node and select "explore object". Please let me know if you have any questions. [1] https://issues.apache.org/jira/browse/AIRAVATA-512 [2] http://svn.codespot.com/a/apache-extras.org/airavata-gsoc-sandbox/trunk/hasitha/sampleDebuggerClient/
        Hide
        hasitha.aravinda Hasitha Aravinda added a comment -

        Here I have attached current version of the debugger POC. Current implementation supports for following nodes.

        • WS Components
        • Dynamic Components
        • IF Components
        • For Each Components
        • SubWorkflow Component - (Including its sub workflow Nodes)
        • And Input and Output Nodes.

        Also I updated to sample debugger GUI client at [1] for recent changes. You can try current debugger implementation by running it, or by running test case WorkflowDebuggingTest ( added into the Xbaya Test).

        Note: Please apply patch to the Xbaya-GUI module and build it, before you try sample debugger GUI. Please refer instructions given in previous comment to debug a workflow using sample debugger GUI.

        I will continue the development of this module along with the MetCat development. Future works of the Debugger module.

        • Adding support for Amazon nodes, doWhile node.
        • Implementing Debugger support for XBaya.
        • Implement Modify data on-fly support.

        Hasitha.

        [1] - https://svn.codespot.com/a/apache-extras.org/airavata-gsoc-sandbox/trunk/hasitha/sampleDebuggerClient

        Show
        hasitha.aravinda Hasitha Aravinda added a comment - Here I have attached current version of the debugger POC. Current implementation supports for following nodes. WS Components Dynamic Components IF Components For Each Components SubWorkflow Component - (Including its sub workflow Nodes) And Input and Output Nodes. Also I updated to sample debugger GUI client at [1] for recent changes. You can try current debugger implementation by running it, or by running test case WorkflowDebuggingTest ( added into the Xbaya Test). Note: Please apply patch to the Xbaya-GUI module and build it, before you try sample debugger GUI. Please refer instructions given in previous comment to debug a workflow using sample debugger GUI. I will continue the development of this module along with the MetCat development. Future works of the Debugger module. Adding support for Amazon nodes, doWhile node. Implementing Debugger support for XBaya. Implement Modify data on-fly support. Hasitha. [1] - https://svn.codespot.com/a/apache-extras.org/airavata-gsoc-sandbox/trunk/hasitha/sampleDebuggerClient
        Hide
        samindaw Saminda Wijeratne added a comment -

        Sounds good Hasitha... I will look at this before the evaluation and give you feedback.

        Show
        samindaw Saminda Wijeratne added a comment - Sounds good Hasitha... I will look at this before the evaluation and give you feedback.
        Hide
        hasitha.aravinda Hasitha Aravinda added a comment -

        Saminda suggested following improvement for Debugger module, during the last meeting with him.

        For Debugger API:

        • Improve the mechanism of retiring inputs/output of an invoker. Because we found, there are some cases like in an application service invoke, output value is not available on the parent invoker.

        • Most of the Java level debugger details are not useful for the programmer in most of the cases, so reduce the scope of object level detail viewing in the Object Navigator.

        • Saminda suggested that user define properties for debugger, may be an interesting feature to have. So programmer can define properties, which debugger should only consider values of the objects/nodes etc at debugging time.

        For GUI improvements:

        • Validate invoker fault message, before displaying it in GUI. Because by default every invoker has default fault message, <fault/> and displaying this default value at runtime may give an impression of a failure even in a successful invoke.

        Show
        hasitha.aravinda Hasitha Aravinda added a comment - Saminda suggested following improvement for Debugger module, during the last meeting with him. For Debugger API: Improve the mechanism of retiring inputs/output of an invoker. Because we found, there are some cases like in an application service invoke, output value is not available on the parent invoker. • Most of the Java level debugger details are not useful for the programmer in most of the cases, so reduce the scope of object level detail viewing in the Object Navigator. • Saminda suggested that user define properties for debugger, may be an interesting feature to have. So programmer can define properties, which debugger should only consider values of the objects/nodes etc at debugging time. For GUI improvements: • Validate invoker fault message, before displaying it in GUI. Because by default every invoker has default fault message, <fault/> and displaying this default value at runtime may give an impression of a failure even in a successful invoke.

          People

          • Assignee:
            Unassigned
            Reporter:
            samindaw Saminda Wijeratne
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development