2

UPDATE: I attached the test script. The two substitutions not being honored are at CSV-DATASOURCE (the filename) and in the main thread group (number of threads): test plan file

This is starting to drive us crazy. Using Jmeter 3.3 r1808647. Property substitution seems to completely fail, but only when the test is ran remotely.

I've tried many different ways, the latest looks like this:

  1. in the setUp Thread Group, I'm defining some user variables using the Config element/User Defined Variables. Literal values work, but ${__P(globalPropName)} is substituted correctly in the local test, and remains the string ${__P(globalPropName)} in remote tests. This is obvious with using debug samplers.
  2. but in the result of the very same debug sampler, the property exists and has a valid value, so it's not the -J/-G problem.
  3. since variable substitution doesn't work, I can't use default values either.

I've tried using the substitutions directly in some items, like Number of Threads, but then the whole thing doesn't work as there is no substitution.

Funnily enough, simple variable substitutions like ${varname} work. Anything fancier does not. It's as if in the remote run the string parser is dumbed down on purpose.

Any ideas how to solve this?

Kemény András
  • 51
  • 2
  • 5
  • Can you show result of debug sampler with property? Does you jmx work with previous version? – Ori Marko Dec 11 '17 at 15:55
  • We don't have the option to work with Jmeter 3.2, so we're stuck with 3.3. The debug sampler shows the correct entries under JMeterProperties: – Kemény András Dec 11 '17 at 16:05

2 Answers2

2

So it looks like a misconfiguration in how the remote server is started up.

The batch file (we're talking Windows here) goes like

"C:\apache-jmeter-3.3\bin\jmeter.bat" -s -Dserver_port=1098 -j "C:\ows\jmeter-service-ows.log" -d "C:\ows"

...since all the miscellany files (source CSVs, result files, logs) should reside in C:\ows. But it turns out that Jmeter gets confused about its libraries then.

When the batch file looks like this:

"C:\apache-jmeter-3.3\bin\jmeter.bat" -s -Dserver_port=1098 -j "C:\ows\jmeter-service-ows.log" -d "C:\apache-jmeter-3.3"

...the test runs fine, with all substitutions working.

I've checked the logs and the WARNings about Jmeter not being able to find any functions in the CompoundVariable class and in the first case they found none, in the second they find 'em all.

I'm actually suspecting a bug as this test uses an additional external library (gson) which is situated in the same folder as the missing culprit (jmeter.functions or stg like that), and that particular library loaded just fine in both cases. What do you think, should I report this bug?

Kemény András
  • 51
  • 2
  • 5
1

  1. Make sure you pass your globalPropName property from the master via -G command-line argument like:

    jmeter -GglobalPropName=foo

  2. Make sure you configure remote slave(s) to write log files like:

    jmeter -s -j slave.log
  3. Make sure you have ApacheJMeter_functions.jar under "lib/ext" folder of JMeter installation on slave machines. If your test works fine locally I would recommend just copying your "working" JMeter instance to the slave hosts over the network.

I can state I cannot reproduce your issue using the same JMeter version, try the same test plan and commands as outlined below and if it works - amend your setup accordingly

JMeter Remote Properties

References:

Dmitri T
  • 159,985
  • 5
  • 83
  • 133
  • 1-2-3 are already like that (there are a few more cmdline switches but basically i'm doing what you've suggested. still no luck. thing is, these are windows 7 enterprise machines, and one machine is the master, and 8 more machines are slaves. all slaves use nssm-based jmeter services to run the slave servers on port 1098 (port 1099 is reserved for 3.2 instances which are still being used on another projects). the home dir for the services is c:\ows, where the logs and the source files (like the .csv it's referring to) reside. so the unfathomable thing is... (cont.d) – Kemény András Dec 14 '17 at 16:41
  • ...that when i do a standalone test -- WHICH WORKS PERFECT -- i run the same instance of jmeter 3.3 on one of the slave machines, just not remotely, but in GUI mode. the test runs flawlessly. the only difference is that with the slave servers, the whole thing is wrapped in nssm as a service. but it's the same installation. same instance. and simple substitutions (like values from the CSV file as post parameters) work. only props are not available. – Kemény András Dec 14 '17 at 16:43