Develop Reference

How to remove an execution data from camunda using workflows

I have a bpmn process that once starts and continues its execution forever based on the Timer cycle event. There is no end event for it.
I had recently done few changes with the workflow and made a redeployment to camunda. Since the existing processes are already running I need an option to stop it which I am finding difficult to do through workflow.
How can I stop existing execution if a new workflow started its execution? Can we achieve that using workflow itself? REST / Java coding cannot be done to achieve this.
I have another question regarding an order by query in camunda.
From the above scenario, i ended up seeing quite a few similar variables in variable table. How can i get the latest variable out of it? orderByActivityInstanceId is the only option i saw, which i feel is not reliable.

You can use other events (conditional, message or signal) to react to the situation in which you want to stop the looping process. You can for instance add an event-based sub process with a interrupting message start event to your process model.
To your second point: https://docs.camunda.org/manual/7.15/reference/rest/history/activity-instance/get-activity-instance-query/
sortBy Sort the results by a given criterion. Valid values are
activityInstanceId, instanceId, executionId, activityId, activityName,
activityType, startTime, endTime, duration, definitionId, occurrence
and tenantId. Must be used in conjunction with the sortOrder
parameter.
https://docs.camunda.org/manual/7.15/reference/rest/variable-instance/get/
is another option

To stop all the active process instances in Camunda, you can do this by calling a Camunda REST API or by Java Coding.
Using REST API
Activate/Suspend Process Instance By Id
Using Java
Suspend Process Instances
If you would like to suspend all process instances of a given process definition, you can use the method suspendProcessDefinitionById(...) of theRepositoryService and specify the suspendProcessInstances option.

Thanks a lot, i appreciate your response #amine & #rob.
I got it resolved using a signal event. Every time when a new process is deployed it triggers a signal event that will stop the recursion.
To sort the data there are options within camunda. But I had done it differently.
If there is more than one variable, I fetch them using versionTag from the process definition table.

Jmeter thread group duration

I have this situation:
Thread Group (n_threads=X,duration Y sec)
Loop
Java Sampler
When the test duration ends, Jmeter does not stop the threads that were making requests and therefore the test does not terminate. How can this be solved?

This can happen in the case when response time of your "Java Sampler" is higher than your test duration. I would recommend introducing reasonable timeout into your Java code so the samplers would fail/exit instead of waiting forever for the response. If you have no idea what's going on there - take a thread dump and see where your thread(s) stuck
As the workaround, the only way to "terminate" the test I can think of would be:
Adding another Thread Group with 1 thread
Adding JSR223 Sampler with the following code:
sleep(5000) // wait for 5 seconds, amend accordingly to your desired test duration
log.info('Exceeded test duration')
System.exit(1) // the process will exit with non-zero exit code (error), change it to 0 if needed
See Apache Groovy - Why and How You Should Use It for more information on Groovy scripting concept in JMeter
Also be aware that this code will terminate the whole JVM so it will probably make sense to add jmeter.save.saveservice.autoflush=true line to user.properties as forcibly terminating the whole JVM might lead to some results loss.

Increase the user load on runtime in jmeter

Is it possible to increase the user load on runtime.For example below is the setup
No of request = 3
No of thread = 5
Ramp-up period = 1
Loop Count = 1
Constant timer in request 2 & 3 of 3000 ms
Q1. is is possible to increase the user load 5-10 while running request 2 after wait?
Please let me know is it possible or not.
Thanks

There are 2 options of "increasing" the load during the test run:
Using Constant Throughput Timer. Despite the word "Constant" it its name the target throughput doesn't have to be constant given you define it using __P() function. Once done you will be able to amend the desired throughput using i.e. __setProperty() function while your test is running. You can even do it outside the test via i.e. Beanshell Server, check out How to Adjust the RPS in Your JMeter Test via the Command Line guide for detailed instructions
In JMeter 3.2 and higher you have possibility to add more threads to the Thread Groups during the runtime using the same "JMeter Properties" approach. Alternative option is using JSR223 Test Elements and the code like:
ctx.getThreadGroup().addNewThread(0, ctx.getEngine())
where ctx stands for JMeterContext class instance, see JavaDoc for referenced methods description.

JMeter - force all transactions/threads to stop when test reaches duration

I have a custom controller type which runs it's own specific test fragments. The important thing to note is that these fragments contain Transaction Controllers, which contain gaussian timers simulating wait times of up to 5 minutes.
The tests I am running are data driven, and should be runnable for a varying length of time. To specify the runtime of a test I have been using the "Duration" option on the Thread Group scheduler.
In the event were a test has ran beyond its duration, I've noticed that when these timer fragments are in use, the test is delayed and cannot end until the transaction (or at least the timer) has been complete. The other timings and samplers recorded seem to be unaffected, however the runtime of the test is impacted.
I'd like to solve this issue without having to rely on the user manually killing a test when it has reached it's duration. Is there any option within JMeter to kill or interrupt any type of running thread when a duration has been reached?

As per my understanding with Jmeter, there is no element which can stop the running test on reaching specific duration.
However, an element named 'Test Action' can be used to Pause/Stop/Stop Now actions on your test during run time and this element can be used under 'If Controller' element so that you can set the condition in this element to stop the thread.
Although JMeter provides various head-on elements to handle different conditions but in rare cases where existing elements could not provide direct solution to the problem then JMeter experts in any software testing company uses multiple elements with child-parent hierarchy to handle the condition [as used above with Test Action & If Controller elements]

I believe this has to do with stop test vs shutdown. When a test reaches its duration, it will issue a stop test, at which point any timer will finish, the request will happen, then the thread stops. This is why manually shutting it down works- shutdown doesn't respect timers, etc.
I don't think there's a way to set duration to use shutdown rather than stop. One thing you might try is multiple, smaller timers, and see if it still waits for all of them.

Timing out tests in TestNG

Thanks to a library upgrade (easymock 2.2 -> 2.4), we're having tests that have started locking up. I'd like to have a time out on individual tests, all of them. The idea is to identify the locked up tests - we're currently guessing - and fix them.
Is this possible, preferably on a suite-wide level? We have 400 tests, doing this each method or even each class will be time consuming.

The suite tag can have the time-out attribute. This time-out will be used as default for all test methods.
This default time-out can than be overridden on a per test method basis.

If the Suite level turns out to be the wrong approach (i.e. "too wide a net", because you end up marking too much methods with a timeout limit), you need to define a custom IAnnotationTransformer which, for each illegible function, will give you the opportunity to modify a #Test annotation (with, for instance the setTimout() method).
(setTimout(0) cancels a timeout directive)

Very late, but: running jstack -l <PID> will give you the stack dump, which you can inspect to find which calls are stuck. You might want to sample a few times to be sure they're stuck.

You can do a search and replace for "#Test" with "#Test(timeout=)"
Should work to find the locked up test and can be undone after that.