/* This is the original way multithreading was implemented in jMeter by implementing the Runnable interface

    public void runTest() throws JMeterEngineException {
        if (host != null){
            long now=System.currentTimeMillis();
            System.out.println("Starting the test on host " + host + " @ "+new Date(now)+" ("+now+")"); // NOSONAR Intentional
        }
        try {
            Thread runningThread = new Thread(this, "StandardJMeterEngine");
            runningThread.start();
        } catch (Exception err) {
            stopTest();
            throw new JMeterEngineException(err);
        }
    }
    
  */
  
  /*This is the proposed way to implentation using executors, this will allow jmeter threads to be paused during execution*/
  
      @Override
    public void runTest() throws JMeterEngineException {
        if (host != null){
            long now=System.currentTimeMillis();
            System.out.println("Starting the test on host " + host + " @ "+new Date(now)+" ("+now+")"); // NOSONAR Intentional
        }
        
        ExecutorService execService = Executors.newCachedThreadPool(); //using newCachedThreadPool to implement multi-threading in jMeter
        execService.execute(this);
        
    }

@Srijon, would you please clarify what do you mean by "pause/restart the threads"?

In the commercial tools that I have used, after starting a test with 100 threads(virtual users), if I see too much load on the server then I am able to pause 50 threads. On pausing the threads, the threads stop generating load. Then once I feel that the server is performing better I can restart the 50 paused threads.

This gives a lot of flexibility to the performance test engineer, to tune the load when he/she does not know what is a good load. Or if the server is not functioning properly then he/she is able to reduce the load instantly without having to stop the test entirely.

>if I see too much load on the server then I am able to pause 50 threads

That is interesting.

However I do not see how the proposed changes correlate with the "pausing/resuming threads on the fly" feature.

Pausing/restarting is not fully implemented. I could not find a way to implement pausing/restarting with the way threads is currently implemented in jmeter. Current way jmeter threads are running in fire and forget mode, this will execute load test fine, but cannot be paused.

But because there is lot of code written around this fire and forget mode of multithreading, I want to just introduce CachedThreadPool in the first iteration. If there are any complains from users it can be rolled back. There are other ways to implement multithreading also which will support pausing/restarting. This is my thinking, so I just tried to make one change.

But somehow build is failing, I am still not used to jmeter build process and trying to understand the code and test cases around it. If you can help please do.

JMeter depends on the current threading model in a lot of places. It basically treats one thread as one user and has done this for a long time. Plugins might depend on this feature by using ThreadLocals (JMeter internally does this in a few places).

So this is not an easy task.

If you want to pause threads you could implement this by using a PreProcessor with some sort of pausing functionality based upon the thread id or the current running threads.

Hello,
Marking as duplicate of Bug 49974.

If you want help on implementing feature, you should start a discussion on dev mailing list with your ideas, and proposals, we'll be happy to help.

If you're new to JMeter code base, starting with the Threading Model is not the good way to start IMO as it is complex and critical.

I'll add comments on other bugs.
Regards

*** This bug has been marked as a duplicate of bug 49974 ***

This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/4785