I have a server which has two JVM's and I have a class which creates dummy threads.This runs on lets say JVM A.How can I create these threads on JVM B programatically.
After some research I came across http://docs.oracle.com/javase/6/docs/jdk/api/attach/spec/index.html. I am not sure if this can suffice my requirement.
You need JVM A to contact JVM B to tell it to start some threads. You will also need to pass any data JVM B need to run and possibly pass back any results. A simple example is using RMI or RPC.
Related
I'm looking for a process pool management library, maybe with an interface similar to Python's concurrent.futures.
My goal is to open N processes to execute a task, and when one finishes, create a new one in its stead. So at any single point in time, there are N running processes.
Is there something in existence?
Ended up writing my own class.
I hope it can be of use to someone: https://bitbucket.org/snippets/dorfire/8jdLn
Say I am running a simple C program. How to know which thread is executing this program? Or Is there any way so that I am sure that my program is translated into a process and this process is again divided into threads. Very sorry for any wrong understanding of the whole concept. It would be very nice if there is an example to explain the solution to my confusion (Actually I want to ask directly how to output process id--->no. of threads , and list all of the thread id's ).How to visualize the above concepts (If they are correct BTW)
Unless otherwise stated, a program consists of exactly one thread, which is the main thread. More threads may be created by calling pthread_create (from ). You can see the exact number of threads in a program if you look at /proc/pid/status (replacing pid with the process id).
In a nutshell, think of the process as a container, for one or more threads. It is the threads themselves which execute (a thread is simply a register state), whereas the process contains the virtual memory image, open file descriptors, and other "objects".
Looking at the status file, you will see "TGID" and "PID" fields. The "PID" is actually the thread id, whereas the "TGID" is the thread group id, which is the true process id. For simple processes (those with one thread) these are equal. But for multi-threaded (2 threads or more), they will be equal only for the main thread. Anywhere but this file, "PID" really does mean the process id, as Linux imitates the UNIX standard.
Additional commands you may want to try: ps -L : this will show you the "LWP" (which is the thread identifier). You can identify multithreaded programs if you look at ps's "STATE" column containing "l" , indicating multithreaded processes.
Currently writing twisted trial tests for an multi-component order flow system that are run together in a single package.
Each test involves calls to external OS proxy objects that are used to regulate traffic - these are common across all tests being run in a package, but across different environments and executions, different ports/ip addresses may be assigned.
Using the test setUp and tearDown methods work, but require constant setting up of connections/port assignments for each test with uncertain wait times for ports to clear.
Is there a way to set up these objects when trial starts up before running the first test, maintain these objects and allow inspection of those object variables, and then allow a teardown on completion of the trial package containing the tests?
You probably don't need to do the set up when trial starts up; rather, you need to do the set up when trial runs the first test that depends on the given fixture. Since trial runs a global reactor, you can use that for your final tear-down before Trial is done.
There's an example of this in the way Calendar Server sets up a Postgres database for testing.
Use testresources:
testresources is attempting to extend unittest with a clean and simple api to provide test optimisation where expensive common resources are needed for test cases
If I want to write a java(or other jvm language script)
Maybe by doing something like caching jit results?
What about gcj compiled binaries?
(P.S. if you could explain waht techniques it uses to decrease startup time)
See https://www-304.ibm.com/support/docview.wss?uid=swg21255195 for such example.
Take a look at Nailgun: Insanely Fast Java. It runs a JVM server in the background and provides a thin client written in C to pass command line arguments and environment variables to the server process.
It means that all your scripts run in the same JVM server process, but avoids the startup overhead.
I'd like to have a small (not doing too damn much) daemon running on a little server, watching a directory for new files being added to it (and any directories in the main one), and calling another Clojure program to deal with that new file.
Ideally, each file would be added to a queue (a list represented by a ref in Clojure?) and the main process would take care of those files in the queue on a FIFO basis.
My question is: is having a JVM up running this little program all the time too much a resource hog? And do you have any suggestions as to how go about doing this?
Thank you very much!
EDIT: Another question I should ask: should I run this as its own instance (using less memory) and have it launch a new JVM when a file is seen, or have it on the same JVM the Clojure code that will process the file?
As long as it is running fine now and it has no memory leaks it should be fine.
From the daemon terminology I gather it is on a unix clone, and in this case best is to start it from an init script, or from the rc.local script. Unfortunately details differ from OS to OS to be more specific.
Limit the memry using -Xmx=64m or something to make sure it fails before taking down the rest of the services. Play a bit with the number to find the lowest reliable size.
Also, since clojures claim to fame is its ability to deal with concurrency it make a lot of sense to only run one JVM with all functionality running on it in multiple threads. The overhead of spawning new processes is already very big and if it is a JVM which needs to JIT and warm up its memory management, doubly so. On a resource constrained machine could pose a problem. and on a resource rich machine this is a waste.
I always found that the JVM is not made to quickly run something script like and exit again. It is really not made for that use case in my opinion
.