Magic with System.out.println..!!

[James Hetfield]

Hi all,
I wonder if any of you have come up with this strange problem. There is a project which involves network programming (TCP sockets), multi-threading, XML parsing...that I developed just reached its bug free working flow.
Then when I commented all the System.out.println's and re-compiled and ran it again...it refused to work..!!
...when I again un-comment all the System.out.println's it works fine again..!!
I'v tried it so many times now...that I am sure it's the System.out.println's...that's doing the magic...!!
people with any clue please do educate me.
thanx,
adios,
james.

[Mani Ram]

Hi James,
What exactly you mean by "it refused to work"?
Did it throw any exception or it simply didn't do what it was supposed to do?
If it threw any exception..can you post them here?

[James Hetfield]

Hi Mani Ram,
No there were no exceptions...infact all my catches have .printStackTraces()...the flow of messages stopped. There were just too many System.out.println's for me to un-comment one by one and try...so I let them remain...
Thanx,
adios,
James.

[Ouaknin lionel]

looks like deadlock to me... but without more info,it is hard to tell...
is there many thread in your app ? the System.out.println might delay threads execution, and cause deadlock.
might be...

[David O'Meara]

I'm wondering if the output has been mapped to a remote location and this is required to run the application. Have a look for 'setOut'.

[James Hetfield]

Hi all,
hmmm I think maybe it could be the threads. There are just too many threads that are spawned and some of them access the output streams of the same sockets at the same time ....to write messages into the streams..as bytes...
maybe I should look into thread synchoronization...guess that could solve my problem....
thanx,
adios,
LearningCurve

[Stan James]

There may be something more subtle in your code. Maybe you forgot to use { } braces somewhere - because of identing you think two lines are in a block of code but really only one is...

if (condition)
   print line
   do something important

Before commenting out print line the something important was always happening. After commenting it out, something important only happens when condition is true.
I only bring this up becuase it's the kind of mistake I'd make!

[vasu maj]

Yeah I think indenting is probably the issue. Please take a closer look....

vasu

[John Smith]

I'v tried it so many times now...that I am sure it's the System.out.println's...that's doing the magic...!!
The problem may have something to do with the threads. System.out.println() contains synchronized code that will cause the reconciliation of the class level variable that was modified by one thread, and read by another thread. Without System.out.println() (or any other equivalent synchronized code), one thread may not see the change in a non-volatile variable set by another thread.
Try this: replace your System.out.println() with

synchronized(anyObject) {}

If this works, you get a confirmation of the problem that I described. To fix the problem, you will need to review your code. Most likely, you are missing a "volatile" qualifier someplace. Are you running your code on the multi-processor machine?
[ September 21, 2003: Message edited by: Eugene Kononov ]

[Stan James]

I used to have a card on the wall that said something to the effect:

Place a rock within easy viewing distance of your computer. When your program is not working correctly, consider that the computer, like the rock, is functioning perfectly.

It reminds us that most problems are our fault. Yes, there are bugs in the JDK and free electrons zooming through the universe can set random bits in computer memory, but it's much more likely we just coded it wrong. Let us know what you find!

[Eddy Chang]

If it is a deadlocking problem, if you generate a thread dump for all the threads, and look at the stack traces, you should be able to identify where the deadlock is occuring is quite quickly.
Generate a thread dump for all threads in the jvm.
For unix machines: kill -QUIT process_id
For windows machines: CTRL+BREAK in the console window.
Look for threads in the "wait" state, and check out the stacktrace for those threads.
To identify which threads are in the wait state, read here:
http://developer.java.sun.com/developer/technicalArticles/Programming/Stacktrace/
If there are multiple threads in the wait state waiting for the same object/lock, that could point you to the code that is deadlocking.
Or the problem could be caused by an infinite loop somewhere in your code which the stacktraces generated by the thread dump will identify for you.
Eddy