give me that cyclic output buffer
IDEA froze again...
When my launched app freezes in endless loop,
dropping lots of debug outputs to console,
I do not want IDEA to additionally freeze due to OutOfMemory :(
Please sign in to leave a comment.
PS: having to restart IDEA gives me enough time to
whine here ;)
dump it to a file.
Files are useful like that.
everybody seems to think that System.out is bad,
and also log.debug is bad with a console appender when it gets too much ;)
yes I have damn log.debugs in my code and I got in an
endless loop... I want the IDE to stay responsive, to have
a convenient way to stop my blocking app, other than -> task manager, find the java process that consumes all CPU and kill it from there.
Note that I am not a fan of putting megabytes of output in IDEA's console. Yes, I agree that you should log it to file if you are interested in such huge output. I just think it would be intelligent to have a cyclic buffer to prevent IDEA from going out of memory.
Thinking on it further, on other idea comes to my mind:
IDEA itself could write the console output to a tempfile, then have the console only read as needed when you scroll through it - memory consumption no problem any more.
That said, in my specific case, it seems like it was sth.
different anyway, as there was actually no sout or log in the while-loop I got locked in. So - strange. A quick test showed that everything is alright when you run an app with a simple while(true) {} So I don't know how or why it happens, only that I was in an endless while loop and IDEA froze, consuming all the memory it was allowed to.
Michael Damberger wrote:
That's an interesting idea...
That's probably because the compiler or the JIT optimised the empty loop
to something that didn't occupy as much CPU time as a non-empty loop would.
Ciao,
Gordon
--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001
java.util.logging
disable ConsoleHandler (or filter it) and enable FileHandler.
This is switchable from the command line params.
You missed the point completely. It's not about "how can I implement better logging" but "idea freezes" - it should never do that regardless how bad your application behaves.
Imagine the huge log output is due to the accidental endless loop. And that endless loop bug only manifests in one of a thousand runs in a very specific context and you failed to reproduce that bug again and again though many of your customers report it. Aren't you happy that you have reproduced the bug while you're debugging in Idea? Oh, no, when you need it most Idea crashes...
Usually my app outputs only very little log texts, but to help in debugging I frequently set the log level to very low, so that much more text is output. I do this often when I debug mouse interaction in our diagram editor - you can't use a debugger for that because any breakpoint interupts the mouse events. (Well, you could do with two machines and debugging remotely, but remember to keep the mouse button pressed on the one mouse while you use the debugger on the other machine ;) )
I think the comment was to change the way IDEA logs, not your app.
That is, play with the internal log4j.xml config file to send the log to a file rather than the console.
As for the larger issue of IDEA become unresponsive, I think there is only so much one program can do to limit the activities of another independant program.
How long is this thread going to last...
Michael has a bug in his app. As a result it generates too much console
output when debugging. The purpose of debugging is to.. find and kill the
bug. But idea FREEZES. How does that help him?
Saying "just remove the bug, IDEA shouldn't have to deal with it" is just
a way to work around the problem that is at the CORE of the functionality
that a debugger should provide.
If IDEA can't cope with console output, it should not even try to capture
it.
If it decides to capture it then it should be crash proof, or at least
provide
an option to capture only some of it (cyclic output buffer).
Vince.
>>If IDEA can't cope with console output, it should not even try to capture
it.
A rather simplistic view. Since 1 program out of X thousands spits out an excessive amount of logging, IDEA should remove the console as a feature. An IDE should support the most likely case in the easiest way and that is what IDEA does.
>If it decides to capture it then it should be crash proof, or at
>least provide an option to capture only some of it
>(cyclic output buffer).
And isn't that exactly what log4j does?
excessive amount of logging, IDEA should remove the console as a feature. An
IDE should support the most likely case in the easiest way and that is what
IDEA does.
I was just taking things to the extreme. It just seems to me that the
problem is being looked at from the wrong angle. "Fix your bug so you can
use the IDE" vs. "Your IDE should help you fix your bug". I go with the
latter. Some people tend to go for the former and based on the very nature
of an IDE it doesn't make to much sense to me. What's interesting is that
there is a good split in between the two points of view.
That's again "fix your bug first". What if I don't have the option of using
Log4J in my project?
Vince.
>> And isn't that exactly what log4j does?
>That's again "fix your bug first". What if I don't have the option of using
>Log4J in my project?
I don't think you understand. Log4j is in IDEA. Logj is used by IDEA. You can configure log4j to configure IDEA's behavior not your application's. This has nothing to do with the debugged application and everything to do with configuring IDEA.
Zoltan Grose wrote:
>>>And isn't that exactly what log4j does?
>>That's again "fix your bug first". What if I don't have the option of using
>>Log4J in my project?
I don't think that IDEA uses log4J to direct the output of an
application being debugged.
If I am wrong, please provide an example of a log4j.xml file that would
cause IDEA to log the output of an application being debugged to a file
rather than to IDEA's Debug panel.
Tim
This problem has been around for ages :
http://www.intellij.net/tracker/idea/viewSCR?publicId=12140
Noone assigned to it though.
N.
Tim Haley wrote:
>>>> And isn't that exactly what log4j does?
>>
>>
>>
>>> That's again "fix your bug first". What if I don't have the option of
>>> using
>>> Log4J in my project?
>>
>>
>>
>> I don't think you understand. Log4j is in IDEA. Logj is used by IDEA.
>> You can configure log4j to configure IDEA's behavior not your
>> application's. This has nothing to do with the debugged application
>> and everything to do with configuring IDEA.
>I don't think that IDEA uses log4J to direct the output of an
>application being debugged.
I guess Nick gave bad advice earlier in the thread then.
You'd think this is something they could/should do, though.
Not me {;-)
That much crap going to a console window makes no sense to me.
To be honest, I dont care, I use log files.
Its a very simple work around, and if Jetbrains spends time thinking about, let alone fixing this before they fix the huge-pain-in-the-ass focus grabbing / lost focus issues, well.. Ill still be left with huge-pain-in-the-ass focus issues, but at least it will stop all this whining about pointless logging crud.
Given that everytime the focus-stealing issue comes up it ends with "it's
swing's fault, JB can't do anything about it", I keep around a simple REG
file that goes and resets the "focus-can-be-stolen" setting in Windows. When
IDEA steals my focus, it means something else has changed my setting and
it's time to reset it again.
===dont-steal-my-focus.reg=====
Windows Registry Editor Version 5.00
"ForegroundFlashCount"=dword:00000003
"ForegroundLockTimeout"=dword:00030d40
==========================
http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/
windows2000/techinfo/reskit/en-us/regentry/55200.asp
(I should really make it accessible via an external tool in IDEA :) )
Vince.
{:-) Try that on Linux.
Eclipse works, JBuilder works, heck, Id be willing to put up with the pain of trying out Netbeans 4.0
Nick
Wow, I was so convinced that it was a Windows-only issue..
I feel your pain then, it is such an irritating problem.
(but still, not sure it's worth going to NetBeans :) )
Vince.