CODEWITHSUNDEEP
javamultithreadingeclipsedebuggingconsole
coffee
coffee

Reputation: 3088

Managing multiple threads at the console

When I run multiple threads I get lost in System.out.println output because I suppose each thread has to be in a different consoles.

Is there an easy way to manage it using Eclipse?

EDIT: The problem is not to know which message belongs to each thread. The exact problem is that the console stops printing when a new thread is called, and the same happens with log4j too.

Upvotes: 1

Views: 5660

Answers (4)

coffee
coffee

Reputation: 3088

I just configured to write all my log in a file.

<appender name="rolling-file" class="org.apache.log4j.RollingFileAppender">
        <param name="file" value="home/.../mylog.log" />
        <param name="MaxFileSize" value="1000KB" />
<!--        Keep one backup file -->
        <param name="MaxBackupIndex" value="4" />
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern" value="%d [%t] %-5p %l - %m%n" />
        </layout>
</appender>

Upvotes: 0

Nathan Hughes
Nathan Hughes

Reputation: 96394

If you use log4j you can keep the threads' logging straight using Nested Diagnostic Contexts.

Here's the description of NDCs from the log4j manual:

Most real-world systems have to deal with multiple clients simultaneously. In a typical multithreaded implementation of such a system, different threads will handle different clients. Logging is especially well suited to trace and debug complex distributed applications. A common approach to differentiate the logging output of one client from another is to instantiate a new separate logger for each client. This promotes the proliferation of loggers and increases the management overhead of logging.

A lighter technique is to uniquely stamp each log request initiated from the same client interaction. Neil Harrison described this method in the book "Patterns for Logging Diagnostic Messages," in Pattern Languages of Program Design 3, edited by R. Martin, D. Riehle, and F. Buschmann (Addison-Wesley, 1997).

To uniquely stamp each request, the user pushes contextual information into the NDC, the abbreviation of Nested Diagnostic Context. The NDC class is shown below.

public class NDC {
    // Used when printing the diagnostic
    public static String get();

    // Remove the top of the context from the NDC.
    public static String pop();

    // Add diagnostic context for the current thread.
    public static void push(String message);

    // Remove the diagnostic context for this thread.
    public static void remove();   }

The NDC is managed per thread as a stack of contextual information. Note that all methods of the org.apache.log4j.NDC class are static. Assuming that NDC printing is turned on, every time a log request is made, the appropriate log4j component will include the entire NDC stack for the current thread in the log output. This is done without the intervention of the user, who is responsible only for placing the correct information in the NDC by using the push and pop methods at a few well-defined points in the code. In contrast, the per-client logger approach commands extensive changes in the code.

To illustrate this point, let us take the example of a servlet delivering content to numerous clients. The servlet can build the NDC at the very beginning of the request before executing other code. The contextual information can be the client's host name and other information inherent to the request, typically information contained in cookies. Hence, even if the servlet is serving multiple clients simultaneously, the logs initiated by the same code, i.e. belonging to the same logger, can still be distinguished because each client request will have a different NDC stack. Contrast this with the complexity of passing a freshly instantiated logger to all code exercised during the client's request.

Upvotes: 1

aioobe
aioobe

Reputation: 421040

I suggest you switch to a better logging facility than System.out.println, log4j is one popular option.

If you don't want to include another library for this purpose, I suggest you

  • give all threads meaningful names (see Thread.setName)
  • wrap the log statements in your own static logging function
  • prefix each line of output with Thread.currentThread().getName().

If you think that is too "invasive" or if you're dealing with legacy code, you could create your own PrintStream which prefixes each argument to println with current thread name (as above) and then do System.setOut(new YourThreadLoggingPrintStream());.

Upvotes: 3

Ernest Friedman-Hill
Ernest Friedman-Hill

Reputation: 81694

You could use log4j and set up a different Logger for each thread, connecting each logger to a different Eclipse view, but that would be a lot of configuration and a lot of coding in your app. Alternatively, if you just logged the thread ID along with your message, then you could tell what thread printed out even if all threads logged to the same view.

Upvotes: 1

Related Questions