# Race between ThreadContext.close() and context access may throw IllegalStateException
**URL:** https://discuss.elastic.co/t/race-between-threadcontext-close-and-context-access-may-throw-illegalstateexception/386792
**Category:** Elasticsearch
**Created:** [June 10, 2026, 10:37am UTC](https://discuss.elastic.co/t/race-between-threadcontext-close-and-context-access-may-throw-illegalstateexception/386792 "2026-06-10T10:37:41Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@denyjohn](https://discuss.elastic.co/u/denyjohn)
#### Post date: [June 10, 2026, 10:37am UTC](https://discuss.elastic.co/t/race-between-threadcontext-close-and-context-access-may-throw-illegalstateexception/386792/1 "2026-06-10T10:37:41Z")
In v6.4.2, `ThreadContext` stores request-specific headers and transient values in the shared field `threadLocal`, whose concrete type is `ThreadContext.ContextThreadLocal`.
There appears to be a race between `ThreadContext.close()` and concurrent context-access operations. `ThreadContext.close()` closes `threadLocal`, while methods such as `getHeader(String key)`, `getHeaders()`, `getTransient(String key)`, and `newStoredContext(boolean preserveResponseHeaders)` may still call `threadLocal.get()` or `threadLocal.set()` from another thread.
---
### Author:  [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)
#### Post date: [June 11, 2026, 3:43pm UTC](https://discuss.elastic.co/t/race-between-threadcontext-close-and-context-access-may-throw-illegalstateexception/386792/2 "2026-06-11T15:43:39Z")
It's unlikely this is a genuine problem, but 6.4.2 is so very old that it wouldn't be worth looking at the code even if you had some links to a specific instance of what you mean. If you can see something similar in a maintained version then maybe share some more details.