Develop Reference

org.eclipse.jdi.TimeOutException

I am facing this eclipse error while debugging:
org.eclipse.jdi.TimeOutException: Timeout occurred while waiting for packet 220 occurred creating step request.
I googled a bit and also checked it on stackoverflow but have not found any solution. I am working on Mac OSx and using Eclipse Kepler but I get the same error on Windows 7 with Eclipse Mars. I am using Java 1.8.0_25, 64-Bit Server VM (build 25.25-b02, mixed mode)

I was also facing the same eclipse error while trying to debug the multi-threaded program code. Reducing the number of break points allowed me to debug the code without any errors. I believe there is some limit to place the debug/watch points in eclipse (w.r.t stack memory).
Increasing the Java stack size could be other solution. Info can be found here.

It seems this problem has been mentioned on the Google Code forums:
The problem seems to occur because the tick [producer] thread doesn't play well with the debugger.
It's suggesting that problems occur with the debugger when you have 2 threads (a producer and a consumer thread), and you attempt to suspend the consumer thread.
The workaround:
If you put a breakpoint to pause the tick thread, then you can step through both test threads nicely.
This suggests that you should set a breakpoint within the producer thread (not the consumer thread). Apprently the timeout occured when putting a breakpoint on the consumer thread, and putting a breakpoint on both threads caused an IllegalStateException.
I hope this helps!
The idea is to block the producer thread, which forces the consumer thread to wait (assuming it's blocked while waiting for data, not polling). You can then resume the producer thread, which resumes the consumer thread for that "tick". The producer thread goes back to waiting.
Apparently, it takes 2 of these cycles to represent 1 "tick", as suggested by the person who found the workaround:
When they're both blocked waiting for a tick, you can release the tick thread until
one of the test threads is released, and then leave the tick thread blocked again
until you need the next tick. It seems to take two cycles of the tick thread to
advance one tick.

Daemon Thread is still alive after closing the app

I'm just testing with an almost empty android project.
I created a daemon thread in the Main Activity.
Started the app, and pressed the back button on the phone to close the app.
But the daemon thread never dies.
Daemon Thread works really well with an empty JAVA PROJECT.
But with android, doesn't work.
I searched for the solution for hours but only got this.
A daemon thread only runs as long as there are non-daemon threads
running. When the last non-daemon thread ends, the runtime will exit.
This is not normally relevant to applications with a UI.
Does anyone know how to solve this?
PS.
I stopped the app not by pressing the hardware back button but by pressing the 'Force stop' button in 'App info', and both of the app and the thread are gone!
I first learned about Daemon Thread from some example codes for android develoment.
But nobody mentioned about what I've experienced.
Do android developers just believe Daemon Threads will be killed for sure?

But the daemon thread never dies.
Presumably, you did not cancel() the thread. You need to do this at an appropriate point.
But with android, doesn't work.
It works just fine. It works the same as in Java, as you can tell by reading your quoted passage. The difference is in how long your process lives and in the threads in that process (Android processes have other threads besides ones that you fork).
Does anyone know how to solve this?
Call cancel() on your thread at an appropriate point.

Pressing back button does not close the app (assuming that closing means process termination). That only finishes an activity but process is still running.
To achieve desired behavior you can use eg. AsyncTask and call cancel() from appropriate callback of your Activity eg. in onDestroy() or onBackPressed() if you are interested exactly in back button presses.

apologies for pointing possible basic out but follow your problem have you ensured after closing that its not running in you Task Manager (ctrl+alt+delete)..have task manager running alongside your daemon then during the closing of daemon watch what happens during and after closing in task manager as it may be backing up files in accordance with settings-check settings in daemon....or have you used an ExecutorService to run as Daemon in Java in which case this will prevent your program from shutting down see here
ExecutorService - 10 tips and tricks
Java Applicatioin Process Hangs on Windows and Cached Thread Pool

Java: How to forcefully kill unneeded thread?

I am using some 3rd party code, which may hang indefinitely in some cases. This leads to hanging threads which keep holding the resources and clogging a thread pool.
Eventually thread pool becomes full of useless threads and system effectively fails.
In Java one can't forcefully kill the thread (kill -9). But how then to manage such edge cases?

Obviously fixing the bug would be better, however alternative include
only run the 3rd party code/library in a sub-process. Just killing the thread is unlikely to be enough.
you could hack the 3rd party code to check for interrupts in the sections you find run for too long. You can take a stack trace to run out where this is.
Use Thread.stop() though this has been disabled in Java 8.
when you detect there is a hung thread, increase the size of the thread pool by one. This will give you the correct number of active threads.

Is there any way to kill the running the deadlock thread "http:8080-42" which blocked all other thread

We have an application which leaks a bit of memory, a bit being an understatement.
I am using jstack to try and find what is causing the problem.
I see the thread count grow quite a bit on threads starting with the name: http-8080- 42
example:
"http-8080-13" daemon prio=10 tid=0x00002aacb4ae6000 nid=0x5ddf waiting for monitor entry [0x0000000043e65000]
java.lang.Thread.State: BLOCKED (on object monitor)
at com.reg_dashboard.DataModel.findRegsRow(DataModel.java:280)
- waiting to lock <0x00002aaab0c996b0> (a java.lang.Class for com.reg_dashboard.DataModel)
My first guess is that each of those threads is a request hit from the client and its waiting for some kind of synchronous block.
My my problem is that those threads have been running for long periods of time (Thus far 10mins).
My question is this:
Is there any way to kill this thread which is causing my application to hang??? there is a some request which is loading the catche and got stuck and other process are waiting for object to get unlocked !

Is there any way to kill this thread which is causing my application
to hang???
Quite unlikely. The underlying JVM implementation should know how to react when an external process kills one of it's threads. You'll likely put the VM in an inconsistent state.
You already know where the dead lock is. Newer VMs pretty much tell you which threads are deadlocked with each other. Solve the problem at it's source instead of trying to kill the thread. Who is to say that the threads will not deadlock 10 seconds after you kill the locked threads (assuming that even works).
I'd recommend a tool like JProfiler if you'd like to take a deeper look at the locking mechanism in your application. You can solve the problem faster. I'm alluding to the Monitor profiling section.

How to listen for current thread changes?

I want to know in every moment of program execution what thread is executed now (not all threads in JVM but only threads that belong to my program).
How can I get it?

YourKit can show you which threads were running, blocked, waiting etc at any given moment and give you a snapshot of the stack at intervals.
You can create a process to poll all the threads yourself with Thread.getAllStackTraces() which gives you the stack trace of every thread. Using a GUI tool is much, much easier.