I'm running JMeter test via cmd and I want to stop the test/shutdown as I do in the GUI mode, but I cannot do it.
I enter the bin folder and double click shutdown.cmd/stoptest.cmd but I keep receiving this error:
Error: Could not find or load main class testing\apache-jmeter-3.0\bin\ApacheJMeter.jar
n.b. There is no folder 'testing' in my path. the path is like this:
C:\Load testing\apache-jmeter-3.0\bin
The majority of developers know only a little bit of SDK of one programming language and suck at everything else, particularly here you are suffering from badly written batch file.
The fastest workaround is renaming your "Load testing" folder into "Loadtesting". Going forward when it comes to Java if possible put the application under the path which doesn't contain whitespaces, non-English characters, special symbols, etc. just in case.
The fix is to surround the path to ApacheJmeter.jar with quotation marks like:
java -cp "%~dp0ApacheJMeter.jar" org.apache.jmeter.util.ShutdownClient Shutdown %*
If possible please report the issue via JMeter bug tracker
In general well-behaved JMeter tests don't need to be shut down, they should end after specified amount of loops or according to Thread Group Scheduler or whatever. If the test last longer than expected it indicates that something went wrong. Make sure you're following steps from 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure article and your JMeter instance(s) are configured optimally.
Related
When you try to run a program on Windows, and the loader can't find all of the required DLLs, the default behavior is to pop up a dialog box that describes the problem, including both the name of the program and the name of (one of the) missing DLLs. The process then hangs until someone clicks OK, and then exits with an error code. Here's an example of this dialog box:
Now suppose you're scripting some automated process that might fail for this reason, e.g. running CI tests after installation, where part of the point is to make sure the installer installs all the DLLs. You don't want your build workers to hang waiting for someone to click on a dialog box that's being displayed on a monitor that the computer physically does not have because it's in a server rack somewhere. You want the test cycle to stop immediately and the details to get written to the log.
Your build driver can disable this dialog box for itself and all its child processes (assuming nobody uses CREATE_DEFAULT_ERROR_MODE) by calling SetErrorMode:
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX | SEM_NOOPENFILEERRORBOX);
hProc = CreateProcess(...);
However, this only solves half of the problem. The offending process will terminate with an exit status of 0xC0000135 (STATUS_DLL_NOT_FOUND), but the name of the problem executable and the name of the missing DLL are not reported anywhere that I can find it.
So here's the actual question: From code running in the build driver, how do I get the name of the problem executable and the name of the missing DLL, so that I can write them to my CI build logs? Anything goes, except that the code of the problem executable itself and its DLLs cannot be modified (because this is supposed to be a general solution) and an approach that does not require elevated privileges is strongly preferred.
(This is a follow-up question for Suppress "The program can't start because X.dll is missing" error popup . I've been vaguely meaning to write it for years now.)
Even though it's a little overkill, you could write a program/script that parses the PE format of each executable, walks its import table to enumerate imported modules, and checks to see if each module exists on the system (i.e. is it in \Windows\System32, the current directory, etc).
Then, if the executable in question is missing an import, log the executable and the missing import somewhere (and don't run the executable, of course).
If you want to do this in Python, the pefile module is excellent (https://pypi.org/project/pefile/).
(Update: This won't work for DLLs that are imported via LoadLibrary)
I have a solution where I am running various load test scenarios via the command line for Visual Studio 2017. I know I can use MSTest to do this, and am using /testcontainer arg for picking which .loadtest file, and the Set Test.UseRunSetting= WhateverRunSetting arg to pick which run setting I want (controller duration, context parameters, etc).
I can't seem to find a way to change the Step Load Pattern from command line, however. This would allow me to, from the command line, set things like ramp up time, max users, initial users, and other flags. The other way I can think to do this is if I can say which scenario to run (instead of all scenarios in the .loadtest file) based on a command line arg.
Well, the route I used was to write a Powershell script that accepts the parameters I want, such as initial users, step duration/ramp time, context parameters, max users, etc. Then takes those and edits my .loadtest file (since it's an XML file) and saves the .loadtest with the edits, including setting it as the active run-setting.
Then using MSTest as noted above, I can make sure that run setting and .loadtest is used and kick off my test(s).
Another way to do this is use of plug-ins. You can create a plug-in in your load test. The plug-in will read the external excel or xml file to control the user load. You can modify the excel or xml through automation.
I have same thought as yours for modifying load test files externally. Never thried though.
I am running the Xunit Test cases as mentioned in my previous question.
How to get passed and fail test case count in xunit using cake(c# make) script
While running the test cases, most of my test cases are failed while trying to access a file from my AppDomain.
The test cases are succeeded in Visual Studio.
From the Error log, I can see that it tries to read the file from Xunit console runner location instead of application location.
Note:
I am using NoAppDomain of Xunit2Settings as false.
When working with unit tests and files, I would recommend first to see if you can avoid using the actual filesystem by using data in memory or assembly resources. That way parallel execution, filesystem locks or similar environment related things won't be an issue.
So if you have the opportunity to refactor the filesystem out of the tests (unless that is what your testing) I would go that route first.
One way to work around the issue you're having is to use absolute paths, you could achieve this by in your tests utilizing the test assembly location and then Path.Combine the relative path to that. There's a good StackOverflow answer explaining on how to get the path of your assembly:
https://stackoverflow.com/a/52956/5883153
A quick fix you could try is using the Xunit2Settings WorkingDirectory to set same current dirrectory as VisualStudio, but that isn't something I've testest or recomend.
I have an Java jar that I've wrapped up with YAJSW for running on Windows. The service installs, starts and ends beautifully. Unfortunately, the jar leaves behind some files that muck up clean restarts. Before YAJSW, these files were cleaned up by a batch script. I have that same small script that cleans up those errant files. I've read over the documentation and configuration parameters for YAJSW and for the life of me, I can't find a clear explanation for how to get my cleanup script to run.
Excerpt from current wrapper.conf
wrapper.script.STOP=bin/stop_ic.gv
The cleanup script cited above doesn't seem to execute because the files are still around.
There are a couple of references to stopping Tomcat services with an extra conf file but when I read through those docs, it doesn't make sense to me what's happening. I've also found references to wrapper.stop.conf and wrapper.stopper but I don't know how to use those parameters.
In the configuration parameters link, there's a large entry for 'wrapper.script..' listing out the various states and how to get scripts to execute when entering those states.
Also, getting the paths right to the script you want to run is important. Relative paths are from the root of the YAJSW folder (which I suppose is obvious but worth stating).
Edit: Removed assertion that shell/batch scripts couldn't be run. I'm not sure where I got that idea.
EDIT: This is due to stupidity. It is a multiple monitor issue. It's just that from cmd.exe we always opened in the primary monitor, whilst from explorer, we always opened in the secondary. Thanks all for the help!
We hit a weird bug recently. We have a Qt + osg app that behaves differently if we run it from explorer than if we run it from a command line. Running from explorer is unusable, while running from command line (or by running from the explorer a simple batch file that calls the .exe) works as expected.
We suspect environment variables, because that's all we can think of. But the fact that it runs fine with a one line batch file seems to refute this. I'm not familiar enough with windows to know of any subtle differences in how it loads executables, nor where to look to find out.
Are there any other differences that could explain this? Does windows load different sets of user environment variables in each case? OS is Windows XP Service Pack 3.
The behavior experienced when running from explorer (double click program.exe) is consistent with a driver issue or improper OSG scene setup: image artifacts, flashing, and weird colors.
The behavior experienced when running the same executable from cmd.exe (or by double clicking a .bat file next to the .exe containing only a line to run the .exe) is the correct, expected behavior: the scene is correct, no flashing, etc.
To rule out potential library load path issues, try using dot-local DLL redirection.
Towards that end, create an (empty) file in the same directory as your executable and give it the same name as your binary, except with .local appended. I.e., if your binary is named yourbinary.exe, name that file yourbinary.exe.local. That will force the PE loader to first look in that directory to resolve LoadLibrary calls (and that includes DLLs loaded indirectly via system DLLs or via COM, no matter how many indirection levels are involved.) Place as many supporting DLLs (including Qt DLLs) in that directory. If you're using Qt plugins, also place the plugins directory there (or use a custom trolltech.conf.)
More details on dot-local redirection here, for example.
This thread looks like it might have the answer to your question:
http://forum.soft32.com/windows/Start-Run-Command-Prompt-ftopict353085.html
In short, I think it might be looking for your executable in different places depending on which method you attempt to use to run it. Perhaps you have 2 different versions hiding somewhere that explorer uses instead of the one you want?
You have not given enough details so I will give you a general answer. In order to use QT and its tools you need 2 environment variables. *QTDIR, and PATH * Make sure you have these variables set instructions are below. I have taken them from this site. See also this link for deployment on windows.
Setup the QTDIR environmental
variable.
1) Create a new System variable
called: QTDIR
a. Right click on My Computer -> Properties -> Advanced Tab ->
Environment Variables button
b. Find System variables -> New -> Type in "QTDIR" 2) Set the value to: C:\your\Qt\directory (NOTICE: No
trailing '\' character!!!)
Now, add the QTDIR on to your PATH
variable.
1) Edit your PATH variable, add onto
the end of it a ';' if one isn't
already on the end. 2) Now add on:
%QTDIR%\bin;
Example:
Before
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;
After,
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%QTDIR%\bin;
That will make sure that our Qt
application(s) will be able to find
the Qt DLL files when you go to run
it.
I hope this helps.
Perhaps there is a difference caused by the way Explorer launches an executable vs directly running it from the console. I think that Explorer uses ShellExecute or ShellExecuteEx and I doubt that executing an application from a console or batch file does the same.
I would create a test app that tries some of the ShellExecute variants and use different parameters to see if the Explorer behavior can be reproduced in order to try to diagnose what parameters passed to ShellExecute might be causing the problem.
There is an interesting community note on the ShellExecuteEx page that may or may not be applicable:
ShellExecuteEx ignores the current input desktop. It always uses winsta0\default. Instead use ShellExecute or CreateProcess.
I would also investigate whether or not AppCompatFlags affect console executed applications (or see if any AppCompatFlags have been set for your application).