Unexpected behaviour is too common phrase - got it As i sad i’ve experienced it in https://github.com/spring-projects/spring-framework/blob/main/spring-aop/src/main/java/org/springframework/aop/interceptor/ExposeInvocationInterceptor.java
Error on ThreadLocal#set in finally section there lead to leaving wrong state of TL (in my case it was non-null value into TL, that Spring’s AOP treats like “part of recursion calls” and AOP will return null insteadof expected value (for all execution in such “poisoned” thread) I believe that the same situation is possible with ThreadLocal#remove too > 29 сент. 2023 г., в 05:37, David Holmes <david.hol...@oracle.com> написал(а): > > On 29/09/2023 6:33 am, Егор Зиборов wrote: >> Hello, Alan >> I’ve experienced SO in ThreadLocal#set on my production instance >> (more than that it‘s happened in Spring’s ExposeInvocationInterceptor >> that uses TL as context storage)As a result of SO in ThreadLocal >> we’ve experienced unexpected errors with Spring AOP, but I’m sure >> that it could affects lots of frameworks > SOE will nearly always lead to unexpected errors, so that in itself is not > sufficient justification for trying to apply ReservedStackAccess. We added > RSA to address an insidious situation where SOE would leave ReentrantLocks in > a broken state - and we wanted ReentrantLock to be as reliable as built-in > monitor locks (or as near as feasible). So you need a very strong case to > apply RSA elsewhere. You also need to be sure that the stack needed from the > annotated method is small enough for the RSA mechanism to protect. Also note > that RSA doesn't prevent SOE it simply defers it out of the critical code > protected by SOE, so the problem is simply pushed to the caller. > > Just my 2c. > > David > >>> >>>> 28 сент. 2023 г., в 19:55, Alan Bateman <alan.bate...@oracle.com> >>>> написал(а): >>> >>> On 28/09/2023 17:21, Егор Зиборов wrote: >>>> Hello, everyone >>>> >>>> I'm new there and writing this letter during advice of Dalibor Topic >>>> >>>> I faced an issue with SOE in ThreadLocal and want to add this java9 >>>> annotation on ThreadLocal#set. Does anyone have any concerns about it? >>>> >>> This annotation is for very core/critical areas that are particularly >>> sensitive to SO. Did the SO that you observe just happen to be in >>> ThreadLocal.set or is there more to this story? Asking because there are >>> dozens places in java.base where the argument could be made but we have to >>> be very careful to not sprinkle it about. >>> >>> -Alab >>>
