Change default recycler pool to newConcurrentDequePool() in 2.18
#1266
Labels
2.18
Issues planned at earliest for 2.18
Comments
cowtowncoder
changed the title
concurrentDequePool in 2.18bewConcurrentDequePool() in 2.18
cowtowncoder
added a commit
that referenced
this issue
Apr 20, 2024
|
Actually. Given all the feedback received so far, it appears that the ThreadLocal-based pool still performs best for pre-Loom threading. So let's postpone this change to 3.0 ( |
cowtowncoder
added a commit
that referenced
this issue
Jun 4, 2024
cowtowncoder
added a commit
that referenced
this issue
Jun 4, 2024
pjfanning
changed the title
bewConcurrentDequePool() in 2.18newConcurrentDequePool() in 2.18
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
(note: follow-up to #1256)
Altho we will revert back to
ThreadLocalPoolfor 2.17.1 and rest of 2.17.x, we do want to move away in 2.18.Let's use "ConcurrentDequePool" (via
JsonRecyclerPools.newConcurrentDequePool()) as that seems to behave better and have otherwise similar approach as shared-lock-pool, but without potentially failing acquire that can lead to imbalanced handling & ever-growing pool.The text was updated successfully, but these errors were encountered: