Automated killing on long-running threads

Just curious to hear if there was anything on the Pulse roadmap related to the automated terminating of certain running threads. Pulse does a great job in identifying (and emailing us) when a thread is running past defined time thresholds. This will trigger us to go into Pulse and make a judgement call on whether to kill the culprit thread. In most cases, we will manually use the Pulse UI to terminate the thread that has been running the longest and potentially causing a lock.

It would seem that these steps could be further automated by having Pulse automatically send the request to terminate a specific thread that runs past a defined time threshold. Obvious the parameters around the “kill” threshold would need to be customizable/robust (e.g., non-system threads > 30 min) to avoid unintentional terminating threads.

Interested to hear if anyone else has seen a need for this and happy to put in an enhancement request!

Hi @weiview,

Which version of Pulse are you using? The current Cancel threads has these filters,

image

Which should help with the above scenario.

Cheers!

Paul

We have this config in our client and it works perfectly:

Thanks guys, I totally missed this feature! (I hadn’t looked closely at all the alert types since I had thought that Alerts only contained email alerts)

Is there any documentation on the syntax that can be used in the “Filter” field? From @monder example, it handles all MDX queries taking > 60 seconds (likely to be triggered by users in Arc/Apliqo creating large cube views). Is this essentially a wildcard field that checks if the “Function” column contains the text string? For example, if we want to cancel a particular TI that runs over XX seconds, we can put something like:

api/v1/Process('TI_Name')/tm1.ExecuteWithReturn

Hi @weiview,

On the above, yes. It is automatically interpreted as like a wild card field.

Cheers!

Paul

@plim sorry to revive this thread after 1+ years but does the “Filter” field support regular expressions as the syntax? Namely, we are trying to set up a filter that excludes more than one TI process so we wanted OR logic.

Is a syntax of /api/v1/Processes('process1')|/api/v1/Processes('process2') supported or is there some other way of indicating this to Pulse? Thanks!

Hi @weiview,

No worries! It only supports the asterisk(*) character - though you can just split the above up into two(2) alerts instead.

Cheers,

Paul

Thanks for your suggestions @plim! To clarify, to exclude multiple TIs from “Cancel Thread”, we could either:

  1. set up 1 alert w/ the “Exclude” field being /api/v1/Processes('process1') * /api/v1/Processes('process2')
  2. set up 2 alerts w/ each having one TI called out in the “Exclude” field

If we do (2), would Pulse always interpret multiple alerts as AND rather than OR logic? Namely, that it would join all the alert conditions together before deciding to Cancel rather than evaluating each alert separately.

Hi @weiview,

If that is the case, then how about just modifying the names of these TIs that you want to exclude to have the word exclude or ignore for example? That way, you can specify process with certain keywords in their name to exclude them using one alert instead of two.

i.e.

  • process1ignore
  • process2ignore

Then filter could be just *ignore*

Cheers,

Paul

@plim thanks for your reply and suggestion! We had considered renaming the TIs but ideally would want to avoid doing so unless there are no other better options.

In this situation where we want to exclude multiple TIs from Pulse “cancel thread”, would neither of your earlier suggestions not work? Thanks!

  1. set up 1 alert w/ the “Exclude” field being /api/v1/Processes('process1') * /api/v1/Processes('process2')
  2. set up 2 alerts w/ each having one TI called out in the “Exclude” field

Hi @weiview,

As for item 1, the asterisk(*) works in that it matches alphanumeric characters. Combining that with a word means Pulse will match the whole word on it plus any where that asterisk is in place. So given expression that you have in item 1, it means it looks for a TI or expression that starts with /api/v1/Processes('process1') and ends with /api/v1/Processes('process2') as an example.

Depending on how the names are, how about,

/api/v1/Processes(‘process*’)

As for item 2, this seems like it may not work as it will just trigger the other alert.

It should be excludable if it can be differentiated compared to the other TI names.

Cheers,

Paul

@plim thanks for the additional clarification! Sorry I misunderstood earlier, but it seems that the asterisk (*) actually functions as a wildcard. If the TIs that we want to exclude has a consistent naming scheme (e.g., ends with “.excludeFromPulseKillThread”), we could do something like

/api/v1/Processes(‘*.excludeFromPulseKillThread’)

But if we want to exclude two (or more) TIs without renaming, it seems that either method wouldn’t quite work. Thanks for explaining Paul and maybe I’ll put in an enhancement request later!