Our application is using System.out.println for logging purpose. On stress test with 'Loadrunner' with less number of users these Standard out are seen on console but with high number of users these are not seen. It looks like getting suppressed or not getting flushed out. I need help in analysing this.

Just to give little direction, following is a sinplet from a site('http://www.redhat.com/docs/manuals/waf/rhea-dg-waf-en-6.0/s1-devenv-logging-debug.html')
----------------------------------------------
Beware of Buffered Streams
----------------------------------------------
The Java language provides two abstractions for doing output: output streams [8] for working with sequences of bytes, and writers [9] for working with sequences of characters. An output stream or a writer can be buffered or unbuffered. For more information, read about BufferedOutputStream [10] and about BufferedWriter [11].

When I/O is buffered, it means that bytes or characters that you write do not necessarily go to their intended output device immediately. They are cached in an intermediate buffer. When the buffer fills up, it is flushed — an actual write to the underlying physical device occurs.

Why should you care about this? If you log a message to a buffered output immediately before the system crashes, you may not see the message logged anywhere. The system didn't have a chance to flush the buffered stream or writer. This situation is fairly rare, but when it does happen, it may stump the unwary troubleshooter. If you want to be absolutely sure you are not losing any logging statements, you must use unbuffered output.

For example, the standard output System.out may be buffered, while the standard error device System.err is usually not. Therefore, System.err is preferable when you want to make sure no logging is lost.

You may pursue this problem, but I would want to ask why use system.out? How about trying a logging framework such as Log4J?

Back to your issue though, are you sure you are reaching that line in code and not bottlenecked due to the load?

Thanks for the reply.
It is because of client reasons we are not using any open source/ 3rd party tool for logging. We may in future use 'log4j' in future. Just to add one more observation to the problem raised.
-------------------------------------------------------------------------------
There are two .ear (say A.ear and B.ear)files deployed in our application. We could see system out from one of the components from 'A.ear' but not a single system out from any of the components from 'B.ear'.
-------------------------------------------------------------------------------

Pretty strange, isn't it?

J2EE/WLS Infrastructure Admin:

Must haves:
- Overall 5-6+ yrs. experience
- Good experience of BEA weblogic Administration, versions 6.1 to 7.0 to 8.1....2-3 years desirable....Clustering knowledge will be helpful
-Hands on experience of Solaris platform
-Good understanding of J2EE space...servlets/JSP/EJBs/JDBC/JMS etc.
-Good understanding of oracle database and JDBC communication.
-Good client handling, communication and troubleshooting skills

Differentiators:
Performance tuning tools like Jprobe/optimizeit
General J2EE application performance tuning.
Load Testing experience with tools as Loadrunner etc.

Nice-to-Haves:
Some experience in monitoring tools as sitescope, topaz etc.
Shell scripting
Java/J2EE Development.

It's a great opportunity for a fortune company in CT area and is a very stable consulting contract which goes until end of Dec 2004 and has a great chance for going through the next whole year.

People who are willing to switch employers need only apply. will process H1 visa. Please email your resumes ASAP to wlsjobs@yahoo.com

I thought the discussion was on SOP's not for a J2EE requirment.
-arun

The System.out is a PrintStream object. The PrintStream by default has autoFlush set to false. So what you can do is.. create a new PrintStream with flush on.. and replace System.out with this instance or PrintStream.

Hope this helps.

Regards.
Rakesh.

Thanks for the reply.
You are abosolutely right. I think I should mention here that there are two .ear (say A.ear and B.ear)files deployed in our application. We could see system out from one of the components from 'A.ear' but not a single system out from any of the components from 'B.ear'.

Pretty strange, isn't it?

Firstly high volume of concurrent log into the screen is highly discouraged. In such situation, the system is blocked to write to the buffer, and certainly your system performance is very low.

A simple wayout is to redirect the output to the file when you're testing. ie, use nohup in Unix or use '>>' in windows. I'm sure the performance will be improved.

regards.