Unknown macro: {next_previous_link3}
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

This section is still a work in progress!

WSO2 Stream Processor Studio allows debugging tasks to be carried out to ensure that the Siddhi applications you create and deploy are validated before they are run on an actual production environment. To debug a Siddhi application, you can run it in the debug mode, apply debug point and then run event simulation so that the specific debug points are analyzed.

To run a Siddhi application in the debug mode, follow the procedure below:

  1. Start the Stream Processor Studio following the instructions in Stream Processor Studio Overview.
  2. You are directed to the welcome-page. In this scenario, let's use the existing sample Siddhi application named ReceiveAndCount to demostrate the debugging functionality. To open this Siddhi application, click on the sample.

    The ReceiveAndCount Siddhi application opens in a new tab.
  3. In order to debug the Siddhi file, you need to first save it in the workspace directory. To do this, click File => Save. In the Save to Workspace dialog box that appears, click Save.
  4. To run the Siddhi application in the debug mode, click Run => Debug.

    This menu option is enabled only when the Siddhi file is saved in the workspace directory as specified in the previous step.

    As a result, the following log is printed in the console.

    Also, another console tab is opened with debug options as shown below.

  5.  Apply debug points for the required queries. To mark a debug point, you need to click on the left of the required line number so that it is marked with a dot as shown in the image below.

    You can only mark lines with from or insert into statements as debug points.

  6. Simulate one or more events for the SweetProductionStream stream in the Siddhi application. The first line that is marked as a debug point is highlighted as shown below when they are hit.



    Two viewing options are provided under both Event State and the Query State sections of the Debug tab for each debug point hit as shown above.

  7.  To expand the tree and understand the details of the processed attributes  and their values etc., click the following icon for the relevant query.
    When you observe the details, note that the value for outputData in the Event State section is null. This is because the debug point is still at begining of the query. Also note that the value calculated via the count() function is sytill displayed as 0 in the Query State section.
  8. Debug panel consists of two buttons which are Resume and Step Over. Where Resume allows you to jump into next available debug point and Step Over allows you to jump next debug point even though you do not have a debug point applied.
  9. Once you navigate to next debug point and see the details by clicking plus signs as mentioned above you can further analyse the processed attributes and its values as below. See after count() aggregate function the value has calcuated to 1.
     
  • No labels