Bug 62390 - jmeter threads use overloaded run method but not CachedThreadPool
Summary: jmeter threads use overloaded run method but not CachedThreadPool
Status: RESOLVED DUPLICATE of bug 49974
Alias: None
Product: JMeter
Classification: Unclassified
Component: Main (show other bugs)
Version: unspecified
Hardware: PC Mac OS X 10.1
: P2 enhancement (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-20 21:25 UTC by Srijon
Modified: 2018-05-21 10:10 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Srijon 2018-05-20 21:25:37 UTC
jmeter threads use overloaded run method to implement multithreading. This makes it impossible to pause/restart the threads. Implementing threads by using CachedThreadPool will make it possible to pause/restart the threads.
Comment 1 Srijon 2018-05-20 21:38:21 UTC
/* 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);
        
    }
Comment 2 Vladimir Sitnikov 2018-05-21 05:16:59 UTC
@Srijon, would you please clarify what do you mean by "pause/restart the threads"?
Comment 3 Srijon 2018-05-21 05:33:07 UTC
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.
Comment 4 Vladimir Sitnikov 2018-05-21 05:36:12 UTC
>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.
Comment 5 Srijon 2018-05-21 05:43:46 UTC
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.
Comment 6 Felix Schumacher 2018-05-21 10:02:44 UTC
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.
Comment 7 Philippe Mouawad 2018-05-21 10:10:03 UTC
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 ***