JTextArea brings program to crash?

[korcs]

Hi,

I use a JTextArea instance in my app to visualize program outputs.

I have a LOT of output, and I have experienced, that if I use
JTextArea instead of TextArea, after a certain time it does not take
any more appends, so my threads which are trying to use the JTextArea
to output something are stopping (start waiting for ethernity).

Does anybody have an idea how could I avoid this? I suppose, that one
could check after or before each append the size of the contents and
clear it, if it is over a certain limit...

Is the JTextArea so much different in managing content than the
TextArea?

Best,

korcs

 

[Andrew Thompson]

korcs wrote:
...

I use a JTextArea instance in my app to visualize program outputs.

I have a LOT of output, ..

It sounds like this ouput might better be written to a
log. To see the live output in the GUI, start a thread
that displays the tail of the log in the text area.

What is this output that is so long that it crashes a
JTextArea, but yet you can read it? At my average
reading speed, I guess it would take 'days' worth of
appends before the JTextArea had trouble (but I have
not tried it).

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200710/1

 

[Martin Gregorie]

Hi,

I use a JTextArea instance in my app to visualize program outputs.

I have a LOT of output, and I have experienced, that if I use
JTextArea instead of TextArea, after a certain time it does not take
any more appends, so my threads which are trying to use the JTextArea
to output something are stopping (start waiting for ethernity).

Does anybody have an idea how could I avoid this? I suppose, that one
could check after or before each append the size of the contents and
clear it, if it is over a certain limit...

Is the JTextArea so much different in managing content than the
TextArea?

Any approach like that will eventually choke if you just feed it data
and don't discard anything. Why not use a list of Strings as a temporary
line buffer and map it into a scrollable JTable to display its contents?
When the list reaches, say 1000 entries, you drop the first item each
time you append a new string. This would run forever without choking.

 

[Ben Phillips]

Any approach like that will eventually choke if you just feed it data
and don't discard anything.

If you feed it upwards of 2GB, maybe.

I'd like to offer a differential diagnosis. This smells of deadlock or
other concurrency issues and the OP explicitly mentioned appending to
the JTextArea from multiple threads. If he's doing it *directly*, or
even synchronizing on the JTextArea, rather than using
SwingUtilities.invokeLater ...

 

[Martin Gregorie]

If you feed it upwards of 2GB, maybe.

I'd like to offer a differential diagnosis. This smells of deadlock or
other concurrency issues and the OP explicitly mentioned appending to
the JTextArea from multiple threads. If he's doing it *directly*, or
even synchronizing on the JTextArea, rather than using
SwingUtilities.invokeLater ...
>

No disagreement here, but I would point out that accumulating stuff in
memory like that is a bad idea. Once the display program starts to swap
(which it will at some point) its performance will deteriorate
drastically: maybe that's what he's seeing. In any case, before it
chokes itself it will have impacted everything else running on the computer.

The approach I suggested is ugly in many ways, but would have caused
minimal disruption to the OP's programs. Of course, what should have
been done was to use a background logging program to capture the data in
a log file. The display program would be rewritten to search, filter and
display the log.

Of course, if he IS using a *NIX its simple: use the system logger to
write his log file and less or tail to view it. The only actual
programming needed is to retrofit a syslogger interface to the source
program(s).

 

[korcs]

Thanks for the replies.

I will use the string buffering with erasing every entries older then
the latest 1000.

As a complementary solution I will log everything into a file.

Best,

korcs