I don’t think that you can just easily do that. If you run your microflow in a thread and you still have the reference to this thread, you might be able to interrupt it, but I never tried it and it seems to me that it would require a lot of overhead to do so.
You can cancel it at Sprintr /Metrics/Running now
As mentioned by others, there is an overview of long running microflows in the environment metrics tab. I dont think that you can get the information about the runtime of these microflows but there might be someone here in the forums who has an ace up the sleeve for it.
Aside from your question on how to terminate long running microflows I would like to add the following to this topic in case the topic is revisited sometime in the future :)
If the microflow is just blocking your users and it would be possible for you to run this task in the background, then there is a java action in the community commons module which is named ‘executeMicroflowInBackground’. This java action runs the microflow without making the browser wait for the microflow to complete.
Also it might be a good approach to batch up your task and process the smaller parts (in a queue). Retrieving loads of entries from db in one go can cause hickups
Just to add to the discussion, the Mendix monitoring API has an option to fetch a list of running requests (e.g. microflows but also XPath requests)
Hope this helps
In the Mendix Runtime I found a InterruptRequestAction. I think this is also used in the mendix cloud.
It basically looks up the corresponding thread and interrupts it accordingly.
My idea is to create a java action which calls a microflow synchronously in a seperate thread and
kills the thread/microflow accordingly after exceeding a timelimit.
This can then prevent a long running microflow from blocking a queue, due to a bug or faulty message.
Furthermore, I’ll have to see if killing a thread doesn’t produce unwanted side effects such as data inconsistencies.
Thanks for taking the time, answering my question.