Closed simondaudin closed 1 year ago
Thank you for reporting this, @simondaudin -- and especially for providing the reproduction!
Without looking too deep, based on failure and test code, it does seem like a legit bug somewhere and not incorrect usage. But I hope to add more information when I have time to look into this problem.
Hello, thanks for the response.
I actually got curious and went digging a little bit.
It seems due to SmileBufferRecycler
being created in the main
thread and so, created only once in SmileParserBase
ThreadLocal _smileRecyclerRef
and then used inside all the parallel thread.
Second problem, in SmileBufferRecycler
there is a race condition between the get and the set to null.
I tried two solutions that both worked:
SmileBufferRecycler._seenNamesBuffer
in an AtomicReferenceSmileParserBase._smileBufferRecycler
field by the method with the same name so that it is lazily instantiated by the correct thread when neededIn the first solution, we only have one instance of SmileBufferRecycler
shared by all the parallel threads.
I had no further insights about what it was supposed to be in this context, so I was not sure about making a PR.
This may be due to earlier assumptions that parser instances were bound 1-to-1 on threads, and as such buffer recyclers would work without explicit synchronization as long as ThreadLocal
was used. This turned out not to be the case with async processing, and changes have been made in jackson-core
for recycling of symbol tables, for example.
But I suspect not for SmileBufferRecycler
; it predates async Smile parser as well.
So this gives a reasonable idea that adding unfortunate-but-now-necessary locking is probably needed.
src/main/java/com/fasterxml/jackson/core/util/BufferRecycler.java
from jackson-core
may provide some clues, I forget exact changes that have been made over various versions.
Thanks for the information ! It seems, indeed, to be a problematic similar to #479
Hi there
I noticed an error when using SMILE NonBlockingByteArrayParser in an asynchronous environment (in an HTTP environment). I managed to reproduce the error in a local test and to propose a "simple" test that produce the error.
Jackson version: 2.15.2 (and before)
Here is the failing test
Here is the error it produces
I noticed 3 things:
SmileFactore
byJsonFactory
-> no errorsupplyAsync
(so same thread) -> no errorExecutorService executorService = Executors.newFixedThreadPool(1);
-> no errorI didn't take the time to track deep in jackson, but it seemed that there was some trouble with the
seenNames
being empty when it should not have been. I don't know if maybe it should not be used this way or if it is a legit error.Thanks