I have run a thread group in JMeter in GUI mode it is working and getting results, but while running same ThreadGroup.jmx file through terminal(Non GUI] mode,I am getting an error Couldn't load .jmx file.
Can anybody suggest me how to resolve the issue.
In linux using files is case sensitive, so use exact letters(as sampleThreadGroup.jmx)
Also make sure the file is saved in the correct folder
And check your user have permission to execute it (try chmod 777 for jmx file)
Related
I am trying to write to a file using a FileOutputStream in java. I am running ubuntu and I think the problem is with the permissions. Even though the error I receive says '(No such file or directory)' I am sure the path I am giving is right, since I can read from the same file with no issues. I am not very familiar with ubuntu write permissions but I think I need to set the mode with chmod -r on the root directory. However I am not sure of the exact command and the option of permission I should set.
I'm trying to run a Vert.x Java based application on a Docker container. My application runs few verticles which it initiates from within itself.
I've put the jar file on a folder and created a Dockerfile with the following content:
FROM vertx/vertx3
ENV VERTICLE_FILE Medical-1.0-SNAPSHOT.jar
ENV VERTICLE_HOME /performit/web/vertx/verticles/
COPY $VERTICLE_FILE $VERTICLE_HOME/
WORKDIR $VERTICLE_HOME
ENTRYPOINT ["sh", "-c"]
EXPOSE 8080
CMD ["java -jar $VERTICLE_FILE"]
USER daemon
I create an image with the command
$ sudo docker build -t medical-main .
I then attempt to create a container with the following line:
sudo docker run --name medical-main -p 8080:8080 -d medical-main
This fails and the log shows the following:
java.lang.IllegalStateException: Failed to create cache dir
at io.vertx.core.impl.FileResolver.setupCacheDir(FileResolver.java:257)
at io.vertx.core.impl.FileResolver.<init>(FileResolver.java:79)
at io.vertx.core.impl.VertxImpl.<init>(VertxImpl.java:138)
at io.vertx.core.impl.VertxImpl.<init>(VertxImpl.java:114)
at io.vertx.core.impl.VertxImpl.<init>(VertxImpl.java:110)
at io.vertx.core.impl.VertxFactoryImpl.vertx(VertxFactoryImpl.java:34)
at io.vertx.core.Vertx.vertx(Vertx.java:79)
What am I missing?
Izhar
Judging by FileResolver.java, vert.x tries to create a ".vertx" directory in the current working directory by default. You have configured a user called "daemon", are you sure that this user has write access to the working dir in the docker image? If not, change the permissions as outlined in docker-image-author-guidance, or revert to using the root user.
This directory is used to serve files contained in jar files (for example web assets packaged in a fat jar). If you are not using this feature, you can disable the creation of this directory by setting the vertx.disableFileCPResolving system property to true. You can also change the location using the vertx.cacheDirBase system property.
Reference:
https://groups.google.com/forum/#!topic/vertx/7cBbKrjYfeI
This exception is caused when Vert.x tries to create .vertx (cache dir) so that it can copy and read a file from the classpath or file that's on the classpath. It's possible, the $user doesn't have permission to create the cache directory.
The reason behind cache dir is simple: reading a file from a jar or from an input stream is blocking. So to avoid to pay the price every time, Vert.x copies the file to its cache directory and reads it from there every subsequent read. This behavior can be configured.
vertx run my.Verticle -Dvertx.cacheDirBase=/tmp/vertx-cache
# or
java -jar my-fat.jar -Dvertx.cacheDirBase=/tmp/vertx-cache
Otherwise, you can completely avoid this behavior, launch your application with -Dvertx.disableFileCaching=true. With this setting, Vert.x still uses the cache, but always refresh the version stored in the cache with the original source. So if you edit a file served from the classpath and refresh your browser, Vert.x reads it from the classpath, copies it to the cache directory and serves it from there. Do not use this setting in production, it can kill your performances.
link to documentation
For me, this same issue was coming for while trying to run a jar file. It started coming suddenly and then I was forced to run the jar file as ROOT for sometime until I finally got fed up and started looking for reason thoroughly.
It happened because I accidentally ran jar file once in SUDO
privileges and the .vertx folder was create as ROOT account.
I could not figure this out initially as I was trying ll alias
command in amazon linux and sadly it does not display hidden folders
So when I was thoroughly investigating the issue next time, I also tried ls -al which showed in .vertx folder and I figured out that issue was it being created as SUDO user.
Deleted .vertx folder and jar file started working normally again as
normal user.
vert.x tries to create a cache-dir (.vertx/file-cache-someuuid) in the current directory. The given exception will be thrown if the mkdirs() call fails.
Has the user daemon sufficient rights in the workdir?
I am trying to run a .jar file from Scheduled Tasks (Windows 2008 Server) and I am getting a file not found exception. My program searches for an .xls file, converts it to a .xlsx file, extracts data, deletes .xlsx file, and uploads info to our database.
Things I've tried:
Running the program directly in the command prompt - Success
Searching for the file using dir in Cmd Prompt - Success
Putting .xls file on Desktop and Running Scheduled Tasks - Success
FileNotFound Exception throws error with correct path to .xls file
Possible Issues:
Could there be any admin privileges not allowing me to access the file from Scheduled Tasks? Why would the .jar file work from the Cmd Prompt but not Scheduled Tasks?
Thanks guys for your help. Willing to upload more information if it helps.
Figured it out! When I use T:\ in my path I am referencing a mapped drive. My scheduled task was meant to run when I wasn't logged on. Of course T:\ wasn't going to be recognized. What I really needed to use was the UNC Path! To find the actual path of your mapped drives type in "net use" into the cmd prompt.
This helped me oceans!
Windows 7 scheduled task "runs" but doesn't DO anything
I have an application (myapplication.jar) running on Windows 2003. The application was running fine few days back on this server.
I am using a bat file to execute the Jar applicatin, for some reason it stopped working on it and I am unable to find the why?
If I copied the same folder to another server where JRE is already installed it works without an issue.
Cansome suggest me how do I find what is the issue. I have already checked the file type association, delete the temporary files (java cache and temporary files in windows)
Thanks in advance!!
Without any log, exception or stack trace it will be impossible to know what is causing the problem. Open the bat file in an editor and add at the end of line that starts with:
java -jar yourProgramBundledInA.jar > yourApp.log
this is going to redirect the console to yourApp.log file. Save the bat, run it and then look up the content of yourApp.log. There should be a clue why the application is failing.
I'm setting up my first job in Hudson, and I'm running into some problems. The job monitors two repositories, one containing our DB setup files, the other a bit of code that validates and tests the DB setup files.
Part of the code that runs will throw the validated setup files at PostgreSQL, using the psql command line tool, using Runtime.exec(). This code works perfectly on my machine, but when Hudson executes it (different machine) I get the following error:
java.io.IOException: Cannot run program "psql": CreateProcess error=2, The system cannot find the file specified
psql.exe is on the path, and I can execute it by typing the whole thing at the command line, from the same place Hudson is executing the code. The file that's meant to be passed into psql exists.
Any ideas?
I find that you need to have the programme in the path when you launch hudson or the slave. Despite having the ability to set the path in hudson it doesn't seem to work. You could also put the full path in the command, which is really a good idea from a security perspective anyway.