ChunkRunner spawning a thousands of chunk-checkpoint-timer threads

[Zerrossetto]

Hi,
today I found that if time-limit was set to a big number of seconds my JVM struggled keeping track of thousands of threads named chunk-checkpoint-timer on certain job.

Investigating on the source code I found that org.jberet.runtime.runner.ChunkRunner class, when time-limit attribute on chunk tag was set bigger than 0, scheduled a timed thread just to update a boolean flag

            if (timeLimit > 0) {
                final Timer timer = new Timer("chunk-checkpoint-timer", true);
                timer.schedule(new TimerTask() {
                    @Override
                    public void run() {
                        processingInfo.timerExpired = true;
                    }
                }, timeLimit * 1000);
            }

I don't know if can be an intended behavior, but java.util.Timer class was not officially but practically deprecated in favor of java.util.concurrent.ScheduledThreadPoolExecutor. In any case here I tried to totally bypass the usage of threads and checking the expiration of the chunk only with a simpler check on the current millis with System.currentTimeMillis().

[chengfang]

Thanks for the PR. IIRC the use of timer was to avoid querying system time for every read, which can add up and be costly. But use of timer to update a flag has its own overhead. We haven't measured exactly which one performs better under which circumstances. Can you elaborate more on the symptom, e.g., why thousands of timer threads, are they all active at the same time?

We may want to use getNano() instead of currentTimeMillis, as the latter is subject to changes in user time adjustment.

This is an area we need to improve. Can you please create a JIRA issue ?

[Zerrossetto]

I created the issue JBERET-485, let's move the discussion there and decide how to proceed.

[Zerrossetto]

Hi, I'm done with the changes we discussed on Jira, feel free to approve it or add new comments.