You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by "Richard Zowalla (Jira)" <ji...@apache.org> on 2026/09/08 19:06:00 UTC
[jira] [Updated] (TOMEE-4699) ThreadContext constructor is not thread-safe, causing loss of submitted tasks.
[ https://issues.apache.org/jira/browse/TOMEE-4699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Zowalla updated TOMEE-4699:
-----------------------------------
Fix Version/s: 11.0.0
10.3.0
> ThreadContext constructor is not thread-safe, causing loss of submitted tasks.
> ------------------------------------------------------------------------------
>
> Key: TOMEE-4699
> URL: https://issues.apache.org/jira/browse/TOMEE-4699
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
> Affects Versions: 10.2.0
> Reporter: Jorren Hendriks
> Priority: Major
> Fix For: 11.0.0, 10.3.0
>
> Attachments: stacktrace.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Some of our tomee applications have experienced issues losing tasks submitted to a managed executor.
> The root cause has been identified as a `{_}ConcurrentModificationException{_}` in the ThreadContext constructor (stacktrace attached).
> {code:java}
> public ThreadContext(final ThreadContext that) {
> this.beanContext = that.beanContext;
> this.primaryKey = that.primaryKey;
> this.data.putAll(that.data); // throws ConcurrentModificationException when that.data is modified on another thread
> this.oldClassLoader = that.oldClassLoader;
> }{code}
> `{_}HashMap.putAll{_}` will iterate the entrySet, which is not thread-safe on the `{_}Collections.synchronizedMap{_}` wrapped HashMap currently in use.
> A possible solution would be to use a thread-safe Map implementation.
> This constructor is called when entering the snapshot in the
> [{_}ApplicationThreadContextProvider{_}|[https://github.com/apache/tomee/blob/main/container/openejb-core/src/main/java/org/apache/openejb/threads/impl/ApplicationThreadContextProvider.java#L76|https://github.com/apache/tomee/blob/main/container/openejb-core/src/main/java/org/apache/openejb/threads/impl/ApplicationThreadContextProvider.java#L76].]]
> This issue also revealed possible other issues for us:
> 1. `{_}CUTask{_}` does not handle exceptions before starting the task. Any exceptions in `{_}contextService.enter(snapshot){_}` cancel invocation, but do not abort the task.
> 2. Exceptions in a `{_}CUTask{_}`/`{_}CURunnable{_}` are propagated to the `{_}ThreadPoolExecutor{_}`. The current implementation does not expose these exceptions which makes this a silent failure.
> If you'd prefer that I can file these as separate issues, but they are related to this problem.
> h2. Reproduction
> This is a race condition which very rarely occurs. We were able to reproduce it (under high load) within an hour on one of our applications with a debugger attached. So far we were not able to create a minimal reproduction outside our application. I will update the issue when we do.
> The pattern we use in the application is as follows, the comments indicate my interpretation of what happens:
> {code:java}
> // MyTaskExecutor.java
> @Stateless
> public class MyTaskExecutor {
> @Resource
> private ManagedExecutorService managedExecutorService; // default TomEE managed executor service
> @Override
> public void execute(@NotNull Runnable runnable) {
> // 1. runnable is wrapped in CUTask. ThreadContext is copied on the executor thread.
> managedExecutorService.submit(runnable);
> } // 2. method returns immediately, causing an update to the current ThreadContext.
> } {code}
> When the exception occurs, 1 & 2 both execute at the same time, accessing the current ThreadContext concurrently.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)