I wrote a Java class, I made it into a runnable jar, I want to call a method in that class in a beanshell or JSR223!
I wrote a beanshell sampler, in that I imported the class and called that method, the method calls another method which has multithreading, it uses ExecutorService.
What is happening is, the beanshell is working fine, the class is imported, the method is called, the method called another method which has threads, the problem comes when the thread is started, when the thread is started, the beanshell script is not moving further, the testcase in jmeter is not stopping at all, Is it because of threads in the class in that jar?
Given you have a runnable .jar it might be better idea to run it using OS Process Sampler. So you will be able to decide whether you want to wait till the .jar completes its work or not by using underlying operating system functionality like start command in MS Windows Family or & operator or nohup command in Linux.
See How to Run External Commands and Programs Locally and Remotely from JMeter article for more details.
If you would like to continue with scripting make sure to use JSR223 Test Elements and Groovy language as currently it is the best option in terms of performance.
With regards to your "not moving further" it is hard to tell what's going wrong without seeing your Java/Beanshell code, try checking jmeter.log file for suspicious entries.
Related
I'm using Jython as a scripting engine in my Java app.
I can run any Jython script from my Java app by calling pi.execfile(script_name). But the problem is that I also need a way to stop script execution manually from Java code. How can I stop it without modifying Jython script?
I'm running a script in a separate thread, so tried to interrupt it via
scriptRunningThread.interrupt(); and catch InterrupredException, but the thread just suspend and hang... Newly created threads will be hang too
Another way - to share a common object and make Jython script to check if user wants to quit.
The 3rd way is to run a separate process (console mode of my app) and kill it when ever STOP button being pressed. But I don't like this solution...
Any suggestions?
The best way is your second idea: to have the Jython script check for a termination flag and exit cleanly if the flag is set.
If you wanted to terminate the thread from another thread, you could call Thread.stop(), but that is generally a bad idea since it could cause your entire application to hang or otherwise misbehave in certain circumstances.
I have a Java application that needs to run several times. Every time it runs, it checks if there's data to process and if so, it processes the data.
I'm trying to figure out what's the best approach (performance, resource consumption, etc.) to do this:
1.- Launch it once, and if there's nothing to process make it sleep (All Java).
2.- Using a bash script to launch the Java app, and when it finishes, sleep (the script) and then relaunch the java app.
I was wondering if it is best to keep the Java app alive (sleeping) or relaunching every time.
It's hard to answer your question without the specific context. On the face of it, your questions sounds like it could be a premature optimization.
Generally, I suggest you do what's easier for you to do (and to maintain), unless you have good reasons not to. Here are some possible good reasons, pick the ones appropriate to your situation:
For sleeping in Java:
The check of whether there's new data is easier in Java
Starting the Java program takes time or other resources, for example if on startup, your program needs to load a bunch of data
Starting the Java process from bash is complex for some reason - maybe it requires you to fiddle with a bunch of environment variables, files or something else.
For re-launching the Java program from bash:
The check of whether there's new data is easier in bash
Getting the Java process to sleep is complex - maybe your Java process is a complex multi-threaded beast, and stopping, and then re-starting the various threads is complicated.
You need the memory in between Java jobs - killing the Java process entirely would free all of its memory.
I would not keep it alive.
Instead of it you can use some Job which runs at defined intervals you can use jenkins or you can use Windows scheduler and configure it to run every 5 minutes (as you wish).
Run a batch file with Windows task scheduler
And from your batch file you can do following:
javac JavaFileName.java // To Compile
java JavaFileName // to execute file
See here how to execute java file from cmd :
How do I run a Java program from the command line on Windows?
I personally would determine it, by the place where the application is working.
if it would be my personal computer, I would use second option with bash script (as resources on my local machine might change a lot, due to extensive use of some other programs and it can happen that at some point I might be running out of memory for example)
if it goes to cloud (amazon, google, whatever) I know exactly what kind of processes are running there (it should not change so dynamically comparing to my local PC) and long running java with some scheduler would be fine for me
I need to execute a shell script in a java program. I figured out that i can use processbuilder and runtime.exec.. but my webserver times out every 180 sec but my script execution takes more than that..i do not want to use process for this approach.. is there any other way where i can use thread for this execution.
thanks.
I'm assuming that the response from the script is intended for humans to read.
Good interface design, and human nature, suggests that if your script is taking over 180 seconds to run, then it should be run separately from the web server. On linux, I would suggest putting it into 'cron', and letting it run on a regular basis. You would only serve the results of the script via the web server, with a response time in seconds instead of minutes.
If your script depends on parameters from the http request, or other information that is only available from within the web server's environment, you have the following choices.
If you can figure out the likely combinations of parameters, run the
script automatically for each combination of parameters,
again only serving the results through the web.
If the majority of the time is spent in a single command, and the
results of that command don't change much between runs, move that
command into a separate script that runs automatically, and use the
results of that separate script to build the web response.
Break the response up into segments, only showing a portion of the
data for each request, allowing the user to page through the
response. The script would be rewritten to only request the
necessary data for the current page, reducing the amount of time
needed to obtain that data.
Rewrite the script in a compilable language, which might gain you enough time to make running it for every request reasonable. However, if the problem is a database query, this won't do you any good. You'd have to go with option (3), whether you rewrote it in a compilable language or not.
Without additional information, like an example of the script, or a description of where you're getting the results from, that's the best I can do.
A process can run several threads, but they still are parts of the process.
So, all threads inside a java program are the threads of the java process, and a thread cannot run another program's threads.
A shell script is ran by a program : the shell program ! (/bin/bash or /bin/sh)
Anyway a shell script will mostly ran other programs inside several other processes.
No, you cannot run a shell inside a thread of java.
In general, if you have code that is separate from your Java program, such as code that is in a separate script, then there is no justification for why your code would execute an outside script when that code could be instead integrated into the program. It is insecure at best. Your basically allowing arbitrary code to be executed by your program since the outside script is editable. What you are doing sounds to me almost like it should be confined either a unit test or a build task.
As a unit test task and you could use a threaded JUnit runner to run your outside script during the test phase of your project.
Also, separately from your program, you could also execute it using a Gradle task and by using the parallellforks option that Gradle has.
I've a bash script that sequentially calls a java program. That's a bit tricky but mainly what i do is to have a loop and executes about 1500 times the same java program with different arguments.
My question is, when using java 1.5 (the sun VM), each time I'm calling the java program a new instance of the jvm is created ? (I'm not sure that's the right vocabulary...)
Should I avoid this situation by introducing a level of indirection, i.e building a list of all the parameters and then executing one java program which takes these parameters and executes what was previously my entry point ?
Or can I deal with the problem by configuring the JVM as resident or something like that and dynamically invokes my program....
hope this is clear....
thx...
You could save the parameters into a file and use the Java program to process it without constant restart. You could also pipe in the parameters into the running Java app through the console, similarly as for example ls | grep java
Edit: And for the first question. I doubt the java runtime would stay deliberately in memory. Probably most JRE files would remain in the disk cache anyway. On Windows there is a Java Quick Start service which keeps the JRE files around to reduce the startup time for a java program. Don't know whether there is a similar thing for *nix.
Obviously having all the parameters beforehand and running the program once after that would be the best solution. If you cannot do that for any reason i have a very dirty solution to this. Have your program register a port and listen to it for input. Then simply pass the arguments to that port and have your program handle them as a new instance.
JVM startup is notoriously slow, and it certainly not intended to be done in a loop like that. Unfortunately the only way to avoid this if you are passing command line parameters to the java program is to modify the java program itself in some way to have alternative forms of interaction (either from the console, or a port, or a read a file). Java Quick Start is the only (closest thing to a) solution if the java program cannot be changed.
The real solution is to change the Java program. The most obvious change would be to have your loop write to a file, and then start the java program that would read the file one line at a time. That works if the loop doesn't care about the results from the java program for the next set of parameters.
If it does, then it would really be necessary to understand that relationship to advise on an appropriate solution. The socket solution suggested by Savvas is certain a general purpose solution, but there may be better options, depending on what you need to accomplish.
You can use a launcher like in the answer to
Simultaneously run java programs run on same JVM? to read input line by line and start your program's main() method.
I have a program 'foo' running different threads, fooT1, fooT2, .. fooTn.
Now if I want write another program 'bar', which could kill the thread fooTr, is that possible?
Reason: One of the thread fooTr tracks product license. If this thread is killed; one may run this product indefinitely. And killing 'foo' itself is tolerable as 'foo' as that is exactly what is being done on license expiry.
System: Fedora Distribution of Linux
Note: The commands which start JVM and program foo are placed in /etc/init.d and anyone who has a decent knowledge of rc.1/rc.2/rc.3 structure can change/add the starting parameters to these.
I hope my question is clear. If not, I can always edit it.
Actually the java debugger will allow you to kill a thread by injecting an exception into it. I was just trying to work out how to use this feature to kill a thread without wiping out the whole jvm, when I came across this question. If you run the jvm with command line options like:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8888 your.app.Main
and connect the debugger with something like:
jdb -attach 127.0.0.1:8888
you can type:
threads
to get a list of the running threads, and use the kill command to kill a running thread. The bit I'm currently not sure about is the syntax of this kill command, I have tried the obvious:
kill 0xe2e new java.lang.IllegalArgumentException("er");
and I get the messages:
killing thread: Swank REPL Thread
Thread not suspended
Expression must evaluate to an object
("Swank REPL Thread" is the thread I want to kill, and yes, I've tried suspending it first ;)
Still my inability to use the java debugger aside, it looks to me like a thread can be killed at random. Maybe you can just make sure you ignore all exceptions and keep running and that will be enough, but I'm not sure about that.
To my knowledge it is not possible to do this directly. What you could consider however is to create some kind of service on your 'foo' that can be called from 'bar' to kill the thread. There are, of course, hundreds of ways to implement this. My first thought would be to do this using RMI.
You could do this even without a separate application. Write your own startup class, which performs a pass-through of parameters to the original startup class of the application. Your class's main method though would create a thread that periodically checks the list of all threads (e.g., Thread.getAllStackTraces or Thread.enumerate), finds the offending thread, and invokes stop() on it. Although Thread.stop is deprecated, it still works.
Another option is to run the application under a Java debugger, say, jdb and then suspend/kill the required thread. You could also add parameters to the application's startup so that the JVM can be attached to, then attach jdb to the running JVM and suspect/kill the thread.
Until now isn´t possible to run to diferent programs in the same JVM, but some people is investigating it, in order to reduce the startup time and the memory and cpu usage of diferent java programs runing in the same machine