Is it possible to know if a process(Java app.) is waiting in Blocked state on a Receive() call on Linux?

Question

My main purpose is to execute processes one by one in a round-robin fashion until one calls receive() and is blocked, so that the execution switches to the next process in the queue. There is a controller application which is coded in Java and it executes these processes(which are also Java applications) using Runtime.getRuntime().exec() and keeps the return values which are Process objects.

To achieve this purpose, I need to capture the receive() calls(or their states, which is blocked) and tell them to the controller(master) application.

I can go as low-level as you want if this is possible.. My first thought was to get this information from the driver and then tell it to my controller Java application. I have written a linux kernel network module which captures the send and receive operations, but AFAIK the socket.receive() function does not tell anything to the network driver.

So, I think the options are to get this information from either the JVM, somehow get it from a linux command or so, or possibly through the linux kernel module?

What are your suggestions?

Answer 1

You should use interprocess communication primitives in your worker processes to notify the controller application that they are ready to receive data.

You can't make assumptions about how the child processes implement their socket read. They could be using recv, or select, or poll, etc., to wait for network data.

Answer 2

Have you looked at systemtap? Should be readily available on recent Fedora systems.

Best Anders

Answer 3

If you want to know if your threads are blocked, or exactly what they are blocked on, you can either take a thread dump or use a tool like jvisualvm to attach to the process and take a look (in jvisualvm you would attach to the process, take a thread dump, and then look at the activity of each thread).

Answer 4

There are actually a few points here. The Linux scheduler is smart enough to pre-empt a blocked task. Meaning, if you call receive() and there's nothing waiting to receive, your task will probably be put to sleep until such a time that the call will return. You don't need to handle the scheduling; the Linux kernel will do it for you.

That said, if you need to know whether your task is blocked from some daemon application, if you're willing to write an LKM, why not just get the task in the task list that you're interested in, and check its state?

Of course, simply checking the state of the task might not tell you exactly what you want. If your task state is TASK_INTERRUPTIBLE, it only tells you that your task is waiting on something, but it might not be a trivial matter to figure out what that something is. Similarly, your task can be in a TASK_RUNNING state and not actually be running on the CPU at the current moment (but, at least, in the TASK_RUNNING state you know your task isn't blocked).

Answer 5

I don't know if this will help you, but you could get information about the state of a Java thread on your machine using local attach.

1) Add the tools.jar to your classpath and use VirtualMachine.list() to get a list of the running JVM on you machine.

2) Attach to the JVM processed using VirtualMachine.attach(virtualMachineDescriptor)

3) Get the local connector address, vm.getAgentProperties().get("com.sun.management.jmxremote.localConnectorAddress");

4) Use JMXConnectorFactory.newJMXConnector(...) to connect to the JVM

5) From the JMX connection lookup up the ThreadMXBean

6) From the ThreadMXBean you get an array of ThreadInfos that describes all threads in the JVM.

7) From TheadInfo#getThreadState() you can check if the state is ThreadState.BLOCKED

Answer 6

You can just send a QUIT signal (Ctrl-\ on the console) to get a thread dump.