I'm working on my usual projects on Eclipse, it's a J2EE application, made with Spring, Hibernate and so on. I'm using Tomcat 7 for this (no particular reason, I don't exploit any new feature, I just wanted to try that). Every time I debug my application, it happens that Eclipse debugger pops out like it has reached a breakpoint, but it is not the case, in fact it stops on a Java source file that is ThreadPoolExecutor. There is no stack trace on the console, it just stops. Then if I click on resume it goes on and the app works perfectly. This is what shows in the debugger window:
Daemon Thread ["http-bio-8080"-exec-2] (Suspended (exception RuntimeException))
ThreadPoolExecutor$Worker.run() line: 912
TaskThread(Thread).run() line: 619
I really can't explain this, because I'm not using ThreadPoolExecutor at all. Must be something from Tomcat, Hibernate or Spring. It's very annoying because I always have to resume during debugging.
Any clues?
The posted stack trace indicates that a RuntimeException was encountered in a Daemon thread. This is typically uncaught at runtime, unless the original developer caught and handled the exception.
Typically, the debugger in Eclipse is configured to suspend execution at the location where the exception was thrown, on all uncaught exceptions. Note that the exception might be handled later, lower down in the stack frame and might not lead to the thread being terminated. This would be cause of the behavior observed.
Configuring the behavior of Eclipse is straightforward:
Go to Window > Preferences > Java > Debug and uncheck Suspend execution on uncaught exceptions.
There's a more specific solution, which prevents Eclipse breaking on RuntimeExceptions thrown only from a given class.
Add a new exception breakpoint from the Debugging perspective
Go to its properties
Go to Filtering
In "Restrict to Selected Location(s)", click "Add Class"
Add java.util.concurrent.ThreadPoolExecutor
Untick the checkbox, meaning these will be ignored
This behavior is triggered by tomcat when a webapp is reloaded. It's part of tomcat "memory leak protection" feature that (among other things) forces the renewal of its threads.
This is now fixed from versions 7.0.54 and 8.0.6 of tomcat :
https://issues.apache.org/bugzilla/show_bug.cgi?id=56492
I have noticed that this often occurs after modifying server files (jsp or java) and STS has trouble reloading the application.
This usually leads to restarting the server in order to get it to get the changes synchronized.
After introducing JRebel - it appears to have gone away. So, I would like to think it is a reproducible issue in STS when hotswapping code in debug mode.
By removing the native hotswapping, it eliminates the issue with it breaking inside the ThreadPoolExecutor class.
Related
When I use remote debugger in IntelliJ to debug a Java application on server, it stops on breakpoints successfully but when I try to evaluate any expressions or variables it hangs and shows nothing (usually with "collecting data" message). From that point I can't even continue stepping through code anymore. I have to click resume so it at least runs, but it will never stop at other breakpoints too until I restart the debug session and usually even the Java application being debugged.
I can step through the code after stopping on breakpoint, also I see the variables in the debugger panel, it only starts to behave weirdly when I try to evaluate an expression or add a watcher. Then it stops working and restart of the debugger and the app is needed.
Did anybody experience something similar? Is it IntelliJ or server problem?
(sorry this is so vaguely described, but I have no idea what to share or what the problem might be)
Expression evaluation during remote debug need more data to be sync then the other operations ( breakpoints add/remove, step managements ecc ).
So this kind of issue should be just related to:
a slow connection
an huge complexity and amount of data involved into the operation to execute in the remote server
In node.js world, there are apps like Supervisor - it's a daemon process that checks if your app is running, and if not (closed, crashed), it restarts it instantly. That's very nice way of temporary handling critical errors in production, when one feature could fail, but rest of system is still running.
I come from PHP background where all you had to do is to press back button in browser, when something is broken.
How to achieve this behavior in Spring Boot ? So far what I noticed is that when app faces unhandled exception, it crashes and whole server is down. I know that those kind of errors are the ones that one should fix asap, but sometimes it's just impossible, and system needs to be running.
Are there any tools that work like Node.js supervisor?
In the past I sometimes used the Java Wrapper by Tanuki which worked quite nice. Otherwise you do have the option to either monitor the process and automatically restart if it fails (dependent on your system environment) or on the highest level of you application catch Throwable, which will not be a good idea because you'll catch fatal cases that by intend should kill your jvm execution, e.g. OutOfMemory...
When I run my code in debug mode in Eclipse, I'm able to find where the code breaks down, but an exception is not being shown on the council. In debug mode, I notice that after an exception is thrown, it seems to be swallowed up by the thread it's running on, and the program keeps going (or at least, keeps running. The program itself becomes unusable). Is there any way to get errors thrown in threads to be more visible?
I apologies if I've misinterpreted the path the debugger took through the code when it reached the exception. It seems to me that it is being caught by the thread. Regardless, whenever I have threaded code, I have a hard time finding out what the error was.
Using the Eclipse debugger, you can configure a breakpoint to break whenever some specified Exception is thrown.
To set this up:
On the debugger's Breakpoints tab, press the J! button. This will enable you to Add Java Exception breakpoint. You can also choose to suspend the JVM or thread that throws the Exception.
Just prior to your specified Exception being thrown, the debugger will suspend the thread or the JVM (all threads) depending on your choice. At this point, you can begin to diagnose the problem. It's not foolproof, but it will give you an excellent starting point to debugging your issue.
If you don't know what Exception is thrown, you can choose java.lang.Exception. This will pause for any Exception thrown.
You may want to register an UncaughtExceptionHandler with the thread, in which you can do the required logging.
Following on from this question https://softwareengineering.stackexchange.com/questions/37294/logging-why-and-what
I was wondering what actually happens to an error that occurs during the runtime of a Java Enterprise Edition applicaiton.
Does the JVM store a log of all the errors?
Or are the errors forgotten?
It is contingent where the output is directed. If output is getting pushed to a console window then yes...it is all but lost. An enterprise application however would be making use of a logging framework to deal with all output thus rendering any exception available within the logs provided by the framework.
Application servers usually have a big catch-all net to mop up any unhandled exceptions. However, if an exception is allowed to bubble up without it ever hitting a catch close, the thread it came from will die and the exception will be passed to the thread's UncaughtExceptionHandler, if one exists.
an error happens when the program is running. and is being handled by exceptions.
Exceptions : ignore the error, handel the exception, and go back to method that was called.
I'm trying to debug a problem in my Java application that throws no errors, no exceptions and doesn't even crash the app (it seems the failure happens in a separate thread).
The problem seems to be inside a call to a library function (it's JAXBContext.newInstance(String) if that matters). The program will reach the line just before the call, but not the one just after it. My catch blocks are not entered and the program just continues to run.
The problem happens while trying to render an XML response to a web request that came in via Struts. The request has been handled and the code should marshal the response object. The client gets a response right away (so the code doesn't seem to hang in a loop), but it's just empty.
I have set a breakpoint just before the problematic line but the debugger just runs over it, I haven't a clue why.
I'm using eclipse and the application runs inside an OSGi container (Apache Felix) that was started with -Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y. From within Eclipse I then use the Debug settings for "Remote Java application" to connect the debugger.
What are techniques to get at such a problem?
Probably an obvious question, but are you sure you are catching Throwable? An unchecked exception could easily cause the thread in question to die (assuming no one above you in the call stack is catching it either.)
Since you are suspending the VM on startup with your debug arguments, I assume you have confirmed that the debugger is attaching correctly. The fact that you say the debugger skips right past the call is very suspect. Are you able to hit any breakpoints in this application? What about in this Class? What about in this thread?
How did you narrow down the line in question without the debugger? println/debugging to a file?
Can you paste a code snippet of the method in question?
You could confirm the theory that the thread is dying by creating a second thread before the problem occurs and joining it to the thread you think is dying. Then the second thread's run() method would be invoked when the thread in question exits, and you'd know it died (but would still not know why.)
In answer to your general question, when I have a bug in a Java app that I can't reproduce in the debugger (which happens from time to time for various reasons), I incrementally modify my code with sysout printlns or output to files. If necessary, I may also modify the code my code is invoking. If you don't have the source code to the code you are invoking, you can try one of the many BCI frameworks to inject your byte code into the methods in question. It's a tedious process, but only happens occasionally.
You could try getting a Thread Dump - that will tell you if any methods are blocking (e.g. waiting for input). [Edit: re-reading your original question, getting a thread dump probably won't help as it looks like nothing is actually blocking. But I'm leaving it here as I find it useful in many other situations!]
If you think the error is happening in another thread you could also set an UncaughtExceptionHandler to try and catch it.
If you're sure the problem is somewhere within that method, you could try looking at the JAXB source code.
EDIT:
Well, if it gets really bad you can build your own private copy with debugging instrumentation. I hope you won't have to resort to that.
perhaps inside the call there is an infitite loop happening and this is why you get no further - but this might not cause a crash (unless memory is being used in each loop).