I am using visualVM to monitor my java program, started within eclipse.
I am using quartz scheduler and have 2 worker threads, so there are 3 threads for quartz.
I have another thread running listening to a socket.
Then I have a thread pool with 50 threads.
But it shows there are total 164 live threads with 110 are deamon threads.
I saw there are dataStreamer. Does java have a thread to handler data stream?
I also saw there are many PesponseProcessor for block blk_...
What does those threads response for, and witch kind of block it point to?
Please note VisualVM will launch 5 threads of his own for the RMI communication and serialization of thread dumps. You can completely ignore those.
Related
The question
The software runs on one DELL server with Linux.
Language could be C++, JAVA or Python.
Both thread A and thread B assign tasks to the service thread. When receiving tasks, service thread will put the tasks on its own task queue. When thread is free, it will execute the tasks and return task results to thread A or thread B depending on who sent request.
Thread A has a higher priority than thread B.
My thoughts
It is very similar to server/client in socket programming. However, since this software runs on one same server, TCPIP does not seem a good solution to me.
Another thought is to use a common database for this, such as redis. But Redis runs also on TCPIP and I am not sure if this could be a good fit.
Someone also suggests using a service DLL and both Thread A and Thread B can invoke service DLL directly. However I do not have experiences building DLL simultaneously serving several threads. Is this possible?
My question is: how to achieve this in a suitable way?
Recently I've been learning more about thread and I was wondering why the resource monitor shows always 19 threads running for the Java process.
Now my questions are:
Is this the VM using 19 threads?
If so:
Are you able to access those threads?
Is it possible to use these threads for thread pooling?
Is it possible to decrease the amount of threads?
If not:
What is causing to show up the 19 threads?
I created a small .jar (see bottom for source) that would run and create a fixed threadpool of 5 worker threads. To that pool I sent tasks and I noticed that after all tasks have been handled, the amount of threads java uses goes back to 19.
Are the threads in the fixed threadpool idle or have they been removed and thus new threads are being created whenever new tasks are submitted?
Sorry for the multiple questions in one post.
Link to source: http://pastebin.com/iXpLbFVF
Image while sending tasks: http://gyazo.com/223d720bf73c1b919fbfe0b69088838a
Image after sending tasks: http://gyazo.com/3147269d90eb2c916373220ef53c0b92
It depends on the JVM version, the JVM vendor and some settings like which garbage collector is in place (and how the GC is tuned). Also some add-ons like agents or JMX can change the system running threads. And of course all threads started by the actual Java program. You can use the jstack program to actually list them (most of the system threads have obvious names). They include threads for finalisation, GC, the main thread, the Gui threads (if used), also JIT Compiler Threads and reference weakeners.
I have an application which just uses ExecutorService.newFixedThreadPool(), and everything runs fine on our development machines (multicore Intels mostly, also runs fine on a 6 core AMD). But when we run it on our server (Opteron CPUs, 64 cores total) and the thread pool is limited to, say, 4 threads, sporadically something weird happens and the program starts using 48 cores.
There is nothing but a main thread and this ExecutorService which should be limited to N threads, so there should be no more than N+1(main)+X(some java services) threads, but definitely not 48+.
Any suggestions on what might be causing this behavior are highly appreciated.
I'm not posting any code here, because we were not able to reproduce this in any other environment, than this server and there's nothing special about the code. It's just the fixed thread pool, on which Callables are run in batches (each batch no more than the size of thread pool) and the results are collected from Futures before submitting the next batch of tasks.
Looks like you're using a parallel garbage collector. See here: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2009-January/000718.html
From that answer, it looks like you'll have 40 threads of GC, plus your application threads. So that's probably what's happening.
Check this out: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html -- in particular set XX:ParallelGCThreads=n
If it helps ... I had this exact same thing happen to me, except the container monitor killed my process for excess thread usage. Oh HP-UX, how I (don't) miss you.
I'd like to use quartz in a project of mine. I know that there is a scheduler and a threadpool for the jobs.
Does the scheduler continuously run in its own thread and fires off the jobs?
If I run the app on a 2 core CPU will one core be busy with the scheduling thread?
Yes, quartz uses at least n+1 threads where 1 is the scheduler thread that is running in an infinite loop sleeping before next task that should be triggered. N is the number of worker threads in the threadpool. You can configure this number using the property org.quartz.threadPool.threadCount.
You can see it work by running the stuff through for example Eclipse and then in the debug view you can see the active and sleeping threads of the application.
Quartz will create a configurable pool of threads. Each job will fire in its own thread (of course, otherwise they can't run concurrently). And no, its not a busy loop so the scheduler won't claim a CPU for itself.
is Eclipse 3.0 Jobs API using any internal thread pool for executing jobs?
or is it creating a new thread each time a job is scheduled (about to be started)?
if it doesn't use any thread pooling, is it somehow possible to use Jobs with Java's ExecutorService so that scheduled jobs will reuse existing threads from the Executor's pool?
if not then last question, is there a chance to provide progress feedback in the Eclipse progress view (as I'd do with Jobs IProgressMonitor) but from within a regular Java Thread?
I really like the features Jobs API provides (especially progress monitoring and cancellation) but I'm a bit concerned about the overhead it may introduce to the main UI thread if it doesn't use thread pooling and the jobs are scheduled really often.
thanks in advance!
regards,
jb.
Eclipse Jobs do use a fixed number of worker threads. Jobs are allocated to these worker threads, based on the priorities.
I cannot find any documentation stating that, but if you start your Eclipse instance in debug mode, you can see some worker threads in the thread list - these are the threads jobs are executed in.