Jmeter中ctx.getCurrentSampler与getPreviousSampler返回相同请求及参数计数异常

Issue 1: ctx.getCurrentSampler() and ctx.getPreviousSampler() Return the Same Sampler #

Let’s break down why this happens and how to fix it:

• A Beanshell PreProcessor is tied directly to a specific sampler, and runs right before that sampler executes.
• ctx.getCurrentSampler() always returns the sampler the preprocessor is attached to (the one about to run).
• ctx.getPreviousSampler() is supposed to return the last sampler that finished executing in the current thread.

If you’re seeing these return the same value, here are the most likely reasons:

1. Preprocessor is in the wrong location: If you placed the preprocessor directly under a Thread Group (instead of as a child of a sampler), it applies to every sampler in the group. When the first sampler runs, there’s no completed "previous" sampler yet, so some JMeter versions fall back to returning the current sampler instead of null.
2. Only one sampler in your test plan: With no prior samplers to reference, JMeter might return the current sampler (though ideally it should return null here).
3. Loop/controller execution quirks: If you’re using a Loop Controller or similar, the "previous" sampler could be the same instance being re-run, making it appear identical to the current one.

Quick fixes:

• Always attach your Beanshell PreProcessor directly as a child of the sampler it’s meant to modify. This ensures getCurrentSampler() targets the right sampler, and getPreviousSampler() correctly references the last completed one.
• If you need a valid "previous" sampler for your logic, add a dummy Debug Sampler as the first item in your thread group to act as the initial prior sampler.

Issue 2: getArguments().getArgumentCount() Returns 0 But the Sampler is Valid #

This is a super common gotcha tied to how JMeter stores different types of request parameters:

• The getArguments() method only retrieves URL query parameters (the ?key=value pairs appended to the end of a URL).
• If your sampler uses other parameter types—like POST form data, raw request bodies, JDBC query parameters, or file uploads—these aren’t stored in the Arguments object. So even if your sampler has valid parameters, getArgumentCount() will return 0 because it’s looking in the wrong place.

For example:

• If you’re using an HTTP Request sampler with data in the Body Data or Form Data tab, those parameters live in the sampler’s body fields, not the Arguments collection.
• For a JDBC Request sampler, parameters are stored in the query string and parameter value list, which aren’t accessible via getArguments().

How to verify and fix:

• First, check what type of sampler you’re working with by printing its class name:

  log.info("Sampler class: " + ctx.getCurrentSampler().getClass().getName());
  

• For HTTP Request samplers, cast the sampler to HTTPSamplerProxy to access form data or raw body content:

  HTTPSamplerProxy sampler = (HTTPSamplerProxy) ctx.getCurrentSampler();
  log.info("Raw post body: " + sampler.getPostBodyRaw());
  log.info("Form parameter count: " + sampler.getParameters().size());
  

• If your parameters are set via variables or runtime functions, they might not be fully initialized when the preprocessor runs. Try using a Beanshell PostProcessor instead—it runs after the sampler executes, so you’ll access the fully loaded parameters.

内容的提问来源于stack exchange，提问作者NewTechie