What is meaning of the number after exec in "[http-bio-8080-exec-494] [ERROR]"?

Question

While going through an investigation in a legacy Java Spring Maven project deployed on tomcat 7 the logs stated like below-

2018-08-29 18:16:42:471 +0600 [http-bio-8080-exec-494] [ERROR]

Asking to demystify the number after

exec-

So basically the meaning of "exec"? which is 494 for the above case.

Solution 1

It's most probably the thread id generated by a custom ThreadFactory, just like:

Executor executor = Executors.newFixedThreadPool(4, new ThreadFactory() {
    AtomicInteger threadId = new AtomicInteger(0);
    @Override
    public Thread newThread(Runnable r) {
        return new Thread(r, "http-bio-8080-exec-" + threadId.getAndIncrement());   // custom a thread factory 
    }
});

IntStream.range(0, 10).forEach(value -> {
    executor.execute(() -> {    
        System.out.println(Thread.currentThread().getName());   // print thread name
        try {
            Thread.sleep(100);
        } catch (Exception e) {

        }
    });
});

OutPut:

http-bio-8080-exec-0
http-bio-8080-exec-1
http-bio-8080-exec-2
http-bio-8080-exec-3
http-bio-8080-exec-0
http-bio-8080-exec-3
http-bio-8080-exec-1
http-bio-8080-exec-2
http-bio-8080-exec-0
http-bio-8080-exec-3

Solution 2

That is a Thread ID number generated by a Thread Pool in tomcat. The real question is different, this being an internal information what is the value of it, now that you know about it? I'd assume close to zero...

Comments

[spi]

that information is only relevant when you debug tricky issues involving multithreading - pretty rare

[Eugene]

@spi well if you even want to try to debug those issues, starting with what a thread id is, means you are very far away from actually debugging the issue...

[M.A.K. Simanto]

@Eugene we have observed the value go up-to 1600 when our system was under full load and weirdly halted without giving any error in log. Hence we are getting a feeling that there might have been too many threads that are unused creating memory leaks.

[spi]

@Eugene for sure ^^ but you may better understand what's going on by looking at the thread id: sometime you may be sure that a call is done in a particular thread, and looking at the id may confirm or not your assumptions.

[spi]

@M.A.K.Simanto yes 1600 active threads is way to much. But the id growing does not indicate that all of the previous threads are still alive, only a debugger/profiler can tell. But if the thread pool was correctly setup, it should never kill and recreate any thread, only reuse the old ones and the id should not grow

[Eugene]

@M.A.K.Simanto how do you know that that ID means the number of active threads? I'm trying to look that up in some documentation for example, but no luck so far.

[M.A.K. Simanto]

Eugene: Profiling with Jprofiler, now I know the ID doesn't mean active threads as I can see the active/waiting threads remain between the max number of threads allowed for Tomcat during a load test. @spi You are absolutely correct. After profiling we can see the eden space continuously grows hence the server was not given any more requests , at the idle state. We are investigating for memory leakage.

[cyberbrain]

The use of that number is: all log entries that have the same thread ID are from the same thread, so if you have multiple log entries close to each other, chances are high that they are from one request. So you can divide the log by individual requests.