To help you understand how the product works and how it’s using your Jira, starting with version 3.2.0 we added the ability for you to see all the incoming and outgoing requests we make. I/O traces are important because it will allow you to understand the I/O we’re doing and to improve the performance of your scripts.
Traces are not enabled by default because the engine is tailored to performance and we’re terrible when it comes for optional features which consume memory. You will find them here:
Enabling traces is as simple as pressing on that toggle:
Executing some script will add a lot of information to this screen; for instance, executing the following script from the SIL Manager:
string newKey = createIssue("TEST", "", "Story", "This issue was created by SIL"); //basic example of creating an issue
if(newKey != null) {
//some additional changes to the issue after it is created.
%newKey%.assignee = currentUser();
%newKey%.labels += "sil_ticket";
}
Will yield the following information:
First, you will see the ID of the execution ( 8 ) and the timestamp. Within this, on thread pool-9-thread-2 you will see the creation of the issue (the first POST request), then the update (the PUT request). Execution for the script itself is over (you notice the collapsible rows), but the Power Scripts still has work to do
Because of the update, the issue is then refreshed (there may be other side-effects, from other addons), and after that, the issue is passed into the indexing thread (thread-3) because it seems we have configured some JQL keywords and standard properties, where it is checked for attachments, issue links and comments (with subsequent updates) then we got to a custom property and we execute another SIL file (slen.sil) and store that JQL property as well.
Notice that slen.sil didn’t create any extra call to Jira, otherwise it would be shown as a collapsible section of that table. Indeed, the code in that file reads as:
return length(summary);
When running a SIL file in a context, we mark the issue the SIL is running, in our case slen.sil run in TEST-10374 context.
All above are product initiated requests, but you would expect to be Jira-initiated requests as well and you wouldn’t be wrong:
The creation and update of the issue has triggered 2 Jira webhooks 1 second apart, and in our particular case we didn’t have any work to do on those Jira webhooks, so we returned immediately. The threads names tells us that there’s a http request involved.
Management of traces
We keep in memory the last 250 traces. A trace is defined as the initiating call, so that trace may contain thousands of actual calls (incoming and outgoing), as we tried to show the call from head to toe. Because of that, it may consume, especially in cases of long operations, an obscene amount of memory.
You can only filter and search the traces that are in memory.
At times, we save the traces as json files in the logs directory. You can download and check them or you can pass them to us for interpreting. Very long traces may be overlapping in multiple such files.
The traces will be set to off each time you reboot your SIL Engine to prevent it from an infinite cycle of running out of memory for traces data.