2

I'm working with threads but after a time, most of them stop doing their job. The first thing I thought was a deadlock, but all are with state RUNNING.

I suppose there is an error in my logic or a new characteristic that I not realized and I must handle (it's a webcrawler).

Is it possible to get the current executing method or operation? I want this to see where my threads are trapped.

EDIT: I think that is something I need to handle or there is error in my logic because this happens after a time executing, not imeddiatly after the start.

Ryan Castillo
  • 1,135
  • 10
  • 22
Renato Dinhani
  • 35,057
  • 55
  • 139
  • 199
  • I think you're actually looking for a debugger. This is probably quite easy, but it depends on your IDE. – Travis Gockel May 28 '11 at 14:31
  • Yes, currently I using the debugger of Netbeans, but I don't know how to see the currently executed method by each thread. – Renato Dinhani May 28 '11 at 14:36
  • I don't use NetBeans, but it should have the list of active threads somewhere. – Travis Gockel May 28 '11 at 15:19
  • Yes, the threads I can see, because this TOO, I know they are running, and not in deadlock. I found how to see the stack of executions in the debugger. I will do tests to confirm if the erros in the place that the stack of executions points. – Renato Dinhani May 28 '11 at 16:01
  • there is a wonderful tool named jstack (come w/ the JDK). other than that `Thread.getAllStackTraces()` is some good stuff. And there is a way to get the caller class as well (as reference not just string, easiest way is extending SecurityManager) – bestsss May 29 '11 at 14:32

7 Answers7

2

You can get the current stack trace in Java. You will get an array of StackTraceElement elements.

The first item in the array is the currently executing method.

See the following question for how to get the stack trace:

Get current stack trace in Java

Code might look like:

StackTraceElement[] trace = Thread.currentThread().getStackTrace();
StackTraceElement yourMethod = trace[1];
System.out.println(yourMethod.getMethodName());
Community
  • 1
  • 1
jjnguy
  • 136,852
  • 53
  • 295
  • 323
  • +1: Except you want element [1] as element [0] is the getStackTrace() itself. ;) – Peter Lawrey May 28 '11 at 15:53
  • @Peter, whoops, thanks. Didn't notice that I screwed that up. – jjnguy May 29 '11 at 01:19
  • I cannot stop but wonder how a stack trace of the current thread would help to identify issues with other, stuck, threads? For logging the current thread position stack trace is unnecessary, just dump some unique marker, i.e. "at user login #1". – Vladimir Dyuzhev May 29 '11 at 03:15
  • I have an engine thread which does critical work. I have another thread which monitors it and if it takes too long to do is work I take a stack trace which I log so I can pick up random delays and the cause of them. – Peter Lawrey May 29 '11 at 07:36
  • Current thread's stack is a trivial operation. `Thread.currentThread().getStackTrace()` equals `new Exception().getStackTrack()`, Thread.getStackTrace is needed ONLY for threads that are not the current running, they have to reach some 'safe point' for the VM to ask them to gather their statck(s). – bestsss May 29 '11 at 14:34
2

A debugger is the way to go. This is what they are designed for.

Java debuggers with threading support are built into both the Eclipse and Netbeans IDEs.

Borealid
  • 95,191
  • 9
  • 106
  • 122
  • You do not need debugger for this, jstack can print the stack of any running java process (and started w/o any debugging option) – bestsss May 29 '11 at 14:32
  • @bestss: will that let you trace variable values over time, to determine *why* your threads have entered the frame they're in? A debugger gives you more power - and the OP is trying to debug a problem. – Borealid May 29 '11 at 16:25
  • I am not arguing about debugger purpose obviously. Debuggers have their purposes, although as of now they dont help much debugging concurrent code. You do not run production processes in debug mode but you can run jstack instead. Taking a memory snapshop (jmap) is an option but it can block the application for way too long. Side note: the debugger in eclipse is horrid if you have tons (200+) threads and esp. on remote debugging. – bestsss May 29 '11 at 16:28
  • The good news is that I got where the methods stops using the Netbeans debugger. The bad news is I don't know how to resolve, but I see this after. Is a problem in the socketRead0. – Renato Dinhani Jun 07 '11 at 18:05
2

Make VM to dump the threads (Ctrl-Break). Find your threads in the list. Look at the topmost stacktrace method. Done.

Vladimir Dyuzhev
  • 18,130
  • 10
  • 48
  • 62
  • +1: thread dumps are the way to go. You can even take thread dumps repeatedly and see how the (top-most) threads are changing in all threads. – sjlee May 28 '11 at 16:36
1

You have 2 options:

  1. Use debug to get some understanding that was executed and what not.

  2. Use a lot of logmessages (you can also produce stacktraces in that messages)

acm0x
  • 775
  • 6
  • 14
1

Thread dumps are the right solution for the problem. If you want to do it programmatically within the process (some kind of monitoring logic), then java.lang.management.ThreadMXBean provides access to all threads along with their current stacks at the time.

sjlee
  • 7,726
  • 2
  • 29
  • 37
0

It is, throw an exception, catch it immediately and save the stack. This is about as performant as asking an elephant to fly overseas but it's possible since it sort of extracts the current call stack to something you can work with.

However, are you sure you haven't run into a livelock?

Esko
  • 29,022
  • 11
  • 55
  • 82
  • You don't need to throw an exception. You could just create a new exception and use it to get the stack trace. Or you could see my answer. – jjnguy May 28 '11 at 14:25
0

Do you suppose your web crawler program is in a loop processing the same urls. Add some high level logging so each thread writes what it's processing.

karmakaze
  • 34,689
  • 1
  • 30
  • 32
  • I doing log in my program. Loop processing don't occurs. I will check the error now. I suspect some error is occuring HttpUrlConnection.getInputStream or instatiating the HTML parser after the download, but this are not my classes, are java native and external lib. I found this following the stacktrace of the debugger of Netbeans. – Renato Dinhani May 28 '11 at 16:10